Een reverse proxy repareren die één domein naar de verkeerde app doorstuurt na het toevoegen van een catch-allregel

Een reverse proxy kan één domein naar de verkeerde app sturen wanneer een nieuwe catch-all-route breder matcht of voorrang krijgt op de bedoelde hostregel.

Dit is specifieker dan een algemene omleiding naar het verkeerde domein of een DNS-probleem. De belangrijkste test is of het juiste domein nog steeds het verwachte proxy-IP-adres en certificaat bereikt, maar de proxy pas de verkeerde backend selecteert nadat de nieuwe standaardroute bestaat. Vergelijk route-overeenkomsten en prioriteiten voordat je DNS, basis-URL’s van de applicatie of certificaten wijzigt.

Bewijs dat de catch-all-regel de backendselectie heeft gewijzigd

Stuur hetzelfde domeinverzoek vóór en na het uitschakelen van alleen de nieuwe catch-all- of standaardroute. Leg het proxy-toegangslogboek, de geselecteerde router of serverblock, het backendadres, de responsmarkering en het certificaat vast.

Een praktische handleiding voor de standaardserver van Nginx waarschuwt dat catch-all-regels verkeer kunnen onderscheppen, zelfs wanneer er al meerdere expliciete virtuele hosts bestaan.

Als het uitschakelen van de fallback de bedoelde app onmiddellijk herstelt, laat DNS en de backendapplicatie dan ongewijzigd. De volgende taak is ervoor te zorgen dat de specifieke route wint, zonder veilige fallback-functionaliteit voor onbekende hostnamen te verwijderen.

Controleer of de specifieke hostregel nog exact overeenkomt

Vergelijk de aangevraagde hostnaam teken voor teken met de bedoelde routeregel, inclusief subdomein, grenzen van wildcards, afsluitende punten in testtools en de vraag of de regel naar hetzelfde HTTP- of HTTPS-eindpunt luistert als de catch-all.

Een handleiding voor een reverse proxy met meerdere apps laat zien dat hostnaamregels verschillende backends selecteren alleen wanneer de binnenkomende host overeenkomt met de regel die de proxy daadwerkelijk heeft geladen.

Corrigeer een onvolledige of verkeerd gespelde hostmatcher voordat je de prioriteit aanpast. Het verhogen van de prioriteit van een regel die nooit overeenkomt, maakt de configuratie alleen moeilijker te begrijpen.

Vergelijk de routeprioriteit met de catch-all

Bekijk bij proxy’s die expliciete of afgeleide prioriteit ondersteunen welke regel wint wanneer zowel de specifieke host als de brede fallback op hetzelfde verzoek kan overeenkomen. Leg de geëvalueerde regel vast, niet alleen de volgorde in het configuratiebestand.

Een Traefik-catch-allvoorbeeld geeft de fallback bewust een lagere prioriteit dan echte routes, zodat specifieke services eerst worden geëvalueerd.

Plaats de fallback onder elke bedoelde applicatieroute en test opnieuw. Los het probleem niet op door aan elke router willekeurig enorme getallen toe te kennen; houd een eenvoudig, gedocumenteerd prioriteitsschema aan dat toekomstige toevoegingen van apps aankan.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Inspecteer de standaardserver op Nginx-achtige proxy’s

Bepaal bij Nginx en vergelijkbare configuraties welk serverblock de standaard wordt voor dat luisteradres en die poort wanneer geen hostnaamovereenkomst wordt gevonden. Het eerst geladen block kan de fallback worden als er geen expliciete standaard is gedefinieerd.

Een gericht artikel over probleemoplossing met Nginx legt uit waarom niet-overeenkomende hosts standaardservers bereiken in plaats van stilzwijgend te worden geweigerd.

Gebruik een neutrale standaardrespons of foutservice in plaats van een echte applicatie als fallback. Zo kan een onbekende of verkeerd gespelde hostnaam niet per ongeluk een andere zelfgehoste app blootleggen.

Controleer HTTP- en HTTPS-fallbacks afzonderlijk

Een catch-all die voor poort 80 is toegevoegd, gedraagt zich niet automatisch hetzelfde op poort 443. TLS-routering, SNI, afzonderlijke eindpunten of een tweede catch-all kunnen ertoe leiden dat alleen HTTPS-verzoeken de verkeerde app bereiken.

Een Caddy-casus over probleemoplossing beschrijft een catch-all die zich per protocol anders gedraagt en laat zien waarom de protocolspecifieke route rechtstreeks moet worden getest.

Verzoek zowel HTTP als HTTPS met dezelfde hostnaam en leg de geselecteerde handler vast. Corrigeer de fallback op het getroffen eindpunt in plaats van het werkende protocolpad te wijzigen.

Houd de fallback neutraal en test elk bekend domein opnieuw

Laat de fallback na het corrigeren van het matchbereik of de prioriteit een neutrale 404, 421 of gecontroleerde foutpagina teruggeven in plaats van elke onbekende hostnaam naar één productieapp te proxien. Test vervolgens elk bekend zelfgehost domein één keer.

Een overzicht van reverse-proxyarchitecturen benadrukt dat de proxy de backend bepaalt nadat het verzoek de proxy bereikt. Daarom kan correcte DNS alleen geen correcte routering bewijzen.

De oplossing is voltooid wanneer elke bekende hostnaam de bedoelde app bereikt en een onbekende hostnaam uitsluitend de neutrale fallback bereikt. Het gerelateerde ZimaSpace-artikel over een reverse proxy die naar een ander domein omleidt is de volgende stap wanneer de proxy de juiste backend selecteert, maar de applicatie daarna van domein verandert.

Veelgestelde vragen

Kan DNS ervoor zorgen dat een catch-all-route wint?

DNS kan het verzoek naar het verkeerde proxy-IP-adres sturen, maar zodra de juiste proxy de bedoelde hostnaam ontvangt, is route matching een beslissing van de proxy. Controleer beide lagen afzonderlijk.

Moet de catch-all naar een dashboardapp proxien?

Meestal niet. Een neutraal foutdoel is veiliger, omdat typefouten en onbekende hostnamen dan niet per ongeluk een echte beheer- of mediaapplicatie kunnen blootleggen.

Waarom bereikt alleen HTTPS de verkeerde app?

HTTPS kan een andere listener, SNI-route, certificaatsite of fallbackregel gebruiken dan HTTP. Test beide eindpunten afzonderlijk voordat je de algemene routering wijzigt.