12 oct 2025·6 min
Nginx vs Caddy: ¿qué servidor web deberías usar en 2025?
Compara Nginx vs Caddy para reverse proxy y hosting: instalación, HTTPS automático, ejemplos de configuración, rendimiento, plugins y cuándo elegir cada uno.
Compara Nginx vs Caddy para reverse proxy y hosting: instalación, HTTPS automático, ejemplos de configuración, rendimiento, plugins y cuándo elegir cada uno.
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:
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.
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.
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.
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.
La configuración de Nginx es potente, pero los principiantes suelen tropezar con:
location)nginx -t antes de recargarLa 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.
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.
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.
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.
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).
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.
import.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 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.
La característica principal de Caddy es HTTPS automático. Si Caddy puede determinar el hostname y es públicamente alcanzable, normalmente:
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 espera que tú conectes TLS. Tendrás que:
ssl_certificate y ssl_certificate_keyEsto es muy flexible, pero es más fácil olvidar un paso—especialmente en torno a la automatización y recargas.
Una trampa clásica es el manejo incorrecto de redirecciones:
Caddy reduce estos errores con valores por defecto sensatos. Con Nginx debes ser explícito y verificar el comportamiento de extremo a extremo.
Para certificados personalizados (comerciales, wildcard, CA privada), ambos servidores funcionan bien.
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.
Ambos pueden ponerse delante de tu app y reenviar peticiones limpiamente, pero los detalles importan.
Un buen setup de reverse proxy suele asegurar:
Host, X-Forwarded-Proto y X-Forwarded-For, para que la app construya redirecciones y logs correctos.Upgrade/Connection; en Caddy generalmente se maneja automáticamente al hacer proxy.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.
Las apps reales tocan casos límite: clientes lentos, llamadas API largas, server-sent events y subidas grandes.
Presta atención a:
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.
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.
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:
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 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.
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.
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.
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.
Comienza con cabeceras que reduzcan riesgos comunes:
Strict-Transport-Security: max-age=31536000; includeSubDomainsX-Frame-Options: DENY (o SAMEORIGIN si es necesario)X-Content-Type-Options: nosniffEl hardening es menos sobre una "config perfecta" y más sobre aplicar estos controles de forma consistente en cada app y endpoint.
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 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.
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:
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.
Elige Caddy si quieres HTTPS automático, una configuración corta y legible, y poner en marcha un despliegue pequeño/mediano con rapidez.
Elige Nginx si necesitas la máxima flexibilidad, si ya tienes un estándar Nginx en tu organización/proveedor, o si esperar apoyarte en patrones maduros para enrutado/caché/afinamiento complejos.
Para un dominio público, Caddy puede hacerlo con solo especificar la dirección del sitio y usar reverse_proxy o file_server. Tras apuntar el DNS al servidor, Caddy suele obtener y renovar certificados automáticamente.
Con Nginx, planifica usar un cliente ACME (por ejemplo Certbot), configurar ssl_certificate/ssl_certificate_key y asegurarte de que las renovaciones disparen un recarga del servidor.
Errores comunes en Nginx incluyen:
location (especialmente con expresiones regulares y reglas superpuestas)nginx -t)La Caddyfile se mantiene simple hasta que necesitas comportamientos muy específicos. En ese punto puede que necesites:
location de Nginx)Si tu infraestructura es inusual, haz un prototipo temprano para no descubrir límites a mitad de migración.
Caddy tiene buenas opciones para HTTPS local. Puedes generar y confiar certificados locales (por ejemplo con caddy trust), lo que ayuda a detectar problemas propios de HTTPS (cookies, redirecciones, contenido mixto) desde desarrollo.
En Nginx, HTTPS local suele ser manual (certificados autofirmados + advertencias del navegador o instalar una CA local), por lo que muchos equipos lo omiten y descubren problemas después.
Ambos pueden hacer proxy inverso correctamente, pero verifica:
Host, X-Forwarded-Proto, X-Forwarded-ForAmbos pueden balancear carga, pero céntrate en:
Si necesitas patrones muy granulares y probados, Nginx suele tener recetas más conocidas; para proxying multi-upstream sencillo, Caddy se configura rápido.
Atento a estos parámetros en cualquiera de los servidores:
Antes de producción, realiza pruebas realistas: sube un archivo grande, mantén una petición larga y confirma que timeouts y buffering entre proxy y upstream encajan con las expectativas de tu app.
Ambos pueden ser seguros, pero difieren en sus valores por defecto.
Checklist práctico:
Para una lista más profunda, consulta /blog/nginx-vs-caddy-security.
Usa un flujo “validar → recargar” y trata la configuración como código.
nginx -t y luego systemctl reload nginx (o nginx -s reload)En ambos casos, guarda configs en Git, despliega via CI/CD con un paso de validación y conserva un camino de rollback rápido.
/Upgrade/Connection; Caddy lo gestiona automáticamente al hacer proxy)Tras los cambios, prueba flujos de inicio de sesión y redirecciones absolutas para confirmar que la app ve el esquema y host correctos.