Apache vs nginx: en qué se diferencian y cómo traducir la configuración
Apache vs nginx
Apache vs nginx: procesos, .htaccess y traducción de config | We.Inc
Apache vs nginx comparados en cómo gestionan las conexiones, .htaccess por directorio frente a configuración central, recargas y proxy, con un traductor de reglas de reescritura comunes.
Ambos son servidores web de código abierto maduros. Apache carga módulos sobre un modelo de procesos a elegir (prefork, worker o event) y deja que cada directorio sobrescriba ajustes con archivos .htaccess. nginx ejecuta un proceso maestro y unos pocos workers basados en eventos, solo lee su configuración central y suele colocarse delante de servidores de aplicaciones como proxy inverso.
Apache y nginx lado a lado
Tema
Apache httpd 2.4
Gestión de conexiones
Elige un MPM: prefork, worker o event (event es el valor por defecto habitual en Unix moderno)
Un proceso maestro más procesos worker con un modelo basado en eventos
Configuración por directorio
Archivos .htaccess, si AllowOverride lo permite (por defecto None)
Ninguna: todo vive en los archivos de configuración principales
upstream: round robin, least_conn, ip_hash, hash, random
Probar y recargar
apachectl configtest y después apachectl graceful
nginx -t y después nginx -s reload
Elegir entre ellos depende sobre todo de dónde vive la configuración y de quién puede cambiarla. Esta página omite las cifras de benchmarks, que dependen por completo de la carga de trabajo y del ajuste, y se centra en las diferencias que encuentras al mantener un sitio: cómo gestiona cada servidor las conexiones, por qué existe .htaccess y cómo se traducen las reglas de reescritura que ya tienes. Usa el traductor para ver la versión nginx de una regla de Apache conocida.
Elige una tarea en el traductor, como forzar HTTPS o enviar cada ruta desconocida a index.html.
Escribe tu propio dominio para que ambas versiones queden listas para pegar.
Pon la versión de Apache en el virtual host o en .htaccess, o la versión de nginx dentro del bloque server correspondiente.
Prueba antes de recargar: apachectl configtest para Apache, nginx -t para nginx.
En Apache, prefiere la configuración principal del servidor a .htaccess cuando controlas la máquina. La documentación de Apache lo dice claramente, porque permitir .htaccess hace que httpd busque el archivo en cada directorio de la ruta de cada petición.
En nginx, un bloque if que comprueba el host casi siempre queda mejor como un bloque server aparte con return 301.
Sustituye las cadenas de comprobaciones de archivos con RewriteCond por una sola línea try_files; nginx comprueba las rutas indicadas en orden.
Recuerda que las líneas add_header de nginx no se heredan en un bloque que define su propio add_header. Repite las cabeceras de seguridad en cada location que establezca alguna cabecera.
Usar los dos es habitual: nginx en el borde para TLS y archivos estáticos, haciendo de proxy de las peticiones dinámicas hacia Apache en un puerto local.
Preguntas frecuentes
¿Es nginx más rápido que Apache?
Depende de la tarea y del ajuste, así que desconfía de cualquier cifra aislada. Los workers de nginx basados en eventos están diseñados para mantener muchas conexiones inactivas con poco coste. El MPM event de Apache redujo esa diferencia usando también sondeo seguro para hilos. Mide tu propia carga de trabajo antes de cambiar solo por velocidad.
¿nginx admite archivos .htaccess?
No. nginx no tiene archivos de sobrescritura por directorio, así que las reglas de un .htaccess deben pasarse a la configuración del servidor y recargar nginx. Es un intercambio deliberado: no hay búsquedas de archivos en cada petición, pero solo quien tiene acceso a la configuración principal puede cambiar las reglas.
¿Puedo convertir .htaccess a nginx automáticamente?
Las redirecciones y los fallbacks sencillos se traducen sin problemas, como muestra el traductor de esta página. Las cadenas largas de RewriteCond con flags como [P] o variables de entorno necesitan que alguien las lea, porque nginx expresa la misma intención con piezas distintas.
¿Cuál elijo para un sitio WordPress o PHP?
Si tu hosting solo te da acceso a archivos, Apache con .htaccess es lo único que te permite cambiar reglas. En un servidor que controlas, cualquiera de los dos funciona con PHP-FPM; en nginx escribes el fallback de URL amigables una sola vez con try_files en el bloque server.
¿Cómo recargo la configuración sin cortar conexiones?
En nginx, ejecuta nginx -s reload: el maestro comprueba la nueva configuración, arranca workers nuevos y pide a los antiguos que terminen de forma ordenada. En Apache, apachectl graceful hace lo equivalente con sus procesos hijo.
Los modelos de procesos en lenguaje sencillo
Apache delega la gestión de conexiones en un Multi-Processing Module. prefork usa un proceso por conexión y no necesita hilos. worker ejecuta varios procesos con muchos hilos cada uno. event se basa en worker y usa sondeo seguro para hilos para que las conexiones keep-alive inactivas no ocupen un hilo. En los sistemas Linux y BSD actuales, event se elige por defecto.
nginx tiene un proceso maestro que lee la configuración y gestiona los workers, y un pequeño número de procesos worker que gestionan cada uno muchas conexiones mediante un bucle de eventos.
Por qué importa .htaccess
.htaccess permite que alguien sin acceso root cambie las reglas de un directorio, y por eso los hostings compartidos dependen de él. El precio es que cada petición obliga a Apache a buscar el archivo en cada directorio padre, aunque no exista ninguno. Con AllowOverride None, que es el valor por defecto, esos archivos se ignoran por completo.
El mismo sitio en ambos servidores
Virtual host de Apache
Archivos estáticos desde una carpeta más un fallback para SPA, configurado en el vhost para no necesitar .htaccess.
Bloque server de nginx
El mismo comportamiento: carpeta raíz, fallback con try_files y una página de error personalizada.
Forzar HTTPS
Apache comprueba el flag HTTPS; nginx usa un server aparte en el puerto 80 que solo redirige.
Enviar el dominio sin www a www
La documentación de nginx recomienda un bloque server dedicado con return en lugar de un if sobre el host.
Fallback para aplicaciones de una sola página
Sirve los archivos reales cuando existen e index.html para cualquier otra ruta.
Redirigir una página antigua
Redirect de mod_alias no necesita el motor de reescritura; nginx coincide con la ruta exacta mediante location =.
Página 404 personalizada
Ambos apuntan el error a una página del mismo sitio.
Proxy de /api hacia un servidor de aplicaciones
Apache necesita mod_proxy y mod_proxy_http cargados, con barras finales coincidentes en ambos argumentos; el proxy de nginx viene integrado.
Bloquear archivos ocultos como .git
Evita que se sirvan archivos cuyo nombre empieza por un punto.
Añadir una cabecera de seguridad
Con always, ambos servidores añaden la cabecera también a las respuestas de error, no solo a las correctas.