PHP en Apache vs NGINX

(Parte 1 general)

comparativa analítica y rigurosa en la práctica actual

Resumen ejecutivo

El debate “Apache vs NGINX” rara vez se resuelve con un único ganador universal, porque en entornos PHP modernos el rendimiento final depende tanto (o más) de cómo se ejecuta PHP (mod_php frente a PHP-FPM), de la concurrencia real (muchas conexiones lentas vs pocas rápidas), del patrón de caché y de la operación diaria (despliegues, observabilidad, reglas de reescritura, seguridad) como del servidor en sí. Aun así, sí hay conclusiones sólidas: NGINX tiende a brillar en escenarios de alta concurrencia, reverse proxy y servicio eficiente de estáticos, mientras que Apache conserva ventajas importantes de compatibilidad y flexibilidad operativa, especialmente donde .htaccess y el ecosistema histórico pesan. [1]

Lo más relevante hoy no es “NGINX o Apache”, sino qué arquitectura eliges:
– Apache con mod_php integra PHP dentro del propio proceso/worker del servidor, con implicaciones directas en memoria y en el modelo de concurrencia; la propia documentación de PHP sigue advirtiendo sobre MPM “threaded” cuando PHP va como módulo en Apache, lo que históricamente empuja al uso de prefork. [2]
– NGINX no ejecuta PHP “dentro”; lo habitual (y recomendado en la industria) es NGINX + PHP-FPM vía FastCGI, separando claramente responsabilidades y facilitando escalado y aislamiento. [3]
– Apache también encaja muy bien con PHP-FPM mediante mod_proxy_fcgi, pero requiere entender detalles finos (reutilización de conexiones, interacción con HTTP/2, dimensionamiento del pool de PHP-FPM) para no caer en cuellos de botella sutiles. [4]

A nivel de adopción, los datos de uso web público sugieren que, a fecha 20 de febrero de 2026, NGINX aparece por encima de Apache en cuota de uso donde se identifica el servidor, aunque Apache sigue siendo muy relevante. [5]

Este informe (parte general) baja el debate al terreno real: arquitectura, integración con PHP, configuración y módulos, seguridad, rendimiento con benchmarks recientes (y sus limitaciones), casos de uso típicos, errores comunes observados en comunidades, tendencias y recomendaciones prácticas por perfil.

Palabras clave

Servidor web, MPM, event-driven, prefork, worker, event MPM, FastCGI, PHP-FPM, mod_php, reverse proxy, HTTP/2, HTTP/3, QUIC, concurrencia, latencia, throughput, tuning, hardening, .htaccess, WordPress, API.

Introducción

Apache y NGINX resuelven el mismo problema (servir HTTP) con filosofías internas distintas: Apache se articula alrededor de MPM (Multi-Processing Modules) que determinan si maneja conexiones con procesos, hilos o una combinación; NGINX se apoya en un modelo event-driven con procesos master/worker y mecanismos eficientes del sistema operativo (por ejemplo epoll en Linux) para manejar muchas conexiones concurrentes con bajo overhead. [6]

En PHP, la discusión se vuelve más interesante porque el servidor web no solo sirve archivos: coordina la derivación de peticiones dinámicas hacia el runtime de PHP. Aquí emerge la distinción crítica: mod_php (PHP como módulo dentro de Apache) vs PHP-FPM (PHP como pool FastCGI externo). La elección impacta modelo de procesos, memoria, aislamiento, despliegue y seguridad. [7]

Supuestos (no especificados por el solicitante, y necesarios para concretar recomendaciones prácticas):
– Entorno típico de servidor: Linux moderno en VPS o bare metal, con TLS terminado en el servidor web o en un CDN/reverse proxy. (Cualquier conclusión cuantitativa de rendimiento puede variar si TLS termina antes, si hay HTTP/2/3, o si se usa caché agresiva.) [8]
– PHP actual (familia 8.x) ejecutado preferentemente como PHP-FPM en despliegues nuevos, aunque se incluye configuración de mod_php por completitud. [9]
– El análisis de “tendencias” se apoya en estadísticas públicas de detección de servidores (con sesgos conocidos: no siempre se puede detectar el servidor y una web puede usar más de uno). [10]

Nota contextual: Apache es mantenido por la Apache Software Foundation[11]. [12]

Metodología

La investigación se realizó con fecha de referencia 20 de febrero de 2026 y priorizó fuentes según esta jerarquía:

Primero, documentación oficial y primaria:
– Apache HTTP Server: MPMs (event, worker, prefork), .htaccess, DSO/módulos, reverse proxy (mod_proxy, mod_proxy_fcgi), HTTP/2 (mod_http2), hardening y vulnerabilidades. [13]
– NGINX: arquitectura/operación (señales y recarga), métodos de procesamiento de conexión (epoll/kqueue), FastCGI y proxy, módulos dinámicos, Windows, QUIC/HTTP/3, y releases recientes. [14]
– PHP (manual oficial): configuración de PHP-FPM (pm, límites, seguridad), instalación como módulo/handler o FastCGI, y notas de thread-safety en Windows. [15]

Segundo, benchmarks y datasets reproducibles (fuentes “originales” o con metodología explícita):
– OpenBenchmarking/Phoronix Test Suite: perfiles pts/nginx y pts/apache, con métricas agregadas y miles de resultados públicos (actualizados a febrero de 2026) y un ejemplo de ejecución concreta en hardware ARM. [16]

