Was verursacht, dass lokales DNS die richtige IP-Adresse, aber den falschen Dienst zurückgibt?

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Lokales DNS kann zwar die korrekte NAS-IP-Adresse zurückgeben, aber dennoch den falschen Dienst öffnen, wenn der gemeinsam genutzte Reverse-Proxy den Hostnamen an einen anderen virtuellen Host weiterleitet.

Auf einem ZimaSpace-Heimserver können sich mehrere Apps hinter Nginx, Traefik, Caddy oder einem anderen Reverse-Proxy eine LAN-Adresse teilen. DNS wählt nur die Ziel-IP-Adresse aus. Der Browser übermittelt weiterhin einen Hostnamen über TLS-SNI und den HTTP-Host-Header, und der Proxy entscheidet, welcher Container die Anfrage erhält.

Überprüfen, ob die Split-DNS-Antwort tatsächlich beabsichtigt ist

Vergleichen Sie den lokalen Eintrag mit dem öffentlichen Eintrag und bestätigen Sie, dass beide Hostnamen für denselben Reverse-Proxy bestimmt sind.

Ein fokussierter Split-DNS-Beitrag für Homelabs auf Split-DNS kann einen privaten Pfad zurückgeben hilft dabei, diesen Zweig einzugrenzen, da er dasselbe konkrete Problem behandelt, statt nur das zugrunde liegende Protokoll zu definieren.

Behalten Sie den Browser-Hostnamen unverändert bei und ändern Sie ausschließlich die von der internen DNS-Auflösung zurückgegebene Adresse.

Nachweisen, dass der Proxy anhand des Hostnamens weiterleitet

Senden Sie Anfragen mit dem erwarteten Hostnamen und vergleichen Sie sie mit dem direkten Zugriff über die IP-Adresse auf dasselbe NAS.

Ein fokussierter Reverse-Proxy-Leitfaden für Homelabs auf der Host-Header wählt das Backend aus hilft dabei, diesen Zweig einzugrenzen, da er dasselbe konkrete Problem behandelt, statt nur das zugrunde liegende Protokoll zu definieren.

Wenn die direkte IP-Adresse eine Standard-App öffnet, während der Hostname die richtige App öffnet, liegt der Fehler nicht bei DNS; die Weiterleitung über den virtuellen Host funktioniert wie vorgesehen.

Prüfen, ob der Host-Header umgeschrieben wird

Untersuchen Sie die Host- und Forwarded-Host-Header beim Proxy und beim Backend.

Ein fokussierter Beitrag zur Sicherheit und zu HTTP auf Änderungen am Host-Header können die Weiterleitung verändern hilft dabei, diesen Zweig einzugrenzen, da er dasselbe konkrete Problem behandelt, statt nur das zugrunde liegende Protokoll zu definieren.

Korrigieren Sie ausschließlich die Ebene, auf der der Hostname umgeschrieben wird. Fügen Sie keine doppelten DNS-Einträge hinzu, um einen Fehler bei der HTTP-Weiterleitung auszugleichen.

TLS-SNI vor der HTTP-Weiterleitung prüfen

Mehrere HTTPS-Apps auf einer IP-Adresse müssen weiterhin den für die Auswahl des vorgesehenen Zertifikats und virtuellen Hosts erforderlichen Hostnamen übermitteln.

Ein fokussierter Praxisleitfaden zu SNI auf SNI wählt zwischen HTTPS-Websites auf einer IP-Adresse aus hilft dabei, diesen Zweig einzugrenzen, da er dasselbe konkrete Problem behandelt, statt nur das zugrunde liegende Protokoll zu definieren.

Vergleichen Sie den Zertifikatsnamen und die Backend-Route. Ein Zertifikat für eine andere App ist ein Hinweis darauf, dass die Auswahl bereits vor dem Erreichen des vorgesehenen Dienstes fehlgeschlagen ist.

Den Standard-Virtual-Host überprüfen

Wenn keine Hostnamenregel zutrifft, geben viele Proxys einen Standardserver zurück, der zu einer anderen App gehören kann.

Ein fokussierter Nginx-Artikel zur Fehlerbehebung auf ein nicht passender Hostname kann den Standardserver erreichen hilft dabei, diesen Zweig einzugrenzen, da er dasselbe konkrete Problem behandelt, statt nur das zugrunde liegende Protokoll zu definieren.

Erstellen Sie explizite Hostregeln und eine neutrale Standardantwort, anstatt eine Anwendung zum Auffangziel für jede unbekannte Domain werden zu lassen.

DNS-Weiterleitung von der Proxy-Weiterleitung getrennt halten

Betrachten Sie DNS als Auswahl der Adresse und den Reverse-Proxy als Auswahl der Anwendung.

Ein fokussierter Beitrag zum Unterschied zwischen DNS und Reverse-Proxys auf DNS und Reverse-Proxys lösen unterschiedliche Weiterleitungsebenen hilft dabei, diesen Zweig einzugrenzen, da er dasselbe konkrete Problem behandelt, statt nur das zugrunde liegende Protokoll zu definieren.

Testen Sie mit dem exakten App-Hostnamen von einem LAN-Client aus erneut. Das korrekte Ergebnis umfasst das erwartete Zertifikat, die Proxy-Route und das Backend – ohne Lesezeichen mit direkter IP-Adresse.

Den exakten Heimserver-Pfad erneut testen

Wiederholen Sie nach der Änderung einer einzelnen Variable denselben NAS- oder Self-Hosting-Ablauf vom selben Client aus, anstatt zu einem anderen Test zu wechseln, der möglicherweise einen anderen Pfad verwendet.

Der zugehörige ZimaSpace-Leitfaden auf der angrenzende Heimserver-Netzwerkpfad hilft dabei, die abschließende Überprüfung an dieselbe Self-Hosting-Umgebung gebunden zu halten.

Die Fehlerbehebung ist erst abgeschlossen, wenn das ursprüngliche Problem auch nach einer erneuten Verbindung, einem Neustart des Dienstes und einer zweiten kontrollierten Übertragung oder Anfrage weiterhin behoben ist.

Support & Tipps

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.