Błąd 502 Bad Gateway i 503 Service Unavailable – czym się różnią i jak je naprawić?

Czym jest błąd 502 Bad Gateway?

Błąd 502 Bad Gateway to komunikat, który oznacza że serwer działający jako bramka (gateway) lub proxy otrzymał nieprawidłową odpowiedź od serwera docelowego. Brzmi skomplikowanie? W praktyce jest prostsze niż myślisz.

Wyobraź sobie, że Twoja strona to restauracja. Kelner (serwer proxy, np. Nginx) przyjmuje zamówienie od klienta i zanosi je do kuchni (serwer aplikacji, np. PHP-FPM). Błąd 502 pojawia się gdy kelner wraca z kuchni z pustymi rękami - albo kuchnia w ogóle nie odpowiedziała, albo odpowiedziała czymś niezrozumiałym. Kelner nie ma pojęcia co się stało w kuchni, wie tylko że nie dostał tego, czego oczekiwał.

W rzeczywistości webowej wygląda to tak: przeglądarka wysyła request do Nginx (lub Apache), ten przekazuje request do PHP-FPM/Python/Node.js, ale backend albo nie odpowiada wcale, albo odpowiada w sposób który Nginx nie rozumie. To może być timeout (backend myśli zbyt długo), crash aplikacji, problem z połączeniem między serwerami, lub po prostu backend jest przeciążony i nie przyjmuje nowych requestów.

Kluczowa rzecz o błędzie 502: problem NIE leży w serwerze, z którym łączy się przeglądarka. Ten serwer działa poprawnie i próbuje pomóc. Problem jest gdzieś głębiej - w serwerze aplikacji, bazie danych, lub w komunikacji między nimi.

Czym jest błąd 503 Service Unavailable?

Błąd 503 Service Unavailable to zupełnie inna historia. Ten komunikat oznacza że serwer jest sprawny, ale celowo odmawia obsługi zapytania. To nie jest awaria - to świadoma decyzja serwera.

Wracając do metafory z restauracją: błąd 503 to sytuacja gdy kelner mówi "przepraszamy, kuchnia jest zamknięta na remont" albo "wszystkie stoliki zajęte, proszę przyjść za godzinę". Kelner komunikuje się z Tobą normalnie, ale nie może Ci pomóc z konkretnych, znanych przyczyn.

W praktyce błąd 503 pojawia się w trzech głównych scenariuszach. Pierwszy: strona jest w trybie maintenance (konserwacji). Administrator włączył ten tryb żeby bezpiecznie zaktualizować system, bazę danych czy wtyczki. Drugi: serwer jest przeciążony i świadomie odrzuca nowe requesty żeby nie zwiększać problemu. Trzeci: rate limiting - zabezpieczenie zidentyfikowało zbyt dużą liczbę zapytań z jednego źródła i tymczasowo je blokuje.

Różnica między 502 a 503 jest fundamentalna: przy błędzie 503 serwer WIE co się dzieje i celowo odmawia. Przy 502 serwer nie ma pojęcia co jest nie tak, bo problem leży gdzie indziej. 503 to kontrolowana sytuacja, 502 to chaos.

Kluczowe różnice między 502 a 503 - tabela porównawcza

Aspekt	502 Bad Gateway	503 Service Unavailable
Przyczyna	Problem z backendem/komunikacją między serwerami	Serwer celowo odmawia (maintenance, przeciążenie)
Czy serwer wie co się dzieje?	NIE - serwer jest zdezorientowany	TAK - serwer kontroluje sytuację
Typowy czas trwania	Sekundy do minut (często przejściowe)	Zaplanowane lub do rozwiązania problemu
Dla użytkownika	Frustrujące - działa/nie działa losowo	Zrozumiałe - jasny komunikat o powodzie
Rozwiązanie	Wymaga diagnozy technicznej	Często wystarczy poczekać

Jak naprawić błąd 502 Bad Gateway?

Błąd 502 jest podstępny, bo często pojawia się i znika samoistnie. To sprawia, że trudno go zdiagnozować. Kiedy w końcu siedziesz przed terminalem gotowy do debugowania, wszystko działa idealnie. Ale masz swoje narzędzia i strategię.

Sprawdź logi - tam jest prawda

