Nginx vs Apache: Diferencias, Rendimiento y Cuándo Usar Cada Uno [2026]

En el dinámico mundo de la administración de servidores Linux, la elección del software adecuado es un pilar fundamental para el rendimiento, la escalabilidad y la seguridad de sus aplicaciones web. Cuando se trata de servidores web, la batalla entre Nginx vs Apache es una de las más relevantes y debatidas. Ambos han dominado el panorama digital durante años, pero sus diferencias arquitectónicas los hacen adecuados para distintos propósitos y escenarios de carga. Entender las nginx apache diferencias es crucial para cualquier administrador de sistemas que busque optimizar su infraestructura.

Este artículo, actualizado a 2026, desglosará las características clave de cada servidor web Linux, examinando su arquitectura, capacidades de rendimiento, manejo de contenido estático y dinámico, y cómo impactan aspectos críticos como el SEO técnico y las Core Web Vitals. Proporcionaremos una guía clara sobre cuándo usar cada uno, con ejemplos de nginx configuración y Apache para que pueda tomar decisiones informadas para sus proyectos.

¿Qué son Nginx y Apache y por qué son cruciales para un servidor web Linux?

Antes de profundizar en las nginx apache diferencias, es esencial comprender su rol. Tanto Nginx como Apache son software de servidor web HTTP de código abierto. Su función principal es aceptar solicitudes HTTP de los clientes (navegadores web) y entregarles contenido web (páginas HTML, CSS, JavaScript, imágenes, etc.). Son la primera capa de interacción para cualquier usuario que accede a un sitio web alojado en un servidor web Linux. Apache HTTP Server, a menudo conocido simplemente como Apache, fue lanzado en 1995 y rápidamente se convirtió en el servidor web dominante, reconocido por su flexibilidad y robustez. Nginx (pronunciado "engine-x"), lanzado en 2004, fue diseñado específicamente para abordar el "problema C10k", es decir, la capacidad de manejar diez mil conexiones concurrentes o más de manera eficiente, un desafío que Apache de la época enfrentaba con dificultad.

La relevancia de estos servidores va más allá de simplemente mostrar una página. Para un analista SEO, el rendimiento del servidor impacta directamente en métricas como el Tiempo hasta el Primer Byte (TTFB) y el Largest Contentful Paint (LCP), componentes clave de las Core Web Vitals. Un servidor lento o ineficiente puede disminuir la velocidad de carga de su sitio, lo que a su vez afecta negativamente el ranking en los motores de búsqueda y la experiencia del usuario. Según Netcraft en 2025, Nginx sigue ganando terreno, alimentando aproximadamente el 35% de los sitios web más grandes, mientras que Apache mantiene una presencia significativa, especialmente en el ámbito del hosting compartido. Ambos son herramientas indispensables en la pila de software de cualquier administrador de sistemas.

Arquitectura y cómo gestionan las conexiones: Event-driven vs. Basado en procesos/hilos

La distinción fundamental entre Nginx y Apache radica en su arquitectura subyacente y cómo manejan las conexiones concurrentes. Esta diferencia es el corazón de sus respectivos puntos fuertes y debilidades. Un servidor web debe ser eficiente en la gestión de miles de solicitudes simultáneas, especialmente en sitios de alto tráfico o cuando un bot como Googlebot realiza un rastreo intensivo.

Nginx: Arquitectura asíncrona y event-driven

Nginx se basa en una arquitectura asíncrona, no-bloqueante y event-driven. Esto significa que un solo proceso "worker" de Nginx puede manejar miles de conexiones simultáneamente. Cuando una solicitud llega, Nginx no crea un nuevo proceso o hilo para esa conexión; en su lugar, utiliza un bucle de eventos para monitorear y gestionar todas las conexiones activas. Este modelo permite a Nginx manejar un gran volumen de conexiones con un consumo de recursos (CPU y RAM) significativamente menor, incluso bajo cargas elevadas. Para el SEO, esto se traduce en un TTFB excepcionalmente estable y bajo, incluso en picos de tráfico. Un servidor estable evita que Googlebot reduzca el límite de rastreo debido a errores de servidor (5xx) o alta latencia, lo que es vital para una indexación eficiente y rápida de sus contenidos.

Apache: Arquitectura basada en procesos y hilos (MPM)

