Varför returnerar en reverse proxy 502 efter att en container har byggts om?

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 Return 502 After a Container Rebuild?

En reverse proxy returnerar 502 efter att en container har byggts om när den inte längre kan upprätta en giltig anslutning till den ombyggda upstream-tjänsten.

En ombyggnad kan ersätta containern, tilldela en ny adress, koppla från eller byta namn på ett Docker-nätverk, ändra den exponerade porten, återställa en ofullständig konfiguration eller starta proxyn innan applikationen är redo. En korrekt felsökning börjar med proxyns fellogg och följer den exakta upstream-adressen från proxy till container i stället för att starta om båda tjänsterna tills felet tillfälligt försvinner.

Bekräfta att 502-felet beror på ett anslutningsfel till upstream-tjänsten

Skicka en begäran till den berörda domänen en gång och notera tidsstämpeln, proxyns status, upstream-adressen och det fullständiga felmeddelandet. Skilj mellan nekad anslutning, värd hittades inte, timeout, återställd anslutning, misslyckad TLS-handskakning och ogiltigt svar.

Ett 502-fel innebär att proxyn inte fick något användbart svar från upstream-tjänsten, men felinformationen avgör om målet saknades, inte kunde nås, inte lyssnade eller använde fel protokoll. En aktuell felsökningsguide för NGINX noterar att en ombyggd container kan göra att proxyn fortsätter använda en gammal backend-adress tills namnupplösningen eller konfigurationen har uppdaterats.

Testa applikationen direkt från proxyvärden eller proxycontainern med det upstream-namn, den adress, port och det protokoll som loggats. Om den direkta begäran misslyckas på samma sätt ska du fortsätta felsökningen mellan proxy och container i stället för att ändra publik DNS eller certifikat.

Jämför upstream-målet före och efter ombyggnaden

Kontrollera den ombyggda containerns namn, tjänstenamn, interna IP-adress, exponerade port, publicerade port, nätverksalias och nätverksanslutningar. Jämför dem med proxykonfigurationen och dess senast fungerande mål.

Ett ärende för nginx-proxy beskriver en ombyggnad som ändrade applikationscontainerns IP-adress medan proxyn fortsatte att skicka begäranden till den otillgängliga upstream-containern. Den publika domänen förblev korrekt medan endast den privata upstream-identiteten ändrades.

Föredra ett stabilt Compose-tjänstenamn eller nätverksalias framför en container-IP-adress. Om en IP-adress är avsiktligt fast, kontrollera att den ombyggda tjänsten verkligen fick den och att ingen annan container nu använder adressen.

Verifiera att proxyn och appen fortfarande delar ett Docker-nätverk

Lista nätverken som är anslutna till proxyn och applikationen och bekräfta att de delar minst ett användardefinierat nätverk. En publicerad värdport gör inte automatiskt containernamnet åtkomligt från ett annat isolerat Docker-nätverk.

Ett fall med Docker-nätverk visade att återkommande 502-svar försvann direkt när en beroende tjänst flyttades till rätt nätverk. Det visade hur en otillgänglig upstream-sökväg kan uppstå även när alla containrar fortfarande körs.

Anslut tjänster via Compose i stället för med engångskommandon, så att relationen överlever ombyggnader. Testa DNS-upplösningen och upstream-porten inifrån proxycontainern efter att stacken har skapats om.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Kontrollera den interna lyssningsporten och bindningsadressen

Bekräfta att applikationen lyssnar på den port som proxyn använder och på en adress som kan nås från containernätverket. Blanda inte ihop en publicerad värdport med containerns interna lyssningsport.

En proxy kan ansluta först när appen binder till något annat än loopback-adressen. En tjänst som lyssnar på 127.0.0.1 inuti sin egen container är inte åtkomlig för proxyn, även om ett lokalt hälsokommando lyckas.

Kontrollera applikationsloggen, socketlistan och en direkt begäran från proxycontainern. Om porten avvisar anslutningar ska du åtgärda appens lyssnare eller konfiguration innan du lägger till nya försök eller längre proxy-timeouts.

Vänta tills applikationen är redo i stället för att bara invänta containerstart

En ombyggd container kan vara igång medan migreringar, databasåterställning, uppvärmning av cache eller generering av konfiguration fortfarande hindrar applikationen från att ta emot begäranden. Jämför tidsstämpeln för det första 502-felet med hälso- och uppstartsloggarna.

En felsökningsdiskussion om Grist visar hur Docker-arkitektur, miljöinställningar och upstream-beredskap kan leda till ihållande 502-fel på containersidan efter en ombyggnad.

Lägg till en meningsfull hälsokontroll och låt proxyn eller de beroende tjänsterna vänta på den funktion som klienterna behöver, inte bara på att en process existerar. Begränsa antalet försök så att en permanent appkrasch inte ser ut som en långsam uppstart.

Uppdatera proxyns namnupplösning och återskapa den stabila sökvägen

Ladda om eller återskapa proxyn efter att tjänstenamn, nätverk, port och hälsotillstånd är korrekta. Om proxyn endast löser namn vid start ska du konfigurera en stödd upplösning i drift eller en förutsägbar omstartsordning.

ZimaSpaces arbetsflöde för att isolera ett felande containerberoende erbjuder en kompletterande diagnos när upstream-tjänsten avslutas upprepade gånger i stället för att förbli frisk.

Åtgärden är klar först när proxyn löser tjänstenamnet efter ännu en ombyggnad, når den avsedda interna porten, väntar igenom uppstarten och levererar domänen utan manuella IP-ändringar. Ta bort tillfälliga direkta IP-mål och odokumenterade nätverksanslutningar efter valideringen.