Apache vs. NGINX: ¿qué servidor web es el mejor para WordPress?

Si ejecutas WordPress en tu propio VPS, tanto Apache como NGINX pueden servir bien el sitio, pero asumen compromisos distintos. NGINX suele ser la mejor opción por defecto para alta concurrencia, entrega de archivos estáticos y HTTP/3 opcional. Apache es más sencillo cuando tu stack de WordPress depende de .htaccess o de módulos propios de Apache.

Esta comparación entre Apache y NGINX se centra en las diferencias que importan para WordPress: arquitectura, gestión de PHP, configuración, HTTP/3 y si vale la pena la complejidad añadida de ejecutar ambos. LiteSpeed y Caddy quedan fuera del alcance.

Respuesta corta: para un VPS de WordPress autogestionado, elige NGINX por defecto. Elige Apache si tu sitio o tus plugins dependen mucho de .htaccess. Ejecuta ambos solo cuando necesites NGINX por delante sin renunciar a la compatibilidad con Apache.

¿Qué es Apache?

Apache es un software de servidor web de código abierto muy usado, desarrollado y mantenido por la organización estadounidense sin ánimo de lucro Apache Software Foundation (ASF). También se le conoce como Apache HTTP Server y HTTPD.

La página de descargas de Apache indica que la versión estable actual es la 2.4.68, publicada en junio de 2026.

Apache HTTP Server es un servidor de código abierto modular con soporte maduro para reglas .htaccess por directorio, varios módulos de multiprocesamiento (MPM), proxy inverso, reescritura de URL, TLS y módulos cargados de forma dinámica. Para WordPress, su mayor ventaja práctica es la compatibilidad de configuración, no la velocidad bruta.

Las funciones de Apache que más pesan en esta comparación son sus MPM prefork, worker y event; .htaccess; HTTP/2; el proxy inverso y el balanceo de carga; el soporte de FastCGI; los módulos dinámicos; la reescritura de URL; y TLS.

¿Qué es NGINX?

NGINX («engine x») es un servidor web de código abierto, proxy inverso, caché de contenido, balanceador de carga, proxy TCP/UDP y proxy de correo, escrito originalmente por Igor Sysoev. Sus procesos worker usan un modelo basado en eventos, pensado para atender muchas conexiones simultáneas con poco coste por conexión.

La página de descargas de NGINX lists the 1.30.x stable branch and the 1.31.x mainline branch.

Apache vs. NGINX: diferencias clave para WordPress

Apache y NGINX se diferencian sobre todo en cómo gestionan las conexiones, la configuración, PHP y el soporte de protocolos. El comportamiento de Apache depende mucho del MPM que use, mientras que NGINX emplea procesos worker basados en eventos.

Apache vs. NGINX: arquitectura

El modelo de peticiones de Apache depende del MPM que uses. Prefork se basa en procesos, mientras que worker y event usan hilos. NGINX emplea procesos worker construidos alrededor de bucles de eventos. Por eso la comparación habitual de «Apache orientado a procesos frente a NGINX orientado a eventos» resulta demasiado simplista para una instalación actual de Apache 2.4.

El MPM event de Apache puede pasar las conexiones keep-alive inactivas a su hilo listener en lugar de bloquear un hilo worker por cada conexión. NGINX sigue teniendo, por lo general, menos coste por conexión cuando hay muchísimas conexiones simultáneas, pero la distancia arquitectónica es mucho menor de lo que sugieren las viejas comparaciones de la época de prefork.

Apache vs. NGINX: rendimiento

La ventaja de rendimiento de NGINX aparece sobre todo con alta concurrencia y cargas de archivos estáticos. Sus workers basados en eventos pueden mantener muchas conexiones abiertas con un coste por conexión relativamente bajo. El MPM event de Apache reduce bastante esa distancia frente a las configuraciones prefork más antiguas.

Las peticiones dinámicas de WordPress son otra historia. NGINX suele pasar PHP a FastCGI, normalmente PHP-FPM. Apache también puede usar PHP-FPM a través de FastCGI, o ejecutar PHP mediante un módulo de Apache.