Tradicionalmente, Apache utiliza una arquitectura basada en procesos o hilos, gestionada por los Módulos de Procesamiento Múltiple (MPM). Los MPM más comunes son:

• Prefork: Crea un proceso nuevo para cada conexión. Es muy estable y compatible con librerías que no son thread-safe, pero consume mucha RAM y es menos escalable para muchas conexiones.
• Worker: Utiliza múltiples procesos, y cada proceso a su vez genera múltiples hilos. Un hilo es más ligero que un proceso, lo que permite manejar más conexiones que Prefork con menos recursos.
• Event: Similar a Worker, pero está diseñado para manejar conexiones keep-alive de manera más eficiente, liberando los hilos cuando no hay datos activos en la conexión. Es el MPM más moderno y eficiente de Apache.

Bajo cargas pesadas, especialmente con MPM Prefork o Worker mal configurado, Apache tiende a consumir más RAM y CPU. Si la memoria se agota, el TTFB puede dispararse, las páginas se cargan más lento, y Googlebot podría abandonar el rastreo, impactando negativamente la indexación. Sin embargo, los MPM modernos de Apache han mejorado considerablemente su rendimiento y eficiencia, reduciendo algunas de estas desventajas históricas.

Rendimiento y consumo de recursos bajo carga

El rendimiento es, sin duda, uno de los factores más decisivos al elegir entre Nginx vs Apache, y es aquí donde la diferencia arquitectónica mencionada anteriormente se manifiesta con mayor claridad. Las pruebas de rendimiento a menudo revelan una ventaja significativa para Nginx en escenarios de alto tráfico y numerosas conexiones concurrentes.

Nginx: Eficiencia superior en conexiones y recursos

Debido a su arquitectura event-driven, Nginx es capaz de manejar un número mucho mayor de solicitudes por segundo en comparación con Apache, especialmente cuando se trata de servir contenido estático o actuar como proxy inverso. Su modelo asíncrono significa que un proceso worker puede permanecer activo mientras espera la respuesta de otra conexión, sin bloquearse. Esto se traduce en un menor consumo de memoria y CPU, incluso cuando el servidor está bajo una presión extrema. Por ejemplo, en pruebas con 10,000 conexiones concurrentes, Nginx puede usar solo una fracción de la RAM que Apache podría requerir, y su TTFB se mantiene consistentemente bajo. Esta eficiencia es invaluable para sitios web que buscan una alta escalabilidad, como plataformas de e-commerce o medios de comunicación con picos de tráfico impredecibles.

Para el SEO, el impacto es directo y positivo. Un Nginx bien configurado asegura un TTFB que rara vez excede los 100-200ms, incluso con miles de usuarios. Un LCP rápido se logra al servir eficientemente los recursos clave. Esto no solo mejora la experiencia del usuario, sino que también es un factor de ranking crucial para Google. La robustez de Nginx bajo carga significa que su sitio estará siempre disponible y responderá rápidamente, lo que reduce la tasa de rebote y mejora el "crawl budget" de Google.

Apache: Consumo más elevado, pero con flexibilidad

Apache, especialmente con MPM Prefork, tiende a consumir más recursos. Cada proceso Apache puede consumir entre 10 MB y 30 MB de RAM o más. Si su servidor necesita manejar 1000 conexiones, podría necesitar entre 10 GB y 30 GB de RAM solo para Apache. Esto lo hace menos eficiente en entornos con recursos limitados o bajo cargas masivas. Sin embargo, con los MPM Worker y Event, Apache ha mejorado significativamente su eficiencia de recursos, acercándose más a Nginx en algunos aspectos. A pesar de esto, en la mayoría de los benchmarks, Nginx aún supera a Apache en el manejo de un gran número de conexiones estáticas y en el consumo total de recursos.

La flexibilidad de Apache, especialmente su capacidad de cargar módulos en tiempo de ejecución y su configuración distribuida vía .htaccess, a menudo justifica este mayor consumo para ciertos casos de uso. Por ejemplo, en entornos de hosting compartido donde los usuarios necesitan control granular sobre sus configuraciones sin reiniciar el servidor central, la conveniencia de Apache puede superar las preocupaciones de rendimiento marginales para sitios de tráfico moderado.

