Så felsöker du en fjärrapp som fungerar via IP-adress men inte via domännamn

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.

How to Troubleshoot a Remote App That Works by IP but Not by Domain - Zima Store Online

Om en app fungerar via IP-adress men inte via domän är servern nåbar, och felet ligger vanligtvis i DNS, värdnamnsbaserad routing, TLS eller omdirigeringar.

Fjärråtkomst via IP bevisar att någon nätverksväg når hemmaservern, men en domänbegäran innehåller ytterligare identitet via DNS, TLS-servernamnet, HTTP Host-huvudet och programmets konfigurerade offentliga URL. Den snabbaste felsökningen behåller samma klient, port och server medan varje identitetslager kontrolleras i tur och ordning, i stället för att ändra reverse proxy, certifikat och DNS-poster samtidigt.

Bekräfta att IP-testet når den avsedda tjänsten

Anteckna den exakta IP-adressen, porten, protokollet och svaret som fungerar på distans. Kontrollera om IP-adressen öppnar den riktiga appen, en standardsida från reverse proxyn, en routerinloggning eller någon annan tjänst som delar samma offentliga adress.

En genomgång av reverse proxy i ett homelab förklarar att en proxy kan vara värd för flera appar på samma adress eftersom den granskar det begärda Host-huvudet innan den väljer uppströmstjänst.

Om IP-adressen bara når en standardsida bevisar det att proxyn är nåbar, men inte att routingen till målappen fungerar. Behåll en känd svarsmärkare, till exempel en sidtitel eller en header, så att senare tester identifierar rätt virtuella värd.

Jämför offentlig DNS med den fungerande IP-adressen

Fråga domänen via en auktoritativ namnserver och minst en extern rekursiv resolver. Anteckna alla A- och AAAA-svar, TTL samt om en CNAME pekar på ett annat värdnamn.

Råd om self-hosting påpekar att cachade svar kan finnas kvar tills den tidigare TTL-tiden löper ut, så en nylig ändring kan göra att vissa klienter fortfarande använder en äldre DNS-destination efter att den auktoritativa posten har korrigerats.

Om A-posten skiljer sig från den fungerande IP-adressen korrigerar du posten eller DDNS-uppdateraren. Om A är korrekt men AAAA pekar på en oåtkomlig IPv6-väg testar du varje adressfamilj separat och tar bort eller reparerar den trasiga posten.

Anslut till den fungerande IP-adressen och behåll domänen

Använd en klient som kan ansluta till den kända fungerande IP-adressen samtidigt som domänen skickas som HTTP Host-header och TLS-servernamn. Då ändras destinationen utan att den identitet som proxyn och certifikatet förväntar sig försvinner.

Server Fault förklarar att en HTTP-reverse proxy kan använda Host-headern för att välja en route på samma sätt som namnbaserade virtuella värdar.

Om begäran med bevarad domän fungerar är DNS det felande lagret. Om den når proxyn men returnerar fel webbplats eller 404 granskar du matchningen av virtuella värdar och routningens prioritet. Om TLS misslyckas innan HTTP granskar du SNI och valet av certifikat.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Kontrollera TLS-SNI och certifikatets identitet

Jämför certifikatet som returneras för domänen med certifikatet som returneras för den nakna IP-adressen. Anteckna ämnesnamn, utfärdare, giltighetstid och om proxyn visar ett standardcertifikat.

SNI överför värdnamnet i TLS ClientHello före den krypterade HTTP-begäran, vilket gör det möjligt för proxyn att välja den säkra virtuella värden. En begäran som endast använder IP-adressen kan därför sakna värdnamnet som användes vid TLS-valet, även när den når samma lyssnare.

Åtgärda domänens certifikat och SNI-routingen i stället för att förvänta dig ett certifikat för en privat eller dynamisk IP-adress. Om en CDN- eller TCP-proxy finns framför, bekräftar du att den vidarebefordrar eller avslutar SNI för det avsedda värdnamnet.

Verifiera att intern och extern DNS inte skickar olika vägar

Jämför domänresultatet från mobildata, en offentlig resolver och hemnätverket. Split DNS kan avsiktligt returnera en privat proxyadress hemma och en offentlig adress på distans, men båda svaren måste nå samma logiska värdnamnsroute.

En homelab-diskussion på Level1Techs visar att lokal reverse-proxyåtkomst kan kräva en egen DNS-design när offentlig DNS och hemmets routing tar olika interna och externa vägar.

Om bara en resolver returnerar fel adress korrigerar du den DNS-vyn. Om den offentliga adressen fungerar via IP men domänen misslyckas överallt behåller du fokus på Host, SNI, certifikat och applikationens identitet i stället för split DNS.

Kontrollera kanoniska URL:er och omdirigeringar innan du förklarar DNS-problemet löst

Granska varje omdirigering efter att domänen når appen. Reverse proxyn eller applikationen kan skicka klienter till ett internt värdnamn, en gammal domän, fel schema, en privat port eller en inaktuell callback-URL.

ZimaSpace-artikeln om huruvida split DNS kan åtgärda ett fel som endast uppstår internt behandlar det närliggande fallet där värdnamnet är korrekt men routingen skiljer sig beroende på plats.

Problemet är löst först när auktoritativ DNS returnerar den avsedda adressen, domänen väljer rätt certifikat och proxyroute, omdirigeringarna bevarar det offentliga värdnamnet och hela fjärrarbetsflödet fungerar utan att IP-adressen ersätter domänen.