Nginx vs Caddy: ¿qué servidor web deberías usar en 2025?

Nginx vs Caddy: qué estás comparando

Nginx y Caddy son ambos servidores web que ejecutas en tu propia máquina (una VM, un servidor físico o un contenedor) para publicar un sitio o aplicación en Internet.

A alto nivel, se usan comúnmente para:

• Sitios estáticos: servir archivos HTML/CSS/JS de forma eficiente
• Reverse proxy: poner una URL pública amigable delante de una app (Node, Python, Go, PHP-FPM, etc.)
• Balanceo de carga: distribuir tráfico entre varias instancias de la app

Por qué la gente los compara

La mayoría de comparaciones se reducen a una compensación: qué tan rápido puedes llegar a una configuración segura y funcional frente a cuánto control tienes sobre cada detalle.

Caddy suele elegirse cuando quieres un camino directo a valores modernos por defecto—especialmente en torno a HTTPS—sin invertir demasiado tiempo en configuración.

Nginx suele elegirse cuando quieres un servidor muy maduro y ampliamente desplegado con un estilo de configuración que puede ser extremadamente flexible una vez que lo conoces.

Para quién es esta guía

Esta guía es para personas que operan desde un sitio personal pequeño hasta aplicaciones web en producción: desarrolladores, fundadores y equipos con mentalidad ops que quieren una decisión práctica, no teoría.

Qué cubriremos y qué no

Nos centraremos en preocupaciones reales de despliegue: ergonomía de configuración, HTTPS y certificados, comportamiento de reverse proxy, fundamentos de rendimiento, valores de seguridad por defecto y operaciones.

No haremos promesas específicas de proveedores ni reclamos de benchmarks que dependan mucho de una nube, CDN o entorno de hosting particular. En su lugar, obtendrás criterios de decisión aplicables a tu propio entorno.

Primeros pasos y experiencia del día uno

Instalar y ejecutar: comportamiento por defecto y primer sitio funcional

Nginx está ampliamente disponible (repositorios Linux, contenedores, hosts gestionados). Tras la instalación, normalmente obtienes una página por defecto "Welcome to nginx!" servida desde un directorio específico de la distro. Poner tu primer sitio real en línea suele implicar crear un archivo de bloque de servidor, habilitarlo, probar la configuración y recargar.

Caddy es igualmente fácil de instalar (paquetes, un único binario, Docker), pero la experiencia al primer arranque es más "todo incluido". Un Caddyfile mínimo puede ponerte a servir un sitio o hacer reverse proxy en minutos, y los valores por defecto están orientados a un HTTPS moderno y seguro.

Curva de aprendizaje: estilo de configuración y errores comunes

La configuración de Nginx es potente, pero los principiantes suelen tropezar con:

• dónde viven los archivos de configuración y cómo funcionan los includes
• reglas sutiles de emparejamiento (precedencia de location)
• olvidar nginx -t antes de recargar

La Caddyfile de Caddy se lee más como intención ("proxy esto a aquello"), lo que reduce las trampas comunes. La compensación es que cuando necesitas un comportamiento muy específico, quizá debas aprender la configuración JSON subyacente de Caddy o conceptos de módulos.

Tiempo para tener HTTPS funcionando en un dominio nuevo

Con Caddy, HTTPS para un dominio público suele ser una línea: configura la dirección del sitio, apunta el DNS, inicia Caddy—los certificados se solicitan y renuevan automáticamente.

Con Nginx, HTTPS normalmente requiere elegir un método de certificado (por ejemplo, Certbot), enlazar las rutas de archivos y configurar renovaciones. No es difícil, pero son más pasos y más lugares para equivocarse.

Experiencia de desarrollo local (localhost, autofirmados, confianza)

Para desarrollo local, Caddy puede crear y confiar certificados locales con caddy trust, haciendo que https://localhost se parezca más a producción.

Con Nginx, HTTPS local suele ser manual (generar un certificado autofirmado, configurarlo, luego aceptar advertencias del navegador o instalar una CA local). Muchos equipos omiten HTTPS local, lo que puede ocultar problemas de cookies, redirecciones y contenido mixto hasta etapas posteriores.

Estilo y legibilidad de la configuración

La configuración es donde Nginx y Caddy se sienten más diferentes. Nginx favorece una estructura explícita y anidada y un vocabulario amplio de directivas. Caddy favorece una sintaxis más pequeña y legible “orientada a la intención” que es fácil de escanear—especialmente cuando gestionas un puñado de sitios.

