So beheben Sie Probleme mit einer Remote-App, die über die IP-Adresse, aber nicht über die Domain funktioniert

Wenn eine App über die IP-Adresse funktioniert, aber nicht über die Domain, ist der Server erreichbar. Die Ursache liegt meist bei DNS, hostnamenbasierter Weiterleitung, TLS oder Weiterleitungen.

Der Remotezugriff über die IP-Adresse beweist, dass ein Netzwerkpfad den Heimserver erreicht. Eine Anfrage an eine Domain übermittelt jedoch zusätzliche Identitätsinformationen über DNS, den TLS-Servernamen, den HTTP-Host-Header und die konfigurierte öffentliche URL der Anwendung. Die schnellste Diagnose verwendet denselben Client, Port und Server und prüft jede Identitätsebene der Reihe nach, anstatt Reverse-Proxy, Zertifikat und DNS-Einträge gleichzeitig zu ändern.

Bestätigen, dass der IP-Test den vorgesehenen Dienst erreicht

Notieren Sie die exakte IP-Adresse, den Port, das Protokoll und die Antwort, die remote funktionieren. Prüfen Sie, ob die IP-Adresse die eigentliche Anwendung, eine Standardseite des Reverse-Proxys, eine Router-Anmeldeseite oder einen anderen Dienst öffnet, der dieselbe öffentliche Adresse verwendet.

Eine Anleitung zu Reverse-Proxys im Homelab erklärt, dass ein Proxy mehrere Apps unter einer Adresse bereitstellen kann, weil er den angeforderten Host-Header prüft, bevor er den Upstream-Dienst auswählt.

Wenn die IP-Adresse nur eine Standardseite erreicht, beweist das, dass der Proxy erreichbar ist, nicht aber, dass die Route zur Zielanwendung funktioniert. Verwenden Sie ein eindeutiges Antwortmerkmal, etwa einen Seitentitel oder Header, damit spätere Tests den richtigen virtuellen Host erkennen.

Öffentliches DNS mit der funktionierenden IP-Adresse vergleichen

Fragen Sie die Domain über einen autoritativen Nameserver und mindestens einen externen rekursiven Resolver ab. Notieren Sie jede A- und AAAA-Antwort, die TTL sowie, ob ein CNAME auf einen anderen Hostnamen verweist.

Hinweise zum Self-Hosting weisen darauf hin, dass zwischengespeicherte Antworten bestehen bleiben können, bis die vorherige TTL abläuft. Daher können einige Clients nach der Korrektur des autoritativen Eintrags weiterhin ein älteres DNS-Ziel verwenden.

Wenn der A-Eintrag von der funktionierenden IP-Adresse abweicht, korrigieren Sie den Eintrag oder den DDNS-Updater. Wenn A korrekt ist, AAAA jedoch auf einen nicht erreichbaren IPv6-Pfad verweist, testen Sie beide Adressfamilien getrennt und entfernen oder reparieren Sie den fehlerhaften Eintrag.

Mit der funktionierenden IP-Adresse verbinden und die Domain beibehalten

Verwenden Sie einen Client, der sich mit der bekannten funktionierenden IP-Adresse verbinden kann und dabei die Domain als HTTP-Host-Header und TLS-Servernamen sendet. Dadurch ändern Sie das Ziel, ohne die Identität zu verwerfen, die der Proxy und das Zertifikat erwarten.

Server Fault erklärt, dass ein HTTP-Reverse-Proxy den Host-Header zur Auswahl einer Route verwenden kann, genauso wie namensbasierte virtuelle Hosts.

Wenn die Anfrage mit beibehaltener Domain funktioniert, liegt die Fehlerquelle bei DNS. Wenn sie den Proxy erreicht, aber die falsche Website oder einen 404-Fehler zurückgibt, prüfen Sie die Zuordnung der virtuellen Hosts und die Priorität der Routen. Wenn TLS bereits vor HTTP fehlschlägt, prüfen Sie SNI und die Zertifikatsauswahl.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

TLS-SNI und Zertifikatsidentität prüfen

Vergleichen Sie das für die Domain zurückgegebene Zertifikat mit dem Zertifikat, das für die reine IP-Adresse zurückgegeben wird. Notieren Sie die Namen des Betreffs, den Aussteller, das Ablaufdatum und, ob der Proxy ein Standardzertifikat bereitstellt.

SNI überträgt den Hostnamen im TLS-ClientHello, bevor die verschlüsselte HTTP-Anfrage gesendet wird. Dadurch kann der Proxy den sicheren virtuellen Host auswählen. Eine reine IP-Anfrage enthält den bei der TLS-Auswahl verwendeten Hostnamen möglicherweise nicht, selbst wenn sie denselben Listener erreicht.

Beheben Sie das Domainzertifikat und die SNI-Route, anstatt ein Zertifikat für eine private oder dynamische IP-Adresse zu erwarten. Wenn ein CDN oder TCP-Proxy vorgeschaltet ist, bestätigen Sie, dass SNI für den vorgesehenen Hostnamen weitergeleitet oder beendet wird.

Sicherstellen, dass internes und externes DNS nicht auf unterschiedliche Pfade verweist

Vergleichen Sie das Ergebnis der Domain über mobile Daten, einen öffentlichen Resolver und das Heimnetzwerk. Split-DNS kann zu Hause absichtlich eine private Proxy-Adresse und remote eine öffentliche Adresse zurückgeben. Beide Antworten müssen jedoch dieselbe logische Hostnamen-Route erreichen.

Eine Diskussion bei Level1Techs über Homelabs zeigt, dass der Zugriff auf einen lokalen Reverse-Proxy ein eigenes DNS-Konzept erfordern kann, wenn öffentliches DNS und das Routing zu Hause unterschiedliche interne und externe Pfade verwenden.

Wenn nur ein Resolver die falsche Adresse zurückgibt, korrigieren Sie diese DNS-Sicht. Wenn die öffentliche Adresse über die IP funktioniert, die Domain jedoch überall fehlschlägt, konzentrieren Sie sich auf Host, SNI, Zertifikat und die Identität der Anwendung statt auf Split-DNS.

Kanonische URLs und Weiterleitungen prüfen, bevor DNS als behoben gilt

Untersuchen Sie jede Weiterleitung, nachdem die Domain die Anwendung erreicht. Der Reverse-Proxy oder die Anwendung kann Clients an einen internen Hostnamen, eine alte Domain, das falsche Schema, einen privaten Port oder eine veraltete Callback-URL weiterleiten.

Der ZimaSpace-Artikel darüber, ob Split-DNS einen Fehler beheben kann, der nur innerhalb des Heimnetzwerks auftritt, behandelt den verwandten Fall, in dem der Hostname korrekt ist, sich die Route je nach Standort jedoch unterscheidet.

Das Problem ist erst gelöst, wenn das autoritative DNS die vorgesehene Adresse zurückgibt, die Domain das korrekte Zertifikat und die richtige Proxy-Route auswählt, Weiterleitungen den öffentlichen Hostnamen beibehalten und der vollständige Remote-Workflow ohne Ersetzen der Domain durch die IP-Adresse erfolgreich funktioniert.