Tercero, señales de adopción/tendencia:
– W3Techs (cuotas de uso y comparación histórica; actualizado diariamente). [5]

Cuarto, fuentes operativas y comunidad (para problemas reales y errores comunes):
– Foros oficiales/comunitarios de NGINX (casos de configuración de PHP/alias y loops de proxy). [17]
– Entradas técnicas de vendor (F5/NGINX) sobre errores típicos de configuración (p. ej., límites de ficheros/FDs). [18]
– Hilos técnicos donde aparecen problemas frecuentes al mezclar MPM, HTTP/2 y el SAPI de PHP en Apache. [19]

Limitación explícita: muchos “comparativos” populares en blogs no detallan condiciones de prueba (hardware, TLS sí/no, tamaño de respuesta, keep-alive, kernel, parámetros de wrk/ab), por lo que se usan solo como apoyo cualitativo cuando la documentación oficial o un benchmark reproducible ya respalda la idea.

Resultados

Tabla comparativa de arquitectura e integración con PHP

Dimensión	Apache (enfoque típico)	NGINX (enfoque típico)	Implicación práctica para PHP
Modelo de concurrencia	Elegido por MPM: prefork (procesos), worker (procesos+hilos), event (optimiza simultaneidad liberando hilos de trabajo mediante hilos “listener”). [20]	Event-driven con selección de métodos eficientes (epoll en Linux, kqueue en BSD, etc.). Recarga mediante señales con arranque de nuevos workers y cierre gradual de los antiguos. [21]	En estáticos y alta concurrencia de conexiones, el modelo event-driven suele ser ventajoso; en dinámico, el runtime PHP y su pool condicionan el techo real. [22]
PHP “dentro” del servidor	Posible vía módulo (mod_php / apache2handler SAPI). El manual de PHP advierte sobre MPM threaded con PHP como módulo en ciertos contextos. [23]	No ejecuta PHP como módulo; deriva a PHP-FPM por FastCGI (configuración con fastcgi_pass, etc.). [3]	Separar PHP (PHP-FPM) ayuda a aislamiento, reinicios y escalado por pool; mod_php simplifica compatibilidad histórica pero penaliza flexibilidad/tuning fino. [9]
PHP externo (PHP-FPM)	Apache + PHP-FPM vía mod_proxy_fcgi / SetHandler proxy:unix:…\|fcgi://… con consideraciones de reuse/pooling y HTTP/2. [4]	NGINX + PHP-FPM es el patrón estándar: FastCGI con opciones de buffering, timeouts, parámetros y separación clara. [24]	Para la mayoría de despliegues nuevos de PHP, PHP-FPM es la vía más controlable (límites pm.max_children, security.limit_extensions, sockets y permisos). [25]
Configuración distribuida	.htaccess permite overrides por directorio (útil en hosting compartido), pero con coste de performance si se habilita AllowOverride. [26]	No hay equivalente a .htaccess; se migra a configuración centralizada (server, location, try_files, etc.). [27]	WordPress y apps con reglas .htaccess requieren migración o mantener Apache. Apache puede ser más “plug-and-play” si el proyecto depende de .htaccess. [28]
Módulos	Amplio catálogo, cargables como DSO (modularidad clásica). [29]	Módulos dinámicos vía load_module y ecosistema de módulos; algunos features pueden depender de edición/compilación. [30]	En tuning/seguridad, ambos son muy extensibles, pero Apache suele ser percibido como “caja de herramientas” enorme; NGINX como “plano de datos” muy eficiente y controlado. [31]

Arquitectura y manejo de procesos/hilos

Apache y los MPM como “decisión arquitectónica”. Apache describe explícitamente que el MPM define su modelo de procesamiento. En Unix, el propio proyecto explica que si el sistema soporta hilos y polling thread-safe (por ejemplo epoll/kqueue), el MPM por defecto suele ser event; si no, worker; y si no hay soporte de threads, prefork. [32] En términos prácticos:
– prefork crea un servidor no-threaded basado en procesos, y su documentación pone el foco en dimensionar MaxRequestWorkers asegurando RAM suficiente para todos los procesos. [33]
– worker implementa un modelo híbrido multi-proceso/multi-hilo, capaz de servir más con menos recursos que un modelo solo de procesos, manteniendo cierta estabilidad al tener múltiples procesos con múltiples hilos. [34]
– event busca servir más simultáneamente liberando hilos de trabajo mediante hilos “listener” que se ocupan de parte del trabajo de conexiones (especialmente útil con keep-alive). [35]

NGINX y el modelo event-driven master/worker. NGINX documenta (y explica en profundidad) que su escalabilidad se apoya en un diseño event-driven, evitando mapear cada conexión a un hilo/proceso dedicado; además, en plataformas con varios métodos de procesamiento, selecciona automáticamente el método más eficiente (por ejemplo epoll en Linux). [36] La operación cotidiana (recargas, rotación de logs, upgrades) está explícitamente descrita mediante señales: un HUP provoca validación de sintaxis, arranque de nuevos workers con la nueva configuración y apagado gradual de los antiguos, lo que habilita cambios sin cortar conexiones activas. [37]

Integración con PHP