Consejo: Para verificar el rendimiento de su servidor web, utilice herramientas como ApacheBench (ab) o wrk para simular carga y medir el número de solicitudes por segundo, la latencia y el uso de CPU/RAM. Esto le dará datos concretos sobre el comportamiento de Nginx vs Apache en su infraestructura.

Sirviendo contenido estático y dinámico: ¿Quién gana en qué?

La naturaleza del contenido que su servidor web principal gestiona diariamente es un factor crucial para determinar si Nginx o Apache es la mejor opción. La forma en que cada uno maneja archivos estáticos y solicitudes dinámicas define sus fortalezas específicas.

Nginx: El campeón indiscutible del contenido estático

Cuando se trata de servir archivos estáticos (HTML, CSS, JavaScript, imágenes, videos, PDFs), Nginx es el ganador indiscutible. Su arquitectura event-driven le permite servir estos archivos directamente desde el disco de manera extremadamente eficiente, a menudo hasta 2.5 veces más rápido que Apache en benchmarks de alto tráfico. Esto se debe a que Nginx minimiza la sobrecarga de cada conexión y puede manejar miles de solicitudes de archivos pequeños sin problemas. Dado que los activos estáticos son la base de su LCP y los tiempos de carga generales de la página, Nginx proporciona una ventaja inmediata en las Core Web Vitals. Un sitio web que depende en gran medida de imágenes y otros archivos estáticos, como un blog de fotografía o una galería en línea, se beneficiará enormemente de la capacidad de Nginx para entregar este contenido a gran velocidad.

Nginx no procesa contenido dinámico de forma nativa. En su lugar, actúa como un proxy inverso que pasa las solicitudes de contenido dinámico (como scripts PHP) a un procesador externo, generalmente PHP-FPM (FastCGI Process Manager). Luego, Nginx toma la respuesta de PHP-FPM y la envía al cliente. Esta separación de roles entre el servidor web y el procesador de aplicaciones es una de las razones de la eficiencia de Nginx, ya que no se carga con la lógica de la aplicación.

Apache: La flexibilidad para el contenido dinámico con .htaccess

Apache puede procesar PHP de forma nativa dentro de sus procesos de trabajo a través de módulos como mod_php. Esto simplifica la configuración para muchos desarrolladores, ya que no se requiere un procesador externo adicional como PHP-FPM. La integración nativa facilita la implementación de aplicaciones PHP, especialmente en entornos de hosting compartido donde los usuarios pueden simplemente cargar sus archivos PHP y esperar que funcionen.

Una de las características más valoradas de Apache es su soporte para archivos .htaccess. Estos archivos permiten a los usuarios sobrescribir la configuración del servidor a nivel de directorio, sin necesidad de acceder al archivo de configuración principal (httpd.conf) ni reiniciar el servidor. Esto es increíblemente conveniente para desarrolladores y entornos de hosting compartido, ya que permite controlar aspectos como redirecciones (301, 302), reescritura de URLs (mod_rewrite), protección por contraseña y configuración de cabeceras HTTP específicas para SEO o seguridad, todo de forma descentralizada. Aunque la lectura y procesamiento de .htaccess puede introducir una ligera sobrecarga de rendimiento en cada solicitud, la comodidad que ofrece a menudo supera este pequeño inconveniente para muchos casos de uso.

Roles especializados: Proxy inverso, balanceador de carga y caché

Más allá de simplemente servir páginas web, Nginx y Apache pueden asumir roles más avanzados en la arquitectura de un sistema web. Sin embargo, es en estos roles especializados donde Nginx a menudo brilla con una eficiencia y simplicidad de configuración superiores.

Nginx como proxy inverso y balanceador de carga

Nginx es ampliamente reconocido como un proxy inverso de alto rendimiento y un excelente balanceador de carga. En una configuración de proxy inverso, Nginx se sienta frente a otros servidores (servidores de aplicaciones como Apache, Gunicorn, Tomcat, etc.) y reenvía las solicitudes de los clientes a ellos. Esto ofrece varias ventajas:

• Seguridad: Nginx oculta los servidores de origen de Internet, agregando una capa de seguridad.
• Rendimiento: Puede manejar la terminación SSL/TLS y comprimir respuestas, liberando a los servidores de aplicaciones de estas tareas.
• Almacenamiento en caché: Nginx puede cachear respuestas de los servidores de backend, reduciendo la carga y mejorando los tiempos de respuesta para solicitudes repetidas.