Pierwszym krokiem zawsze są logi. Dla Nginx sprawdź /var/log/nginx/error.log. Dla Apache to /var/log/apache2/error.log. Szukaj wpisów z czasu gdy błąd wystąpił. Komunikaty w stylu "upstream timed out" lub "Connection refused" mówią Ci dokładnie co poszło nie tak.

tail -f /var/log/nginx/error.log
tail -f /var/log/php-fpm/error.log

Komenda tail -f pokazuje logi na żywo - odśwież stronę i zobacz co się pojawia w logach w tym samym momencie. To najszybszy sposób na złapanie problemu.

Problem z backendem (PHP-FPM, Node.js, Python)

Najczęstsza przyczyna 502 to backend który nie odpowiada. Dla stron PHP sprawdź czy PHP-FPM działa:

systemctl status php-fpm
systemctl status php7.4-fpm # lub inna wersja PHP

Jeśli usługa nie działa, uruchom ją ponownie: systemctl restart php-fpm. Dla aplikacji Node.js sprawdź czy proces działa: pm2 status lub systemctl status twoja-aplikacja. Dla Pythona/Django: systemctl status gunicorn lub uwsgi.

Timeout'y - backend myśli za długo

Jeśli backend odpowiada, ale za wolno, Nginx wyrzuci 502 zanim dostanie odpowiedź. Zwiększ timeout'y w konfiguracji Nginx:

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;

Te wartości ustawiają timeout na 10 minut (600 sekund). Dla większości zastosowań 60-120 sekund wystarczy, ale jeśli masz ciężkie operacje (import danych, generowanie raportów), możesz potrzebować więcej.

Zasoby serwera - RAM i CPU

Sprawdź czy serwer nie jest przeciążony. Użyj komendy top lub htop żeby zobaczyć użycie CPU i RAM. Jeśli któryś proces żre 100% CPU lub RAM jest zapchany, masz problem. PHP-FPM z ograniczoną liczbą worker'ów przy dużym ruchu szybko się zapycha.

Zwiększ liczbę worker'ów PHP-FPM w pliku konfiguracyjnym (zazwyczaj /etc/php-fpm.d/www.conf):

pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15

Jak naprawić błąd 503 Service Unavailable?

Błąd 503 jest zazwyczaj prostszy do rozwiązania niż 502, ponieważ przyczyna jest znana i kontrolowana. Nie musisz się domyślać co jest nie tak - serwer Ci to mówi.

Tryb maintenance - najczęstsza przyczyna

Jeśli właśnie aktualizowałeś stronę i widzisz 503, prawdopodobnie zapomniałeś wyłączyć tryb konserwacji. W WordPressie sprawdź czy w głównym katalogu nie ma pliku .maintenance - po prostu go usuń. W Laravel użyj: php artisan up. W Magento: usuń plik maintenance.flag z katalogu var/.

Przeciążenie serwera

Jeśli serwer świadomie zwraca 503 bo jest przeciążony, masz problem wydajnościowy do rozwiązania. Krótkoterminowo: zrestartuj usługi (systemctl restart nginx php-fpm). Długoterminowo: musisz albo zwiększyć zasoby (więcej RAM, więcej CPU), albo zoptymalizować aplikację.

Rate limiting - zbyt wiele requestów

Jeśli widzisz 503 przy próbie dostępu do API lub po wielu odświeżeniach strony, może to być rate limiting - zabezpieczenie które blokuje zbyt częste zapytania. Sprawdź konfigurację rate limiting w Nginx lub firewall'u. Jeśli to Ty jesteś zablokowany, poczekaj kilka minut lub skontaktuj się z hostingiem o zwiększenie limitów.

⚠️ Uwaga: Jeśli widzisz masowe błędy 503 bez widocznej przyczyny, może to być atak DDoS. Serwer broni się odrzucając requesty. Sprawdź logi dostępu i rozważ włączenie ochrony DDoS (Cloudflare, Sucuri).

Dlaczego monitoring jest kluczowy dla błędów 502 i 503?

Oto prawda o błędach 502 i 503: większość z nich trwa krótko i występuje sporadycznie. Błąd 502 może pojawić się na 30 sekund gdy backend się restartuje. 503 może wystąpić przez 2 minuty podczas krótkiego przeciążenia. Problem w tym, że te 30 sekund czy 2 minuty mogą kosztować Cię setki złotych w straconej sprzedaży.

