Verfolgen Sie eine Anfrage von DNS bis zu Ihrer App.

Schreiben Sie die Route auf, die Sie erwarten

Diese Schritt-für-Schritt-Anleitung setzt einen von Ihnen administrierten Linux VPS, eine funktionierende SSH-Sitzung, eine Anwendung mit einem harmlosen /healthz Endpunkt und Zugriff auf die autoritativen DNS-Einstellungen für eine von Ihnen kontrollierte Domain voraus. Die Beispiel-App lauscht auf 127.0.0.1:3000; Caddy ist der öffentliche Reverse-Proxy. Wenn Ihre App einen anderen Supervisor oder Proxy verwendet, behalten Sie die Diagnosereihenfolge bei und verwenden Sie deren Dokumentation.

api.example.com und 203.0.113.10 sind Dokumentationsplatzhalter, kein Live-Dienst. Ersetzen Sie beide, bevor Sie Prüfungen gegen Ihr eigenes System ausführen. Notieren Sie den echten Hostnamen, die beabsichtigte IP-Adresse, den App-Port und den Dienstnamen an einer Stelle. Das Festlegen eines VPS-Hostnamens im Konfigurator erstellt keinen öffentlichen DNS-Eintrag.

1. DNS gibt die beabsichtigte Adresse zurück.
2. Die Verbindung erreicht den beabsichtigten Server und Port.
3. TLS authentifiziert den angeforderten Hostnamen.
4. Der Proxy leitet die Anfrage an den richtigen Upstream weiter.
5. Die Anwendung gibt die erwartete Antwort zurück.

Prüfen Sie beide Adressfamilien

Fragen Sie von einem Rechner außerhalb des VPS die Einträge ab, die Sie veröffentlichen möchten. dig gehört zu BINDs DNS-Werkzeugen; Paketnamen variieren. Diese Befehle fordern den Antwortabschnitt an, damit Sie Eintragstyp, Adresse und verbleibende Cache-Lebensdauer sehen können. Siehe die BIND dig-Referenz.

dig api.example.com A +noall +answer
dig api.example.com AAAA +noall +answer

Vergleichen Sie jede zurückgegebene Adresse mit Ihrem beabsichtigten Ziel. Veröffentlichen Sie einen AAAA-Eintrag nur, wenn IPv6-Routing, Listening und Filterung für diese Adresse funktionieren. Ein alter AAAA-Eintrag kann einige Clients an einen anderen Ort als den A-Eintrag senden. Wenn Sie absichtlich ein CDN oder einen DNS-Proxy verwenden, können dessen Adressen korrekt sein; zeichnen Sie diesen zusätzlichen Hop auf, anstatt anzunehmen, dass der VPS erscheinen muss.

Eine leere Antwort erfordert einen genaueren Blick auf die vollständige dig Antwort: Sie kann bedeuten, dass kein Eintrag dieses Typs vorhanden ist, ein Name nicht existiert oder ein Auflösungsproblem vorliegt. Prüfen Sie, welcher DNS-Dienst autoritativ ist, bevor Sie bearbeiten. Zeichnen Sie den alten Wert und TTL auf, nehmen Sie die beabsichtigte Änderung dort vor und vergleichen Sie dann frische Ergebnisse, nachdem bestehende Caches abgelaufen sind. Wiederholte zusammenhanglose Änderungen machen die Zeitleiste schwerer verständlich.

Trennen Sie Verbindungsfehler von Zertifikatsfehlern

Fordern Sie den kleinen Endpunkt von außerhalb des Servers an. Verwenden Sie GET, anstatt davon auszugehen, dass Ihre Anwendung HEAD implementiert. Curls Timeout-Optionen begrenzen die Prüfung; seine ausführliche Ausgabe zeigt Verbindungs- und TLS-Fortschritt. Curl dokumentiert diese Optionen und die Zertifikatsverifizierung.

curl --verbose --connect-timeout 5 --max-time 10 https://api.example.com/healthz

Ein Auflösungsfehler weist zurück auf DNS. Eine verweigerte Verbindung bedeutet, dass die Verbindung aktiv abgelehnt wurde; ein Timeout kann Routing oder Filterung betreffen und identifiziert nicht, welche Firewall ihn verursacht hat. Ein Zertifikatsfehler bedeutet, dass die erwartete sichere Verbindung nicht hergestellt wurde. Machen Sie das Deaktivieren von Zertifikatsprüfungen nicht zu Ihrer dauerhaften Lösung.

