Waarom werkt een reverse proxy op domeinnaam maar niet op lokaal IP-adres?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

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

Een reverse proxy werkt op domeinniveau omdat de routerings- en TLS-regels vaak afhangen van de gevraagde hostnaam, niet alleen van het bestemmings-IP.

Wanneer een thuisclient https://app.example.com opent, levert DNS een IP-adres, maar de browser stuurt nog steeds het domein mee via de TLS-handshake en de HTTP Host-header. Het openen van https://192.168.1.20 verandert die identificaties, waardoor de proxy mogelijk een standaardsite selecteert, het certificaat afwijst, de applicatieroute mist of terugverwijst naar de geconfigureerde publieke URL. De juiste test behoudt de bedoelde hostnaam terwijl alleen de netwerkbestemming verandert.

Vergelijk het Hostnaamverzoek met het Direct-IP-verzoek

Stuur één verzoek naar het domein en één naar het lokale IP, en vergelijk vervolgens statuscode, certificaat, response headers, redirectlocatie en reverse-proxy toeganglog. Ga er niet vanuit dat beide verzoeken gelijkwaardig zijn omdat ze hetzelfde Ethernet-interface bereiken.

Een homelab reverse-proxy walkthrough legt uit dat de proxy de HTTP Host-header inspecteert om meerdere diensten via één IP en poort te routeren.

Als het domeinverzoek overeenkomt met een applicatieroute terwijl het IP-verzoek een standaardpagina of 404 bereikt, werkt de proxy zoals geconfigureerd. De volgende beslissing is of directe IP-toegang daadwerkelijk nodig is of dat lokale DNS het domein moet behouden.

Test het lokale IP terwijl je de bedoelde Host-header behoudt

Gebruik een clienttool die verbinding maakt met het lokale proxy-IP terwijl het applicatiedomein als Host-header wordt meegestuurd. Voor HTTPS behoud je ook de domeinnaam als TLS-servernaam in plaats van deze te vervangen door het IP.

Server Fault beschrijft hoe een HTTP reverse proxy de Host-header gebruikt om de route te kiezen, net zoals naamgebaseerde virtuele hosts dat doen.

Als het geforceerde hostverzoek slaagt, zijn de proxyroute en backend gezond; een mislukking bij direct IP is een identiteitsconflict. Als het nog steeds faalt, controleer dan de listener, lokale firewall, proxy-ingang en routeprioriteit voordat je DNS wijzigt.

Controleer TLS SNI en certificaatmatching

HTTPS voegt een hostnaamkeuze toe vóór het HTTP-verzoek. De client stuurt meestal Server Name Indication tijdens de TLS-handshake zodat de proxy het juiste certificaat en de juiste beveiligde virtuele host kan selecteren.

Een SNI reverse-proxy-implementatie merkt op dat HTTPS-backends worden geselecteerd met behulp van de SNI-hostnaam van de client voordat gewone HTTP-headers kunnen worden bekeken.

Directe toegang via IP kan een standaardcertificaat tonen of falen bij hostnaamvalidatie, zelfs als de proxy bereikbaar is. Gebruik het domein met lokale DNS, of implementeer een bewust beheerd certificaat met alleen het IP als directe IP-HTTPS een echte operationele vereiste is.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Inspecteer de standaardsite en routeprioriteit

Bekijk welke virtuele host verzoeken afhandelt die niet overeenkomen met een geconfigureerd domein. Een standaardsite kan een dashboard tonen, doorverwijzen naar een andere hostnaam, de verbinding sluiten of een generieke fout tonen.

Een Caddy-discussie laat zien dat een verzoek het juiste proxy-IP kan bereiken terwijl de Host-header en TLS-naam nog steeds bepalen of de bedoelde upstream wordt gekozen.

Houd de standaardroute expliciet en veilig. Voeg geen brede catch-all proxy toe aan één backend alleen om IP-toegang te laten werken, want dat kan onbekende hostnamen of scanverkeer naar een applicatie leiden die bedoeld was om domeinbeperkt te zijn.

Controleer of de applicatie doorverwijst naar zijn canonieke URL

Zelfs als de proxy het IP-verzoek accepteert, kan de backend een geconfigureerde publieke basis-URL afdwingen en de browser doorverwijzen naar het domein. Authenticatiecookies, OAuth-callbacks, WebSocket-origins en CSRF-controles kunnen ook afhankelijk zijn van die canonieke host.

Vergelijk de proxylog met de applicatielog en controleer de Location-header. Een doorverwijzing naar het domein is geen routeringsfout; het is bewijs dat de applicatie één publieke identiteit verwacht.

Corrigeer doorgestuurde host- en protocolheaders wanneer de app de verkeerde externe URL genereert. Vervang het canonieke domein niet door een privé-IP alleen om de redirect te omzeilen, want dat kan certificaten en externe toegang breken.

Gebruik lokale DNS wanneer het domein de bedoelde interface is

Maak een interne DNS-record aan die het applicatiedomein naar het lokale reverse-proxyadres verwijst. De browser gebruikt dan het efficiënte LAN-pad terwijl dezelfde Host-header, SNI-naam, certificaat, cookies en applicatie-URL behouden blijven.

De ZimaSpace vergelijking van reverse proxies en private toegangspaden helpt beslissen of het domein een lokale en publieke toegangspoort moet blijven of achter een privénetwerk moet blijven.

Het probleem is opgelost wanneer het domein zowel binnen als buiten werkt via bewuste DNS-antwoorden, terwijl direct IP ofwel een gedocumenteerde standaardsite bereikt of bewust wordt geweigerd. Een domeingegerouteerde proxy hoeft zich niet te gedragen als een enkelvoudige site-server met IP-adres.