Waarom geeft een reverse proxy na het opnieuw bouwen van een container een 502-foutmelding?

Een reverse proxy retourneert een 502 nadat een container opnieuw is opgebouwd wanneer er geen geldige verbinding meer kan worden geopend met de opnieuw opgebouwde upstream.

Bij het opnieuw opbouwen kan de container worden vervangen, een nieuw adres krijgen, kan een Docker-netwerk worden losgekoppeld of hernoemd, kan de blootgestelde poort veranderen, kan een onvolledige configuratie worden teruggezet of kan de proxy worden gestart voordat de toepassing klaar is. De juiste diagnose begint met het foutlogboek van de proxy en volgt het exacte upstreamadres van proxy naar container, in plaats van beide services opnieuw te starten totdat de fout tijdelijk verdwijnt.

Bevestig dat de 502 wordt veroorzaakt door een verbindingsfout met de upstream

Vraag het betreffende domein één keer op en noteer het tijdstip, de proxystatus, het upstreamadres en het volledige foutbericht. Maak onderscheid tussen een geweigerde verbinding, een onbekende host, een time-out, een verbroken verbinding, een mislukte TLS-handshake en een ongeldige respons.

Een 502 betekent dat de proxy geen bruikbare upstreamrespons heeft ontvangen, maar de foutdetails bepalen of het doel ontbrak, onbereikbaar was, niet luisterde of het verkeerde protocol gebruikte. Een actuele NGINX-gids voor probleemoplossing vermeldt dat een opnieuw opgebouwde container ervoor kan zorgen dat de proxy een oud backendadres blijft gebruiken totdat de naamresolutie of configuratie is vernieuwd.

Test de toepassing rechtstreeks vanaf de proxyhost of proxycontainer met de gelogde upstreamnaam, het adres, de poort en het protocol. Als dat rechtstreekse verzoek op dezelfde manier mislukt, beperk het onderzoek dan tot de verbinding tussen proxy en container en wijzig de openbare DNS of certificaten niet.

Vergelijk het upstreamdoel voor en na het opnieuw opbouwen

Controleer de naam van de opnieuw opgebouwde container, de servicenaam, het interne IP-adres, de blootgestelde poort, gepubliceerde poort, netwerkaliassen en netwerkkoppelingen. Vergelijk deze met de proxyconfiguratie en het laatst werkende doel.

Een probleem met nginx-proxy beschrijft een opnieuw opgebouwde container waarvan het IP-adres veranderde, terwijl de proxy verzoeken bleef verzenden naar de onbereikbare upstreamcontainer. Het openbare domein bleef correct; alleen de identiteit van de private upstream was veranderd.

Gebruik bij voorkeur een stabiele Compose-servicenaam of netwerkalias in plaats van een container-IP-adres. Als een IP-adres bewust vast is ingesteld, controleer dan of de opnieuw opgebouwde service dit adres daadwerkelijk heeft gekregen en of geen andere container het adres nu gebruikt.

Controleer of de proxy en toepassing nog steeds hetzelfde Docker-netwerk gebruiken

Bekijk de netwerken die aan de proxy en toepassing zijn gekoppeld en bevestig dat ze minstens één door de gebruiker gedefinieerd netwerk delen. Een op de host gepubliceerde poort zorgt er niet automatisch voor dat de containernaam bereikbaar is vanaf een ander geïsoleerd Docker-netwerk.

In een Docker-netwerkgeval bleek dat het verplaatsen van een afhankelijke service naar het juiste netwerk terugkerende 502-responsen direct verhelpt. Dit toont aan hoe een onbereikbaar upstreampad kan ontstaan, zelfs wanneer alle containers actief blijven.

Koppel services via Compose in plaats van via eenmalige opdrachten, zodat de relatie behouden blijft bij het opnieuw opbouwen. Test de DNS-resolutie en de upstreampoort vanuit de proxycontainer nadat de stack opnieuw is aangemaakt.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controleer de interne luisterpoort en het bindadres

Bevestig dat de toepassing luistert op de poort die de proxy gebruikt en op een adres dat vanaf het containernetwerk bereikbaar is. Verwar een op de host gepubliceerde poort niet met de interne luisterpoort van de container.

Een proxy kan pas verbinding maken wanneer de toepassing niet alleen aan loopback is gebonden. Een service die binnen de eigen container op 127.0.0.1 luistert, is niet beschikbaar voor de proxy, zelfs wanneer een lokale gezondheidscontrole slaagt.

Controleer het toepassingslogboek en de socketlijst en voer één rechtstreeks verzoek uit vanuit de proxycontainer. Als de poort verbindingen weigert, herstel dan eerst de listener of configuratie van de toepassing voordat je retries toevoegt of langere proxytime-outs instelt.

Wacht tot de toepassing klaar is in plaats van alleen tot de container is gestart

Een opnieuw opgebouwde container kan actief zijn terwijl migraties, databaseherstel, het opwarmen van de cache of het genereren van configuratie de toepassing nog verhindert verzoeken te accepteren. Vergelijk het tijdstip van de eerste 502 met de gezondheids- en opstartlogboeken.

Een discussie over het oplossen van problemen met Grist laat zien hoe Docker-architectuur, omgevingsinstellingen en gereedheid van de upstream kunnen leiden tot aanhoudende 502-fouten aan de containerzijde na het opnieuw opbouwen.

Voeg een zinvolle gezondheidscontrole toe en laat de proxy of afhankelijke services wachten op de bewerking die clients nodig hebben, niet alleen op het bestaan van een proces. Houd retries begrensd, zodat een permanent defecte toepassing niet wordt aangezien voor een trage opstart.

Vernieuw de proxyresolutie en bouw het stabiele pad opnieuw op

Laad de proxy opnieuw of maak deze opnieuw aan nadat de servicenaam, het netwerk, de poort en de gezondheidsstatus correct zijn. Als de proxy namen alleen bij het opstarten resolveert, configureer dan ondersteunde runtime-resolutie of een voorspelbare herstartvolgorde.

De ZimaSpace-werkwijze voor het isoleren van een defecte containerafhankelijkheid biedt aanvullende diagnostiek wanneer de upstream herhaaldelijk afsluit in plaats van gezond te blijven.

De reparatie is pas voltooid wanneer de proxy de servicenaam na een volgende rebuild resolveert, de bedoelde interne poort bereikt, de opstart afwacht en het domein zonder handmatige IP-wijzigingen aanbiedt. Verwijder tijdelijke doelen met rechtstreekse IP-adressen en ongedocumenteerde netwerkkoppelingen na de validatie.