El ingeniero Yusuf Seyitoğlu comparó durante seis semanas NGINX, Caddy y Traefik sobre el mismo clúster de Kubernetes, con doce microservicios y tráfico real de una empresa logística. NGINX ganó con claridad en rendimiento, Caddy consumió menos memoria y Traefik terminó elegido para la mayor parte del tráfico por una razón menos vistosa: reducía el tiempo que el equipo dedicaba a publicar y mantener rutas.
Las claves de la comparativa de proxies en 20 segundos
- NGINX alcanzó el mayor rendimiento, con unos 46.000 req/s.
- Caddy destacó por su menor consumo y la gestión automática de TLS.
- Traefik fue el más lento, pero redujo el alta de rutas a unos cuatro minutos.
- La retirada de ingress-nginx obliga a muchas empresas a buscar sustituto.
- Los resultados pertenecen a un entorno concreto y no son universales.
La prueba resulta útil porque no se limitó a ejecutar un benchmark sintético durante unos minutos. Cada alternativa pasó dos semanas gestionando tráfico con API REST, conexiones WebSocket y exportaciones CSV de entre 15 y 40 MB. El entorno tenía un promedio aproximado de 35.000 peticiones por minuto y picos declarados de 61.000, con un balanceador AWS Network Load Balancer por delante y despliegue en tres zonas de disponibilidad.
Aun así, los datos deben leerse como un caso práctico, no como una clasificación definitiva. El artículo no aporta todos los scripts, configuraciones, modelos de CPU ni conjuntos de resultados necesarios para reproducir la prueba de forma independiente. Además, existe una aparente incoherencia entre algunas unidades publicadas: 61.000 solicitudes por minuto equivalen a unas 1.017 por segundo, de modo que los 36.000 req/s atribuidos a Traefik representarían más de 35 veces ese pico, no tres veces como sostiene el texto original.
El mismo clúster para tres formas distintas de operar
La comparación se realizó en Amazon Elastic Kubernetes Service (EKS) con doce servicios. Los tres proxies recibieron las mismas solicitudes de recursos, dos CPU y 2 GiB de memoria por réplica, y debían resolver los mismos requisitos de cifrado, limitación de tráfico y observabilidad.
| Elemento de la prueba | Configuración utilizada |
|---|---|
| Plataforma | Amazon EKS |
| Aplicaciones | 12 microservicios |
| Tráfico medio declarado | 35.000 peticiones por minuto |
| Pico declarado | 61.000 peticiones por minuto |
| Tipos de tráfico | REST JSON, WebSocket y descargas CSV |
| Tamaño de las exportaciones | Entre 15 y 40 MB |
| Recursos por réplica | 2 CPU y 2 GiB de memoria |
| Balanceador frontal | AWS NLB en tres zonas |
| Certificados | ACME y cert-manager |
| Métricas | Prometheus |
| Duración | Dos semanas por alternativa |
| Cambios de ruta medidos | 14 |
El calendario comenzó con NGINX Ingress Controller de F5 como referencia. Durante las dos semanas siguientes se probó Caddy en una clase de ingreso paralela, incluida una comparación interna con HTTP/3. Traefik ocupó la última fase, primero con servicios no críticos y después con una distribución progresiva del tráfico.
Hay un matiz importante en los nombres. El proyecto comunitario kubernetes/ingress-nginx, utilizado durante años en numerosos clústeres, terminó su mantenimiento en marzo de 2026. Su repositorio oficial está archivado y ya no recibirá versiones, correcciones ni actualizaciones para futuras vulnerabilidades. Los despliegues existentes no dejan de funcionar, pero mantenerlos expuestos aumenta el riesgo con el paso del tiempo.
Ese proyecto no es el mismo que NGINX Ingress Controller, mantenido por NGINX y F5. La segunda implementación continúa activa, utiliza NGINX o NGINX Plus y ofrece soporte comercial. La comparación empleó esta alternativa de F5, no el controlador comunitario retirado.
Comparativa de rendimiento y consumo
| Métrica observada | NGINX F5 NIC | Caddy | Traefik |
|---|---|---|---|
| Rendimiento con JSON de 2 KB | 46.000 req/s | 41.000 req/s | 36.000 req/s |
| Diferencia frente a NGINX | Referencia | −10,9 % | −21,7 % |
| Sobrecarga p99 declarada | 0,9 ms | 1,2 ms | 1,6 ms |
| Memoria en reposo | 35 MB | 28 MB | 48 MB |
| Memoria con 10.000 conexiones | 120 MB | 95 MB | 135 MB |
| Alta de una ruta estándar | 23-25 min | 8-9 min | 4 min |
| Tiempo de la primera ruta | No indicado | No indicado | 38 min |
| Coste mensual de tres réplicas | 186 dólares | 142 dólares | 198 dólares |
NGINX fue aproximadamente un 12,2 % más rápido que Caddy y un 27,8 % más rápido que Traefik tomando como base los resultados del resto de alternativas. También obtuvo la menor latencia adicional en el percentil 99.
Esa diferencia importa en servicios que terminan enormes volúmenes de conexiones, sirven archivos de gran tamaño o trabajan cerca de la capacidad disponible. En el entorno analizado, sin embargo, los tres productos superaban ampliamente el tráfico habitual, siempre que las unidades publicadas sean correctas.
Caddy se situó en segundo lugar con 41.000 solicitudes por segundo. Consumió menos memoria tanto en reposo como con 10.000 conexiones concurrentes. Su coste mensual estimado también fue el más bajo, aunque la diferencia entre los tres apenas alcanzaba 56 dólares y dependía de los precios y recursos concretos de AWS.
Traefik quedó último en rendimiento y fue el que más memoria utilizó. A cambio, una ruta nueva requería unos cuatro minutos una vez establecidas las convenciones del equipo, frente a los más de veinte minutos necesarios con el proceso basado en archivos YAML, anotaciones y revisión mediante pull request de NGINX.
La primera ruta de Traefik tardó 38 minutos. Este dato explica una parte que las comparativas rápidas suelen ocultar: la automatización reduce trabajo después de definir nombres, etiquetas, puntos de entrada, middlewares y permisos. Antes de llegar a ese estado existe un coste inicial de diseño y documentación.
NGINX gana el benchmark, pero Traefik gana la operación diaria
La principal conclusión de la prueba es que el proxy con más solicitudes por segundo no tiene por qué ser el más barato para la organización. Los costes de computación mensuales fueron relativamente parecidos, mientras que el tiempo de los operadores mostró diferencias mayores.
El equipo calculó que Traefik ahorraba alrededor de seis horas mensuales frente a NGINX en cambios habituales de rutas. Con el coste laboral utilizado en el proyecto, esa reducción equivalía a unos 900 dólares al mes.
| Coste operativo observado | NGINX | Caddy | Traefik |
|---|---|---|---|
| Tiempo por ruta | 23-25 min | 8-9 min | 4 min |
| Coste de cómputo mensual | 186 dólares | 142 dólares | 198 dólares |
| Ahorro de horas frente a NGINX | Referencia | No cuantificado | Unas 6 horas/mes |
| Ahorro económico estimado | Referencia | No cuantificado | Unos 900 dólares/mes |
| Principal ventaja | Rendimiento y madurez | Simplicidad y TLS | Integración con Kubernetes |
El cálculo no puede trasladarse directamente a otra empresa. Un equipo que apenas modifica rutas no recuperará el esfuerzo de migración con esos ahorros. Otro que despliega servicios cada día puede obtener una diferencia mucho mayor.
NGINX mantuvo una ventaja reconocible durante las recargas. Cuando se introdujo una configuración incorrecta, rechazó el cambio y siguió trabajando con la anterior. Esta conducta puede resultar molesta en un proceso de integración continua, pero evita que un error sintáctico derribe inmediatamente el proxy en producción.
Caddy redujo buena parte de la complejidad relacionada con los certificados. El proyecto activa HTTPS automático por defecto, puede obtener y renovar certificados mediante ACME y admite HTTP/1.1, HTTP/2 y HTTP/3. También permite aplicar configuración dinámica mediante una API JSON.
La facilidad no elimina todas las tareas en Kubernetes. Cuando existen varias réplicas deben coordinarse el almacenamiento de certificados, la persistencia y las renovaciones. Caddy es muy sencillo en una máquina o un entorno pequeño, pero un despliegue distribuido sigue necesitando arquitectura.
Traefik encajó mejor con el ritmo de cambios del clúster. Observa los recursos de Kubernetes y transforma eventos, etiquetas y objetos personalizados en configuración dinámica. Esto evita muchas recargas manuales, pero amplía las consecuencias de una etiqueta incorrecta.
Durante la prueba, un pod mal etiquetado recibió tráfico público durante once minutos. El incidente no se debió a un fallo del proxy, sino a una convención insuficientemente definida. La automatización hizo exactamente lo que indicaba la configuración, aunque no era lo que esperaba el equipo.
Traefik 3.7 incorpora además un proveedor pensado para interpretar anotaciones de ingress-nginx. La función puede acelerar una migración porque traduce reglas existentes en routers, servicios y middlewares de Traefik. No ofrece una compatibilidad idéntica: su documentación advierte de diferencias en el almacenamiento en búfer, las cabeceras reenviadas y ciertos comportamientos definidos previamente en el ConfigMap de NGINX.
Un timeout de 30 segundos que parecía un fallo del proxy
La incidencia más visible apareció durante el cambio progresivo a Traefik. El nuevo controlador gestionaba el 60 % del tráfico cuando varios usuarios comenzaron a descargar grandes archivos CSV.
Una anotación proxy-read-timeout estaba configurada en 30 segundos, aunque algunas exportaciones necesitaban unos 42 segundos en el percentil 99. Tanto el antiguo controlador como la capa de compatibilidad de Traefik respetaron el valor configurado. Las conexiones se cerraron y la tasa de error pasó del 0 % al 8 % en tres minutos.
El soporte culpó inicialmente al nuevo proxy y el equipo de desarrollo sospechó que la aplicación se había vuelto más lenta. La causa era más sencilla: el timeout heredado no servía para esa carga. La solución inmediata consistió en elevarlo a 300 segundos y dejar como trabajo posterior la creación de exportaciones asíncronas.
El cambio también dejó al descubierto un segundo problema. El balanceador de nivel 4 situado delante del clúster no estaba incluido correctamente entre las fuentes de confianza para las cabeceras reenviadas. Traefik registraba una dirección de cliente incorrecta, de modo que algunos usuarios móviles compartieron el mismo grupo de limitación de tráfico.
La configuración de X-Forwarded-For es una cuestión de seguridad, no solo de observabilidad. Confiar en cualquier origen permite que un cliente falsifique su dirección. No confiar en el balanceador correcto provoca que el proxy vea su IP en lugar de la del usuario.
El análisis detectó además que la tabla nf_conntrack alcanzaba el 92 % en dos nodos debido a las descargas prolongadas. Cambiar de proxy no habría resuelto ese límite del kernel. El caso muestra por qué un error 502 puede proceder del controlador, de la aplicación, del balanceador, de un timeout o del seguimiento de conexiones del nodo.
Qué proxy elegir según el entorno
| Situación | Elección más razonable | Motivo |
|---|---|---|
| Muchísimo tráfico y prioridad absoluta al rendimiento | NGINX | Mayor caudal y menor p99 en la prueba |
| Archivos muy grandes o streaming intensivo | NGINX | Amplias posibilidades de ajuste de búferes |
| Equipo con experiencia previa y soporte de F5 | NGINX F5 NIC | Continuidad operativa y conocimiento disponible |
| Pocos servicios y rutas estables | Caddy | Configuración sencilla y menor consumo |
| TLS automático con poca administración | Caddy | HTTPS y renovaciones integradas |
| HTTP/3 y ECH como requisitos | Caddy | Soporte incorporado en la distribución oficial |
| Kubernetes con cambios frecuentes | Traefik | Descubrimiento y configuración dinámica |
| Migración urgente desde ingress-nginx | Traefik | Compatibilidad parcial con anotaciones existentes |
| Rutas creadas continuamente por varios equipos | Traefik | Menos trabajo manual tras definir convenciones |
| Necesidades distintas dentro de la misma plataforma | Arquitectura híbrida | Cada proxy puede cubrir un tipo de tráfico |
La empresa de la prueba no terminó utilizando una única opción. Traefik se quedó con la mayor parte del tráfico de Kubernetes porque simplificaba la operación diaria, mientras que NGINX permaneció en una ruta dedicada a las exportaciones CSV, donde el ajuste del streaming y los búferes ofrecía más valor. Caddy quedó fuera del entorno principal, aunque el autor lo mantuvo en su infraestructura de pruebas por su sencillez.
Ese resultado híbrido es probablemente la conclusión más útil. NGINX, Caddy y Traefik resuelven problemas parecidos, pero parten de prioridades diferentes. NGINX ofrece control y rendimiento; Caddy reduce la administración del servidor y de TLS; Traefik sigue el movimiento de servicios dentro de Kubernetes.
La mejor elección no depende únicamente de cuántas solicitudes procesa cada segundo. También cuenta cuánto tarda un equipo en publicar una ruta, qué ocurre cuando una configuración es incorrecta y cuánto conocimiento hace falta para diagnosticar una caída de madrugada.
Preguntas frecuentes
¿Cuál fue el proxy más rápido en la prueba?
NGINX alcanzó unos 46.000 req/s, frente a 41.000 de Caddy y 36.000 de Traefik. Los resultados corresponden a una prueba concreta con respuestas JSON de 2 KB y no representan todos los entornos.
¿Por qué eligieron Traefik si fue el más lento?
El tráfico real estaba muy por debajo de su capacidad y el equipo valoró más la reducción del tiempo necesario para configurar rutas. Traefik pasó a gestionar la mayor parte del clúster, mientras NGINX conservó el tráfico de archivos grandes.
¿Ha dejado de mantenerse NGINX para Kubernetes?
El proyecto comunitario kubernetes/ingress-nginx terminó su mantenimiento en marzo de 2026. NGINX Ingress Controller de NGINX y F5 es un proyecto diferente y continúa activo.
¿Traefik puede importar todas las anotaciones de ingress-nginx?
Traefik 3.7 incorpora una capa de compatibilidad que reconoce muchas anotaciones, pero no reproduce todos los comportamientos. Es necesario revisar los valores del ConfigMap, los búferes, las cabeceras y los middlewares antes de migrar.
Fuentes:
- Comparativa de seis semanas realizada por Yusuf Seyitoğlu con NGINX, Caddy y Traefik.
- Repositorio oficial de ingress-nginx, aviso de retirada y fin de las actualizaciones en marzo de 2026.
- Documentación oficial de Traefik 3.7 sobre compatibilidad con anotaciones de ingress-nginx y diferencias de configuración.
- Repositorio oficial de NGINX Ingress Controller, mantenido de forma separada al proyecto comunitario retirado.
- Repositorio oficial de Caddy, funciones de HTTPS automático, API dinámica, ECH y HTTP/3.
