Dlaczego odwrotny serwer proxy zwraca błąd 502 po przebudowaniu kontenera?

Serwer proxy zwraca błąd 502 po ponownym zbudowaniu kontenera, gdy nie może już nawiązać prawidłowego połączenia z odbudowanym serwerem nadrzędnym.

Ponowne zbudowanie może zastąpić kontener, nadać mu nowy adres, odłączyć lub zmienić nazwę sieci Docker, zmienić wystawiony port, przywrócić niekompletną konfigurację albo uruchomić proxy, zanim aplikacja będzie gotowa. Prawidłowa diagnoza zaczyna się od dziennika błędów proxy i polega na śledzeniu dokładnego adresu serwera nadrzędnego od proxy do kontenera, zamiast ponownego uruchamiania obu usług aż do chwilowego zniknięcia błędu.

Potwierdź, że błąd 502 wynika z nieudanego połączenia z serwerem nadrzędnym

Wyślij raz żądanie do domeny, której dotyczy problem, i zapisz znacznik czasu, status proxy, adres serwera nadrzędnego oraz pełny komunikat błędu. Rozróżnij odmowę połączenia, nieznalezienie hosta, przekroczenie limitu czasu, zresetowanie połączenia, nieudaną negocjację TLS i nieprawidłową odpowiedź.

Błąd 502 oznacza, że proxy nie otrzymało użytecznej odpowiedzi z serwera nadrzędnego, ale szczegóły błędu wskazują, czy cel nie istnieje, jest nieosiągalny, nie nasłuchuje lub korzysta z niewłaściwego protokołu. Aktualny przewodnik rozwiązywania problemów z NGINX wskazuje, że ponowne zbudowanie kontenera może sprawić, że proxy będzie używać starego adresu zaplecza, dopóki rozpoznawanie nazwy lub konfiguracja nie zostaną odświeżone.

Przetestuj aplikację bezpośrednio z hosta proxy lub kontenera proxy, używając zapisanej nazwy serwera nadrzędnego, adresu, portu i protokołu. Jeśli bezpośrednie żądanie kończy się takim samym błędem, kontynuuj analizę między proxy a kontenerem, zamiast zmieniać publiczny DNS lub certyfikaty.

Porównaj cel serwera nadrzędnego przed ponownym zbudowaniem i po nim

Sprawdź nazwę odbudowanego kontenera, nazwę usługi, wewnętrzny adres IP, wystawiony port, opublikowany port, aliasy sieciowe i podłączenia do sieci. Porównaj je z konfiguracją proxy oraz z ostatnim działającym celem.

Opis problemu nginx-proxy przedstawia sytuację, w której ponowne zbudowanie zmieniło adres IP kontenera aplikacji, a proxy nadal wysyłało żądania do nieosiągalnego kontenera serwera nadrzędnego. Publiczna domena pozostała prawidłowa, a zmieniła się jedynie wewnętrzna tożsamość serwera nadrzędnego.

Preferuj stabilną nazwę usługi Compose lub alias sieciowy zamiast adresu IP kontenera. Jeśli adres IP jest celowo stały, sprawdź, czy odbudowana usługa rzeczywiście go otrzymała i czy żaden inny kontener nie korzysta obecnie z tego adresu.

Sprawdź, czy proxy i aplikacja nadal współdzielą sieć Docker

Wyświetl sieci podłączone do proxy i aplikacji oraz potwierdź, że współdzielą co najmniej jedną sieć zdefiniowaną przez użytkownika. Opublikowany port hosta nie sprawia automatycznie, że nazwa kontenera będzie dostępna z innej, odizolowanej sieci Docker.

W jednym z przypadków dotyczących sieci Docker przeniesienie zależnej usługi do właściwej sieci natychmiast usunęło powtarzające się odpowiedzi 502, pokazując, jak nieosiągalna ścieżka do serwera nadrzędnego może powodować problemy, nawet gdy wszystkie kontenery nadal działają.

Podłączaj usługi za pomocą Compose zamiast poleceń jednorazowych, aby ta zależność była zachowywana po ponownym zbudowaniu. Po odtworzeniu stosu przetestuj rozpoznawanie DNS i port serwera nadrzędnego z wnętrza kontenera proxy.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Sprawdź wewnętrzny port nasłuchu i adres powiązania

Potwierdź, że aplikacja nasłuchuje na porcie używanym przez proxy oraz na adresie dostępnym z sieci kontenera. Nie myl portu opublikowanego na hoście z wewnętrznym portem nasłuchu kontenera.

Proxy może nawiązać połączenie dopiero wtedy, gdy aplikacja powiąże się z adresem innym niż tylko interfejs pętli zwrotnej. Usługa nasłuchująca na 127.0.0.1 we własnym kontenerze jest niedostępna dla proxy, nawet jeśli lokalne polecenie sprawdzające stan zakończy się powodzeniem.

Sprawdź dziennik aplikacji, listę gniazd oraz jedno bezpośrednie żądanie z kontenera proxy. Jeśli połączenia z portem są odrzucane, napraw nasłuchiwanie aplikacji lub konfigurację, zanim dodasz ponowienia albo wydłużysz limity czasu proxy.

Poczekaj na gotowość aplikacji zamiast na samo uruchomienie kontenera

Odbudowany kontener może działać, podczas gdy migracje, odzyskiwanie bazy danych, rozgrzewanie pamięci podręcznej lub generowanie konfiguracji nadal uniemożliwiają aplikacji przyjmowanie żądań. Porównaj znacznik czasu pierwszego błędu 502 ze stanem zdrowia i dziennikami uruchamiania.

W dyskusji dotyczącej rozwiązywania problemów z Grist pokazano, jak architektura Docker, ustawienia środowiska i gotowość serwera nadrzędnego mogą wspólnie prowadzić do trwałych błędów 502 po stronie kontenera po ponownym zbudowaniu.

Dodaj sensowne sprawdzanie stanu i spraw, aby proxy lub usługi zależne czekały na operację potrzebną klientom, a nie tylko na istnienie procesu. Ogranicz liczbę ponowień, aby trwale niesprawna aplikacja nie sprawiała wrażenia wolnego uruchamiania.

Odśwież rozpoznawanie proxy i odbuduj stabilną ścieżkę

Przeładuj lub odtwórz proxy, gdy nazwa usługi, sieć, port i stan zdrowia będą prawidłowe. Jeśli proxy rozpoznaje nazwy tylko podczas uruchamiania, skonfiguruj obsługiwane rozpoznawanie w czasie działania lub przewidywalną kolejność ponownego uruchamiania.

Proces ZimaSpace dotyczący izolowania niesprawnej zależności kontenera zawiera powiązaną procedurę diagnostyczną na wypadek, gdy serwer nadrzędny wielokrotnie kończy działanie zamiast pozostawać w dobrym stanie.

Naprawa jest zakończona dopiero wtedy, gdy po kolejnym ponownym zbudowaniu proxy rozpoznaje nazwę usługi, dociera do właściwego portu wewnętrznego, czeka na zakończenie uruchamiania i obsługuje domenę bez ręcznej edycji adresu IP. Po przeprowadzeniu walidacji usuń tymczasowe cele bezpośrednio wskazujące adres IP oraz nieudokumentowane podłączenia do sieci.