Caddy vs Nginx en un VPS: la comparación de archivos de configuración

example.com {
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Las líneas TLS en el bloque de Nginx dan por hecho que Certbot ya se ejecutó. Para un upstream HTTP como el anterior, Caddy pasa el Host encabezado entrante tal cual y establece X-Forwarded-For, X-Forwarded-Proto, y X-Forwarded-Host de forma predeterminada. Con Nginx, normalmente añades los encabezados de proxy de forma explícita cuando el upstream necesita el host original, el esquema y la cadena de direcciones del cliente. Ese es el compromiso en miniatura: Caddy incluye valores predeterminados de proxy prácticos, mientras que Nginx hace explícito más de ese comportamiento.

Servicio de archivos estáticos:

Caddyfile

example.com {
    root * /var/www
    file_server
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    root /var/www;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

Autenticación básica, protegiendo todo detrás de un nombre de usuario y una contraseña:

Caddyfile

example.com {
    basic_auth {
        Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
    }
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    auth_basic           "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Ambas herramientas cifran la contraseña con hash fuera de banda. Caddy usa caddy hash-password; Nginx usa htpasswd para construir el archivo .htpasswd. La directiva es basic_auth en el Caddy actual, por cierto. Era basicauth hasta que v2.8.0 la renombró, como se indica en la documentación de basic_auth de Caddy, y los tutoriales antiguos siguen haciendo tropezar a la gente con ello.

Consejo pro: Ese hash en el Caddyfile no es la contraseña. Es la salida bcrypt de caddy hash-password. Ejecuta el comando y pega lo que imprime. Caddy rechaza las contraseñas en texto plano en la configuración, lo cual es el valor predeterminado correcto y una pequeña sorpresa la primera vez.

Las configuraciones hablan por sí solas. Caddy condensa TLS, encabezados de proxy razonables y una redirección en unas pocas líneas; Nginx es explícito y verboso y te entrega cada perilla. Si has pasado años en Nginx, la verbosidad es memoria muscular y el control es justo el punto. Si no, el Caddyfile es una configuración que puedes retener en la cabeza. El punto práctico es sencillo: la configuración de Caddy es más fácil de leer de un vistazo, mientras que Nginx te da un control más explícito.

Rendimiento y memoria: leer los benchmarks con cuidado

Las pruebas publicadas apuntan en la misma dirección general: Nginx suele usar menos memoria y a menudo lidera en rendimiento bruto, pero el tamaño de esa ventaja depende en gran medida del entorno.

In una prueba de un tercero en una VM de cuatro núcleos, Nginx alcanzó aproximadamente 48 000 solicitudes por segundo, frente a unas 42 000 de Caddy. La misma prueba reportó una latencia p99 de HTTPS de 2,1 ms para Nginx y 2,4 ms para Caddy. Trátalos como resultados de una sola configuración y no como un margen de rendimiento universal.

Los rangos de memoria de la tabla comparativa provienen de una prueba de VPS aparte. Otra prueba sintética con 50 000 conexiones concurrentes reportó 145 MB para Nginx y 520 MB para Caddy, pero esa prueba usó condiciones de hardware y carga de trabajo sustancialmente diferentes. Sus cifras absolutas no deben compararse directamente con los números de VPS de arriba.

La conclusión fiable es más acotada: Nginx generalmente tiene la menor huella de memoria y tiende a liderar en cargas de trabajo de alto rendimiento o alta concurrencia. Para un proxy inverso ordinario en un VPS de gama pequeña a media, ambos suelen ser lo bastante rápidos, así que la simplicidad operativa suele ser el factor decisivo más útil.

Conclusión de la sección: elige según la operativa, a menos que tu servidor tenga memoria limitada o tus propias pruebas de carga muestren que el rendimiento del proxy es el cuello de botella.

El truco del certificado comodín (Caddy no siempre es de configuración cero)

Caddy puede automatizar los certificados comodín, pero no con sus desafíos HTTP-01 o TLS-ALPN-01 predeterminados. Un certificado para *.example.com requiere validación DNS-01, que Let's Encrypt exige para los certificados comodín. Eso implica un plugin de proveedor de DNS (integrado en tu binario de Caddy mediante xcaddy) más un token de API para tu host de DNS, configurado en el bloque tls. No es la historia de escribe-una-línea-y-olvídate que Caddy promociona.

Esto pilla a los usuarios de homelab que ponen muchos servicios bajo un dominio real que controlan, como *.home.example.com, y dan por hecho que la emisión de comodines es tan automática como app.example.com. Para nombres puramente internos como *.homelab.internal, trátalo como territorio de PKI local/interna, no como un comodín público de Let's Encrypt. Para ser precisos: Caddy hace bien los comodines, simplemente no los hace con los desafíos predeterminados, y la configuración es un paso más que en el caso de un solo dominio. Nginx está en el mismo barco aquí, ya que el requisito de DNS-01 viene de Let's Encrypt, no del servidor.

Si quieres una GUI: Nginx Proxy Manager (un breve inciso)

Nginx Proxy Manager es un animal distinto de las dos herramientas anteriores, y merece un párrafo porque el nombre confunde a la gente. NPM es un envoltorio con GUI sobre Nginx: gestiona reglas de proxy inverso y certificados de Let's Encrypt a través de una interfaz web en el port 81. No es Nginx core, y no se configura como se configura Nginx core.

El compromiso es el habitual de clic frente a configuración. NPM es el botón fácil hasta que te sales del camino feliz. Su configuración se gestiona a través de una base de datos de la aplicación en lugar de un único archivo de configuración editado a mano. La configuración predeterminada de Docker usa SQLite, mientras que MySQL/MariaDB y PostgreSQL son opciones de base de datos externa admitidas. Esa diferencia también afecta a la portabilidad: una configuración de Caddy a menudo se puede mover copiando un único Caddyfile, mientras que un despliegue de Nginx Proxy Manager requiere que se conserven sus datos de aplicación y su base de datos . NPM es una buena elección si de verdad prefieres hacer clic a editar y tu configuración se mantiene simple. Es la elección equivocada para un flujo de trabajo de infraestructura como código.

Migrar de Nginx a Caddy (qué se traslada y qué no)

Si ya estás en Nginx y sopesas el cambio, empieza por rebajar tus expectativas sobre la automatización: existe un adaptador de configuración de NGINX para Caddy, pero está incompleto y no debe tratarse como un camino de migración fiable de un solo paso. Una migración de Nginx a Caddy es en su mayoría una reescritura manual, y la mayor parte se acorta.

Lo que se traslada y se simplifica, según la guía de conversión de la comunidad de Caddy:

• Para upstreams HTTP, reverse_proxy pasa el Host encabezado entrante tal cual y establece los encabezados X-Forwarded-* estándar de forma predeterminada, así que la mayoría de esas proxy_set_header líneas desaparecen.
• PHP se reduce de un bloque location con try_files más fastcgi_pass más un montón de parámetros a una única php_fastcgi directiva.
• El manejo de WebSocket es automático en Caddy v2. Si un tutorial te dice que añadas una websocket directiva aparte, es una reliquia de Caddy v1. Ignórala.

Lo que no se traslada automáticamente: cualquier cosa ligada a un módulo específico de Nginx que Caddy no tiene, la lógica compleja de rewrite y location que tendrás que replantear en lugar de portar, y las configuraciones de certificados comodín, que te devuelven a la configuración del desafío DNS de la sección anterior. Reserva tiempo para los módulos y las reescrituras; el resto suele ser una reducción neta de líneas.

¿Cuál deberías instalar? (La decisión)

Has visto las configuraciones, los números, el truco del comodín y el coste de migración, así que aquí queda la cosa. Instala Caddy si eres un desarrollador en solitario o un equipo pequeño, esto es un despliegue en un VPS recién creado, quieres TLS que configuras y olvidas, ejecutas Docker con enrutamiento simple, o simplemente quieres una configuración que quepa en la memoria muscular. Esa es la mayoría de quienes leen esto.

Instala Nginx si necesitas un control detallado o un módulo específico de su ecosistema maduro, estás exprimiendo el rendimiento de un servidor con memoria limitada, estás haciendo servicio de archivos estáticos de alta concurrencia, o tu equipo ya tiene una profunda experiencia en Nginx y un montón de configuraciones que funcionan. Son razones sólidas, y si una de ellas es la tuya, Nginx es la decisión correcta. Este no es un caso en el que la herramienta más antigua sea la herramienta equivocada.

Cualquiera que elijas, el siguiente paso es ponerlo en la máquina. Ambos Caddy y Nginx están disponibles como despliegues con un clic en nuestro marketplace, así que puedes saltarte el trabajo de instalación e ir directo al Caddyfile o al bloque de servidor. Un VPS de 1 GB es un punto de partida razonable para un despliegue de un solo sitio con poco tráfico, pero dimensiona el servidor según la aplicación y el tráfico que hay detrás del proxy, y no según el proxy por sí solo. Si usas Caddy como puerta de entrada para servicios autoalojados, puede situarse delante de un stack de monitorización con Prometheus y Grafana o de un despliegue de Uptime Kuma sin requerir herramientas de TLS aparte.

Conclusión de la sección: elige Caddy a menos que tengas una razón específica que apunte a Nginx.

Preguntas frecuentes