Varför omdirigerar en omvänd proxy en app till en annan apps domän?

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 Redirect One App to Another App’s Domain? - Zima Store Online

En reverse proxy kan skicka en app till en annan apps domän när backend-systemet eller mellanlagret bygger omdirigeringar från fel offentligt värdnamn.

I en egenhostad ZimaSpace-stack kan flera appar dela samma proxy, samtidigt som varje app förväntar sig sin egen offentliga bas-URL. Om Host, X-Forwarded-Host, schema, mellanlager eller en kanonisk URL på appnivå pekar på en annan tjänst kan den första sidan laddas korrekt, medan nästa 301-, 302- eller inloggningscallback hoppar till en annan domän.

Kontrollera Host och schema som skickas till backend

Fånga begärandehuvuden vid proxyn och backend-systemet medan du återskapar omdirigeringen.

En fokuserad implementeringsguide för reverse proxy på vidarebefordrat värdnamn och schema når backend hjälper till att isolera denna gren, eftersom den behandlar samma specifika delproblem i stället för att bara definiera det underliggande protokollet.

Korrigera proxyhuvudena innan du ändrar apparnas URL:er. En backend kan inte skapa rätt absolut omdirigering när den tror att begäran använde en annan värd.

Granska X-Forwarded-Host specifikt

Vissa ramverk använder X-Forwarded-Host i stället för det råa Host-huvudet när de genererar absoluta URL:er.

En fokuserad förklaring av HTTP-huvudet på X-Forwarded-Host bevarar det offentliga värdnamnet hjälper till att isolera denna gren, eftersom den behandlar samma specifika delproblem i stället för att bara definiera det underliggande protokollet.

Jämför detta huvud mellan appen som fungerar och appen som omdirigeras fel. Ta bort globala åsidosättningar som tvingar alla backends att använda en enda domän.

Kontrollera om appen genererar absoluta URL:er

Leta efter inställningar i ramverket som litar på proxyhuvuden och skapar kanoniska länkar eller omdirigeringar.

Ett fokuserat blogginlägg om felsökning av proxyer i praktiken på absoluta URL:er som kan bli fel bakom en proxy hjälper till att isolera denna gren, eftersom det behandlar samma specifika delproblem i stället för att bara definiera det underliggande protokollet.

Korrigera ramverkets förtroende för proxyer eller inställningen för den offentliga URL:en i stället för att skriva om varje omdirigering vid kanten.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Verifiera appens bas-URL eller kanoniska domän

Många egenhostade appar lagrar en webbplats-URL separat från proxyregeln.

En fokuserad praktisk fallstudie om en app bakom en proxy på appens bas-URL kan åsidosätta proxyns värdnamn hjälper till att isolera denna gren, eftersom den behandlar samma specifika delproblem i stället för att bara definiera det underliggande protokollet.

Jämför de lagrade URL-värdena i appen efter migreringar eller återställningar. En kopierad databas kan innehålla den kanoniska värdnamnet från en annan appmiljö.

Granska omdirigeringsmellanlager före backend

En proxyregel kan avsiktligt skriva om schema eller värd innan begäran någonsin når appen.

En fokuserad steg-för-steg-guide om Traefik i homelab på omdirigeringsmellanlager kan ersätta värden hjälper till att isolera denna gren, eftersom den behandlar samma specifika delproblem i stället för att bara definiera det underliggande protokollet.

Inaktivera endast det misstänkta omdirigeringsmellanlagret för en testrouter. Håll HTTPS-tvingning åtskild från omdirigeringar mellan domäner.

Kontrollera callback-URL:er för OAuth och OIDC

Autentiseringsflöden avslöjar ofta ett felaktigt offentligt värdnamn eftersom leverantören validerar en exakt omdirigerings-URI.

En fokuserad felsökningsartikel om OIDC på OIDC-callbacker är beroende av proxyns offentliga URL hjälper till att isolera denna gren, eftersom den behandlar samma specifika delproblem i stället för att bara definiera det underliggande protokollet.

Jämför utfärdare, callback, vidarebefordrade huvuden och appens bas-URL tillsammans. Att en vanlig sida laddas bevisar inte att sökvägen för inloggningscallbacken är korrekt.

Testa den exakta sökvägen till hemservern igen

Efter att du har ändrat en variabel upprepar du samma NAS- eller egenhostade arbetsflöde från samma klient i stället för att byta till ett annat test som kan använda en annan sökväg.

Den relaterade ZimaSpace-guiden på den närliggande nätverkssökvägen till hemservern hjälper till att hålla den slutliga verifieringen kopplad till samma egenhostade miljö.

Problemet är åtgärdat först när det ursprungliga symtomet förblir löst efter återanslutning, omstart av tjänsten och en andra kontrollerad överföring eller begäran.

Vanliga frågor

Kan DNS orsaka en HTTP 301 eller 302?

DNS returnerar endast en adress. Omdirigeringen genereras av proxyn, autentiseringslagret eller appen.

Varför laddas rätt app innan webbläsaren byter domän?

Den ursprungliga proxyrutten kan vara korrekt, medan backend senare genererar en absolut omdirigering från en felaktig bas-URL eller ett felaktigt vidarebefordrat värdnamn.