NGINX suele ser la mejor elección cuando necesitas máximo control, servir archivos estáticos, usar caché o exprimir el rendimiento de un proxy estable. Traefik suele ser mejor cuando tus servicios cambian con frecuencia y quieres que Docker, Kubernetes u otro proveedor actualice las rutas automáticamente. Ninguno gana en todos los escenarios: NGINX es un servidor web y proxy multipropósito; Traefik es un proxy de aplicaciones cloud native diseñado alrededor del descubrimiento dinámico.
Traefik —pronunciado aproximadamente “traffic”— está escrito principalmente en Go. NGINX está escrito principalmente en C y utiliza una arquitectura de proceso maestro y workers orientada a eventos. Esa diferencia técnica importa, pero no debería decidir por sí sola: la pregunta útil es qué trabajo quieres automatizar y qué funciones necesita tu tráfico.
| Si tu prioridad es… | Punto de partida | Razón |
|---|---|---|
| Un VPS con WordPress, PHP-FPM o archivos estáticos | NGINX | Servidor web, FastCGI, caché y proxy en una sola pieza |
| Docker Compose con servicios que aparecen y desaparecen | Traefik | Descubrimiento desde labels y actualización dinámica de rutas |
| Kubernetes y Gateway API | Depende | Ambos tienen implementaciones; compara compatibilidad, políticas y modelo operativo |
| Rendimiento bruto con una ruta estable | NGINX | En nuestro laboratorio sintético obtuvo mayor throughput y menor latencia |
| HTTPS automático para muchos microservicios | Traefik | ACME y certificados se integran con routers y proveedores |
| Caché HTTP en el proxy | NGINX | Incluye caché de contenido y controles de buffering |
| Configuración declarativa revisada en Git | Ambos | NGINX usa archivos explícitos; Traefik también admite proveedor de archivos |
Qué son NGINX y Traefik
NGINX: servidor web, proxy y caché
NGINX Open Source puede servir archivos, terminar TLS, actuar como reverse proxy, balancear HTTP y tráfico TCP/UDP, almacenar respuestas en caché y comunicarse con FastCGI, uWSGI y SCGI. Su configuración normalmente vive en archivos que un operador valida y recarga. El proceso maestro comprueba la nueva configuración, inicia nuevos workers y retira los anteriores de forma gradual; si la configuración no puede aplicarse, conserva la anterior.
Esto lo hace especialmente fuerte cuando la topología cambia poco, necesitas controles finos de buffers y caché, o quieres que la misma capa entregue contenido estático y reenvíe peticiones a una aplicación.
Traefik: application proxy cloud native
Traefik Proxy observa proveedores de infraestructura —como Docker, Kubernetes, Consul o archivos— y construye su configuración de enrutamiento a partir de ellos. Se distribuye como un único binario compilado en Go y como imagen oficial. Su modelo separa la configuración de instalación, que define entrypoints y proveedores, de la configuración dinámica de routers, middlewares, servicios y TLS.
Su ventaja no es “usar Go”, sino convertir cambios del orquestador en cambios de ruta sin que una persona regenere y recargue manualmente cada archivo. Para equipos con muchos servicios pequeños, esa reducción de trabajo repetitivo puede valer más que una diferencia de microsegundos.
NGINX vs Traefik: diferencias que sí cambian una arquitectura
| Área | NGINX Open Source | Traefik Proxy |
|---|---|---|
| Función principal | Servidor web, reverse proxy, caché y balanceador | Application proxy y balanceador cloud native |
| Lenguaje principal | C | Go |
| Configuración | Archivos explícitos y recarga validada | Proveedores dinámicos, archivos, CLI o variables |
| Descubrimiento de servicios | No es el centro de NGINX OSS; suele requerir DNS, plantillas, controlador o automatización externa | Nativo mediante Docker, Kubernetes y otros proveedores |
| Archivos estáticos | Sí | No es un servidor de archivos de propósito general; se coloca delante de otro servicio |
| Caché HTTP | Sí, con controles de caché y buffering | No ofrece una caché HTTP equivalente en el núcleo |
| TLS automático | Posible mediante herramientas externas o productos/controladores complementarios | ACME integrado mediante certificate resolvers |
| Dashboard | No en NGINX OSS básico | Dashboard y API integrados; deben protegerse |
| Observabilidad | Logs y métricas mediante módulos/herramientas; el alcance depende de la distribución | Logs, access logs, métricas y tracing integrados, incluido OpenTelemetry |
| Kubernetes | NGINX Gateway Fabric y controladores específicos | Ingress, CRD y Gateway API mediante proveedores |
| Mejor encaje típico | VPS, WordPress, monolitos, contenido estático, caché y tuning fino | Docker, microservicios, despliegues frecuentes y routing dinámico |
Configuración y descubrimiento: la diferencia más importante
Con NGINX, el archivo es la fuente de verdad. El flujo habitual es editar, validar con nginx -t y recargar. Esta fricción es pequeña en un VPS con tres aplicaciones y puede ser una virtud: el cambio queda explícito, es fácil de revisar y no depende de permisos sobre la API del orquestador.
upstream app_backend {
server 10.0.0.11:3000;
server 10.0.0.12:3000;
keepalive 32;
}
server {
listen 443 ssl;
server_name app.example.com;
location / {
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://app_backend;
}
}
Antes de aplicar una modificación:
Despliega el proxy que encaja con tu stack
Elige un VPS con recursos claros para configurar NGINX, Traefik, Docker y la observabilidad que necesita tu aplicación.
sudo nginx -t
sudo systemctl reload nginx
Traefik puede obtener la misma intención desde labels de Docker. Al crear, reemplazar o eliminar el contenedor, el proveedor recalcula las rutas. Este ejemplo desactiva la exposición automática para que solo se publique un servicio con consentimiento explícito:
services:
traefik:
image: traefik:v3.7
command:
- --entrypoints.websecure.address=:443
- --providers.docker=true
- --providers.docker.exposedbydefault=false
ports:
- "443:443"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
app:
image: example/app:1.0
labels:
- traefik.enable=true
- traefik.http.routers.app.rule=Host(`app.example.com`)
- traefik.http.routers.app.entrypoints=websecure
- traefik.http.services.app.loadbalancer.server.port=3000
Advertencia: acceso al socket de Docker implica acceso sensible a la API del daemon. Montarlo como solo lectura no crea autorización por operación sobre el socket. En producción, limita el alcance con un socket proxy o un endpoint protegido, ejecuta Traefik con el mínimo privilegio posible y mantén exposedByDefault=false.
Rendimiento: qué medimos realmente
Los resultados de Internet no son intercambiables. Un test puede medir archivos estáticos servidos directamente por NGINX contra Traefik reenviando a otro servidor; otro puede comparar controladores completos de Gateway API; otro puede activar TLS, logs o middlewares solo en uno. Cualquiera de esas diferencias puede dominar el resultado.
Para disponer de una referencia reproducible, ejecutamos un laboratorio local el 29 de agosto de 2026. No intenta simular toda una producción; aísla el dataplane de un reverse proxy con una sola ruta fija.
- NGINX 1.30.4 y Traefik 3.7.12, este último compilado con Go 1.26.7.
- Contenedores oficiales,
linux/amd64, con límite de 2 CPU y 256 MB para cada proxy. - Mismo backend NGINX, mismo archivo JSON de aproximadamente 1 KB y misma red Docker.
- HTTP sin TLS, access logs desactivados, 100 usuarios virtuales con k6 y 30 segundos por ejecución.
- Tres ejecuciones por proxy; la tabla muestra la mediana de cada métrica.
| Proxy | Solicitudes/s | Latencia p95 | Latencia p99 | Errores |
|---|---|---|---|---|
| NGINX 1.30.4 | 53,359 | 2.47 ms | 3.40 ms | 0% |
| Traefik 3.7.12 | 37,705 | 5.74 ms | 8.01 ms | 0% |
En este escenario, NGINX procesó aproximadamente 41.5% más solicitudes por segundo que Traefik y obtuvo menor latencia de cola. Es una señal útil para una ruta estable y de alto volumen; no demuestra que NGINX será 41.5% más rápido en tu aplicación.
La prueba no midió TLS, HTTP/2 o HTTP/3, compresión, caché, WebSockets, gRPC, autenticación, rate limiting, observabilidad, múltiples upstreams ni cambios de configuración. Tampoco asigna valor al tiempo que Traefik ahorra descubriendo servicios. El repositorio público Gateway API Bench llega a resultados distintos bajo Kubernetes y advierte que la medición de dataplanes depende de miles de variables. La lectura correcta es: repite el test con tu protocolo, payload, middlewares, CPU, topología y patrón de despliegue.
HTTPS y certificados
NGINX termina TLS de forma sólida y ofrece control detallado de protocolos y cifrados, pero NGINX OSS no convierte por sí solo cada nuevo host de Docker en un certificado de Let's Encrypt. Es habitual combinarlo con Certbot, scripts, un panel o un controlador de Kubernetes.
Traefik integra ACME mediante certificate resolvers. Cada router que necesite HTTPS referencia el resolver, y Traefik obtiene y renueva certificados a partir de las reglas de dominio. Debes persistir el almacenamiento de ACME y usar el servidor de staging durante pruebas para no agotar límites de emisión. En Kubernetes Gateway API, la propia documentación de Traefik señala escenarios donde conviene utilizar cert-manager y Secrets en lugar del ACME integrado.
Caché, contenido estático y WordPress
Esta es una diferencia fácil de pasar por alto. NGINX puede servir CSS, JavaScript, imágenes y archivos directamente, hablar con PHP-FPM y almacenar respuestas del upstream en caché. Para WordPress, un VPS tradicional, un sitio con descargas o una aplicación donde el proxy también funciona como servidor web, NGINX reúne más piezas en un solo proceso.
Traefik enruta tráfico; no sustituye a un servidor de archivos ni ofrece una caché de contenido comparable al proxy_cache de NGINX. La configuración explícita también facilita localizar límites por capa, como explicamos en la guía del error 413 en NGINX. Puedes usar Traefik delante de NGINX, Caddy, una aplicación o un CDN, pero esa capa adicional debe justificar su existencia. Si solo tienes un WordPress y dos virtual hosts, probablemente añade complejidad sin suficiente beneficio.
Docker y seguridad operativa
Traefik encaja de forma natural con Docker porque lee labels y detecta puertos y redes. La ventaja también crea un límite de confianza: el proxy necesita consultar la API de Docker. Un dashboard expuesto con api.insecure=true es únicamente para desarrollo; en producción debe ir detrás de autenticación y una ruta protegida.
NGINX puede ejecutarse en Docker sin acceso al socket. A cambio, alguien o alguna herramienta debe mantener su lista de upstreams. Proyectos como plantillas, controladores o service discovery externo pueden automatizarlo, pero entonces ya estás construyendo parte del plano de control que Traefik incluye.
Kubernetes: no compares solo “NGINX” contra “Traefik”
En Kubernetes, el nombre del producto no identifica toda la arquitectura. Debes comparar implementaciones concretas, versiones, Gateway API o Ingress, CRDs, políticas, separación entre control plane y data plane y funciones disponibles en la edición elegida.
Traefik ofrece proveedores para Kubernetes Ingress, CRD y Gateway API. NGINX Gateway Fabric implementa Gateway API con NGINX como dataplane y un control plane que observa recursos del clúster. Por eso un benchmark de NGINX OSS con un archivo local no predice automáticamente el comportamiento de NGINX Gateway Fabric, y un test del proveedor de archivos de Traefik no representa todos los eventos de Kubernetes.
Balanceo, middlewares y observabilidad
Ambos soportan balanceo y routing avanzado, pero expresan las capacidades de forma diferente. NGINX organiza upstreams, locations y módulos; incluye métodos como round robin, least connections, hash y random. Traefik utiliza routers, services y middlewares para encadenar redirecciones, headers, autenticación, retries o circuit breakers.
Traefik expone logs, access logs, métricas y tracing de forma integrada y permite controlar observabilidad por router. NGINX produce logs de acceso y error muy maduros y puede integrarse con métricas y tracing mediante módulos, agentes o productos complementarios. Si tu plataforma ya estandarizó OpenTelemetry y despliega decenas de servicios, Traefik reduce configuración repetida; si ya tienes una pila sólida alrededor de NGINX, migrar solo por el dashboard rara vez compensa.
Cuándo elegir NGINX
- Administras uno o varios sitios estables en un VPS.
- Necesitas servir archivos estáticos, usar FastCGI o configurar caché HTTP.
- Quieres tuning detallado de buffers, timeouts, conexiones y comportamiento del upstream.
- La latencia y el throughput del dataplane son prioritarios y las rutas cambian poco.
- Prefieres una configuración explícita, validada y revisada antes de recargar.
- No quieres entregar acceso a la API de Docker al proxy.
Cuándo elegir Traefik
- Tu plataforma nace en Docker, Kubernetes, Nomad u otro proveedor compatible.
- Los servicios cambian con frecuencia y mantener archivos manuales ya es una fuente de errores.
- Quieres routing, TLS y middlewares definidos junto al despliegue de cada servicio.
- Necesitas dashboard, métricas y tracing con menos ensamblaje inicial.
- El coste operativo de registrar servicios pesa más que la diferencia de rendimiento del proxy.
- Tu equipo entiende y protege correctamente las credenciales del proveedor y la API de administración.
Cuándo usar ambos
También existe una arquitectura válida en la que Traefik descubre y enruta servicios, mientras un NGINX interno sirve estáticos, ejecuta caché o se comunica con PHP-FPM. No la adoptes por moda: cada salto añade configuración, métricas y puntos de fallo. Úsala cuando cada capa tenga una responsabilidad comprobable.
Opinión sincera: ¿cuál es mejor?
Para un VPS tradicional, WordPress, una aplicación monolítica o contenido estático, elegiría NGINX. Tiene más funciones de servidor web, su configuración es predecible y en nuestra prueba de ruta fija ofreció mayor rendimiento.
Para una plataforma de microservicios en Docker o Kubernetes con despliegues continuos, elegiría Traefik si el equipo quiere que el routing siga al orquestador. Su valor aparece cuando evita cambios manuales, no cuando se reduce la comparación a solicitudes por segundo.
En Kubernetes evaluaría Traefik y NGINX Gateway Fabric como implementaciones concretas, junto con otras opciones, usando Gateway API, políticas necesarias y una prueba de carga de la propia aplicación. La mejor herramienta es la que reduce riesgo operativo sin incumplir tus objetivos de latencia, seguridad y recuperación.
Preguntas frecuentes
¿Traefik está escrito en Go?
Sí. El repositorio oficial identifica Go como su lenguaje principal y la distribución se entrega como un binario compilado.
¿Traefik reemplaza completamente a NGINX?
No siempre. Puede reemplazarlo como reverse proxy o ingress, pero no ofrece el mismo papel como servidor de archivos, FastCGI y caché HTTP.
¿NGINX puede descubrir contenedores automáticamente?
NGINX OSS no centra su diseño en observar Docker. Puedes combinarlo con DNS, plantillas, controladores o automatización externa. NGINX Gateway Fabric sí añade un control plane específico para Kubernetes Gateway API.
¿Cuál consume menos recursos?
Depende de versión, carga, protocolos, módulos y observabilidad. No uses una cifra aislada: mide CPU, memoria, latencia p95/p99 y errores bajo tu configuración real.
¿Cuál es mejor para Docker Compose?
Traefik suele reducir trabajo porque lee labels y actualiza rutas. NGINX sigue siendo razonable si hay pocos servicios estables o si ya generas y validas su configuración automáticamente.
¿Cuál es mejor para WordPress?
NGINX suele encajar mejor porque puede servir estáticos, conectarse a PHP-FPM y aplicar caché. Traefik puede ir delante cuando WordPress forma parte de una plataforma mayor de contenedores.
Fuentes y reproducibilidad
- NGINX Open Source: funciones y arquitectura
- NGINX: recarga gradual de configuración
- NGINX: proxy HTTP y caché
- Traefik: configuración de instalación y routing dinámico
- Traefik: proveedor Docker
- Traefik: ACME y Let's Encrypt
- NGINX Gateway Fabric
- Gateway API Bench: metodología y resultados públicos
Los archivos de configuración y la carga del laboratorio se conservaron para repetir la prueba. Última revisión técnica: 29 de agosto de 2026.