Como balanceador de carga, Nginx puede distribuir las solicitudes entrantes entre múltiples servidores de backend, asegurando que ningún servidor se sobrecargue y que la aplicación sea altamente disponible y escalable. Sus algoritmos de balanceo de carga, como round-robin, least-connections o ip-hash, son altamente configurables y eficientes. Esta capacidad es crucial para sitios web y aplicaciones con arquitecturas distribuidas o que experimentan picos de tráfico masivos, como las plataformas de streaming o grandes tiendas en línea. La configuración de Nginx para estos roles es notablemente sencilla y declarativa, lo que facilita su implementación y mantenimiento.

Apache en roles de proxy y balanceo

Apache también puede funcionar como proxy inverso y balanceador de carga utilizando módulos como mod_proxy y mod_proxy_balancer. Si bien es capaz de realizar estas funciones, su rendimiento y eficiencia en estos roles no suelen igualar a Nginx, especialmente bajo cargas extremas. La configuración de Apache para estos propósitos puede ser más compleja y tiende a consumir más recursos que Nginx. Sin embargo, para entornos que ya utilizan Apache extensivamente, o para necesidades de proxy más simples, Apache puede ser una solución perfectamente viable.

En el contexto de la arquitectura moderna de microservicios o aplicaciones desacopladas, Nginx se ha convertido en la opción preferida para la "capa de entrada" (API Gateway) que enruta y balancea las solicitudes a diferentes servicios backend. La capacidad de Nginx para manejar la terminación SSL, la autenticación y el rate limiting lo convierte en una herramienta potente para construir arquitecturas web resilientes y de alto rendimiento.

Consejo: Considere una arquitectura híbrida donde Nginx actúe como proxy inverso y balanceador de carga, sirviendo también contenido estático, y Apache (o PHP-FPM) se encargue del procesamiento de contenido dinámico. Esta es una configuración común y muy eficiente que aprovecha los puntos fuertes de ambos.

Configuración, flexibilidad y ecosistema de módulos

La experiencia de configuración y la flexibilidad son aspectos clave para los administradores de sistemas. Tanto Nginx como Apache ofrecen una gran capacidad de personalización, pero lo hacen de maneras distintas, influenciando la facilidad de uso y la arquitectura de los proyectos.

Configuración de Nginx: Declarativa y centralizada

La nginx configuración se basa en un archivo principal (típicamente /etc/nginx/nginx.conf) y puede incluir archivos adicionales para bloques de servidor (virtual hosts) en directorios como /etc/nginx/sites-available o /etc/nginx/conf.d. La sintaxis es limpia, jerárquica y declarativa, similar a JSON o un lenguaje de configuración simple. Esto hace que las configuraciones de Nginx sean fáciles de leer, entender y mantener para un administrador experimentado.

Nginx no soporta archivos .htaccess. Todas las configuraciones deben realizarse en los archivos de configuración principales y requieren un reinicio o recarga del servicio de Nginx para que los cambios surtan efecto. Aunque esto puede parecer menos flexible para entornos de hosting compartido, asegura que Nginx opere con la máxima eficiencia, ya que no tiene que buscar y procesar archivos .htaccess en cada solicitud. Además, la ausencia de .htaccess puede ser vista como una ventaja de seguridad, ya que evita que los usuarios finales (potencialmente menos experimentados) modifiquen configuraciones críticas del servidor de forma inadvertida.

Configuración de Apache: Modular y distribuida (con .htaccess)

Apache utiliza el archivo httpd.conf como su configuración principal, complementado por archivos de configuración de módulos y Virtual Hosts (a menudo en /etc/httpd/conf.d/ o /etc/apache2/sites-available/). La configuración de Apache es altamente modular, lo que significa que la funcionalidad se añade o se elimina mediante la carga de diferentes módulos (por ejemplo, mod_rewrite para reescritura de URLs, mod_ssl para SSL/TLS). Esto permite a los administradores personalizar el servidor exactamente a sus necesidades.

La mayor diferencia, y a menudo un punto de conveniencia para muchos, es el soporte de Apache para los archivos .htaccess. Estos archivos permiten configuraciones descentralizadas por directorio, ofreciendo a los usuarios un control granular sobre sus sitios web sin acceso al archivo de configuración principal. Esto es una ventaja significativa en entornos de hosting compartido donde los usuarios no tienen privilegios de root. Sin embargo, la lectura de .htaccess en cada solicitud puede añadir una pequeña sobrecarga de rendimiento y, si no se gestionan correctamente, pueden introducir vulnerabilidades de seguridad.

