Błąd 502 Bad Gateway w Nginx zwykle oznacza, że Nginx nie otrzymał prawidłowej odpowiedzi z serwera nadrzędnego, takiego jak PHP-FPM, Node.js lub inna aplikacja backendowa.
Najczęstsze przyczyny to zatrzymane usługi aplikacji, nieprawidłowe porty lub gniazda serwera nadrzędnego oraz procesy backendowe, które ulegają awarii lub nieoczekiwanie zamykają połączenia.
Zacznij od sprawdzenia logów błędów Nginx. Często wskazują one dokładną przyczynę niepowodzenia połączenia.
Ten przewodnik przedstawia siedem praktycznych kroków diagnozowania problemów na serwerach z systemem Linux i Nginx.
Co powoduje błąd 502 Bad Gateway w Nginx?
Nginx często działa jako odwrotne proxy: przekazuje żądania do aplikacji backendowych i zwraca ich odpowiedzi odwiedzającym.
Jeśli usługa nadrzędna nie odpowie prawidłowo, Nginx może zwrócić kod stanu HTTP 502.
Typowe przyczyny to:
- Zatrzymane usługi backendowe lub ich awarie.
- Nieprawidłowe adresy IP, porty lub gniazda Unix serwera nadrzędnego.
- Awarie procesów PHP-FPM lub aplikacji.
- Problemy z uprawnieniami dostępu do gniazd.
- Niewystarczająca ilość pamięci lub miejsca na dysku.
- Nieprawidłowe lub przedwcześnie zamykane połączenia z serwerem nadrzędnym.
Poniższe czynności wymagają dostępu przez SSH i uprawnień do administrowania serwerem z systemem Linux.
1. Sprawdź logi błędów Nginx
Logi błędów Nginx to zwykle najszybszy sposób na ustalenie przyczyny błędu 502.
Połącz się z serwerem przez SSH i uruchom:
sudo tail -n 50 /var/log/nginx/error.logSpowoduje to wyświetlenie 50 najnowszych wpisów w logu.
Aby śledzić log na bieżąco podczas diagnozowania problemu, użyj:
sudo tail -f /var/log/nginx/error.logOdśwież stronę, na której występuje błąd, i obserwuj nowe komunikaty.
| Komunikat w logu | Prawdopodobny problem |
|---|---|
connect() failed (111: Connection refused) | Aplikacja backendowa nie przyjmuje połączeń |
No such file or directory | Skonfigurowane gniazdo serwera nadrzędnego nie istnieje |
Permission denied | Nginx nie ma dostępu do gniazda lub zasobu |
upstream prematurely closed connection | Aplikacja backendowa nieoczekiwanie zamknęła połączenie |
upstream sent invalid header | Aplikacja backendowa zwróciła nieprawidłowo sformatowane nagłówki odpowiedzi |
W Twojej konfiguracji hostingu logi mogą znajdować się w innej lokalizacji.
Nie zmieniaj ustawień Nginx, dopóki nie ustalisz prawdopodobnej przyczyny.
2. Sprawdź, czy usługa backendowa działa
Błąd 502 często występuje dlatego, że aplikacja działająca za Nginx została zatrzymana.
W przypadku usługi aplikacji zarządzanej przez systemd uruchom:
sudo systemctl status myappZastąp myapp rzeczywistą nazwą swojej usługi.
W przypadku aplikacji opartych na PHP i korzystających z PHP-FPM nazwa usługi może wyglądać tak:
sudo systemctl status php8.3-fpmZainstalowana wersja PHP i nazwa usługi mogą być inne.
Jeśli usługa uległa awarii, przejrzyj jej logi:
sudo journalctl -u myapp -n 50Sprawdź, czy wystąpiły awarie, brakuje zależności albo pojawiły się błędy konfiguracji lub problemy związane z pamięcią.
Uruchom usługę ponownie dopiero po ustaleniu i usunięciu przyczyny problemu.
3. Sprawdź port lub gniazdo serwera nadrzędnego
Nginx musi przekazywać żądania na właściwy adres aplikacji backendowej.
Na przykład konfiguracja odwrotnego proxy może zawierać:
location / {
proxy_pass http://127.0.0.1:3000;
}Oznacza to, że Nginx przekazuje żądania do aplikacji HTTP nasłuchującej na porcie 3000.
Sprawdź, czy na tym porcie działa usługa nasłuchująca:
sudo ss -ltnp | grep ':3000'Możesz też przetestować aplikację backendową HTTP bezpośrednio:
curl -i http://127.0.0.1:3000/Jeśli aplikacja backendowa jest niedostępna, sprawdź konfigurację jej usługi, zanim zmienisz ustawienia Nginx.
Sprawdź gniazda PHP-FPM
PHP-FPM często korzysta z gniazd Unix lub portów TCP.
Konfiguracja Nginx może zawierać:
fastcgi_pass unix:/run/php/php8.3-fpm.sock;Sprawdź, czy skonfigurowane gniazdo istnieje:
ls -l /run/php/Ścieżka do gniazda musi odpowiadać ustawieniu listen puli PHP-FPM, a Nginx musi mieć uprawnienia do nawiązania połączenia.
Ważne: proxy_pass służy do obsługi serwerów nadrzędnych HTTP, a fastcgi_pass — usług FastCGI, takich jak PHP-FPM. Nie można ich stosować zamiennie.
4. Sprawdź pamięć i miejsce na dysku serwera
Aplikacje backendowe mogą ulegać awariom lub przestawać odpowiadać, gdy serwerowi zabraknie zasobów.
Sprawdź pamięć:
free -hSprawdź miejsce na dysku:
df -hSprawdź uruchomione procesy:
topJeśli aplikacja została zakończona z powodu niedoboru pamięci, odpowiednie komunikaty możesz znaleźć w dzienniku systemowym:
sudo journalctl -k --since "1 hour ago"Poszukaj zdarzeń związanych z wyczerpaniem pamięci lub komunikatów o zakończeniu procesów.
Jeśli na dysku zabrakło miejsca, przed usunięciem plików ustal, co je zajmuje.
5. Sprawdź uprawnienia do gniazd i logi aplikacji
Czasami aplikacja backendowa działa, ale Nginx nie może się z nią komunikować.
W przypadku gniazd Unix sprawdź właściciela i uprawnienia:
ls -l /run/php/Jeśli logi wskazują na błąd uprawnień, sprawdź również katalogi na ścieżce do gniazda.
Właściwe uprawnienia zależą od użytkownika, na którego koncie działają procesy robocze Nginx, oraz od konfiguracji usługi backendowej.
Unikaj nadawania zbyt szerokich uprawnień, na przykład przez chmod 777. Zamiast tego dostosuj konfigurację odpowiedniej usługi lub puli, aby uprawnione procesy miały dostęp do gniazda.
Jeśli logi błędów wskazują, że serwer nadrzędny przedwcześnie zamknął połączenie, sprawdź logi aplikacji backendowej pod kątem awarii, wyjątków lub nieudanych żądań.
6. Przetestuj konfigurację Nginx
Nieprawidłowe ustawienia proxy lub zmiany w konfiguracji również mogą zakłócić komunikację z serwerem nadrzędnym.
Przed zastosowaniem zmian sprawdź poprawność konfiguracji Nginx:
sudo nginx -tJeśli test zakończy się pomyślnie, przeładuj Nginx:
sudo systemctl reload nginxPrzeładowanie pozwala zastosować poprawne zmiany w konfiguracji bez zbędnego ponownego uruchamiania usługi.
Jeśli test się nie powiedzie, najpierw popraw zgłoszony błąd konfiguracji.
Nie zwiększaj bez namysłu limitów czasu ani rozmiaru buforów proxy. Takie zmiany nie naprawią zatrzymanej aplikacji backendowej, nieprawidłowego gniazda ani odrzucanych połączeń.
7. Potwierdź, że błąd 502 został usunięty
Po usunięciu przyczyny problemu przetestuj adres URL, pod którym występował błąd:
curl -I https://example.comZastąp example.com swoją rzeczywistą domeną.
Pomyślne żądanie zwykle zwraca odpowiedni kod stanu HTTP, na przykład 200 OK, choć przekierowania i inne prawidłowe odpowiedzi mogą mieć inne kody.
Otwórz też witrynę w przeglądarce i ponownie przejrzyj logi błędów Nginx.
Jeśli błąd powraca przy dużym obciążeniu, monitoruj usługę backendową i wykorzystanie zasobów podczas odtwarzania problemu.
Jak zapobiegać błędom 502 w Nginx
Nie każdej awarii aplikacji backendowej da się zapobiec, ale właściwe zarządzanie serwerem ogranicza liczbę przerw w działaniu, których można uniknąć.
- Monitoruj stan Nginx i usług backendowych.
- Przeglądaj logi aplikacji po wdrożeniach.
- Skonfiguruj odpowiednie zasady przywracania działania usług.
- Monitoruj wykorzystanie pamięci, przestrzeni dyskowej i połączeń.
- Sprawdzaj poprawność zmian w konfiguracji przed ich zastosowaniem.
- Testuj aplikacje bezpośrednio, zanim skierujesz do nich ruch przez Nginx.
Jeśli aplikacja potrzebuje więcej zasobów, zmierz jej rzeczywiste zużycie, zanim zdecydujesz się zwiększyć zasoby serwera.
Najczęściej zadawane pytania
Oznacza to, że Nginx, działając jako brama lub proxy, otrzymał nieprawidłową odpowiedź z serwera nadrzędnego. Przyczyną często jest zatrzymana usługa backendowa lub problem z połączeniem z serwerem nadrzędnym.
Niekoniecznie. Ponowne uruchomienie lub przeładowanie Nginx nie naprawi niedostępnej aplikacji, nieprawidłowego portu aplikacji backendowej ani brakującego gniazda PHP-FPM.
Błąd 502 oznacza nieprawidłową odpowiedź z serwera nadrzędnego, natomiast błąd 504 oznacza, że brama nie otrzymała od niego odpowiedzi przed upływem limitu czasu.
Tak. Wyczerpanie pamięci może spowodować awarię lub zakończenie procesów backendowych, przez co Nginx nie będzie mógł się z nimi komunikować.
Nie. Błędy HTTP 502 mogą również zwracać inne bramy, serwery proxy, sieci CDN i systemy równoważenia obciążenia.
Podsumowanie
Naprawę błędu 502 Bad Gateway w Nginx należy zacząć od ustalenia, dlaczego aplikacja nadrzędna nie odpowiada prawidłowo.
Najpierw sprawdź logi błędów Nginx, upewnij się, że usługa backendowa działa, i zweryfikuj skonfigurowany port lub gniazdo. Następnie zbadaj limity zasobów, uprawnienia i awarie aplikacji.
W większości przypadków ustalenie konkretnej przyczyny awarii serwera nadrzędnego jest skuteczniejsze niż wielokrotne ponowne uruchamianie Nginx lub zmienianie limitów czasu.