En cuanto PHP empieza a ejecutar WordPress, el código de los plugins, las consultas a la base de datos, la caché de objetos o de páginas y el dimensionado de los workers de PHP pueden pesar más que el servidor web que está delante. Si un plugin lanza una docena de consultas costosas por petición, cambiar de Apache a NGINX no arreglará el problema de fondo.

Apache vs. NGINX: soporte de HTTP/3 y QUIC

HTTP/3 es la versión actual del protocolo y funciona sobre QUIC en lugar de TCP. Que tu sitio pueda ofrecerlo depende del servidor web que tenga delante, y este es el único punto de la comparación donde los dos servidores no están cerca.

NGINX incluye un módulo HTTP/3 desde la versión 1.25.0. No se compila por defecto y la compilación necesita el parámetro --with-http_v3_module.

La documentación del módulo HTTP/3 de NGINX sigue describiendo el módulo como «experimental, caveat emptor applies».

Apache 2.4 no incluye ningún módulo nativo de HTTP/3 ni de QUIC; su soporte de protocolos se detiene en mod_http2.

La consecuencia práctica para el dueño de un sitio: una instalación estándar de Apache 2.4 no ofrece HTTP/3. En producción, la opción viable sigue siendo terminar HTTP/3 en un proxy inverso o una CDN compatible situados delante de Apache. Si quieres el protocolo, una opción es poner NGINX delante de Apache y dejar que NGINX termine las conexiones de los clientes, la disposición que se explica más abajo.

Apache vs. NGINX: seguridad

Ni Apache ni NGINX es categóricamente «más seguro». Los dos son proyectos maduros con mantenimiento de seguridad activo, y la seguridad de un despliegue en producción depende más de los parches, los módulos activados, la configuración TLS, los controles de acceso, los límites de tasa y la aplicación que hay detrás del servidor.

La comparación útil es la de superficie de ataque y configuración, no la de un ganador absoluto. Desactiva los módulos y endpoints que no necesites, mantén el servidor parcheado y refuerza el stack de WordPress que está detrás.

Apache vs. NGINX: configuración

Los archivos .htaccess por directorio de Apache funcionan siempre que AllowOverride lo permita. Eso resulta útil para WordPress, porque las reglas de reescritura se pueden cambiar sin tocar la configuración global del servidor.

Esa comodidad tiene un coste. La propia documentación de Apache recomienda poner las reglas en la configuración principal del servidor cuando tienes acceso root: los archivos .htaccess se comprueban durante las peticiones, y habilitarlos añade consideraciones tanto de rendimiento como de seguridad.

NGINX no tiene equivalente de .htaccess. Su configuración es centralizada, así que WordPress no puede escribir por ti reglas de reescritura a nivel de servidor. Las reglas de enlaces permanentes y las directivas de servidor propias de cada plugin las tiene que añadir un administrador a la configuración de NGINX y luego recargarla.

Apache vs. NGINX: módulos y extensibilidad

Apache tiene un soporte maduro de objetos compartidos dinámicos (DSO): los módulos se pueden compilar por separado y cargar con LoadModule. NGINX también admite módulos dinámicos mediante load_module, pero la compatibilidad binaria con la versión de NGINX instalada y su configuración de compilación pesa más cuando usas módulos de terceros poco habituales.

Por eso Apache lleva ventaja si dependes de módulos de terceros poco comunes. Para el hosting de WordPress habitual, esa diferencia suele importar menos que .htaccess, la gestión de PHP y las herramientas que ya usas.

Apache vs. NGINX: soporte de plataformas

Apache funciona en Linux, Windows, macOS y muchos sistemas tipo Unix. NGINX también está disponible en las principales plataformas, pero su compilación nativa para Windows tiene limitaciones importantes. NGINX sigue calificando la versión de Windows como beta, advierte de que no hay que esperar alto rendimiento ni escalado, señala que solo un worker hace el trabajo de verdad y no admite UDP ni QUIC. Para desplegar NGINX en producción, un sistema tipo Unix es la opción práctica.

Apache vs. NGINX: gestión de peticiones

