Warum funktioniert ein Reverse-Proxy über die Domain, aber nicht über die lokale IP?

Ein Reverse-Proxy funktioniert nach Domain, da seine Routing- und TLS-Regeln oft vom angeforderten Hostnamen abhängen und nicht nur von der Ziel-IP.

Wenn ein Heimclient https://app.example.com öffnet, liefert DNS eine IP, aber der Browser sendet die Domain weiterhin während des TLS-Handshakes und im HTTP-Host-Header. Das Öffnen von https://192.168.1.20 ändert diese Identifikatoren, sodass der Proxy möglicherweise eine Standardseite auswählt, das Zertifikat ablehnt, die Anwendungsroute verfehlt oder zurück zur konfigurierten öffentlichen URL umleitet. Der korrekte Test bewahrt den beabsichtigten Hostnamen und ändert nur das Netzwerkziel.

Vergleichen Sie die Hostnamen-Anfrage mit der Direkt-IP-Anfrage

Senden Sie eine Anfrage an die Domain und eine an die lokale IP und vergleichen Sie dann Statuscode, Zertifikat, Antwortheader, Weiterleitungsziel und Reverse-Proxy-Zugriffsprotokoll. Gehen Sie nicht davon aus, dass beide Anfragen gleichwertig sind, nur weil sie dieselbe Ethernet-Schnittstelle erreichen.

Ein Homelab-Reverse-Proxy-Leitfaden erklärt, dass der Proxy den HTTP-Host-Header inspiziert, um mehrere Dienste über eine IP und einen Port zu routen.

Wenn die Domain-Anfrage mit einer Anwendungsroute übereinstimmt, während die IP-Anfrage eine Standardseite oder 404 trifft, arbeitet der Proxy wie konfiguriert. Die nächste Entscheidung ist, ob der Direkt-IP-Zugriff tatsächlich erforderlich ist oder ob lokales DNS die Domain erhalten sollte.

Testen Sie die lokale IP unter Beibehaltung des beabsichtigten Host-Headers

Verwenden Sie ein Client-Tool, das sich mit der lokalen Proxy-IP verbindet und dabei die Anwendungsdomain als Host-Header sendet. Bei HTTPS bewahren Sie auch die Domain als TLS-Servernamen, anstatt sie durch die IP zu ersetzen.

Server Fault beschreibt, wie ein HTTP-Reverse-Proxy den Host-Header zur Routenwahl ähnlich wie bei namensbasierten virtuellen Hosts verwendet.

Wenn die erzwungene Host-Anfrage erfolgreich ist, sind Proxy-Route und Backend gesund; ein Fehler bei der Direkt-IP ist eine Identitätsabweichung. Wenn sie weiterhin fehlschlägt, prüfen Sie den Listener, lokale Firewall, Proxy-Einstiegspunkt und Routenpriorität, bevor Sie DNS ändern.

Überprüfen Sie TLS SNI und Zertifikatsübereinstimmung

HTTPS fügt eine Hostnamenentscheidung vor der HTTP-Anfrage hinzu. Der Client sendet normalerweise Server Name Indication während des TLS-Handshakes, damit der Proxy das richtige Zertifikat und den sicheren virtuellen Host auswählen kann.

Eine SNI-Reverse-Proxy-Implementierung stellt fest, dass HTTPS-Backends anhand des SNI-Hostnamens des Clients ausgewählt werden, bevor gewöhnliche HTTP-Header geprüft werden können.

Direkter Zugriff per IP kann ein Standardzertifikat präsentieren oder die Hostnamenvalidierung fehlschlagen, selbst wenn der Proxy erreichbar ist. Verwenden Sie die Domain mit lokalem DNS oder setzen Sie ein gezielt verwaltetes Zertifikat ein, das nur die IP enthält, wenn Direkt-IP-HTTPS eine echte betriebliche Anforderung ist.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Überprüfen Sie die Standardseite und Routenpriorität

Prüfen Sie, welcher virtuelle Host Anfragen behandelt, die keiner konfigurierten Domain entsprechen. Eine Standardseite kann ein Dashboard zurückgeben, zu einem anderen Hostnamen weiterleiten, die Verbindung schließen oder eine generische Fehlermeldung anzeigen.

Eine Caddy-Diskussion zeigt, dass eine Anfrage die korrekte Proxy-IP erreichen kann, während der Host-Header und TLS-Name weiterhin bestimmen, ob das beabsichtigte Upstream ausgewählt wird.

Halten Sie die Standardroute explizit und sicher. Fügen Sie keinen breit gefassten Catch-All-Proxy zu einem Backend hinzu, nur um den IP-Zugriff zu ermöglichen, da dies unbekannte Hostnamen oder Scan-Verkehr in eine Anwendung leiten kann, die eigentlich domainbeschränkt sein sollte.

Prüfen Sie, ob die Anwendung auf ihre kanonische URL umleitet

Auch wenn der Proxy die IP-Anfrage akzeptiert, kann das Backend eine konfigurierte öffentliche Basis-URL erzwingen und den Browser zur Domain umleiten. Authentifizierungs-Cookies, OAuth-Callbacks, WebSocket-Ursprünge und CSRF-Prüfungen können ebenfalls von diesem kanonischen Host abhängen.

Vergleichen Sie das Proxy-Protokoll mit dem Anwendungsprotokoll und prüfen Sie den Location-Header. Eine Weiterleitung zur Domain ist kein Routing-Fehler; sie zeigt, dass die Anwendung eine öffentliche Identität erwartet.

Korrigieren Sie weitergeleitete Host- und Protokoll-Header, wenn die App die falsche externe URL generiert. Ersetzen Sie die kanonische Domain nicht durch eine private IP, nur um die Weiterleitung zu umgehen, da dies Zertifikate und Fernzugriff beeinträchtigen kann.

Verwenden Sie lokales DNS, wenn die Domain die beabsichtigte Schnittstelle ist

Erstellen Sie einen internen DNS-Eintrag, der die Anwendungsdomain auf die lokale Reverse-Proxy-Adresse auflöst. Der Browser nutzt dann den effizienten LAN-Pfad und bewahrt dabei denselben Host-Header, SNI-Namen, das Zertifikat, Cookies und die Anwendungs-URL.

Der ZimaSpace-Vergleich von Reverse-Proxies und privaten Zugriffswegen hilft bei der Entscheidung, ob die Domain ein lokaler und öffentlicher Einstiegspunkt bleiben oder hinter einem privaten Netzwerk verborgen werden soll.

Das Problem ist gelöst, wenn die Domain sowohl innen als auch außen durch gezielte DNS-Antworten funktioniert, während die Direkt-IP entweder eine dokumentierte Standardseite erreicht oder bewusst abgelehnt wird. Ein domaingesteuerter Proxy muss sich nicht wie ein einzelner Server mit IP-Adresse verhalten.