502 oznacza, że brama lub proxy otrzymały nieprawidłową odpowiedź od usługi po stronie upstream. Sprawdź komunikację między proxy a aplikacją oraz log błędu z konkretnej chwili.
Narysuj drogę żądania
Ustal, czy klient łączy się z CDN, potem z Nginx, a następnie PHP-FPM lub aplikacją kontenerową. Błąd może powstawać na różnych połączeniach. Strona błędu z logo proxy daje wskazówkę, lecz nie jest pełną diagnozą. Odróżnij 502 od timeoutu 504 i ogólnego 500.
Sprawdź zakres: cała witryna, jedna ścieżka czy tylko większe żądania? Zapisz godzinę i ostatnią zmianę. Przy aktualizacji PHP zmienić się mogła nazwa socketa. Po odtworzeniu kontenera aplikacja może nasłuchiwać na innym porcie lub interfejsie.
Czy usługa docelowa działa i nasłuchuje?
systemctl status nginx --no-pager
ss -ltnp
ss -lxnpDla PHP-FPM odczytaj nazwę właściwej jednostki. Ss dla TCP i socketów Unix pomaga porównać rzeczywisty nasłuch z konfiguracją fastcgi_pass lub proxy_pass. Część danych wymaga uprawnień administratora.
Jeśli to aplikacja HTTP na lokalnym porcie, przetestuj jej własny endpoint z serwera, np. curl http://127.0.0.1:3000/. To przykład, port zależy od aplikacji. Nie wysyłaj zwykłego żądania HTTP bezpośrednio do socketa FastCGI — PHP-FPM używa innego protokołu.
Log wskazuje następny krok
| Fragment logu | Co sprawdzić |
|---|---|
| Connection refused | Proces, port i adres nasłuchiwania. |
| No such file or directory dla socketa | Ścieżkę socketa oraz działanie PHP-FPM. |
| Permission denied | Prawa socketa i użytkowników usług. |
| Upstream prematurely closed connection | Awarię procesu, pamięć i log aplikacji. |
Odczytaj wpisy usługi z tego samego czasu przez journalctl. Szukaj OOM, restartu, błędu kodu lub zakończenia workera. Jeśli problem występuje tylko w okresach obciążenia, zbierz metryki zamiast zwiększać limity na ślepo.
Konfiguracja proxy i kontenery
W Dockerze localhost wewnątrz kontenera oznacza ten kontener. Proxy może wymagać nazwy usługi w sieci projektu. Sprawdź, czy oba kontenery są w odpowiedniej sieci i czy port docelowy jest wewnętrznym portem aplikacji. Nie publikuj wszystkich portów na świat tylko po to, by usunąć błąd łączności.
Przed wdrożeniem zmiany Nginx wykonaj nginx -t. Przeładuj dopiero poprawną konfigurację i sprawdź rezultat. Restart obu usług równocześnie może usunąć ślady potrzebne do diagnozy, a przy problemie z danymi nie będzie trwałą naprawą.
Kiedy zwiększać timeout?
Dopiero gdy aplikacja wykonuje poprawne, świadomie długie zadanie i to właśnie limit czasu jest potwierdzoną przyczyną. Import trwający wiele minut może wymagać zadania w tle zamiast utrzymywania połączenia przeglądarki. Zwiększenie timeoutu nie naprawia błędnego portu, brakującego socketa ani braku pamięci.
Na VPS Castpol zbierz konfigurację połączenia, czas i zanonimizowany log. Jeśli korzystasz z hostingu współdzielonego, nie masz kontroli nad usługą systemową — przekaż te dane obsłudze, a w aplikacji sprawdź błąd 500.
Źródła i dokumentacja
Dokumentacja do dalszej weryfikacji ustawień i wymagań swojej wersji.