Comparación de servidores web Apache y Nginx

Dos servidores, dos filosofías de diseño

Apache HTTP Server y Nginx son los dos servidores web de código abierto que con más probabilidad encontrarás en cuentas de hosting, VPS e imágenes cloud. Ambos son maduros, se mantienen activamente, son seguros si se configuran bien y pueden servir webs con muchísimo tráfico. Las diferencias están en cómo gestionan las conexiones, cómo se configuran y qué tareas facilitan.

Apache apareció a mediados de los años noventa y se convirtió en el servidor web por defecto de la primera web. Nginx nació a principios de los 2000 precisamente para gestionar de forma eficiente grandes cantidades de conexiones simultáneas, un reto conocido como el problema C10k. Ese origen sigue marcando hoy el comportamiento de cada uno.

Arquitectura: procesos, hilos y eventos

Apache y sus módulos de multiprocesamiento

Apache delega la gestión de conexiones en un módulo de multiprocesamiento (MPM):

• prefork ejecuta un proceso por conexión, sin hilos. Es muy compatible, incluso con módulos que no son thread-safe como el antiguo mod_php, pero es el que más memoria consume.
• worker ejecuta varios hilos por proceso y usa menos memoria por conexión.
• event es similar a worker, pero pasa las conexiones keep-alive inactivas a un hilo de escucha y libera los hilos de trabajo. Es el predeterminado en muchas distribuciones actuales.

Nginx y su bucle de eventos

Nginx arranca un proceso maestro y un pequeño número de procesos worker, normalmente uno por núcleo de CPU. Cada worker ejecuta un bucle de eventos no bloqueante y puede manejar miles de conexiones a la vez sin crear un hilo para cada una. El consumo de memoria se mantiene relativamente estable al aumentar la concurrencia, y por eso Nginx se hizo popular en webs de mucho tráfico, proxies inversos y balanceadores de carga.

Comparativa lado a lado

Contenido estático frente a dinámico

Para archivos estáticos como imágenes, hojas de estilo y scripts, Nginx suele ser la opción que mejor aprovecha los recursos, y su ventaja tiende a crecer a medida que aumentan las conexiones simultáneas. Apache con el MPM event reduce mucho la distancia respecto a las antiguas configuraciones prefork, así que en una web modesta la diferencia puede ser pequeña.

En el contenido dinámico, el panorama está más equilibrado. En los despliegues modernos ambos servidores suelen pasar las peticiones PHP a PHP-FPM mediante FastCGI. En ese punto el servidor web es sobre todo un enrutador de tráfico, y el tiempo de respuesta depende en gran medida de la versión de PHP, OPcache, la caché de objetos, las consultas a la base de datos y el código de la aplicación. Cambiar de servidor web rara vez arregla un plugin lento de WordPress o una tabla sin índices.

Configuración: .htaccess frente a configuración central

La diferencia que la mayoría de propietarios de webs notan primero es la configuración. Apache puede leer archivos .htaccess en cualquier directorio, lo que permite a los usuarios de hosting compartido añadir redirecciones, reglas de reescritura y controles de acceso sin tocar la configuración principal del servidor. Es cómodo, pero Apache tiene que buscar esos archivos en cada petición a lo largo de la ruta de directorios, lo que añade cierta sobrecarga, y las reglas dispersas pueden ser difíciles de auditar.

Nginx no tiene equivalente. Todas las reglas viven en la configuración del servidor, lo que es más rápido y más fácil de entender, pero exige acceso a esa configuración y una recarga tras cada cambio.

Ejemplo: redirigir HTTP a HTTPS

Apache, en un virtual host o en .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx, en el bloque server:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Ejemplo: URL amigables para una aplicación PHP

Nginx con PHP-FPM:

location / {
    try_files $uri $uri/ /index.php?$args;
}
location ~ [.]php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

La ruta del socket varía según la distribución y la versión de PHP, así que comprueba la tuya antes de copiarla.

Módulos, ecosistema y compatibilidad

El sistema de módulos es uno de los puntos fuertes de Apache. Módulos como mod_rewrite, mod_security, mod_headers y muchos de autenticación pueden activarse con un comando y cargarse sin recompilar. Muchos paneles de control de hosting, incluido cPanel, están construidos en torno a Apache o a servidores compatibles con Apache, e innumerables aplicaciones incluyen reglas .htaccess que dan por hecho Apache.

Históricamente, Nginx exigía compilar los módulos, aunque admite módulos dinámicos desde hace años y los paquetes de las distribuciones incluyen los más comunes. Su ecosistema es más fuerte en proxy, caché, limitación de peticiones y terminación TLS. Muchas aplicaciones publican ya fragmentos oficiales de configuración para Nginx junto a sus reglas de Apache.