Apache + mod_php (PHP como módulo dentro del servidor). El manual oficial de PHP muestra cómo cargar el módulo (LoadModule) y cómo asociar extensiones a SetHandler application/x-httpd-php, recomendando acotar el patrón para reducir riesgos (evitar que “dobles extensiones” ejecuten PHP). [38] En Windows, el manual añade un matiz importante: si usas apache2handler SAPI, debes usar la build “Thread Safe (TS)” de PHP. [39]
Punto crítico: el propio manual de PHP mantiene una advertencia histórica sobre usar MPM threaded con Apache cuando PHP se integra de este modo, recomendando prefork en esos escenarios. [2] En la práctica moderna, esto es una de las fuerzas que empujan a migrar PHP hacia PHP-FPM cuando se desea event/worker con eficiencia en conexiones.

NGINX + PHP-FPM (FastCGI). El módulo FastCGI de NGINX documenta fastcgi_pass, parámetros típicos (SCRIPT_FILENAME, etc.) y opciones de buffering y buffering del request body (fastcgi_buffering, fastcgi_request_buffering) que influyen tanto en latencia como en uso de memoria y disco temporal. [24] Esta arquitectura separa claramente responsabilidades: NGINX gestiona conexiones y estáticos, PHP-FPM gestiona procesos PHP y su concurrencia.

Apache + PHP-FPM (mod_proxy_fcgi). La documentación oficial de mod_proxy_fcgi ofrece ejemplos de ProxyPassMatch y del enfoque “Handler” con SetHandler «proxy:unix:/path/to/app.sock|fcgi://localhost/». [4] Lo más valioso de esta misma fuente es que advierte de un problema real: al habilitar reuse/pooling, y dado que PHP-FPM usa un modelo prefork donde cada worker maneja una conexión a la vez, un exceso de conexiones persistentes puede consumir workers y acabar en timeouts; además, con HTTP/2 puede aumentar el número de conexiones backend por cómo está implementado mod_http2. [4] Esto conecta directamente con el dimensionamiento de PHP-FPM (pm.max_children) y con estrategias como límites y timeouts en el frontend.

Configuración y ejemplos básicos

A continuación se incluyen configuraciones mínimas (orientativas). Ajusta rutas, versiones de PHP, usuarios/grupos, y política TLS según distribución y hardening.

NGINX + PHP-FPM (ejemplo básico con socket Unix)
(La sintaxis y variables de FastCGI están documentadas por NGINX; la elección de listen y permisos del socket está documentada por PHP-FPM). [3]

server {
listen 80;
server_name example.com;
root /var/www/html/public;
index index.php index.html;

location / {
try_files $uri $uri/ /index.php?$query_string;
}

location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

# Debian/Ubuntu suele usar sockets tipo /run/php/php8.x-fpm.sock
fastcgi_pass unix:/run/php/php-fpm.sock;

# Opcional: ajustar timeouts según carga/latencia de PHP
fastcgi_read_timeout 60s;
}

# Buenas prácticas mínimas
location ~ /\.(?!well-known).* {
deny all;
}
}

Apache + mod_php (ejemplo básico)
(La guía oficial de PHP para Apache 2.x muestra el patrón LoadModule + FilesMatch con SetHandler y advierte sobre asociar extensiones de forma demasiado amplia). [38]

# Carga del módulo PHP (el nombre puede variar según versión/compilación)
LoadModule php_module modules/libphp.so

# Ejecutar solo .php como PHP (evitar dobles extensiones)
<FilesMatch «\.php$»>
SetHandler application/x-httpd-php
</FilesMatch>

DirectoryIndex index.php index.html
DocumentRoot «/var/www/html/public»

