Waarom verwijst een reverseproxy de ene app door naar het domein van een andere app?

Een reverse proxy kan de ene app naar het domein van een andere app sturen wanneer de backend of middleware omleidingen opbouwt met de verkeerde openbare hostnaam.

In een zelfgehoste ZimaSpace-stack kunnen meerdere apps dezelfde proxy delen, terwijl elke app zijn eigen openbare basis-URL verwacht. Als Host, X-Forwarded-Host, schema, middleware of een canonieke URL op appniveau naar een andere service verwijst, kan de eerste pagina correct laden en kan de volgende 301-, 302- of login-callback naar een ander domein springen.

Controleer de Host en het schema dat naar de backend wordt verzonden

Leg de requestheaders bij de proxy en backend vast terwijl je de omleiding reproduceert.

Een gerichte implementatiegids voor reverse proxies over doorgegeven host en schema die de backend bereiken helpt deze tak te isoleren, omdat die hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.

Corrigeer de proxyheaders voordat je applicatie-URL’s wijzigt. Een backend kan geen juiste absolute omleiding opbouwen als deze denkt dat het verzoek een andere host gebruikte.

Inspecteer specifiek X-Forwarded-Host

Sommige frameworks gebruiken X-Forwarded-Host in plaats van de onbewerkte Host-header bij het genereren van absolute URL’s.

Een gerichte uitleg over HTTP-headers op X-Forwarded-Host behoudt de openbare hostnaam helpt deze tak te isoleren, omdat die hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.

Vergelijk deze header tussen de goed werkende app en de verkeerd doorgestuurde app. Verwijder globale overschrijvingen die elke backend naar één domein forceren.

Controleer of de app absolute URL’s genereert

Zoek naar frameworkinstellingen die proxyheaders vertrouwen en canonieke links of omleidingen opbouwen.

Een gerichte blog over het oplossen van proxyproblemen in de praktijk op absolute URL’s kunnen achter een proxy verkeerd zijn helpt deze tak te isoleren, omdat die hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.

Corrigeer het proxyvertrouwen van het framework of de instelling voor de openbare URL, in plaats van elke omleiding aan de rand te herschrijven.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controleer de basis-URL of het canonieke domein van de app

Veel zelfgehoste apps slaan een site-URL op die onafhankelijk is van de prox regel.

Een gerichte praktijkcasus over een app achter een proxy op de basis-URL van de applicatie kan de proxyhost overschrijven helpt deze tak te isoleren, omdat die hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.

Vergelijk de opgeslagen URL-waarden van de applicatie na migraties of herstelbewerkingen. Eén gekopieerde database kan de canonieke hostnaam van een andere appomgeving bevatten.

Controleer redirect-middleware vóór de backend

Een proxregel kan het schema of de host bewust herschrijven voordat het verzoek de applicatie bereikt.

Een gerichte handleiding voor Traefik in een homelab op redirect-middleware kan de host vervangen helpt deze tak te isoleren, omdat die hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.

Schakel alleen de verdachte redirect-middleware uit voor één testrouter. Houd HTTPS-afdwinging gescheiden van omleidingen tussen domeinen.

Controleer OAuth- en OIDC-callback-URL’s

Authenticatiestromen brengen vaak een verkeerde openbare hostnaam aan het licht, omdat de provider een exacte redirect-URI valideert.

Een gerichte handleiding voor het oplossen van OIDC-problemen op OIDC-callbacks zijn afhankelijk van de openbare proxy-URL helpt deze tak te isoleren, omdat die hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.

Vergelijk de issuer, callback, doorgestuurde headers en basis-URL van de app gezamenlijk. Dat een normale pagina wordt geladen, bewijst niet dat het pad voor de login-callback correct is.

Test het exacte thuisserverpad opnieuw

Herhaal na het wijzigen van één variabele dezelfde NAS- of zelfgehoste workflow vanaf dezelfde client, in plaats van over te schakelen naar een andere test die mogelijk een ander pad gebruikt.

De gerelateerde ZimaSpace-handleiding op het aangrenzende thuisservernetwerkpad helpt de uiteindelijke verificatie gekoppeld te houden aan dezelfde zelfgehoste omgeving.

De oplossing is pas voltooid wanneer het oorspronkelijke probleem opgelost blijft na opnieuw verbinden, het herstarten van de service en een tweede gecontroleerde overdracht of aanvraag.

Veelgestelde vragen

Kan DNS een HTTP 301 of 302 veroorzaken?

DNS retourneert alleen een adres. De omleiding wordt gegenereerd door de proxy, authenticatielaag of applicatie.

Waarom wordt de juiste app geladen voordat de browser van domein verandert?

De oorspronkelijke proxroute kan correct zijn, terwijl de backend later een absolute omleiding genereert op basis van een verkeerde basis-URL of doorgestuurde host.

Moet ik elke Location-header bij de proxy herschrijven?

Nee. Corrigeer eerst de bron van de onjuiste hostnaam; brede herschrijvingen van reacties kunnen configuratiefouten in de applicatie verbergen.