Jeszcze gorsze jest to, że możesz w ogóle nie wiedzieć że problem wystąpił. Sprawdzasz stronę rano - działa. Sprawdzasz wieczorem - działa. A między 14:00 a 14:05 była niedostępna i 50 klientów się wycofało. Nie dzwonili, nie pisali - po prostu poszli do konkurencji.

Profesjonalny monitoring stron sprawdza dostępność Twojej witryny co 1-5 minut z wielu lokalizacji na świecie. Gdy wykryje błąd 502 lub 503, natychmiast wysyła alert SMS lub email. Dowiadujesz się o problemie w ciągu 2-3 minut od jego wystąpienia, a nie po fakcie z Google Analytics. To różnica między szybką reakcją a stratami finansowymi.

Jak zapobiegać błędom 502 i 503?

Lepiej zapobiegać niż naprawiać. Oto sprawdzone metody na minimalizację ryzyka błędów 502 i 503 na Twojej stronie.

Load balancing - rozłóż obciążenie

Jeśli masz duży ruch, jeden serwer to single point of failure. Load balancer rozdziela ruch między wiele serwerów backendowych. Jeśli jeden z nich przestanie odpowiadać (502), load balancer automatycznie kieruje ruch do pozostałych. Problem dotyczy tylko części użytkowników przez krótki czas, nie wszystkich naraz.

Health checks - monitoruj backend

Skonfiguruj health checks w Nginx lub load balancerze. Serwer regularnie sprawdza czy backend odpowiada. Jeśli wykryje problem, automatycznie przestaje kierować do niego ruch zanim użytkownicy zobaczą 502. W Nginx wygląda to tak:

upstream backend {
  server backend1.example.com max_fails=3 fail_timeout=30s;
  server backend2.example.com max_fails=3 fail_timeout=30s;
}

CDN - odciąż serwer

Content Delivery Network cache'uje statyczne zasoby (obrazy, CSS, JS) i serwuje je z serwerów na całym świecie. To dramatycznie zmniejsza obciążenie Twojego serwera. Mniej obciążenia = mniejsze ryzyko 502/503. Cloudflare, KeyCDN, czy BunnyCDN potrafią zredukować obciążenie o 60-80%.

Optymalizacja kodu i bazy danych

Wolne zapytania SQL, nieoptymalne pętle, brak cache'owania - to wszystko zwiększa czas odpowiedzi backendu. Im dłużej backend myśli, tym większe ryzyko timeout'u i błędu 502. Regularnie optymalizuj bazę danych, używaj cache'owania (Redis, Memcached), optymalizuj kod. Szybki backend = mniejsze ryzyko problemów.

💡 Pro tip: Ustawienie Retry-After header przy błędzie 503 mówi przeglądarce i botom Google kiedy mogą spróbować ponownie. To minimalizuje negatywny wpływ na SEO: Retry-After: 3600 (powrót za godzinę).

Podsumowanie

Błędy 502 Bad Gateway i 503 Service Unavailable to dwa różne światy. 502 to problem z komunikacją między serwerami - backend nie odpowiada lub odpowiada źle, a serwer proxy nie wie dlaczego. 503 to kontrolowana odmowa - serwer działa, ale celowo nie obsługuje requestów z powodu maintenance, przeciążenia lub rate limiting.

Kluczem do radzenia sobie z tymi błędami jest szybka diagnoza. Sprawdź logi, zidentyfikuj czy problem jest w backendzie (502) czy w świadomej konfiguracji (503). Dla 502: uruchom ponownie backend, zwiększ timeout'y, sprawdź zasoby. Dla 503: wyłącz maintenance, zmniejsz obciążenie, poczekaj aż rate limiting wygaśnie.

Najważniejsze: nie czekaj aż użytkownicy Ci powiedzą że strona nie działa. Te błędy są często przemijające i sporadyczne. Profesjonalny monitoring wyłapie je w czasie rzeczywistym i pozwoli Ci reagować zanim problem urośnie. Bo w internecie każda minuta niedostępności to utracone pieniądze, które nigdy nie wrócą.