Varför fungerar en omvänd proxy med domän men inte med lokal IP?

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.

Why Does a Reverse Proxy Work by Domain but Fail by Local IP?

En reverse proxy fungerar per domän eftersom dess routing- och TLS-regler ofta beror på det begärda värdnamnet, inte bara destinations-IP-adressen.

När en hemmaklient öppnar https://app.example.com tillhandahåller DNS en IP, men webbläsaren skickar fortfarande domänen genom TLS-handshake och HTTP Host-headern. Att öppna https://192.168.1.20 ändrar dessa identifierare, så proxyn kan välja en standardsida, avvisa certifikatet, missa applikationsrutten eller omdirigera tillbaka till den konfigurerade publika URL:en. Det korrekta testet bevarar det avsedda värdnamnet samtidigt som endast nätverksdestinationen ändras.

Jämför Hostname-förfrågan med Direkt-IP-förfrågan

Skicka en förfrågan till domänen och en till den lokala IP-adressen, och jämför sedan statuskod, certifikat, svarshuvuden, omdirigeringsplats och reverse-proxy-accesslogg. Anta inte att båda förfrågningarna är likvärdiga bara för att de når samma Ethernet-gränssnitt.

En genomgång av en homelab reverse proxy förklarar att proxyn inspekterar HTTP Host-headern för att routa flera tjänster genom en IP och port.

Om domänförfrågan matchar en applikationsrutt medan IP-förfrågan träffar en standardsida eller 404, fungerar proxyn som konfigurerat. Nästa beslut är om direkt-IP-åtkomst verkligen krävs eller om lokal DNS bör bevara domänen.

Testa den Lokala IP:n samtidigt som det avsedda Host-headern bevaras

Använd ett klientverktyg som ansluter till den lokala proxy-IP:n samtidigt som applikationsdomänen skickas som Host-header. För HTTPS, bevara också domänen som TLS-servernamn istället för att ersätta den med IP-adressen.

Server Fault beskriver hur en HTTP reverse proxy kan använda Host-headern för att välja rutt på samma sätt som namn-baserade virtuella värdar.

Om den tvingade host-förfrågan lyckas är proxy-rutten och backend friska; misslyckande med direkt-IP är en identitetsmismatch. Om det fortfarande misslyckas, inspektera lyssnaren, lokal brandvägg, proxy-entré och ruttprioritet innan DNS ändras.

Kontrollera TLS SNI och Certifikatmatchning

HTTPS lägger till ett värdnamnsbeslut före HTTP-förfrågan. Klienten skickar vanligtvis Server Name Indication under TLS-handshake så att proxyn kan välja rätt certifikat och säker virtuell värd.

En SNI reverse-proxy-implementation noterar att HTTPS-backends väljs med klientens SNI-värdnamn innan vanliga HTTP-huvuden kan undersökas.

Direktåtkomst via IP kan visa ett standardcertifikat eller misslyckas med värdnamnsvalidering även när proxyn är nåbar. Använd domänen med lokal DNS, eller distribuera ett medvetet hanterat certifikat som innehåller IP:n endast när direkt-IP HTTPS är ett verkligt operativt krav.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Inspektera Standardsidan och Ruttprioritet

Granska vilken virtuell värd som hanterar förfrågningar som inte matchar en konfigurerad domän. En standardsida kan returnera en instrumentpanel, omdirigera till ett annat värdnamn, stänga anslutningen eller visa ett generiskt fel.

En Caddy-diskussion visar att en förfrågan kan nå rätt proxy-IP medan Host-headern och TLS-namnet fortfarande avgör om den avsedda upstream väljs.

Håll standardrutten tydlig och säker. Lägg inte till en bred catch-all proxy till en backend bara för att få IP-åtkomst att fungera, eftersom det kan routa okända värdnamn eller skannings trafik till en applikation som var tänkt att vara domänbegränsad.

Kontrollera om Applikationen Omdirigerar till sin Kanoniska URL

Även när proxyn accepterar IP-förfrågan kan backend tvinga en konfigurerad offentlig bas-URL och omdirigera webbläsaren till domänen. Autentiseringscookies, OAuth-callbacks, WebSocket-origin och CSRF-kontroller kan också bero på den kanoniska värden.

Jämför proxyloggen med applikationsloggen och inspektera Location-headern. En omdirigering till domänen är inte ett routingfel; det är bevis på att applikationen förväntar sig en offentlig identitet.

Korrigera vidarebefordrade host- och protokollhuvuden när appen genererar fel extern URL. Ersätt inte den kanoniska domänen med en privat IP bara för att kringgå omdirigeringen, eftersom det kan bryta certifikat och fjärråtkomst.

Använd Lokal DNS när Domänen är den Avsedda Gränssnittet

Skapa en intern DNS-post som löser applikationsdomänen till den lokala reverse-proxy-adressen. Webbläsaren använder då den effektiva LAN-vägen samtidigt som samma Host-header, SNI-namn, certifikat, cookies och applikations-URL bevaras.

ZimaSpace-jämförelsen av reverse proxies och privata åtkomstvägar hjälper till att avgöra om domänen ska förbli en lokal och offentlig ingångspunkt eller stanna bakom ett privat nätverk.

Problemet löses när domänen fungerar både inifrån och utifrån genom avsiktliga DNS-svar, medan direkt IP antingen når en dokumenterad standardsida eller medvetet avvisas. En domän-routad proxy behöver inte bete sig som en IP-adresserad enskild webbserver.