Una aplicación detrás de un proxy inverso

Muchas aplicaciones tienen su propio pequeño servidor web en un puerto, como 3001 o 5678. Ese puerto no se abre a Internet. Su servidor web recibe el tráfico en el 443 con https y lo pasa a la aplicación: un proxy inverso.

Con Caddy

Si la aplicación escucha en el propio servidor en el puerto 3001:

status.example.com {
	reverse_proxy 127.0.0.1:3001
}

Caddy pasa automáticamente los encabezados correctos (como X-Forwarded-For y X-Forwarded-Proto) y los websockets. Si la aplicación se ejecuta en Docker junto a Caddy, utilice el nombre del contenedor, como en Su carpeta de trabajo con compose.yaml, .env y Caddy.

Con nginx

server {
    listen 80;
    listen [::]:80;
    server_name status.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        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;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

A continuación, sudo nginx -t, sudo systemctl reload nginx y sudo certbot --nginx -d status.example.com.

Conviene saber

• Haga que la aplicación escuche solo en 127.0.0.1, no en todas las direcciones. Así nadie puede eludir su proxy.
• Muchas aplicaciones necesitan saber en qué dirección están accesibles, por ejemplo con un ajuste como DOMAIN o N8N_HOST. Indique ahí la dirección https.
• Proteja de forma adicional un panel de administración que no sea para todo el mundo: con una contraseña en la propia aplicación, con verificación en dos pasos o solo a través de un túnel SSH (consulte Una configuración SSH: iniciar sesión con un nombre corto).
• Los encabezados de seguridad adicionales, como HSTS, se configuran con header en Caddy o add_header en nginx. Active HSTS solo cuando https funcione correctamente en todas partes.