Vad får lokal DNS att returnera rätt IP-adress men fel tjänst?
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.
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.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