Apache + PHP-FPM (ejemplo moderno con proxy_fcgi y socket Unix)
(El ejemplo “Proxy via Handler” y el formato proxy:unix:…|fcgi://… están documentados en mod_proxy_fcgi). [4]

# Asegúrate de tener habilitados módulos necesarios:
# proxy, proxy_fcgi, setenvif (recomendación típica en distros)

<FilesMatch «\.php$»>
SetHandler «proxy:unix:/run/php/php-fpm.sock|fcgi://localhost/»
</FilesMatch>

DocumentRoot «/var/www/html/public»
DirectoryIndex index.php index.html

Seguridad

Apache (hardening y superficie de configuración). Apache publica recomendaciones de “Security Tips” que enfatizan medidas base (actualizar, minimizar privilegios, permisos correctos, cuidado con features como CGI/SSI y configuración segura). [40] Además, mantiene páginas de vulnerabilidades por rama (2.4) para seguimiento y gestión de riesgo. [41] En el plano de configuración, cuando se habilita proxying deben evitarse configuraciones que conviertan el servidor en un “open proxy”; la documentación oficial de mod_proxy_fcgi lo resalta explícitamente. [4]

NGINX (seguridad de upstream y actualizaciones). NGINX documenta controles de seguridad como cifrado del tráfico hacia upstreams (TLS entre NGINX y backend), relevante en arquitecturas con microservicios o segmentación de red. [42] En cuanto a ciclo de vida de seguridad, el propio sitio oficial anuncia releases con correcciones CVE; por ejemplo, el 4 de febrero de 2026 se publicaron releases stable y mainline con fix de una vulnerabilidad en upstream SSL. [43]

Un punto de seguridad muy “PHP” que se olvida: PHP-FPM expone directivas de seguridad que ayudan a evitar errores de frontend, como security.limit_extensions para limitar qué extensiones puede interpretar, reduciendo impacto de configuraciones erróneas del servidor web. [25]

Rendimiento y benchmarks recientes

Cómo interpretar “rendimiento” aquí. Hay al menos cuatro ejes: concurrencia (muchas conexiones), throughput (requests/s), latencia (p95/p99) y coste (CPU/RAM). Los servidores web pueden variar mucho según: TLS sí/no, tamaño de respuesta, keep-alive, HTTP/1.1 vs HTTP/2, kernel, y configuración. Por eso, en este informe se priorizan benchmarks con metodología reproducible y se indica cuando la comparabilidad no es perfecta.

Benchmarks agregados (OpenBenchmarking/Phoronix Test Suite).
OpenBenchmarking mantiene perfiles de test para NGINX y Apache. Ambos perfiles se apoyan hoy en wrk y tienen miles de resultados públicos; además, el perfil de NGINX especifica que usa HTTPS con certificado autofirmado para benchmarking local, lo que introduce trabajo criptográfico en la medición. [44] El perfil de Apache indica que usa wrk para generar carga, con una revisión importante el 25 de marzo de 2023 para “mejor escalado”. [45]

Ejemplo de señal cuantitativa (no “veredicto final”). En la vista de métricas agregadas del perfil pts/nginx (configuración “Connections: 500”), se muestran rangos de resultados públicos (desde muy bajos en hardware modesto hasta cientos de miles de requests/s en sistemas potentes) y se reporta también desviación estándar media baja entre corridas. [46] Para Apache, el perfil muestra distribución y rangos (en su configuración seleccionada “Concurrent Requests: 1000”), con miles de resultados y desviación típica media también reportada. [47]
Interpretación rigurosa: estos datos no demuestran que “uno gane siempre”, pero sí muestran que ambos pueden escalar fuertemente en estáticos; y que comparar números aislados sin igualar condiciones (TLS, concurrencia exacta, tamaño de payload, etc.) lleva a conclusiones erróneas. [48]

Un caso concreto (hardware ARM, resultado público) ilustra la trampa de la comparabilidad. En un resultado publicado (rk3588 / Ubuntu 22.04 / conexiones concurrentes 500), se ven cifras distintas para NGINX y Apache, pero el perfil de NGINX usa HTTPS mientras que el de Apache no declara lo mismo en su resumen; por tanto, contraponer esos dos números como “NGINX vs Apache” sería metodológicamente débil. [49]

Conclusión operativa sobre rendimiento en PHP (inferencia apoyada en documentación): en aplicaciones dinámicas PHP, el techo suele venir dominado por el pool de PHP-FPM (pm.max_children como límite de requests simultáneas) y por la interacción del frontend con ese pool (conexiones persistentes/reuse, timeouts, buffering). Esto se infiere directamente de:
– PHP-FPM define explícitamente pm.max_children como límite de requests simultáneas, y expone control de modelo (static/dynamic/ondemand) y mecanismos de seguridad/operación. [25]
– Apache advierte que, al reutilizar conexiones FastCGI y con HTTP/2, el número de conexiones backend y el consumo de workers de PHP-FPM puede dispararse y trasformarse en timeouts si el pool está mal dimensionado. [4]

Tabla comparativa de rendimiento (con cautelas metodológicas)

Escenario	Qué suele importar más	Señales en fuentes reproducibles	Lectura práctica
Estáticos, HTTP/1.1/keep-alive, muchas conexiones	Gestión eficiente de conexiones y event loop; límites de FDs; kernel	NGINX documenta métodos eficientes (epoll) y control operativo; además hay guías de errores típicos (no ajustar FDs/worker_connections). [50]	NGINX suele ser una elección muy sólida como frontal de estáticos y reverse proxy cuando hay mucha concurrencia. [51]
Estáticos, comparación por datasets públicos	Throughput (requests/s) bajo un perfil de load test	OpenBenchmarking muestra miles de resultados para perfiles de NGINX y Apache basados en wrk, con rangos amplios por hardware/configuración. [52]	Útil como “orden de magnitud”, no como sentencia universal. Igualar condiciones es obligatorio si vas a decidir por números. [53]
PHP dinámico (WordPress, apps)	Límite real del pool PHP-FPM y BBDD; timeouts; caché; colas	PHP-FPM define pm.max_children como límite de simultaneidad; Apache detalla cómo reuse/HTTP/2 puede “ocupar” workers de PHP-FPM y causar timeouts. [22]	Con PHP-FPM bien dimensionado y caché adecuada, la diferencia “Apache vs NGINX” suele reducirse; el diseño global manda. (Inferencia.) [22]
Reverse proxy / balanceo	Capacidad de proxying, headers, TLS a upstream, estabilidad operativa	NGINX documenta proxy_pass; Apache documenta reverse proxy, balanceo y casos de uso. [54]	Ambos valen; NGINX domina como “frontal” por simplicidad y patrones cloud-native; Apache es potente y muy modular. [55]

Casos de uso

Sitios estáticos y mixtos (HTML/CSS/JS + assets). NGINX suele encajar especialmente bien por su modelo de conexiones y por su papel típico como servidor de estáticos al frente de backends, apoyado en una configuración directa y explícita de rutas y proxy. [56] Apache también es plenamente capaz, y además ofrece enorme flexibilidad mediante módulos; cuando .htaccess es requisito (por ejemplo, despliegues donde el equipo no controla la config global), Apache conserva ventaja operativa, aunque con coste de performance si se permite AllowOverride. [57]

Aplicaciones PHP/WordPress.
– Si la aplicación depende de .htaccess y reglas de reescritura en hosting compartido, Apache sigue siendo el camino de menor fricción. [26]
– Si controlas el servidor y priorizas eficiencia/claridad en separación de capas, NGINX + PHP-FPM suele ser el patrón preferente: NGINX enruta, PHP-FPM ejecuta, y cada uno se dimensiona por separado. [3]
– Apache + PHP-FPM es igualmente viable, pero exige más atención a detalles de pool/reuse y a la interacción con HTTP/2/threads si se quiere exprimir rendimiento sin efectos secundarios. [58]

APIs. En APIs (JSON, latencia, p99), el servidor web suele actuar como terminador TLS, normalizador de headers, rate limiting y reverse proxy hacia el runtime. NGINX documenta el paso a upstream con proxy_pass y Apache documenta reverse proxy y balanceo como usos típicos. [54] En la práctica, los patrones de despliegue modernos (contenedores, gateways) tienden a posicionar NGINX como plano de datos/proxy, pero Apache no queda excluido: puede cumplir el mismo rol con su ecosistema de módulos. [59]

Reverse proxies, microservicios y compatibilidad con HTTP/2/HTTP/3. Apache documenta HTTP/2 mediante mod_http2. [60] NGINX documenta soporte QUIC/HTTP/3 disponible desde 1.25.0 e incluido en paquetes binarios Linux, con detalles de compilación y configuración (listen … quic, TLSv1.3, etc.). [61]
Observación importante: en Windows, NGINX sigue considerándose beta y no soporta UDP/QUIC, por lo que HTTP/3 no aplica en esa plataforma con NGINX. [62]
En Apache, la documentación oficial de la rama 2.4 muestra HTTP/2 como guía destacada, pero no presenta una guía análoga oficial de HTTP/3 en el mismo nivel; en la práctica, cuando HTTP/3 es requisito, un patrón común es terminarlo en un proxy que sí lo soporte. (Inferencia apoyada en la diferencia documental observable.) [63]

Tabla comparativa de casos de uso y recomendación “por defecto”

Caso de uso	Apache encaja especialmente cuando…	NGINX encaja especialmente cuando…
Hosting compartido / equipos sin control del servidor	Necesitas .htaccess y overrides por directorio; compatibilidad histórica con reglas. [26]	No es su fuerte: la configuración es centralizada y requiere control del nginx.conf / vhosts. [64]
WordPress / PHP clásico	Quieres evitar migrar reglas y tienes plugins/config heredada en .htaccess. [26]	Controlas el servidor y quieres separación limpia con PHP-FPM y tuning por capa. [3]
Alto tráfico, mucha concurrencia, CDN, reverse proxy	Puedes hacerlo con mod_proxy/balanceo, pero el tuning y la complejidad modular crecen. [65]	Diseño “de serie” para proxy y muchas conexiones; recarga operativa sin corte y event-driven. [66]
Plataforma Windows	Apache tiene soporte y documentación específica de plataforma. [67]	NGINX en Windows sigue con limitaciones severas (select/poll, un worker efectivo, beta, sin UDP/QUIC). [68]

Facilidad de uso y administración

Apache: ventajas y fricciones. Apache ofrece una “gramática” rica y una modularidad enorme (catálogo oficial de módulos y soporte DSO para cargar casi todo en runtime). [69] .htaccess puede ser una ventaja operativa (delegar configuración), pero la propia documentación advierte que habilitarlo introduce un golpe de rendimiento porque el servidor busca .htaccess en cada directorio y lo recarga en cada request. [26]

NGINX: ventajas y fricciones. La administración de NGINX es muy “operativa”: señales, recargas, y configuración centralizada. La documentación describe explícitamente cómo una recarga correcta valida configuración, abre sockets y rota workers sin cortes. [37] La fricción típica aparece al migrar reglas de reescritura desde .htaccess: el propio proyecto tiene un documento específico sobre conversión de reglas y “anti-patrones” comunes. [27] En grandes despliegues, errores de límites del sistema (FDs, worker_connections, etc.) son suficientemente frecuentes como para aparecer en guías oficiales de vendor. [18]

Despliegue y compatibilidad

Versiones y estado actual (referencia 20 feb 2026).
– Apache anuncia la release 2.4.66 publicada el 4 de diciembre de 2025 como “best available” de la rama 2.4.x estable. [70]
– NGINX anunció el 4 de febrero de 2026 releases stable/mainline (1.28.2/1.29.5) incluyendo un fix de seguridad CVE; además, documenta QUIC/HTTP/3 como disponible desde 1.25.0. [71]

Compatibilidad con Windows. Apache tiene documentación específica para Windows, y su MPM por defecto allí (mpm_winnt) se basa en un proceso de control que lanza un proceso hijo que crea threads para manejar requests. [67] NGINX, en cambio, documenta explícitamente limitaciones de su build Windows y que no se espere alta escalabilidad. [68]

Problemas reales y errores comunes

Errores típicos con NGINX + PHP-FPM. Un caso clásico: combinaciones de alias/root y reglas de location que provocan que los .php se descarguen en lugar de ejecutarse; aparece en el foro comunitario de NGINX como un problema real de configuración. [72] Otro patrón frecuente en reverse proxy es el loop de redirecciones al terminar SSL en NGINX y dejar backend en HTTP si no se propagan correctamente headers/estado “https” al backend. [73] Y, a nivel de sistema, no ajustar límites de ficheros/FDs en relación con worker_connections es un error tan común que F5/NGINX lo incluye en su lista de “Top 10 mistakes”. [18]

Errores típicos con Apache (especialmente en PHP).
– Confiar en .htaccess para todo sin entender que AllowOverride fuerza búsquedas de .htaccess por directorio en cada request, penalizando rendimiento incluso si no existe el fichero. [26]
– Mezclar un stack “mod_php + prefork” con objetivos modernos como HTTP/2 puede llevar a callejones. En discusiones técnicas se observa explícitamente el diagnóstico “si estás en mpm_prefork, tienes que cambiar el SAPI de PHP” para desbloquear ciertas capacidades/estabilidad; es una señal de fricción real al combinar decisiones históricas con objetivos actuales. [19]
– En Apache + PHP-FPM, un error menos obvio es el dimensionamiento: habilitar reuse/pooling sin ajustar PHP-FPM puede “ocupar” workers con conexiones persistentes y generar timeouts; Apache lo advierte directamente en su doc de mod_proxy_fcgi, enlazándolo con MaxRequestWorkers y con HTTP/2. [74]

Diagrama de flujo de petición

flowchart LR
C[Cliente] –>|HTTP/HTTPS| FE{Frontend}

FE –>|Opción A| N[NGINX]
N –>|Estáticos| FS[(Sistema de archivos)]
N –>|FastCGI| FPM[PHP-FPM]
FPM –>|Ejecuta PHP| APP[(Aplicación PHP)]
APP –> DB[(Base de datos)]

FE –>|Opción B| A[Apache]
A –>|mod_php (PHP embebido)| APP2[(Aplicación PHP)]
APP2 –> DB

FE –>|Opción C| A2[Apache]
A2 –>|proxy_fcgi / FastCGI| FPM2[PHP-FPM]
FPM2 –>|Ejecuta PHP| APP3[(Aplicación PHP)]
APP3 –> DB

(La opción C requiere comprender detalles de mod_proxy_fcgi y el dimensionamiento de PHP-FPM; FastCGI en NGINX se configura mediante ngx_http_fastcgi_module y en Apache mediante mod_proxy_fcgi). [75]

Comandos sugeridos de prueba de carga (ab y wrk)

ApacheBench (ab) — herramienta oficial documentada por Apache para medir requests/s y dar una impresión del rendimiento. [76]

# Estático (keep-alive activado) – ajustar a tu endpoint y capacidad
ab -n 20000 -c 200 -k http://127.0.0.1/

# Dinámico (PHP) – endpoint mínimo (ej. /ping.php) y concurrencia moderada
ab -n 10000 -c 50 -k http://127.0.0.1/ping.php

wrk — herramienta moderna de benchmarking HTTP que usa threads, conexiones y duración, con opción –latency. [77]

# Estático: 8 hilos, 400 conexiones, 30s, con estadísticas de latencia
wrk -t8 -c400 -d30s –latency http://127.0.0.1/

# Dinámico (PHP): baja conexiones si PHP-FPM es el cuello de botella
wrk -t4 -c100 -d30s –latency http://127.0.0.1/ping.php

Regla práctica (orientativa): empieza por un test estable con duración suficiente (≥30s), repite varias veces, y separa pruebas de estáticos vs dinámico para no confundir “servidor web” con “runtime + base de datos”. (Inferencia operativa; la documentación de ab y wrk define sus parámetros, pero la metodología depende del objetivo). [78]

Discusión

Qué diferencias son estructurales y cuáles se “diluyen” con PHP

La diferencia estructural más fuerte es el modelo de conexión y concurrencia. NGINX está diseñado alrededor de procesamiento de eventos y métodos eficientes (epoll, kqueue), y su operación de recarga sin corte está pensada como comportamiento de primera clase. [21] Apache, en cambio, es una plataforma más “polimórfica”: puede comportarse como servidor por procesos (prefork), híbrido con threads (worker) o con optimización de simultaneidad (event), pero esa flexibilidad obliga a elegir correctamente el MPM y a ajustar límites como MaxRequestWorkers para no sobrepasar RAM o colapsar bajo carga. [79]

En PHP, muchas diferencias de servidor se diluyen porque el límite de concurrencia real lo impone PHP-FPM (pm.max_children) o el propio hecho de ejecutar PHP embebido en workers con consumo de memoria por proceso. La documentación oficial de PHP-FPM define explícitamente ese límite y los modos static/dynamic/ondemand, y recomienda mecanismos de seguridad como security.limit_extensions. [25] Y Apache añade una advertencia “de producción” que muchos ignorarían: si se habilita reuse/pooling hacia PHP-FPM sin dimensionar bien, puede acabarse con todos los workers ocupados en conexiones persistentes, generando timeouts al usuario final; con HTTP/2, los matices aumentan. [58]

En otras palabras: si tu sitio es dinámico y tu PHP/FPM y base de datos están mal dimensionados, cambiar Apache por NGINX no “arregla” el problema; como máximo desplaza el cuello. (Inferencia apoyada en los límites de simultaneidad y en la advertencia de saturación de workers). [22]

Comunidad, ecosistema y “coste de migración”

Apache conserva un enorme ecosistema histórico: .htaccess es una característica que, para bien o para mal, define cómo se operan muchos CMS y hostings. La propia documentación oficial reconoce su utilidad pero recomienda evitarlo cuando sea posible por rendimiento y por centralización de control. [26] NGINX, por su parte, asume control centralizado y ofrece documentación específica para traducir mentalidad .htaccess a configuraciones correctas con server/location (y señala anti-patrones comunes). [27]

En la “vida real”, los foros muestran que los fallos no suelen ser “NGINX es lento” o “Apache es lento”, sino: “mis .php se descargan”, “tengo loops de redirect”, “no ajusté límites del sistema” o “mis workers están ocupados”. [80]

Adopción y tendencias actuales

Según W3Techs (actualizado a 20 de febrero de 2026), entre los sitios donde se conoce el servidor, NGINX aparece con una cuota mayor que Apache (y se observa además que una web puede usar más de un servidor). [5] Esta señal es consistente con la realidad de arquitectura moderna: NGINX se usa masivamente como reverse proxy frontal (incluso cuando Apache sigue detrás para compatibilidad o por herencia). Sin embargo, Apache mantiene peso importante por base instalada, por compatibilidad y por su papel histórico en ecosistemas de hosting y aplicaciones legadas. (La segunda frase es interpretación razonada sobre el tipo de despliegue; la cuota de uso es el dato principal). [81]

Tabla de pros y contras resumidos

Servidor	Pros (en la práctica)	Contras (en la práctica)
Apache	Flexibilidad por módulos y DSO; compatibilidad y .htaccess; opciones MPM para adaptar modelo; documentación amplia de reverse proxy/balanceo. [82]	.htaccess penaliza rendimiento si se activa; mod_php condiciona MPM y memoria; tuning de MPM/MaxRequestWorkers requiere disciplina; PHP-FPM vía proxy exige conocer detalles de pooling y HTTP/2. [83]
NGINX	Event-driven y eficiente en conexiones; operación limpia (recarga sin corte); muy fuerte como reverse proxy; FastCGI bien documentado; soporte QUIC/HTTP/3 en Linux desde 1.25.0. [84]	Migrar desde .htaccess requiere trabajo; errores de config típicos (alias/root, headers en proxy, límites FDs); en Windows tiene limitaciones severas y no se espera alta escalabilidad. [85]

Conclusiones

Recomendaciones prácticas por perfil de uso

Perfil: pequeño blog (WordPress típico, tráfico bajo/medio, prioridad “que funcione” y mantenimiento simple).
Si el entorno depende de .htaccess y quieres minimizar migraciones (plugins, reglas de rewrite heredadas), Apache te dará menor fricción inicial; aun así, procura no abusar de .htaccess si puedes mover reglas a la configuración principal por rendimiento. [26] Si tienes control total del servidor y buscas un stack moderno y constantemente optimizable, NGINX + PHP-FPM suele ser una base excelente: separa capas, facilita cacheo/optimización y permite dimensionar PHP aparte. [3]

Perfil: sitio de alto tráfico (muchas conexiones, CDN, picos, necesidad de proxy, escalado).
Como frontal, NGINX suele ser la opción más directa: modelo event-driven, control operativo de recargas sin cortes y fortaleza como reverse proxy. [86] Si mantienes Apache detrás (por compatibilidad o legado), utiliza event MPM y ejecuta PHP por PHP-FPM en lugar de embebido, y revisa muy cuidadosamente la interacción entre reuse/pooling hacia PHP-FPM, HTTP/2 y el tamaño del pool (pm.max_children). [87]

Perfil: API (JSON, latencia, despliegues frecuentes, microservicios).
Aquí la elección suele estar dominada por el rol de reverse proxy: terminación TLS, headers, balanceo y enrutado. NGINX documenta de forma muy directa proxy_pass y su operación por señales, lo que encaja bien con despliegues frecuentes; Apache también soporta reverse proxy y balanceo modular. [88] Si HTTP/3 es un requisito (especialmente en Linux), NGINX documenta soporte QUIC/HTTP/3 desde 1.25.0; en Windows, NGINX queda limitado y sin UDP/QUIC. [89]

¿Cuál es mejor en general para el uso más frecuente en la actualidad?

Para el uso más frecuente actual en entornos modernos (Linux, control del servidor, PHP con PHP-FPM, necesidad de servir estáticos bien y actuar como reverse proxy), mi valoración final favorece a NGINX como “mejor opción general por defecto”, principalmente por:
– Su arquitectura event-driven y selección de métodos eficientes por plataforma. [36]
– Su modelo operativo de recarga sin corte y control explícito por señales. [37]
– Su patrón estándar con PHP-FPM vía FastCGI, que separa capas y facilita tuning. [3]
– Su posición actual de adopción en datos de uso web público (señal de tendencia, no prueba técnica). [5]

Dicho eso, Apache sigue siendo “mejor” cuando el factor dominante es compatibilidad/operación heredada: .htaccess, ecosistema de hosting compartido, o migraciones donde el coste de reescritura y el riesgo operativo superan cualquier ganancia potencial. Además, Apache puede ser un reverse proxy/balanceador robusto y puede correr PHP vía PHP-FPM con buen rendimiento si se domina mod_proxy_fcgi y se dimensiona correctamente el pool. [90]

Conclusión final (síntesis): si hoy montas un stack PHP nuevo y tienes control del servidor, empieza por NGINX + PHP-FPM; si heredas un entorno con .htaccess y mod_rewrite por todas partes, o necesitas compatibilidad inmediata, Apache sigue siendo una elección plenamente válida, idealmente con PHP-FPM y MPM event cuando aplique. [91]

Referencias bibliográficas

W3Techs. Usage statistics and market shares of web servers (20 febrero 2026). [10]
W3Techs. Comparison: Nginx vs Apache usage statistics (febrero 2026; actualizado diariamente). [92]
Apache HTTP Server Project. Apache httpd 2.4.66 Released (2025-12-04) (2025). [93]
Apache HTTP Server Project. Download: Latest Version 2.4.66 (released 2025-12-04) (2025). [94]
Apache HTTP Server Documentation. Multi-Processing Modules (MPMs) (año no especificado; doc viva). [32]
Apache HTTP Server Documentation. event MPM (año no especificado). [35]
Apache HTTP Server Documentation. worker MPM (año no especificado). [34]
Apache HTTP Server Documentation. prefork MPM (año no especificado). [95]
Apache HTTP Server Documentation. Apache HTTP Server Tutorial: .htaccess files (año no especificado). [26]
Apache HTTP Server Documentation. Dynamic Shared Object (DSO) Support (año no especificado). [96]
Apache HTTP Server Documentation. mod_so (DSO loader) (año no especificado). [97]
Apache HTTP Server Documentation. mod_proxy_fcgi (copyright 2025 en la página; contenido de referencia). [4]
Apache HTTP Server Documentation. mod_proxy (reverse proxy, balanceo y casos de uso) (año no especificado). [98]
Apache HTTP Server Documentation. mod_proxy_balancer (año no especificado). [99]
Apache HTTP Server Documentation. mod_http2 (HTTP/2 support) (año no especificado). [60]
Apache HTTP Server Documentation. Security Tips (año no especificado). [40]
Apache HTTP Server Project. Apache HTTP Server 2.4 vulnerabilities (año no especificado; lista mantenida). [41]
NGINX. Latest News: nginx-1.28.2 stable y nginx-1.29.5 mainline released (2026-02-04) + fix CVE (2026). [43]
NGINX. Connection processing methods (select/poll/kqueue/epoll…) (año no especificado). [100]
NGINX. Controlling nginx (signals, reload, upgrade on the fly) (año no especificado). [37]
NGINX. Module ngx_http_fastcgi_module (año no especificado; doc viva, incluye directivas y buffering). [24]
NGINX. Module ngx_http_proxy_module (año no especificado). [101]
NGINX. Support for QUIC and HTTP/3 (available since 1.25.0) (año no especificado; doc viva). [102]
NGINX. nginx for Windows (limitaciones; beta; sin UDP/QUIC) (año no especificado). [68]
NGINX. Converting rewrite rules (referencias a .htaccess y conversiones correctas) (año no especificado). [27]
NGINX Blog. Inside NGINX: How We Designed for Performance & Scale (2015). [51]
PHP Manual. Apache 2.x on Unix systems (año no especificado; incluye advertencia sobre MPM threaded y ejemplo de mod_php). [38]
PHP Manual. Installation for Apache 2.x on Windows systems (año no especificado; nota sobre TS en apache2handler SAPI). [39]
PHP Manual. PHP-FPM configuration directives (pm, pm.max_children, security.limit_extensions, sockets y permisos) (año no especificado). [25]
Apache HTTP Server Documentation. ab — Apache HTTP server benchmarking tool (año no especificado). [76]
wg/wrk. wrk: Modern HTTP benchmarking tool (options -t/-c/-d/–latency) (año no especificado; repo). [77]
OpenBenchmarking.org. NGINX Benchmark (pts/nginx) — perfil, metodología y métricas agregadas (última actualización del perfil: 25 marzo 2023; datos agregados hasta 18 febrero 2026). [44]
OpenBenchmarking.org. Apache HTTP Server Benchmark (pts/apache) — perfil, metodología y métricas agregadas (última actualización del perfil: 25 marzo 2023; datos agregados hasta 20 febrero 2026). [103]
OpenBenchmarking.org. Resultado público ejemplo (rk3588, carga concurrente 500) (2023; muestra necesidad de igualdad de condiciones). [104]
F5/NGINX. Avoiding the Top 10 NGINX Configuration Mistakes (2022). [18]
NGINX Community Forum. PHP config con alias: descarga de .php en lugar de ejecución (2025). [72]
NGINX Community Forum. Redirect loop en reverse proxy con terminación SSL (2025). [73]
Comunidad (caso real). Diagnóstico de MPM prefork y necesidad de cambiar SAPI para HTTP/2/HTTP/3 en Apache (2024). [19]