Caddy : een webservice publiceren in HTTPS met een minimale Caddyfile

Uw applicatie luistert op 127.0.0.1:3000. Lokaal reageert het. Vanuit het publieke domein is het nog niet correct blootgesteld.

Caddy kan dienen als reverse proxy voor deze webservice en HTTPS beheren met een automatisch TLS-certificaat. Op een Debian of Ubuntu VPS, begin met het controleren van de backend, open de publieke poorten, stel een minimale Caddyfile op en controleer de HTTPS-reactie van buitenaf.

Controleer het domein, de backend en de poorten

Voordat je Caddy start, moet de domeinnaam op deze server aankomen. Controleer ook de IPv6-records: een oude AAAA-invoer naar een andere machine kan de uitgifte van het certificaat blokkeren.

Houd een SSH-sessie open voordat je de firewall of een al aanwezig proxy aanraakt.

dig +short A app.exemple.net
dig +short AAAA app.exemple.net
curl -I http://127.0.0.1:3000/
sudo ss -lntp '( sport = :80 or sport = :443 )'

Vervang app.exemple.net door uw naam. De A- en AAAA-records moeten naar het publieke adres van de VPS wijzen. curl -I moet de verwachte code van de applicatie teruggeven, vaak 200 of 302.

Als de backend niet reageert op de lokale loopback, corrigeer dan eerst de applicatie. Caddy zal geen stopgezette service of een verkeerde interne URL repareren.

ss toont de processen die al aan de poorten 80 en 443 zijn gekoppeld. Sluit Nginx of Apache niet uit gewoonte af: kies eerst de proxy die deze poorten bewaart, en migreer indien nodig op een nette manier.

Maak een Caddyfile voor reverse proxy

Installeer Caddy vanuit het voorgeschreven pakket voor uw distributie en open dan /etc/caddy/Caddyfile. Voor een lokale HTTP-service is dit blok voldoende:

app.exemple.net {
    reverse_proxy 127.0.0.1:3000
}

De eerste regel is de publieke naam. reverse_proxy stuurt de verzoeken naar de applicatie die luistert op 127.0.0.1:3000.

Met een echt domein vraagt Caddy een publiek erkend certificaat aan en renewt dit automatisch. De applicatie blijft achter de proxy en hoeft niet op het internet te luisteren.

Op dezelfde VPS houdt u 127.0.0.1 voor de backend. U voorkomt dat de applicatiepoort op het netwerk wordt geopend.

Als de backend zich in een andere VM of op een andere host bevindt, gebruik dan een expliciet privé-adres en filter het verkeer tussen de machines.

Valideer de Caddyfile voor het opnieuw laden

Herlaad geen gewijzigde Caddyfile blindelings. Valideer de syntaxis, laad de service opnieuw, en controleer vervolgens zijn status en 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-pager

caddy validate moet eindigen zonder fout. systemctl reload caddy past de configuratie toe zonder de daemon volledig te herstarten, wanneer de service herladen is toegestaan.

Na het herladen moet systemctl status active tonen. Als het certificaat niet is uitgegeven of de backend de verbinding weigert, wijst journalctl naar de nuttige fout: DNS, bezette poort, firewall of afwezig lokale service.

Test HTTPS vanaf een andere machine

De lokale test op de VPS is niet voldoende. Voer het verzoek uit vanaf een machine die via internet gaat of vanuit een externe probe.

curl -I https://app.exemple.net/
curl -v https://app.exemple.net/ -o /dev/null

De eerste curl moet de verwachte HTTP-code tonen. Met -v, controleer de naam van het certificaat, de TLS-onderhandeling en eventuele omleidingen.

Voor het diagnosticeren van een HTTP-reactie helpt de gids Curl onder Linux om de headers te lezen. De controle van open poorten helpt bij het opsporen van een luisterconflict. De pagina over systemd-services voltooit de controle van de daemon voordat deze opnieuw wordt opgestart.

Een Caddy reverse proxy versleutelt het verkeer tussen de browser en de server, maar vervangt de authenticatie van de applicatie niet. Voordat u een beheerscherm blootstelt, voegt u een beveiliging toe of beperkt u de toegang via IP, VPN of applicatieregel.