Kan Split DNS lösa ett självhostat program som bara kraschar hemma hos dig?
Ja, split DNS kan åtgärda ett fel som endast uppstår inifrån när det offentliga värdnamnet ska peka på en annan lokal adress hemma.
En självhostad app kan fungera via mobildata eftersom den offentliga DNS pekar på hemnätverkets WAN-adress, medan enheter inom LAN misslyckas eftersom routern inte kan hairpinna den anslutningen tillbaka genom den offentliga NAT-regeln. Split DNS undviker den loopen genom att returnera den lokala reverse-proxyn eller app-adressen till hemmaklienter, men det lyckas bara när samma värdnamn, certifikat, proxy-rutt och applikationsbas-URL är giltiga på båda vägarna.
Bevisa att det offentliga namnet fungerar utifrån först
Testa den exakta applikations-URL:en från mobildata eller ett annat externt nätverk. Bekräfta DNS-upplösning, TLS, reverse-proxy-routing, inloggning, omdirigeringar och applikationens funktion som för närvarande misslyckas inifrån hemmet.
Tailscale beskriver split DNS som ett sätt att ge klienter olika DNS-svar beroende på kontext istället för att tvinga interna och externa användare genom en identisk rutt.
Om appen också misslyckas externt är split DNS inte den första åtgärden. Fixa offentlig DNS, tunneln eller portvidarebefordran, proxy-routing, TLS eller applikationskonfiguration innan du skapar ett andra svar som kan dölja det ursprungliga felet.
Kontrollera om felet inifrån är Hairpin NAT
Från en hemmaklient, fråga efter det offentliga värdnamnet och notera den returnerade adressen. Om det pekar på hemnätverkets offentliga IP, spåra om routern stödjer NAT loopback eller hairpin NAT för den vidarebefordrade tjänsten.
En felsökningsdiskussion på Level1Techs rekommenderar en lokal DNS-överskrivning som pekar domänen till den interna serveradressen när hairpin NAT är opålitligt.
Jämför felet med det offentliga namnet med direkt åtkomst till den lokala reverse-proxy-adressen. Om direkt lokal åtkomst når den avsedda proxyn eller appen, medan den offentliga IP:n bara misslyckas inifrån, är split DNS en stark kandidat.
Peka det interna svaret till samma logiska ingångspunkt
Skapa en intern DNS-post för det befintliga offentliga värdnamnet, men peka den till LAN-adressen för reverse-proxyn eller den kontrollerade lokala ingångspunkten. Undvik att peka direkt på en backend när externa användare normalt passerar genom proxyn.
En jämförelse av split DNS förklarar att lokala klienter kan lösa samma domän till en privat intern adress medan externa klienter fortsätter att få den offentliga adressen.
Att behålla båda vägarna på samma proxy bevarar värdnamnsbaserad routing, åtkomstpolicy, headers och certifikat. Att peka hemmaklienter runt proxyn kan ladda sidan men bryta autentisering, callbacks, WebSockets eller säkerhetskontroller som bara finns på proxyn.
Verifiera att varje nödvändig klient använder den interna resolvern
Kontrollera vilken DNS-server som används av telefoner, laptops, TV-apparater, containers och VPN-klienter som ska få det interna svaret. Webbläsarens säkra DNS, mobilens Private DNS, en VPN-resolver eller en hårdkodad offentlig DNS-server kan kringgå den interna resolvern.
Råd för självhosting om split DNS varnar för att avbrott ofta uppstår när VPN eller klient fortsätter använda fel resolver-kontext trots att de är på det interna nätverket.
Fråga den interna DNS-servern direkt och jämför sedan svaret med en vanlig klientuppslagning. Om servern returnerar den lokala adressen men klienten inte gör det, åtgärda DHCP DNS-distribution, krypterad DNS, VPN-policy eller klientöverskrivningar innan du redigerar posten igen.
Behåll samma värdnamn för TLS och applikations-callbacks
Åtkomst till appen via dess normala domän efter att den interna posten är aktiv. Ersätt den inte med ett bokmärke till den privata IP:n, eftersom HTTPS-certifikat och reverse-proxy-rutter vanligtvis är kopplade till värdnamnet.
Den interna vägen måste också bevara applikationens offentliga bas-URL, OAuth-omdirigerings-URI, webhook-adress och vidarebefordrade headers. Split DNS ändrar destinationsadressen, inte värdnamnet som webbläsaren eller leverantören ska använda.
Om appen omdirigerar tillbaka till den offentliga IP:n, genererar ett internt värdnamn eller avvisar host-headern, åtgärda proxy- och app-URL-inställningarna. DNS kan inte ensam reparera en tjänst som är konfigurerad med inkonsekventa identiteter.
Behåll split DNS endast när båda vägarna förblir förutsägbara
Testa från hem-Wi-Fi, gäst-Wi-Fi, VPN, mobildata och en enhet som använder Private DNS. Bekräfta att varje klient får den avsedda adressen och når samma applikationsidentitet.
ZimaSpace-guiden till varför en privat moln endast fungerar på ett nätverk ger det omvända symptomet och hjälper till att verifiera att de två DNS-vyerna förblir avsiktligt olika.
Split DNS är rätt lösning när det tar bort en trasig offentlig loop samtidigt som samma domän, TLS-certifikat, proxy-rutt och applikationsbeteende bevaras. Använd hairpin NAT istället när routern hanterar det pålitligt och att underhålla två DNS-vyer skulle innebära mer risk än nytta.
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.