Nginx: bloques server, location e includes

La configuración de Nginx se construye alrededor de contexts. La mayoría de aplicaciones web terminan con uno o más bloques server {} (hosts virtuales), y dentro de ellos, múltiples bloques location {} que casan rutas.

Esta estructura es poderosa, pero la legibilidad puede degradarse cuando las reglas se acumulan (locations con regex, múltiples if, largas listas de headers). La principal herramienta de mantenibilidad son los includes: divide configuraciones grandes en ficheros más pequeños y mantén una disposición consistente.

Varios sitios en un mismo servidor suele implicar múltiples server {} (a menudo un archivo por sitio), más fragmentos compartidos:

# /etc/nginx/conf.d/example.conf
server {
  listen 80;
  server_name example.com www.example.com;

  include /etc/nginx/snippets/security-headers.conf;

  location / {
    proxy_pass http://app_upstream;
    include /etc/nginx/snippets/proxy.conf;
  }
}

Una regla práctica: trata nginx.conf como el “cableado raíz” y guarda lo específico de apps/sitios en /etc/nginx/conf.d/ (o sites-available/sites-enabled, según la distro).

Caddy: directivas de Caddyfile y legibilidad

La Caddyfile de Caddy se lee más como una lista de lo que quieres que ocurra. Declara un site block (normalmente el dominio) y añade directivas como reverse_proxy, file_server o encode.

Para muchos equipos, la principal ventaja es que la "ruta feliz" se mantiene corta y legible—even al añadir características comunes:

example.com {
  reverse_proxy localhost:3000
  encode zstd gzip
  header {
    Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  }
}

Varios sitios en un mismo servidor típicamente son varios site blocks en el mismo archivo (o archivos importados), lo que es fácil de revisar.

Mantener configuraciones mantenibles a medida que los proyectos crecen

• Estandariza la estructura desde temprano. En Nginx decide archivos por sitio + snippets compartidos. En Caddy decide si cada sitio tiene su propio archivo e importarlo con import.
• Nombra snippets compartidos por propósito. “proxy defaults”, “security headers”, “static caching”—evita copiar bloques entre sitios.
• Optimiza para el próximo lector. Nginx puede expresar casi cualquier cosa, pero el location más ingenioso suele ser el más difícil de depurar después. Caddy fomenta patrones más simples; si los superas, documenta tu intención en comentarios.

Si tu prioridad es claridad con poca ceremonia, la Caddyfile es difícil de superar. Si necesitas control muy fino y no te importa un estilo más estructurado y verboso, Nginx sigue siendo una buena opción.

HTTPS y gestión de certificados

HTTPS es donde la experiencia diaria entre Nginx y Caddy diverge más. Ambos pueden servir TLS excelente; la diferencia es cuánto trabajo haces y cuántos lugares pueden introducir deriva de configuración.

Caddy: HTTPS automático por defecto

La característica principal de Caddy es HTTPS automático. Si Caddy puede determinar el hostname y es públicamente alcanzable, normalmente:

• Obtiene un certificado (generalmente vía ACME/Let’s Encrypt)
• Lo renueva automáticamente antes de que caduque
• Habilita valores TLS modernos sin que tengas que afinar suites de cifrado

En la práctica, configuras un sitio, inicias Caddy y HTTPS “sucede” para dominios públicos comunes. También gestiona redirecciones HTTP→HTTPS automáticamente en la mayoría de las configuraciones, eliminando una fuente frecuente de errores.

Nginx: HTTPS potente, pero mayormente manual

Nginx espera que tú conectes TLS. Tendrás que:

• Adquirir certificados (cliente ACME como Certbot, o tu proveedor)
• Apuntar Nginx a ssl_certificate y ssl_certificate_key
• Recargar Nginx tras renovaciones (y asegurarte de que las renovaciones realmente sucedan)

Esto es muy flexible, pero es más fácil olvidar un paso—especialmente en torno a la automatización y recargas.

Redirecciones y errores comunes

Una trampa clásica es el manejo incorrecto de redirecciones:

• Redirigir solo la página de inicio y no todos los paths
• Crear bucles de redirección (por ejemplo detrás de un CDN o balanceador)
• Terminar TLS en el upstream pero redirigir basándose en el scheme equivocado