Apache normalmente traduce la URL de una petición a una ruta del sistema de archivos bajo DocumentRoot, aunque su sistema de configuración también puede aplicar ubicaciones basadas en el URI, reescrituras y reglas de proxy. NGINX elige primero un bloque server y después un bloque location, sobre todo a partir del URI de la petición, antes de decidir si sirve un archivo o pasa la petición al backend.

Esa diferencia cambia cómo escribes la configuración, pero por sí sola no demuestra que NGINX transfiera datos más rápido.

Comparativa rápida entre NGINX y Apache

Así quedan los dos servidores en los ejes anteriores, más el soporte de protocolos y la versión actual de cada uno.

Usar Apache y NGINX juntos

Sí, puedes ejecutar los dos. Un diseño híbrido habitual pone NGINX delante como proxy inverso de cara al cliente y Apache detrás. NGINX puede terminar TLS y HTTP/2, y puede terminar HTTP/3 cuando su módulo HTTP/3 experimental está compilado y activado. También puede servir él mismo ciertos archivos estáticos mientras pasa las peticiones de aplicación a Apache.

La advertencia importante es de quién son las reglas. Una petición que NGINX sirve directamente nunca llega a Apache, así que las reglas .htaccess de Apache no se le aplican. Las dos configuraciones tienen que coincidir en reescrituras, caché, reenvío de la IP del cliente, comportamiento de TLS y en qué servidor manda en cada ruta.

El coste es que ahora tienes dos servidores web en marcha. Dos configuraciones que deben concordar entre sí, dos ciclos de actualización que seguir y un sitio más donde mirar cuando una petición devuelve algo raro. En un único sitio pequeño ese sobrecoste suele superar al beneficio; empieza a compensar cuando quieres HTTP/3 o entrega estática más rápida sin renunciar al comportamiento .htaccess del que dependen tus plugins.

¿NGINX es más fácil que Apache?

Ninguno es más fácil de forma universal. NGINX lo es si prefieres una configuración centralizada y te manejas bien editando bloques server. Apache lo es cuando WordPress o los plugins de terceros esperan reglas .htaccess, porque esas reglas funcionan a nivel de directorio sin tocar la configuración global del servidor.

En un servidor que controlas, «más fácil» se reduce sobre todo a qué modelo de configuración espera ya tu stack.

¿Cuándo usar Apache en lugar de NGINX?

Elige Apache cuando tu stack de WordPress dependa de .htaccess, cuando los plugins o las herramientas del panel de control esperen directivas de reescritura de Apache, o cuando necesites un módulo concreto de Apache. También es razonable dejar Apache en un sitio que ya va bien: cambiar de servidor web por una ganancia teórica en un benchmark rara vez compensa la interrupción.

¿Cuándo usar NGINX en lugar de Apache?

Elige NGINX cuando esperes muchas conexiones simultáneas, quieras una capa sólida de archivos estáticos o de proxy inverso, prefieras una configuración centralizada, o quieras tener la opción de activar HTTP/3. En WordPress, la contrapartida es que las reglas de reescritura y las directivas de servidor propias de cada plugin pasan a ser tarea del administrador en vez de algo que WordPress pueda escribir en .htaccess.

NGINX vs Apache: ¿cuál es el mejor servidor web para WordPress?

Usa NGINX. Para un sitio WordPress en un servidor que controlas, es la mejor opción por defecto: poco coste por conexión con alta concurrencia, entrega eficiente de archivos estáticos y HTTP/3 disponible si lo quieres.

La excepción es .htaccess, y pesa. WordPress puede escribir reglas de reescritura de Apache cuando .htaccess está activado, pero no puede modificar la configuración de servidor de NGINX. Si un plugin espera directivas de reescritura, de seguridad o de caché, necesitas sus instrucciones para NGINX o una regla equivalente en el bloque server, y luego recargar NGINX. Si no quieres esa responsabilidad operativa, Apache es la opción WordPress más sencilla. En un sitio con tráfico normal, es más probable que limiten el rendimiento PHP, la base de datos y el cacheo que el propio servidor web.

Bajo todo esto hay un supuesto: el servidor tiene que ser tuyo y poder cambiarse. En un hosting WordPress gestionado, el servidor web lo decide el proveedor, y la respuesta a esta pregunta es sencillamente lo que ya tenga en marcha. Esta comparación es para alguien con acceso root en su propia máquina.

