En omvänd proxy kan skicka en domän till fel app när en ny catch-all-rutt matchar bredare eller prioriteras högre än den avsedda värdregeln.
Detta är mer specifikt än en generell omdirigering till fel domän eller ett DNS-problem. Det viktiga testet är om den korrekta domänen fortfarande når den förväntade proxy-IP-adressen och det förväntade certifikatet, men proxyn väljer fel backend först efter att den nya standardrutten har skapats. Jämför ruttmatchningar och prioriteringar innan du ändrar DNS, programmets bas-URL:er eller certifikat.
Bevisa att catch-all-regeln ändrade valet av backend
Skicka samma domänförfrågan före och efter att du endast har inaktiverat den nya catch-all- eller standardrutten. Anteckna proxyns åtkomstlogg, vald router eller serverblock, backend-adress, svarmarkör och certifikat.
En praktisk guide till Nginx-standardservrar varnar för att catch-all-regler kan fånga trafik även när flera uttryckliga virtuella värdar redan finns.
Om inaktivering av reservrutten omedelbart återställer den avsedda appen ska du låta DNS och backend-appen vara oförändrade. Nästa steg är att se till att den specifika rutten vinner utan att ta bort ett säkert reservbeteende för okända värdnamn.
Kontrollera om den specifika värdregeln fortfarande matchar exakt
Jämför det begärda värdnamnet med den avsedda ruttregeln tecken för tecken, inklusive underdomän, wildcard-gränser, avslutande punkter i testverktyg och om regeln lyssnar på samma HTTP- eller HTTPS-ingång som catch-all-rutten.
En guide för omvänd proxy med flera appar visar att värdnamnsregler väljer olika backends endast när den inkommande värden matchar regeln som proxyn faktiskt har läst in.
Åtgärda en ofullständig eller felstavad värdmatchare innan du justerar prioriteten. Att höja prioriteten för en regel som aldrig matchar gör bara konfigurationen svårare att förstå.
Jämför ruttprioriteten med catch-all-rutten
För proxyservrar som stöder uttrycklig eller härledd prioritet ska du kontrollera vilken regel som vinner när både den specifika värden och den breda reservrutten kan matcha samma förfrågan. Anteckna den utvärderade regeln, inte bara ordningen i konfigurationsfilen.
Ett Traefik-exempel med catch-all ger medvetet reservrutten lägre prioritet än de riktiga rutterna så att specifika tjänster utvärderas först.
Placera reservrutten under alla avsedda apprutter och testa igen. Lös inte problemet genom att tilldela godtyckligt stora tal till varje router. Använd i stället ett enkelt, dokumenterat prioritetssystem som fungerar även när nya appar läggs till.
Inspektera standardservern på Nginx-liknande proxyservrar
På Nginx och liknande konfigurationer ska du fastställa vilket serverblock som blir standard för den lyssningsadressen och porten när ingen matchning av värdnamnet hittas. Det första inlästa blocket kan bli reservrutt om ingen uttrycklig standard har definierats.
En fokuserad felsökningsartikel om Nginx förklarar varför omatchade värdar når standardservrar i stället för att avvisas tyst.
Använd ett neutralt standardsvar eller en feltjänst i stället för att göra en riktig app till reservrutt. Då kan ett okänt eller felstavat värdnamn inte oavsiktligt exponera en annan självhostad app.
Kontrollera HTTP- och HTTPS-reservrutter separat
En catch-all-rutt som läggs till för port 80 beter sig inte automatiskt på samma sätt på port 443. TLS-dirigering, SNI, separata ingångar eller en andra catch-all-rutt kan göra att endast HTTPS-förfrågningar når fel app.
Ett felsökningsfall i Caddy beskriver en catch-all-rutt som beter sig olika beroende på protokoll och visar varför den protokollspecifika rutten måste testas direkt.
Skicka både HTTP och HTTPS med samma värdnamn och anteckna vilken hanterare som valdes. Åtgärda reservrutten på den berörda ingången i stället för att ändra den fungerande protokollvägen.
Håll reservrutten neutral och testa alla kända domäner igen
När matchningsomfattningen eller prioriteten har korrigerats ska du låta reservrutten returnera ett neutralt 404-, 421- eller kontrollerat felsvar i stället för att proxiera varje okänt värdnamn till en produktionsapp. Testa sedan varje känd självhostad domän en gång.
En översikt över arkitektur för omvända proxyservrar betonar att proxyn bestämmer backend efter att förfrågan nått proxyn, vilket är anledningen till att korrekt DNS inte ensamt kan bevisa att dirigeringen är korrekt.
Åtgärden är slutförd när varje känt värdnamn når sin avsedda app och ett okänt värdnamn endast når den neutrala reservrutten. Den relaterade ZimaSpace-artikeln om en omvänd proxy som omdirigerar till en annan domän är nästa spår när proxyn väljer rätt backend men appen senare ändrar domän.
Vanliga frågor
Kan DNS göra att en catch-all-rutt vinner?
DNS kan skicka förfrågan till fel proxy-IP-adress, men när den korrekta proxyn tar emot det avsedda värdnamnet är ruttmatchningen ett beslut som proxyn fattar. Kontrollera båda lagren separat.
Bör catch-all-rutten proxiera till en instrumentpanelapp?
Vanligtvis inte. Ett neutralt felmål är säkrare eftersom stavfel och okända värdnamn då inte oavsiktligt kan exponera en riktig administrations- eller medieapp.
Varför når endast HTTPS fel app?
HTTPS kan använda en annan lyssnare, SNI-väg, certifikatplats eller reservregel än HTTP. Testa båda ingångarna separat innan du ändrar den globala dirigeringen.
Support och tips
Mer att läsa

Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.

Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.

Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.

