Vad får lokal DNS att returnera rätt IP-adress men fel tjänst?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

What Causes Local DNS to Return the Right IP but the Wrong Service? - Zima Store Online

Lokalt DNS kan returnera rätt NAS-IP men ändå öppna fel tjänst när den gemensamma reverse proxyn dirigerar värdnamnet till en annan virtuell värd.

På en ZimaSpace-hemmserver kan flera appar dela samma LAN-adress bakom Nginx, Traefik, Caddy eller en annan reverse proxy. DNS väljer endast destinations-IP-adressen. Webbläsaren skickar fortfarande ett värdnamn via TLS SNI och HTTP Host-headern, och proxyn avgör vilken container som tar emot begäran.

Verifiera att svaret från split-DNS faktiskt är avsett

Jämför den lokala posten med den offentliga posten och bekräfta att båda värdnamnen ska avslutas vid samma reverse proxy.

En fokuserad homelab-artikel om split-DNS på split-DNS kan returnera en privat sökväg hjälper till att isolera denna gren eftersom den behandlar samma specifika problem i stället för att bara definiera det underliggande protokollet.

Behåll webbläsarens värdnamn oförändrat och ändra endast adressen som returneras av det interna DNS-systemet.

Bevisa att proxyn dirigerar efter värdnamn

Skicka begäranden med det förväntade värdnamnet och jämför dem med direktåtkomst via IP-adress till samma NAS.

En fokuserad genomgång av reverse proxy för homelab på Host-headern väljer backend hjälper till att isolera denna gren eftersom den behandlar samma specifika problem i stället för att bara definiera det underliggande protokollet.

Om direktåtkomst via IP öppnar en standardapp medan värdnamnet öppnar rätt app, är DNS inte felet; dirigeringen av virtuella värdar fungerar som avsett.

Kontrollera om Host-headern skrivs om

Inspektera Host- och forwarded-host-headers vid proxyn och backend-systemet.

En fokuserad förklaring av säkerhet och HTTP på ändringar av Host-headern kan påverka dirigeringen hjälper till att isolera denna gren eftersom den behandlar samma specifika problem i stället för att bara definiera det underliggande protokollet.

Korrigera endast det lager som skriver om värdnamnet. Lägg inte till dubbla DNS-poster för att kompensera för ett fel i HTTP-dirigeringen.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Kontrollera TLS SNI före HTTP-dirigeringen

Flera HTTPS-appar på samma IP-adress måste fortfarande presentera det värdnamn som krävs för att välja rätt certifikat och virtuella värd.

En fokuserad praktisk guide till SNI på SNI väljer mellan HTTPS-webbplatser på samma IP-adress hjälper till att isolera denna gren eftersom den behandlar samma specifika problem i stället för att bara definiera det underliggande protokollet.

Jämför certifikatets namn med backend-dirigeringen. Ett certifikat för en annan app visar att valet blev fel innan begäran nådde den avsedda tjänsten.

Inspektera den virtuella standardvärden

Om ingen regel matchar värdnamnet returnerar många proxyservrar en standardserver som kan tillhöra en annan app.

En fokuserad artikel om felsökning av Nginx på ett omatchat värdnamn kan nå standardservern hjälper till att isolera denna gren eftersom den behandlar samma specifika problem i stället för att bara definiera det underliggande protokollet.

Skapa uttryckliga värdnamnsregler och ett neutralt standardsvar i stället för att låta en applikation bli uppsamlingspunkt för alla okända domäner.

Håll DNS-dirigering åtskild från proxy-dirigering

Betrakta DNS som adressval och reverse proxyn som applikationsval.

En fokuserad förklaring av DNS kontra reverse proxy på DNS och reverse proxyservrar löser olika dirigeringslager hjälper till att isolera denna gren eftersom den behandlar samma specifika problem i stället för att bara definiera det underliggande protokollet.

Testa igen med det exakta appvärdnamnet från en LAN-klient. Det korrekta resultatet är det förväntade certifikatet, proxyvägen och backend-systemet utan bokmärken med direktåtkomst via IP.

Testa den exakta sökvägen till hemservern igen

Efter att ha ändrat en variabel upprepar du samma NAS- eller self-hosting-arbetsflöde från samma klient i stället för att byta till ett annat test som kan använda en annan sökväg.

Den relaterade ZimaSpace-guiden på den närliggande nätverkssökvägen för hemservern hjälper till att hålla den slutliga verifieringen kopplad till samma self-hostade miljö.

Åtgärden är klar först när det ursprungliga symptomet fortsätter att vara löst efter återanslutning, omstart av tjänsten och en andra kontrollerad överföring eller begäran.