"Nos estamos mudando a Nginx" aparece en cada auditoría, a veces por una buena razón, a veces porque un blog de 2014 lo dice. Sin embargo, el Apache compartido todavía aloja miles de WordPress sin emergencia gracias a .htaccess. Y las pilas modernas ejecutan nginx antes que Apache precisamente porque nadie ha migrado las reglas.
Nginx y Apache no son dos religiones. Estos son dos puntos en la ruta de consulta con diferentes puntos fuertes. Elegir "lo mejor" sin mapear HTTP → PHP → estático → caché es optimizar la etapa equivocada.
Mapear la ruta de una solicitud
Antes de comparar puntos de referencia, determine qué sucede cuando un visitante carga una página. ¿La solicitud pasa primero por una CDN? ¿El servidor web sirve archivos estáticos directamente o todo se transfiere a PHP? ¿Quién puede modificar las reglas de reescritura: el equipo técnico o el cliente a través de .htaccess?
| Paso | rol nginx | Papel de Apache |
|---|---|---|
| Terminación TLS | Genial | Correcto (mod_ssl) |
| Archivos estáticos | Muy rápido (enviar archivo) | Correcto |
| Aplicación de proxy inverso | Nativo, ligero | mod_proxy |
| Reescritura de URL | try_files, mapas | .htaccess, mod_rewrite |
| PHP | A través de PHP-FPM ascendente | PHP-FPM o mod_php |
| Autenticación de directorio básica | auth_basic | .htaccess Tipo de autenticación |
La pregunta útil: ¿cuánto tráfico llega al servidor web antes de PHP y quién debería poder cambiar las reglas sin volver a implementarlas?
Escenarios concretos: tres perfiles típicos
Escenario A: SaaS PHP-FPM, API + SPA
Alrededor del setenta por ciento de los activos pasan por una CDN. Ningún cliente .htaccess. Necesita limitación de velocidad y proxy WebSocket. Nginx solo (o nginx + CDN) es suficiente; Apache no aporta nada decisivo.
Escenario B: alojamiento compartido multicliente de WordPress
Reglas .htaccess por sitio, complementos que escriben reglas de reescritura, soporte histórico de mod_php. Apache sigue siendo la opción natural, o nginx con conversión manual de reglas, lo que tiene un costo de migración que a menudo se subestima.
Escenario C: transición gradual
Apache heredado + nueva aplicación Node. Nginx front-end → Apache (puerto 8080) + Nodo (puerto 3000) por bloque ubicación. Arquitectura común cuando no se puede migrar todo a la vez.
Rendimiento: lo que los benchmarks olvidan
Nginx gana a las conexiones simultáneas y a los archivos estáticos. Apache con mpm_event + PHP-FPM sigue siendo competitivo para PHP dinámico moderado. El cuello de botella suele ser PHP y MySQL, no el servidor web en sí.
Medida antes de la migración: origen TTFB con y sin caché, porcentaje de respuestas estáticas 304/200 servidas directamente por nginx, costo de memoria de mod_php versus PHP-FPM. Un cambio de servidor web sin estas cifras equivale a veces a semanas de migración para obtener una ganancia del cinco por ciento, mientras que la falta de un índice SQL vale el cincuenta por ciento.
Alojamiento compartido, VPS o PaaS
En compartido, a menudo se imponen Apache y .htaccess; nginx rara vez permanece configurable. En VPS, la elección es gratuita: se recomienda nginx + PHP-FPM para un nuevo proyecto sin deuda .htaccess. En PaaS, una capa de abstracción (Caddy, Traefik) oculta el servidor web; en realidad, ya no eliges.
En VPS, instale solo una interfaz a menos que esté documentada una arquitectura híbrida; evite nginx + Apache sin ningún motivo (configuración TLS doble, superficie de error doble).
Para WordPress específicamente, la comparación Apache o nginx para WordPress completa esta lectura. Para una pila más ligera, consulte también Nginx ou Caddy.
Lo mejor: la reputación rara vez reemplaza el inventario de consultas
Cambiar de servidor web sin crear perfiles a veces significa semanas de migración para ganar un cinco por ciento, mientras que un índice de base de datos vale un cincuenta por ciento.
Decide y avanza sin puntos ciegos
Durante medio día, podrás decidir sin ningún punto ciego. Rastree diez solicitudes típicas (inicio, API, administrador, activo). Enumere las dependencias .htaccess y los módulos de Apache necesarios. Mida el TTFB para comprobar si el servidor web es realmente el cuello de botella. Si elige nginx, planifique la conversión de reglas y pruebe las redirecciones 301. Si combina los dos, nginx solo debería servir como proxy: un único propietario de la configuración.
Consulte Apache o nginx para WordPress y Nginx o Caddy. Para elegir el alojamiento subyacente, consulte el directorio y la comparación.
Preguntas frecuentes
¿Nginx todavía reemplaza a Apache?
No. Nginx suele ser mejor en el front-end (TLS, caché, proxy inverso). Apache sigue siendo relevante si depende de .htaccess por directorio, mod_php heredado o módulos sin un equivalente de nginx. La elección correcta se puede leer en su pila, no en la reputación del logotipo.
¿Qué combinación para PHP moderno?
Nginx + PHP-FPM es el estándar actual. Apache + PHP-FPM también funciona. Evite mod_php en una producción ocupada: los trabajadores mezclan la carga web y la carga de PHP, lo que complica el dimensionamiento.
¿Podemos usar ambos?
Sí. Nginx como proxy inverso frente a Apache o frente a aplicaciones Node/Python es una arquitectura común en la migración progresiva. Lo importante es documentar quién finaliza TLS y dónde residen las reglas de reescritura.
¿Cómo decidir en 30 minutos?
Enumere el porcentaje de tráfico estático, el requisito .htaccess, los módulos requeridos y la habilidad del equipo. Si ochenta por ciento estático/CDN + PHP-FPM → interfaz nginx. Si docenas de reglas .htaccess cliente → presupuesto de migración de Apache o nginx.
Se elige Nginx o Apache en la ruta de solicitud, no en el logotipo de la arquitectura de la diapositiva.