Ecosistema de módulos y extensiones

El ecosistema de módulos de Apache es vasto y maduro, desarrollado durante décadas. Hay un módulo Apache para casi cualquier funcionalidad que uno pueda imaginar, desde la autenticación hasta la compresión de contenido. Esta riqueza de módulos es una de las principales razones por las que Apache sigue siendo popular. Nginx, aunque más joven, tiene un creciente ecosistema de módulos de terceros y muchas funcionalidades que en Apache serían un módulo, en Nginx vienen integradas o se resuelven con directivas de configuración.

Tabla comparativa: Nginx vs Apache, un vistazo rápido [2026]

Para resumir las principales nginx apache diferencias, presentamos una tabla comparativa que destaca sus características clave a partir de 2026.

Característica	Nginx	Apache HTTP Server
Arquitectura	Asíncrona, no-bloqueante, event-driven	Basada en procesos/hilos (MPM: Prefork, Worker, Event)
Manejo de conexiones	Altamente eficiente, miles de conexiones con pocos procesos.	Depende del MPM; Prefork menos eficiente, Event más cercano a Nginx.
Rendimiento estático	Superior (2.5x más rápido en benchmarks de alto tráfico).	Bueno, pero generalmente superado por Nginx.
Rendimiento dinámico (PHP)	Requiere un procesador externo (PHP-FPM), muy eficiente.	Puede procesar PHP internamente (mod_php) o externamente (FPM).
Uso de memoria/CPU	Bajo, muy eficiente bajo carga.	Más alto que Nginx, especialmente con Prefork. Mejorado con Event.
Archivos .htaccess	No compatible. Configuración centralizada.	Sí compatible. Configuración distribuida por directorio.
Proxy inverso/Balanceador de carga	Excelente, considerado líder en el mercado.	Capaz, pero Nginx suele ser preferido por eficiencia.
Configuración	Sintaxis declarativa, más compacta y fácil de leer.	Sintaxis modular, más verbosa.
Curva de aprendizaje	Puede ser un poco más pronunciada inicialmente para nuevos conceptos.	Más suave para principiantes debido a su omnipresencia y .htaccess.
Casos de uso ideales	Sitios de alto tráfico, CDN, microservicios, API Gateway.	Hosting compartido, aplicaciones PHP legacy, setups sencillos.
Cuota de mercado (Netcraft 2025)	Dominante en los sitios de alto tráfico (aprox. 35% de los top).	Presencia significativa, especialmente en hosting compartido.

Cuándo usar Nginx y cuándo Apache: Casos de uso específicos [2026]

La elección entre Nginx y Apache no es una cuestión de cuál es "mejor" en general, sino de cuál es "mejor" para un escenario específico. Ambos servidores web son herramientas poderosas, y comprender sus fortalezas permite tomar decisiones informadas que optimicen el rendimiento, la escalabilidad y la gestión de sus aplicaciones web.

Cuándo elegir Nginx

• Sitios de alto tráfico y escalabilidad: Si su sitio web o aplicación espera un gran volumen de usuarios simultáneos o picos de tráfico impredecibles, Nginx es la elección superior. Su arquitectura event-driven le permite manejar miles de conexiones con un consumo mínimo de recursos, asegurando un TTFB bajo y consistente.
• Servicio de contenido estático: Para sitios ricos en imágenes, videos, CSS y JavaScript (como portafolios, galerías de fotos, o sitios de noticias con mucho contenido multimedia), Nginx entregará estos archivos mucho más rápido que Apache, mejorando directamente las Core Web Vitals.
• Proxy inverso y balanceador de carga: Nginx es la opción preferida para actuar como la capa frontal de su infraestructura, distribuyendo solicitudes entre múltiples servidores de aplicaciones, proporcionando caché HTTP, o sirviendo como API Gateway en arquitecturas de microservicios.
• CDN (Content Delivery Network) origen: Si está construyendo o utilizando una CDN, Nginx es un excelente servidor de origen debido a su eficiencia y capacidad de caché.
• Servidores con recursos limitados: En VPS o máquinas virtuales con poca RAM y CPU, Nginx optimiza el uso de recursos al máximo.