Caddy reduce estos errores con valores por defecto sensatos. Con Nginx debes ser explícito y verificar el comportamiento de extremo a extremo.

Certificados personalizados y PKI interna

Para certificados personalizados (comerciales, wildcard, CA privada), ambos servidores funcionan bien.

• Nginx es directo: proporcionas los archivos cert/key y configuras TLS.
• Caddy también soporta certificados personalizados y puede usarse en escenarios de PKI interna (útil en entornos privados), pero debes ser deliberado sobre la distribución de confianza a clientes y servicios.

Características de reverse proxy que importan en apps reales

La mayoría de equipos no eligen un servidor por un “Hello World”. Lo eligen por las tareas diarias del proxy: conseguir los detalles del cliente correctos, soportar conexiones de larga duración y mantener las apps estables bajo tráfico imperfecto.

Fundamentos del reverse proxy (headers, IP real, WebSockets)

Ambos pueden ponerse delante de tu app y reenviar peticiones limpiamente, pero los detalles importan.

Un buen setup de reverse proxy suele asegurar:

• Encabezados reenviados correctos como Host, X-Forwarded-Proto y X-Forwarded-For, para que la app construya redirecciones y logs correctos.
• Manejo de la IP real del cliente, que afecta rate limiting, auditoría, reglas geográficas y ajustes de “trusted proxy” en tu framework.
• Soporte de WebSockets para chat, dashboards y features en tiempo real. En Nginx esto suele implicar manejar explícitamente Upgrade/Connection; en Caddy generalmente se maneja automáticamente al hacer proxy.

Balanceo de carga y health checks

Si tienes más de una instancia de app, ambos servidores pueden repartir tráfico entre upstreams. Nginx tiene patrones consolidados para balanceo con pesos y control más granular, mientras que el balanceo de Caddy es directo para setups comunes.

Los health checks son el diferenciador operativo real: quieres que instancias no saludables se retiren rápido y que los timeouts estén afinados para que los usuarios no esperen por backends muertos.

Timeouts, buffering y subidas grandes

Las apps reales tocan casos límite: clientes lentos, llamadas API largas, server-sent events y subidas grandes.

Presta atención a:

• Timeouts de lectura/escritura entre proxy y upstream
• Buffering de peticiones/respuestas (útil para estabilidad, negativo para streaming si está mal configurado)
• Límites de tamaño de cuerpo y comportamiento de almacenamiento temporal para archivos grandes

Rate limiting y protecciones básicas

Ninguno de los dos es un WAF completo por defecto, pero ambos ayudan con medidas prácticas: límites de peticiones por IP, topes de conexiones y comprobaciones básicas de cabeceras. Si comparas postura de seguridad, combínalo con tu checklist en /blog/nginx-vs-caddy-security.

Rendimiento y soporte de protocolos

El rendimiento no es solo "peticiones por segundo". También es qué tan rápido el usuario ve algo útil, qué tan eficientemente sirves activos estáticos y qué tan moderno es tu stack de protocolos por defecto.

Archivos estáticos: cabeceras de caché y compresión

Para hosting de sitios estáticos (CSS, JS, imágenes), ambos pueden ser muy rápidos con buena configuración.

Nginx te da control granular sobre cabeceras de caché (por ejemplo, caché larga para assets con hash y caché más corta para HTML). Caddy puede hacer lo mismo, pero quizá uses snippets o matchers para expresar la misma intención.

La compresión es una compensación:

• Gzip está ampliamente soportado y suele ser un valor seguro por defecto.
• Brotli puede reducir más los assets de texto, lo que ayuda en redes lentas, pero cuesta más CPU.

Para sitios pequeños, habilitar Brotli rara vez perjudica y puede hacer que las páginas se sientan más rápidas. Para sitios grandes con mucho tráfico, mide la capacidad de CPU y considera assets precomprimidos o descargar la compresión al edge/CDN.

HTTP/2 y HTTP/3: qué nota el usuario

HTTP/2 es la base para navegadores modernos y mejora la carga de muchos assets pequeños sobre una sola conexión. Ambos servidores lo soportan.

HTTP/3 (sobre QUIC) puede mejorar el rendimiento en redes móviles inestables reduciendo el coste de pérdida de paquetes y handshakes. Caddy suele facilitar probar HTTP/3, mientras que el soporte en Nginx varía según la compilación y puede requerir paquetes específicos.

SPAs y rutas fallback

