Su aplicación escucha en 127.0.0.1:3000. En local, responde. Desde el dominio público, aún no está expuesta correctamente.
Caddy puede actuar como un reverse proxy frente a este servicio web y gestionar HTTPS con un certificado TLS automático. En un VPS Debian o Ubuntu, comience por verificar el backend, liberar los puertos públicos, colocar un Caddyfile minimal, y luego controlar la respuesta HTTPS desde el exterior.
Verificar el dominio, el backend y los puertos
Antes de lanzar Caddy, el nombre de dominio debe apuntar a este servidor. Verifique también los registros IPv6: una antigua entrada AAAA hacia otra máquina puede bloquear la emisión del certificado.
Mantenga una sesión SSH abierta antes de tocar el cortafuegos o un proxy que ya está en su lugar.
dig +short A app.ejemplo.net
dig +short AAAA app.ejemplo.net
curl -I http://127.0.0.1:3000/
sudo ss -lntp '( sport = :80 or sport = :443 )'Reemplace app.ejemplo.net por su nombre. Los registros A y AAAA deben apuntar a la dirección pública del VPS. curl -I debe devolver el código esperado por la aplicación, a menudo 200 o 302.
Si el backend no responde en la loopback, primero corrija la aplicación. Caddy no reparará ni un servicio detenido ni una mala URL interna.
ss lista los procesos ya adjuntos a los puertos 80 y 443. No corte Nginx o Apache por reflejo: elija primero el proxy que ocupa estos puertos y luego migre adecuadamente si es necesario.
Crear un Caddyfile de reverse proxy
Instale Caddy desde el paquete previsto para su distribución, luego abra /etc/caddy/Caddyfile. Para un servicio HTTP local, este bloque es suficiente:
app.ejemplo.net {
reverse_proxy 127.0.0.1:3000
}La primera línea es el nombre público. reverse_proxy transmite las solicitudes a la aplicación que escucha en 127.0.0.1:3000.
Con un dominio real, Caddy solicita un certificado públicamente reconocido y lo renueva automáticamente. La aplicación permanece detrás del proxy y no necesita escuchar en Internet.
En un mismo VPS, mantenga 127.0.0.1 para el backend. Así evita abrir el puerto de la aplicación en la red.
Si el backend está en otra VM o en otro host, utilice una dirección privada explícita y filtre el tráfico entre las máquinas.
Validar el Caddyfile antes del reload
No recargue un Caddyfile modificado a ciegas. Valide la sintaxis, recargue el servicio y luego revise su estado y sus logs.
sudo caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
sudo systemctl reload caddy
sudo systemctl status caddy --no-pager
sudo journalctl -u caddy -n 50 --no-pagercaddy validate debe terminar sin errores. systemctl reload caddy aplica la configuración sin reiniciar completamente el demonio, cuando el servicio acepta la recarga.
Después del reload, systemctl status debe mostrar active. Si el certificado no se emite o si el backend rechaza la conexión, journalctl apunta hacia el error útil: DNS, puerto ocupado, cortafuegos o servicio local ausente.
Probar HTTPS desde otra máquina
La prueba local en el VPS no es suficiente. Lance la solicitud desde una máquina que pase por Internet o desde un sensor externo.
curl -I https://app.ejemplo.net/
curl -v https://app.ejemplo.net/ -o /dev/nullEl primer curl debe mostrar el código HTTP esperado. Con -v, controle el nombre del certificado, la negociación TLS y las posibles redirecciones.
Para diagnosticar una respuesta HTTP, la guía Curl en Linux ayuda a leer las cabeceras. El control de los puertos abiertos sirve para detectar un conflicto de escucha. La página sobre los servicios systemd completa la verificación del demonio antes de un reinicio.
Un reverse proxy Caddy cifra el tráfico entre el navegador y el servidor, pero no reemplaza la autenticación de la aplicación. Antes de exponer un panel de administración, añada protección o limite el acceso por IP, VPN o regla de aplicación.