Nginx y Apache siguen siendo los dos servidores web más usados de la web pública. La elección entre uno y otro raramente es de «el mejor»: depende del tipo de contenido (estático vs dinámico), del nivel de tráfico esperado y del stack que ya tienes en producción. La respuesta corta, la que aplicamos nosotros a diario: para proyectos nuevos o con tráfico alto, Nginx como servidor web y proxy inverso; para parques heredados que dependen de .htaccess, Apache detrás de Nginx; y migrar de uno a otro solo cuando hay un problema real medido, nunca por moda. La diferencia práctica entre ambos casi nunca está donde la sitúan los rankings, sino en dos sitios muy concretos: cómo consumen memoria bajo miles de conexiones simultáneas y cuánto cuesta operarlos con el software que ya tienes.
En esta guía repasamos las diferencias de arquitectura, qué órdenes de magnitud son consistentes bajo carga y cómo decidir cuál usar (o cuándo combinarlos).
Arquitectura: ¿por qué importan los procesos?
Importan porque determinan cuánta memoria consume cada visitante concurrente, y esa es la variable que tumba servidores en picos de tráfico. Apache usa un modelo de proceso/hilo por conexión (MPM prefork o worker): cada petición consume su propio proceso o hilo, y con PHP embebido (mod_php) cada proceso arrastra además el intérprete completo, decenas de MB por conexión. Bajo alta concurrencia el consumo crece linealmente hasta agotar la RAM, y el servidor empieza a matar procesos o a encolar visitantes. Nginx usa un modelo asíncrono basado en eventos: un puñado de workers (normalmente uno por núcleo) atiende miles de conexiones concurrentes con un consumo de memoria casi plano, porque ninguna conexión bloquea un hilo propio. Esta diferencia estructural explica la mayoría de los benchmarks públicos: no es que Nginx «sea más rápido» procesando una petición suelta, es que degrada muchísimo mejor cuando las conexiones se cuentan por miles.
La ventaja histórica de Apache está en otro plano: la flexibilidad de configuración por directorio (.htaccess) y un ecosistema de módulos muy amplio, que es lo que el hosting compartido y buena parte del software PHP llevan veinte años asumiendo.
Rendimiento real bajo carga
Lo que se observa de forma consistente, tanto en benchmarks públicos (TechEmpower, pruebas con wrk o k6) como en los servidores que operamos:
- Contenido estático con miles de conexiones concurrentes: Nginx mantiene latencias estables con un consumo de memoria casi constante; Apache (incluso con MPM event) muestra más jitter y un consumo que crece con la concurrencia.
- Contenido dinámico (PHP-FPM, Python, Ruby): la diferencia se diluye porque el cuello de botella es el procesador de aplicación y la base de datos, no el servidor web. Con PHP-FPM bien dimensionado, la elección de servidor web apenas mueve la aguja.
- Reverse proxy: Nginx es la opción habitual por su modelo de eventos y su sintaxis para upstreams. Apache puede hacerlo con
mod_proxy, pero requiere más configuración para el mismo resultado.
Un caso tipo que vemos con frecuencia al auditar servidores ajenos: WordPress sobre Apache con mod_php y KeepAlive activo, que funciona perfectamente a 50 visitantes y se ahoga a 500 —no por CPU, sino porque cada conexión abierta retiene un proceso de decenas de MB y la RAM se agota—. La solución casi nunca es «más servidor»: es poner Nginx delante sirviendo los estáticos y pasar PHP a FPM. El mismo hardware pasa de ahogarse a ir sobrado, sin tocar la aplicación.
Si tu carga está dominada por backend lento, optimizar Nginx vs Apache aporta poco. El gain está en cachear, en el balanceador o en la base de datos.
¿Cuándo elegir cada uno?
Elige Nginx si:
- Sirves contenido estático con tráfico alto (CDN propio, sitios con muchas conexiones cortas).
- Necesitas un reverse proxy o load balancer delante de aplicaciones.
- Quieres terminar TLS de forma eficiente delante de un backend.
- Trabajas con microservicios o contenedores y necesitas routing flexible.
Elige Apache si:
- Dependes de
.htaccess(típico en hosting compartido WordPress legacy). - Usas módulos específicos solo disponibles en Apache (
mod_securityhistóricamente, aunque Nginx tiene equivalentes). - Necesitas configuración por directorio que distintos usuarios puedan modificar sin recargar el servidor.
- Tu stack ya está estable en Apache y no hay problema real de rendimiento.
Combinación habitual en producción: Nginx delante como reverse proxy y terminador TLS; Apache detrás sirviendo PHP-FPM. Captura lo mejor de ambos.
Tabla resumen
| Aspecto | Nginx | Apache |
|---|---|---|
| Modelo de concurrencia | Asíncrono, basado en eventos | Proceso/hilo por conexión |
| Memoria bajo alta concurrencia | Casi constante | Crece con las conexiones |
| Contenido estático bajo carga | Excelente | Bueno |
| Configuración por directorio | No (.htaccess no soportado) |
Sí |
| Reverse proxy / load balancer | Nativo, sintaxis directa | Posible con mod_proxy |
| Curva de aprendizaje | Más concisa | Más documentación legacy |
| Ecosistema de módulos | Más limitado | Muy amplio |
Qué usamos nosotros (y por qué)
En los servidores de aplicación que montamos a medida, la elección por defecto es Nginx: como servidor web para estáticos, como proxy inverso delante de la aplicación y como terminador TLS. Su modelo de eventos rinde más con menos memoria en los escenarios que más gestionamos (webs con picos de tráfico y muchas conexiones concurrentes).
Pero no somos talibanes de una opción: en plataformas de hosting gestionado es habitual —y sensato— que convivan los dos, con Nginx delante sirviendo estáticos y haciendo de proxy, y Apache detrás por compatibilidad con .htaccess y con aplicaciones que lo esperan (WordPress y compañía). Esa combinación da el rendimiento de Nginx sin romper el ecosistema de Apache, y es la que más veces acabamos operando en la práctica.
Nuestra regla corta: proyecto nuevo o alto tráfico, Nginx; parque heredado con dependencia de .htaccess, Apache detrás de Nginx; migrar de uno a otro solo cuando hay un problema real que lo justifique, no por moda. Y antes de migrar nada, medir: más de una vez el «problema de Apache» que nos piden resolver resulta ser una base de datos sin índices o una aplicación sin caché, y cambiar de servidor web no habría arreglado nada.
¿Te ayudamos a decidir?
La decisión entre Nginx, Apache o una combinación de ambos depende del stack que ya tienes, del tipo de tráfico y de qué partes son cuello de botella real. En Elimática auditamos arquitecturas web y proponemos cambios con impacto medible.
Revisa nuestro servicio de servidores gestionados o pide un diagnóstico gratuito.