Caddy : einen Webservice in HTTPS mit einer minimalen Caddyfile veröffentlichen

Ihre Anwendung hört auf 127.0.0.1:3000. Lokal antwortet sie. Aus dem öffentlichen Bereich ist sie noch nicht richtig exponiert.

Caddy kann als Reverse-Proxy vor diesem Webdienst dienen und verwaltet HTTPS mit einem automatischen TLS-Zertifikat. Auf einem Debian- oder Ubuntu-VPS beginnen Sie damit, das Backend zu überprüfen, die öffentlichen Ports freizugeben, eine minimale Caddyfile zu erstellen und dann die HTTPS-Antwort von außen zu kontrollieren.

Domain, Backend und Ports überprüfen

Bevor Sie Caddy starten, muss der Domainname auf diesem Server ankommen. Überprüfen Sie auch die IPv6-Einträge: Ein alter AAAA-Eintrag zu einem anderen Rechner reicht aus, um die Ausstellung des Zertifikats zu blockieren.

Halten Sie eine SSH-Sitzung offen, bevor Sie die Firewall oder einen bereits bestehenden Proxy berühren.

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 )'

Ersetzen Sie app.exemple.net durch Ihren Namen. Die A- und AAAA-Einträge sollten auf die öffentliche IP-Adresse des VPS verweisen. curl -I sollte den von der Anwendung erwarteten Code zurückgeben, oft 200 oder 302.

Wenn das Backend nicht auf der lokalen Schleife antwortet, beheben Sie zuerst die Anwendung. Caddy repariert keinen gestoppten Dienst und keine falsche interne URL.

ss listet die Prozesse auf, die bereits an die Ports 80 und 443 gebunden sind. Trennen Sie nicht reflexartig Nginx oder Apache: Wählen Sie zuerst den Proxy, der diese Ports hält, und migrieren Sie dann gegebenenfalls ordnungsgemäß.

Caddyfile für Reverse-Proxy erstellen

Installieren Sie Caddy aus dem Paket, das für Ihre Distribution vorgesehen ist, und öffnen Sie /etc/caddy/Caddyfile. Für einen lokalen HTTP-Dienst genügt dieser Block:

app.exemple.net {
    reverse_proxy 127.0.0.1:3000
}

Die erste Zeile ist der öffentliche Name. reverse_proxy leitet die Anfragen an die Anwendung weiter, die auf 127.0.0.1:3000 hört.

Mit einer echten Domain fordert Caddy ein öffentlich anerkanntes Zertifikat an und erneuert es automatisch. Die Anwendung bleibt hinter dem Proxy und muss nicht im Internet mithören.

Auf demselben VPS behalten Sie 127.0.0.1 für das Backend bei. Sie vermeiden, den Anwendungsport im Netzwerk zu öffnen.

Wenn das Backend in einer anderen VM oder auf einem anderen Host lebt, verwenden Sie eine explizite private Adresse und filtern Sie den Datenverkehr zwischen den Maschinen.

Caddyfile vor dem Reload validieren

Laden Sie eine modifizierte Caddyfile nicht blind neu. Validieren Sie die Syntax, laden Sie den Dienst neu und überprüfen Sie dann dessen Status und Protokolle.

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 sollte ohne Fehler enden. systemctl reload caddy wendet die Konfiguration an, ohne den Daemon vollständig neu zu starten, wenn der Dienst das Neuladen akzeptiert.

Nach dem Reload sollte systemctl status active anzeigen. Wenn das Zertifikat nicht ausgestellt wird oder das Backend die Verbindung verweigert, verweist journalctl auf den nützlichen Fehler: DNS, belegter Port, Firewall oder abwesender lokaler Dienst.

HTTPS von einem anderen Rechner testen

Der lokale Test auf dem VPS ist nicht ausreichend. Starten Sie die Anforderung von einem Rechner, der über das Internet verbunden ist, oder von einem externen Monitoring-Tool.

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

Das erste curl sollte den erwarteten HTTP-Code anzeigen. Mit -v überprüfen Sie den Namen des Zertifikats, die TLS-Verhandlung und eventuelle Weiterleitungen.

Um eine HTTP-Antwort zu diagnostizieren, hilft der Leitfaden Curl unter Linux, die Header zu lesen. Die Überprüfung der offenen Ports dient dazu, einen Konflikt beim Mithören zu erkennen. Die Seite über die Systemd-Dienste vervollständigt die Überprüfung des Daemons vor einem Neustart.

Ein Caddy-Reverse-Proxy verschlüsselt den Datenverkehr zwischen dem Browser und dem Server, ersetzt jedoch nicht die Authentifizierung der Anwendung. Bevor Sie ein Administrationsdashboard exponieren, fügen Sie einen Schutz hinzu oder beschränken Sie den Zugang über IP, VPN oder Anwendungsregel.