Cómo configurar Caddy como reverse proxy en 2026 (HTTPS automático, Docker y cuándo elegirlo)

Un reverse proxy con Caddy coloca un servidor web pequeño y rápido delante de tus aplicaciones y le da a cada una un certificado HTTPS válido de forma automática, sin certbot, sin renovaciones por cron y, por lo general, con no más de tres líneas de configuración. Apunta un dominio a tu servidor, escribe example.com { reverse_proxy localhost:8080 }, arranca Caddy y ya tienes una puerta de entrada HTTPS lista para producción. Esta guía recorre la instalación de Caddy, la escritura del Caddyfile, su ejecución en Docker y cómo decidir cuándo Caddy es el reverse proxy adecuado frente a Nginx, Traefik o un Cloudflare Tunnel.

¿Qué es un reverse proxy con Caddy y por qué usarlo?

Un reverse proxy se sitúa entre internet público y tus aplicaciones. En lugar de exponer cada app en su propio puerto (el clásico desorden de server-ip:8080, server-ip:3000), el proxy escucha en los puertos 80 y 443, termina el TLS y enruta cada solicitud entrante al backend correcto según el nombre de host o la ruta. Eso te da URLs limpias, un único lugar para gestionar certificados y un único punto de control para cabeceras de seguridad y límites de tasa.

Caddy destaca porque el HTTPS automático está activado por defecto: si conoce el nombre de tu dominio, provisiona y renueva por ti un certificado de Let's Encrypt o ZeroSSL, y luego lo sigue renovando para siempre. Nginx y Traefik también pueden hacerlo, pero Caddy necesita la menor configuración para llegar ahí. Como lo expresó XDA, Caddy es "una forma realmente sencilla de obtener certificados SSL para tus apps autoalojadas", que es justo la tarea para la que la mayoría de la gente quiere un reverse proxy.

Instalar Caddy en Ubuntu o Debian

En un VPS recién creado con Ubuntu o Debian, instala Caddy desde su repositorio apt oficial. Estos son los comandos actuales de la documentación de Caddy:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Instalar mediante apt configura Caddy como un servicio de systemd que arranca al inicio y lee su configuración desde /etc/caddy/Caddyfile. Comprueba la versión con caddy version; a mediados de 2026 la versión estable actual es Caddy 2.11.4 (junio de 2026), y las versiones recientes de la serie 2.11.x parchearon problemas de seguridad, incluidos CVE-2026-27590 y CVE-2026-27589 (ambos corregidos en 2.11.1), así que ejecuta una compilación actualizada en lugar de la que se distribuyó hace un año. Si prefieres no tocar el host en absoluto, salta a la sección de Docker. Antes de exponer cualquier cosa públicamente, asegúrate de que la propia máquina esté bien protegida primero, según nuestra guía sobre la primera hora segura en un nuevo VPS.

El Caddyfile mínimo: una línea para HTTPS automático

Todo el sentido de Caddy está en lo poco que tienes que escribir. Edita /etc/caddy/Caddyfile para que contenga un bloque de sitio con tu dominio real y la dirección local de la app que quieres exponer:

example.com {
    reverse_proxy localhost:8080
}

Recarga con sudo systemctl reload caddy (o caddy reload si lo ejecutas manualmente) y listo. Al arrancar, Caddy escucha en los puertos 80 y 443, solicita un certificado de confianza para example.com y enruta el tráfico a tu app en el puerto 8080. Deben cumplirse dos cosas para que se emita el certificado: un registro DNS A/AAAA del dominio debe apuntar al servidor, y los puertos 80 y 443 deben estar abiertos a internet público para que el desafío ACME pueda completarse. Para una prueba local rápida sin dominio, usa localhost como dirección del sitio y Caddy instalará su propio certificado autofirmado. Adquiere el hábito de ejecutar caddy validate --config /etc/caddy/Caddyfile antes de cada recarga; detecta erratas antes de que tumben un sitio.

Enrutar varias apps y subdominios

Ejecutar varios servicios detrás de un solo servidor es donde un reverse proxy demuestra su valor. Cada app obtiene su propio bloque, y Caddy enruta por nombre de host de forma automática, provisionando un certificado independiente para cada dominio:

app.example.com {
    reverse_proxy localhost:3000
}

grafana.example.com {
    reverse_proxy localhost:3001
}

api.example.com {
    reverse_proxy localhost:5000
}

También puedes dividir por ruta dentro de un mismo dominio usando un bloque handle_path o route, algo útil cuando una app debería vivir en example.com/api en lugar de su propio subdominio. Caddy gestiona las actualizaciones de WebSocket automáticamente, por lo que las apps en tiempo real funcionan sin directivas adicionales, y desde Caddy 2.11 reescribe automáticamente la cabecera Host del upstream para upstreams HTTPS, eliminando una fuente habitual de errores del tipo "funciona en el puerto 8080 pero no a través del proxy". Este patrón de un subdominio por app encaja de forma natural con una flota de servicios pequeños, del tipo que cubrimos en nuestro tutorial sobre autoalojar tus apps en un VPS.

Caddy en Docker con Docker Compose

La mayoría de los autoalojadores ejecutan Caddy en un contenedor junto a las apps que sirve. La imagen oficial caddy reduce esto a unas pocas líneas de Compose. El único detalle que la gente pasa por alto es el volumen caddy_data: almacena los certificados emitidos, y sin él cada reinicio del contenedor vuelve a solicitar certificados y puede toparse con los límites de tasa de Let's Encrypt.

services:
  caddy:
    image: caddy:2.11
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
  app:
    image: your-app-image
    restart: unless-stopped