Si gestionas servidores cPanel, nuestra guía de consejos de automatización para hosting cPanel cubre tareas de mantenimiento relacionadas.

Usar Nginx y Apache juntos

No tienes por qué elegir solo uno. Un patrón muy extendido coloca Nginx delante como proxy inverso:

• Nginx acepta todas las conexiones de los clientes, termina TLS y sirve directamente los archivos estáticos.
• Puede cachear respuestas y aplicar límites de peticiones.
• Las peticiones de páginas dinámicas se envían a Apache en un puerto local, donde las reglas .htaccess existentes siguen funcionando.

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Asegúrate de que el backend registra y confía en la IP del cliente reenviada (por ejemplo, con mod_remoteip de Apache); si no, todos los visitantes parecerán venir de 127.0.0.1. La contrapartida es una capa más que configurar, monitorizar y actualizar.

Ajuste, seguridad y mantenimiento

Ajustes que importan más que la elección

Uses el servidor que uses, unos pocos parámetros suelen influir más en la velocidad real que cambiar de software:

• Activa HTTP/2 (y HTTP/3 si tu versión y tu configuración lo admiten) para que los navegadores descarguen muchos archivos por una sola conexión.
• Comprime las respuestas de texto con gzip o Brotli. Apache usa mod_deflate o mod_brotli; Nginx usa las directivas gzip y, si está instalado, un módulo Brotli.
• Define cabeceras de caché para los recursos estáticos, de modo que los visitantes recurrentes y las CDN no los vuelvan a pedir sin necesidad.
• Dimensiona bien PHP-FPM. Muy pocos workers ponen las peticiones en cola; demasiados agotan la memoria. Basa el límite en la RAM disponible y la memoria media por proceso.
• Mantén un keep-alive razonable. Los tiempos de espera muy largos acaparan recursos, sobre todo en Apache con prefork.
• Usa el MPM de Apache adecuado. Si sigues con prefork y mod_php, pasar a event con PHP-FPM suele ser la mayor mejora que puedes hacer en Apache.

Por ejemplo, activar la compresión en Nginx solo requiere unas líneas:

gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;
gzip_min_length 1024;

Mide antes y después de cada cambio. Las herramientas que informan del tiempo hasta el primer byte y del tiempo de carga total desde varias ubicaciones te dirán si un ajuste ha servido de verdad.

Seguridad básica para ambos servidores

Ninguno de los dos es inseguro por naturaleza, y ambos proyectos publican avisos y parches de seguridad con regularidad. La mayoría de problemas reales vienen de paquetes desactualizados, rutas de administración expuestas, configuraciones TLS débiles o permisos de archivo demasiado abiertos. Buenas prácticas para los dos:

• Instala desde tu distribución o los repositorios oficiales y aplica las actualizaciones de seguridad sin demora.
• Oculta los detalles de versión (ServerTokens Prod en Apache, server_tokens off; en Nginx).
• Usa una configuración TLS moderna y automatiza la renovación de certificados.
• Prueba la configuración antes de recargar: apachectl configtest o nginx -t.
• Revisa los logs de acceso y de errores en busca de tráfico inusual, peticiones fallidas repetidas y patrones de escaneo.

La renovación automática puede fallar sin avisar, por ejemplo tras un cambio de DNS. Controlar las fechas de caducidad de certificados y hosting en el panel de hosting de TLDix te avisa antes de que los visitantes vean una advertencia del navegador.

¿Cuál deberías elegir?

Elige Apache si dependes de .htaccess, usas hosting compartido o un panel de control construido en torno a él, o ejecutas aplicaciones que dan por hecho módulos de Apache. Elige Nginx si gestionas tu propio VPS o servidor cloud, sirves mucho contenido estático o muchas conexiones simultáneas, o necesitas un proxy inverso, un balanceador de carga o una caché. Elige ambos cuando quieras la eficiencia de Nginx en primera línea sin perder la compatibilidad de Apache para una aplicación existente.

Una prueba rápida antes de decidir

Si dudas, monta ambos servidores en un VPS de pruebas con una copia de tu web y compara resultados con tu propia carga: tiempo hasta el primer byte de varias páginas, consumo de memoria con tráfico simulado y esfuerzo necesario para trasladar tus reglas de redirección. Una tarde de pruebas suele aclarar más que cualquier comparativa genérica, porque refleja tu aplicación, tus plugins y tu forma de trabajar.

¿Quieres saber qué usa una web concreta? Las cabeceras de respuesta suelen revelar el software del servidor, y la consulta de hosting de TLDix muestra el proveedor que hay detrás de un dominio. Para orientarte sobre el propio alojamiento, consulta qué es un VPS y quién lo necesita.