¿Cómo comprobar si estás usando Apache o NGINX?

Si es tu propio VPS, comprueba directamente los servicios en ejecución:

systemctl status nginx
systemctl status apache2   # Debian/Ubuntu
systemctl status httpd     # RHEL/Fedora-family systems

En un sitio ajeno que no controlas, la cabecera de respuesta HTTP Server puede ser una pista, pero no es concluyente. Un proxy inverso o una CDN pueden exponer su propio software de servidor en lugar del del origen, y además la cabecera se puede ocultar o cambiar.

Alojar Apache o NGINX en un VPS

Si el VPS es tuyo, los dos servidores son sencillos de poner en marcha. Dimensiona la máquina para todo el stack de WordPress, no solo para Apache o NGINX: los workers de PHP, la base de datos, el cacheo, el tráfico y las tareas en segundo plano suelen consumir más recursos que el propio servidor web.

Elijas el servidor que elijas, la configuración, las actualizaciones, TLS, las copias de seguridad y la monitorización son cosa tuya. Ejecutar los dos añade una configuración y una vía de actualización más, así que usa el montaje híbrido solo si tienes un motivo concreto.

El VPS NGINX de Cloudzy es un VPS Linux autogestionado con acceso root completo, así que la configuración del servidor sigue siendo tuya.

La imagen de Apache HTTP Server de nuestro marketplace se instala igual, con un clic, así que levantar cualquiera de los dos servidores, o ambos, no empieza compilando desde el código fuente.

LEER

Caddy vs Nginx en un VPS: la comparación de archivos de configuración

Preguntas frecuentes

¿Apache es mejor que NGINX?

Ninguno es mejor de forma universal. NGINX suele ser la opción por defecto más sólida cuando te importa la alta concurrencia, la entrega de archivos estáticos, el proxy inverso o HTTP/3. Apache suele ser más fácil cuando tu stack de WordPress depende de .htaccess o de módulos propios de Apache.

¿Por qué NGINX es más rápido que Apache?

NGINX puede atender muchas conexiones dentro del bucle de eventos de cada worker, lo que mantiene bajo el coste por conexión con alta concurrencia. El MPM event de Apache también gestiona conexiones de forma asíncrona, así que la diferencia es menor de lo que sugieren las viejas comparaciones con prefork. En WordPress, PHP, las consultas a la base de datos y el cacheo pueden pesar más que la diferencia entre servidores web.

¿Debería usar Apache o NGINX para WordPress?

Para un VPS de WordPress autogestionado, NGINX es una opción por defecto muy válida si te manejas gestionando tú mismo las reglas de los bloques server. Elige Apache si te apoyas en .htaccess o en plugins que esperan reglas de reescritura de Apache y quieres que funcionen con menos configuración manual del servidor.

¿Por qué NGINX es tan popular?

NGINX combina un procesamiento eficiente de peticiones con alta concurrencia con proxy inverso, balanceo de carga, caché, soporte de FastCGI y terminación TLS. Eso lo hace útil tanto como servidor web principal como en forma de proxy frontal.

¿Por qué se sigue usando Apache?

Apache sigue muy extendido por su ecosistema de módulos, el soporte de .htaccess, sus herramientas maduras, su amplio soporte de plataformas y la compatibilidad con flujos de trabajo de hosting y paneles de control construidos a su alrededor.

¿Cuál es la diferencia entre Apache y apache2?

En Debian y Ubuntu, apache2 es el nombre del paquete y del servicio de Apache HTTP Server. Los sistemas de la familia RHEL y Fedora suelen llamar httpd a ese servicio. No son servidores web distintos: los dos se refieren a Apache HTTP Server. La rama estable actual de Apache es la 2.4, con la 2.4.68 como última versión.

¿Apache admite HTTP/3?

De forma nativa no. Apache HTTP Server 2.4 no incluye un módulo de HTTP/3 ni de QUIC; el soporte de protocolos que trae se detiene en HTTP/2. Si necesitas HTTP/3 en producción, puedes terminarlo en un proxy inverso o una CDN compatibles situados delante de Apache.