volumes:
  caddy_data:
  caddy_config:

Como ambos contenedores comparten una red de Compose, el Caddyfile puede llegar a la app por su nombre de servicio en lugar de localhost:

app.example.com {
    reverse_proxy app:8080
}

Esa es toda la configuración: docker compose up -d, y Caddy sirve app.example.com sobre HTTPS con certificados de renovación automática. Si prefieres que un panel de control lleve todo esto por ti, una plataforma como Coolify envuelve la misma idea; consulta nuestra guía para desplegar cualquier app con Coolify.

Caddy vs Nginx vs Traefik: ¿qué reverse proxy deberías elegir?

Los tres son sólidos, y la elección correcta depende de cómo despliegues. Caddy gana en simplicidad y HTTPS listo para usar, Nginx gana en pura ubicuidad y profundidad de ajuste, y Traefik gana cuando quieres que el proxy se configure a sí mismo a partir de etiquetas de contenedor.

Reverse proxy	Estilo de configuración	HTTPS automático	Encaje con Docker	Ideal para
Caddy	Caddyfile (unas pocas líneas)	Sí, por defecto	Configuración simple y explícita	Autoalojadores que quieren HTTPS con casi nada de configuración
Nginx	Directivas de nginx.conf	No (necesita certbot)	Manual, muy maduro	Ajuste de alto tráfico y equipos con Nginx existente
Traefik	Etiquetas de contenedor / YAML	Sí, con configuración	Autodescubre contenedores	Flotas dinámicas de Docker y Kubernetes basadas en etiquetas

Si empiezas desde cero y solo quieres un puñado de servicios sobre HTTPS, Caddy es el camino más rápido. Elige Nginx si ya lo conoces o necesitas su enorme ecosistema de módulos y controles de rendimiento de grano fino. Elige Traefik si tu stack es muy dinámico y quieres que el proxy se reconfigure a sí mismo a medida que los contenedores aparecen y desaparecen, y no te importa tener más piezas móviles para lograrlo.

Dónde encaja Caddy frente a un Cloudflare Tunnel

Un reverse proxy y un túnel resuelven problemas solapados de formas opuestas, y vale la pena saber cuál necesitas realmente. Caddy espera que los puertos entrantes 80 y 443 estén abiertos para poder aceptar tráfico público y emitir certificados directamente. Eso es ideal en un VPS con IP pública. Un Cloudflare Tunnel, en cambio, establece una conexión saliente hacia Cloudflare y no necesita ningún puerto entrante abierto, lo que encaja mejor detrás de un router doméstico o un NAT restrictivo donde no puedes redirigir puertos.

No son mutuamente excluyentes. Una configuración habitual ejecuta Caddy como el reverse proxy local que enruta hacia tus apps y termina el TLS interno, mientras un Cloudflare Tunnel se encarga de la exposición pública y la protección en el borde. Si tu servidor tiene una IP pública y quieres el stack más simple posible, Caddy por sí solo es suficiente. Si alojas desde una conexión doméstica o quieres la protección DDoS de Cloudflare por delante, recurre al túnel, o combina ambos.

Preguntas frecuentes

¿Caddy es gratis? Sí. Caddy es de código abierto bajo la licencia Apache 2.0 y gratuito para cualquier uso, incluido el comercial. No hay un nivel de pago para las funciones de reverse proxy, y el HTTPS automático vía Let's Encrypt y ZeroSSL no cuesta nada.

¿Caddy renueva los certificados SSL automáticamente? Sí. Una vez que Caddy emite un certificado para un dominio, gestiona la renovación por su cuenta, normalmente bastante antes del vencimiento, sin cron ni certbot. Mantén persistente el directorio /data (o el volumen de Docker caddy_data) para que los certificados sobrevivan a los reinicios.

¿Caddy vs Nginx: cuál es mejor para un reverse proxy? Para la mayoría de las configuraciones autoalojadas, Caddy es más fácil porque el HTTPS es automático y la configuración son unas pocas líneas. Nginx es mejor si necesitas su maduro ecosistema de módulos, estás ajustando para tráfico muy alto o ya lo ejecutas. Ambos son reverse proxies de nivel de producción.

¿Puedo ejecutar Caddy como reverse proxy en Docker? Sí, y es la forma más común de ejecutarlo. Usa la imagen oficial caddy, monta tu Caddyfile y haz persistente el volumen caddy_data para que los certificados no se vuelvan a solicitar en cada reinicio. Referencia las apps por su nombre de servicio de Compose en lugar de localhost.

¿Necesito abrir algún puerto? Caddy necesita que los puertos 80 y 443 sean accesibles desde internet para emitir certificados públicos y servir tráfico. Si no puedes abrir puertos entrantes, usa en su lugar un Cloudflare Tunnel, que funciona a través de una conexión saliente.

Fuentes

• Caddy — Inicio rápido del reverse proxy: el Caddyfile mínimo oficial, la forma del comando de una línea y cómo el HTTPS automático usa los puertos 80/443.
• Caddy — Documentación de instalación: los comandos apt actuales de Debian/Ubuntu y la imagen oficial de Docker.
• Caddy — Releases de GitHub: 2.11.4 estable (junio de 2026), la cabecera Host automática del upstream para upstreams HTTPS desde 2.11 y las correcciones de CVE-2026-27590 / 27589 (2.11.1).
• XDA — Caddy es mi nuevo reverse proxy favorito: opinión de un tercero sobre la facilidad de Caddy para obtener SSL para apps autoalojadas.
• Documentación de Traefik: reverse proxy basado en etiquetas y con autodescubrimiento para flotas dinámicas de Docker/Kubernetes.