Cuándo elegir Apache

• Hosting compartido y configuraciones fáciles: Para proveedores de hosting que necesitan ofrecer a sus usuarios control sobre las configuraciones a través de .htaccess, Apache es insuperable. Es más fácil de configurar para que los clientes gestionen redirecciones, reescrituras de URLs y otras directivas sin necesitar acceso al archivo principal del servidor.
• Aplicaciones PHP "legacy" o basadas en mod_php: Muchas aplicaciones PHP más antiguas o entornos que dependen de mod_php para la integración directa con el servidor web funcionarán sin problemas con Apache.
• Curva de aprendizaje más suave para principiantes: Para quienes se inician en la administración de servidores, la abundancia de documentación, tutoriales y la facilidad de uso de .htaccess pueden hacer que Apache sea una opción más accesible al principio.
• Sitios web de tráfico moderado a bajo: Si su sitio no tiene requisitos extremos de rendimiento y el tráfico es predecible y moderado, Apache puede ser una solución robusta y fácil de gestionar.
• Entornos donde se necesita una gran cantidad de módulos específicos: El amplio ecosistema de módulos de Apache puede ser un factor decisivo si su aplicación requiere una funcionalidad muy específica que ya está disponible como módulo Apache.

En muchos casos modernos, la mejor solución es una arquitectura híbrida: Nginx actúa como proxy inverso y servidor de contenido estático en el frontend, y pasa las solicitudes dinámicas a Apache (o PHP-FPM) en el backend. Esta configuración aprovecha las fortalezas de ambos, ofreciendo una combinación óptima de rendimiento, flexibilidad y escalabilidad.

Ejemplos de configuración básica para un Virtual Host

Para ilustrar las nginx apache diferencias en la configuración, veamos ejemplos básicos de cómo configurar un Virtual Host (o Server Block en Nginx) para un sitio web simple.

Configuración de Virtual Host en Nginx (Server Block)

En Nginx, las configuraciones de los sitios se suelen guardar en archivos separados dentro de /etc/nginx/sites-available/ y luego se enlazan simbólicamente a /etc/nginx/sites-enabled/. Aquí un ejemplo para example.com:

# /etc/nginx/sites-available/example.com
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example.com/html;
    index index.html index.htm index.nginx-debian.html;

    location / {
        try_files $uri $uri/ =404;
    }

    # Para servir PHP, se proxy a PHP-FPM
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock; # Asegúrese de que el socket coincida con su versión de PHP-FPM
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # Opcional: Bloquear el acceso a archivos .htaccess si estuvieran presentes
    location ~ /\.ht {
        deny all;
    }
}

Después de crear este archivo, lo activaría con un enlace simbólico y probaría la configuración:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Este ejemplo muestra cómo Nginx maneja las solicitudes de forma directa para archivos estáticos (`root`, `location /`) y cómo las pasa a PHP-FPM para archivos dinámicos (`location ~ \.php$`).

Configuración de Virtual Host en Apache

En Apache, las configuraciones de Virtual Hosts se suelen guardar en archivos dentro de /etc/apache2/sites-available/ (Debian/Ubuntu) o /etc/httpd/conf.d/ (CentOS/RHEL). Aquí un ejemplo para example.com:

# /etc/apache2/sites-available/example.com.conf
<VirtualHost *:80>
    ServerAdmin webmaster@example.com
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com/html

    <Directory /var/www/example.com/html>
        Options Indexes FollowSymLinks
        AllowOverride All  # Habilita el procesamiento de archivos .htaccess
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    # Para PHP, si usa mod_php, no necesita configuración adicional aquí.
    # Si usa PHP-FPM con Apache (mod_proxy_fcgi), la configuración sería:
    # <FilesMatch \.php$>
    #    SetHandler "proxy:unix:/var/run/php/php8.1-fpm.sock|fcgi://localhost/"
    # </FilesMatch>
</VirtualHost>

Para activar este Virtual Host en Debian/Ubuntu:

sudo a2ensite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

En este ejemplo de Apache, `DocumentRoot` define la raíz del sitio, y `AllowOverride All` habilita el uso de archivos `.htaccess` dentro de ese directorio, otorgando gran flexibilidad a nivel de directorio.