Um einen bestimmten Origin zu vergleichen und dabei den Hostnamen in der TLS-Anfrage beizubehalten, verwenden Sie Curls Adressüberschreibung:

curl --verbose --connect-timeout 5 --max-time 10 --resolve api.example.com:443:203.0.113.10 https://api.example.com/healthz

Wenn dies gelingt, während die gewöhnliche Anfrage fehlschlägt, vergleichen Sie DNS und etwaige Zwischenstellen. Diese Übersteuerung bearbeitet DNS nicht. Wenn sowohl A- als auch AAAA-Einträge existieren, wiederholen Sie die gewöhnliche Anfrage mit --ipv4 und --ipv6 von einem Client, der das entsprechende Netzwerk tatsächlich unterstützt.

Untersuchen Sie das Serverende der Verbindung

Untersuchen Sie auf dem VPS lauschende TCP-Sockets und fragen Sie die App direkt ab:

sudo ss -ltnp
curl --silent --show-error --max-time 5 http://127.0.0.1:3000/healthz

ss zeigt Listener und, mit ausreichenden Berechtigungen, deren Prozesse an. Ein Loopback-Listener ist lokal erreichbar; sein Vorhandensein allein sagt nichts über den externen Zugriff aus. Konsultieren Sie das upstream ss-Handbuch. Wenn die direkte App-Anfrage fehlschlägt, wechseln Sie zum Leitfaden zur Prozessdiagnose bevor Sie DNS ändern.

Für dieses Single-App-Layout ist der relevante Caddyfile-Block:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Der Hostname und der Upstream müssen zu Ihrer Anwendung passen. Caddys reverse proxy directive leitet Anfragen an den konfigurierten Upstream weiter; das Platzieren einer beliebigen Domain hier gibt Ihnen keine Kontrolle darüber. Bewahren Sie die bestehende Konfiguration vor der Bearbeitung auf. Validieren Sie mit dem paketierten Dienst und diesem Dateipfad zuerst und laden Sie erst nach erfolgreicher Validierung neu:

sudo caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
sudo systemctl reload caddy

Die Befehle haben unterschiedliche Zwecke: Die Validierung prüft das Laden der Konfiguration, während das Neuladen die Änderung anwendet. Prüfen Sie den tatsächlichen Dateipfad und die Berechtigungen des installierten Dienstes. Caddys Befehlsreferenz erklärt das Validierungs- und Neuladeverhalten.

Verifizieren Sie den vollständigen Pfad und behalten Sie dann die Beweise

Für die gewöhnliche öffentliche Zertifikatsautomatisierung benötigt Caddy korrektes DNS, extern erreichbare Challenge-Ports, die Berechtigung zum Binden seiner Listener und persistenten beschreibbaren Zertifikatsspeicher. Die HTTP- und TLS-ALPN-Challenges verwenden die Ports 80 bzw. 443; eine DNS-Challenge ist eine separate Einrichtung. Siehe Caddys HTTPS-Voraussetzungen. Halten Sie den administrativen Zugriff intakt, wenn Sie Firewall-Regeln überprüfen.

Beispielhaftes Ergebnis: der lokale Endpunkt liefert {"status":"ok"}, die externe HTTPS-Anfrage liefert denselben kleinen Body und curl meldet eine erfolgreiche Zertifikatsüberprüfung. Dies sind erwartete Beobachtungen für dieses Beispiel, keine aufgezeichneten Ergebnisse von einem OffVPS-Server. Üben Sie außerdem eine normale Anwendungsaktion aus: Ein oberflächlicher Health-Endpunkt kann erfolgreich sein, während eine datenbankabhängige Route fehlschlägt.

Notieren Sie die Anforderungszeit, den Hostnamen, die Adressfamilie und die erste fehlgeschlagene Ebene. Diese kurze Beschreibung ist nützlicher als „die Domain ist kaputt“. Sobald der Pfad funktioniert, verwenden Sie den Leitfaden für wiederholbare Releases , um dieselben Prüfungen in jede Bereitstellung aufzunehmen.