Si sirves una SPA, normalmente necesitas “intentar archivo, si no sirve /index.html”. Ambos lo hacen bien, pero verifica que las rutas de la API no caigan accidentalmente al fallback de la SPA y oculten 404 reales.

Valores de seguridad por defecto y checklist de hardening

Ambos pueden asegurarse bien, pero parten de valores por defecto diferentes.

Caddy es "secure-by-default" para muchos despliegues comunes: habilita TLS moderno automáticamente, renueva certificados y fomenta setups HTTPS-only. Nginx es flexible y ampliamente desplegado, pero normalmente necesitas elegir explícitamente TLS, cabeceras y control de acceso.

Valores por defecto comunes (y qué aún debes configurar)

• Deshabilitar endpoints/funciones no usadas: no publiques sitios de ejemplo, UIs de admin o rutas de debug en producción.
• Limitar exposición: vincula servicios internos a interfaces privadas y publica solo lo necesario.
• Mantener dependencias actualizadas: actualiza el servidor y módulos regularmente.

Versiones TLS y elección de cifrados (mantenlo simple)

• Prefiere TLS 1.2 y TLS 1.3; evita versiones antiguas.
• Usa los valores modernos del servidor a menos que tengas requisitos de cumplimiento estrictos.
• En Nginx, establece explícitamente protocolos permitidos y mantén configs consistentes entre hosts.

Auth básica, allow/deny por IP y proteger endpoints administrativos

Protege herramientas internas (métricas, paneles admin, previews) con autenticación y/o listas de IP.

Ejemplo (Caddy):

admin.example.com {
  basicauth {
    admin $2a$10$..............................................
  }
  reverse_proxy 127.0.0.1:9000
}

En Nginx, aplica auth_basic o allow/deny a los location que exponen rutas sensibles.

Cabeceras de seguridad: HSTS, CSP básicas y valores seguros

Comienza con cabeceras que reduzcan riesgos comunes:

• HSTS (solo después de HTTPS estable): Strict-Transport-Security: max-age=31536000; includeSubDomains
• Protección contra clickjacking: X-Frame-Options: DENY (o SAMEORIGIN si es necesario)
• Anti MIME sniffing: X-Content-Type-Options: nosniff
• CSP (básico): empieza con una política conservadora y relájala según sea necesario (errores de CSP pueden romper sitios)

El hardening es menos sobre una "config perfecta" y más sobre aplicar estos controles de forma consistente en cada app y endpoint.

Ecosistema, módulos y extensibilidad

Tu experiencia a largo plazo con un servidor suele determinarse menos por las funcionalidades núcleo y más por el ecosistema: módulos, ejemplos reproducibles y lo complejo que es extender cuando cambian los requisitos.

Nginx: módulos maduros y una gran base de conocimiento

Nginx tiene un ecosistema profundo construido a lo largo de muchos años. Hay muchos módulos oficiales y de terceros, además de una enorme cantidad de ejemplos comunitarios (posts, gists, documentación de proveedores). Eso es una ventaja real cuando necesitas una capacidad específica—caché avanzado, balanceo con matices o patrones de integración para apps populares—porque probablemente alguien ya lo resolvió.

La contraparte: no todos los ejemplos que encuentres están actualizados o son seguros. Verifica siempre contra la documentación oficial y las recomendaciones modernas de TLS.

Caddy: extensiones potentes—úsalas con criterio

El núcleo de Caddy cubre mucho (especialmente HTTPS y reverse proxy), pero usarás extensiones cuando necesites métodos de auth no estándar, descubrimiento inusual de upstreams o manipulación de peticiones personalizada.

Cómo evaluar una extensión:

• Señales de mantenimiento: lanzamientos recientes, issues/PRs activos, mantenimiento claro
• Postura de seguridad: permisos mínimos, modelo de amenazas documentado, valores por defecto sensatos
• Ajuste operacional: proceso de build/release reproducible en CI

Gestionar riesgo operativo y evitar lock-in

Depender de plugins poco comunes aumenta el riesgo en upgrades: un rompimiento en compatibilidad o abandono puede dejarte atascado en una versión antigua. Para mantener flexibilidad, prefiere funcionalidades del núcleo, conserva la configuración portátil (documenta intención, no solo sintaxis) e intenta aislar la "salsa especial" detrás de interfaces bien definidas (p. ej. deja la auth en un servicio dedicado). Cuando dudes, prototipa ambos servidores con tu app real antes de decidir.