Błąd 502, 503 i 504 — czym się różnią i jak znaleźć przyczynę?

Kody 502, 503 i 504 należą do błędów serwerowych, lecz opisują inne sytuacje. Ich rozróżnienie zawęża miejsce poszukiwań: połączenie bramy z usługą zaplecza, czasową niedostępność albo przekroczenie czasu oczekiwania. Sam kod nadal nie podaje technicznej przyczyny, dlatego potrzebny jest ślad z właściwej warstwy.

Krótka odpowiedź: 502 Bad Gateway oznacza, że brama lub proxy dostały nieprawidłową odpowiedź od serwera nadrzędnego; 503 Service Unavailable informuje, że usługa jest chwilowo niedostępna, np. z powodu przeciążenia lub prac; 504 Gateway Timeout oznacza, że brama nie otrzymała odpowiedzi na czas. Zapisz dokładny URL, godzinę, działanie, kod i nagłówki, sprawdź zakres awarii oraz logi CDN, serwera WWW, PHP i aplikacji. Nie zwiększaj timeoutów, dopóki nie wiesz, co blokuje odpowiedź.

Jak wygląda łańcuch żądania?

W typowej stronie droga może wyglądać tak:

przeglądarka → CDN/WAF → reverse proxy → serwer WWW → PHP-FPM → WordPress → baza lub zewnętrzne API

Użytkownik widzi jedną stronę, ale odpowiedź przechodzi przez kilka systemów. Brama nie zawsze jest CDN-em; może nią być Nginx przed Apache, load balancer albo infrastruktura hostingu. Kod i strona błędu często wskazują warstwę, która zakończyła żądanie, nie tę, która pierwotnie zawiodła.

502 Bad Gateway: odpowiedź z zaplecza była nieprawidłowa

Według definicji HTTP serwer działający jako brama lub proxy otrzymał niewłaściwą odpowiedź od upstreamu, czyli usługi stojącej dalej w łańcuchu. Przykładowe przyczyny:

• proces PHP-FPM nie działa lub zerwał połączenie;
• proxy łączy się z błędnym adresem lub portem;
• usługa została ponownie uruchomiona w trakcie żądania;
• upstream zamknął połączenie bez poprawnej odpowiedzi HTTP;
• konfiguracje protokołu lub TLS między warstwami się nie zgadzają;
• awaria sieci dotyczy połączenia wewnętrznego.

502 nie oznacza automatycznie awarii WordPressa. Najpierw trzeba ustalić, która brama wyświetliła komunikat i do jakiego upstreamu próbowała dotrzeć.

503 Service Unavailable: usługa chwilowo nie może obsłużyć żądania

503 opisuje czasową niedostępność. Może być celową odpowiedzią w trakcie prac albo skutkiem braku zasobów. Typowe sytuacje to:

• zaplanowany tryb konserwacji;
• wyczerpana pula procesów;
• przeciążenie ruchem lub zadaniami w tle;
• chwilowo wyłączona aplikacja;
• ochrona serwera odrzucająca kolejne żądania;
• zależność, bez której usługa nie może działać.

Serwer może dołączyć nagłówek Retry-After, wskazujący, kiedy klient powinien spróbować ponownie. Nie każda odpowiedź 503 go zawiera. Jeśli prace są planowane, poprawny 503 jest lepszym sygnałem tymczasowości niż zwracanie strony awarii z kodem 200.

504 Gateway Timeout: zaplecze nie odpowiedziało w czasie

504 pojawia się, gdy brama lub proxy nie otrzymały potrzebnej odpowiedzi od upstreamu przed upływem własnego limitu. Połączenie mogło istnieć, ale operacja trwała zbyt długo. Powody obejmują:

• wolne zapytanie do bazy;
• zawieszoną integrację API;
• ciężki import, raport lub generowanie obrazu;
• blokadę procesu albo zasobu;
• kolejkę żądań przy przeciążeniu;
• zbyt krótki timeout bramy w stosunku do prawidłowej operacji.

Ostatni punkt można potwierdzić dopiero po pomiarze. Bez tego podniesienie timeoutu może tylko sprawić, że użytkownik dłużej będzie czekał na ten sam błąd.

500 a 502, 503 i 504

Błąd 500 jest ogólną informacją, że serwer napotkał nieoczekiwany stan podczas obsługi żądania. 502 i 504 mówią dodatkowo o roli bramy oraz komunikacji z upstreamem. 503 opisuje niedostępność usługi, często czasową.

W praktyce ta sama pierwotna usterka może dać inne kody zależnie od architektury. Awaria PHP na prostym serwerze może skończyć się 500, a w układzie z proxy — 502. Dlatego nie diagnozuje się wyłącznie po numerze.

Co może zrobić właściciel strony?

1. Zapisz dowody

Zanotuj:

• pełny adres URL;
• dokładną godzinę ze strefą czasową;
• kod błędu i treść strony;
• działanie poprzedzające problem;
• czy użytkownik był zalogowany;
• identyfikator żądania, jeśli jest widoczny;
• ostatnią zmianę w witrynie lub hostingu.

Zrzut ekranu jest pomocny, ale godzina i adres zwykle dają administratorowi więcej.

2. Sprawdź zakres

Otwórz inną podstronę, panel i prosty statyczny plik. Sprawdź stronę z innej sieci, ale nie odświeżaj jej agresywnie. Ustal, czy problem dotyczy:

• wszystkich użytkowników;
• jednego regionu lub operatora;
• tylko panelu albo formularza;
• jednej ciężkiej operacji;
• domeny za CDN-em, podczas gdy origin działa;
• całego konta hostingowego.

3. Sprawdź status dostawców

Zajrzyj na oficjalny status hostingu, CDN-u i kluczowych integracji. Publiczny status nie zastępuje logów, ale może oszczędzić przypadkowych zmian w aplikacji podczas awarii infrastruktury.

4. Odczytaj odpowiedź i nagłówki

Administrator może wykonać bezpieczny odczyt:

curl -I https://example.com/problem

Nagłówki takie jak Server, Via, identyfikator CDN-u lub Retry-After mogą wskazać warstwę odpowiedzi. Nie publikuj pełnych nagłówków, jeśli zawierają dane wewnętrzne albo identyfikatory sesji.

5. Dopasuj logi do godziny

Sprawdź w tej kolejności:

• zdarzenia CDN/WAF;
• log błędów reverse proxy i serwera WWW;
• log PHP-FPM;
• log aplikacji WordPress;
• wolne zapytania i stan bazy;
• log integracji zewnętrznej;
• wykresy CPU, RAM, procesów i operacji dyskowych.

Jeśli zegary systemów mają różne strefy, przelicz czas. Korelacja tego samego żądania między warstwami jest bardziej wiarygodna niż pojedynczy komunikat.

Szybka macierz diagnostyczna

Czego nie robić w ciemno?

• nie wyłączaj firewalla i CDN-u bez planu;
• nie zwiększaj wszystkich timeoutów;
• nie restartuj kolejnych usług bez zapisania stanu;
• nie kasuj cache, jeśli potrzebujesz zachować dowód;
• nie uruchamiaj wielu ciężkich prób jednocześnie;
• nie przywracaj starej kopii, zanim potwierdzisz, że problem jest w danych lub kodzie;
• nie uznawaj pojedynczego udanego odświeżenia za naprawę.

Restart może chwilowo odblokować pulę, ale bez znalezienia przyczyny błąd wróci. Warto zapisać metryki przed restartem.

Jak ograniczyć powroty błędów?

Wprowadź monitoring dostępności i czasu odpowiedzi, centralne logi, alarmy wykorzystania zasobów oraz identyfikatory żądań. Ciężkie prace przenieś do kolejek, zapytania do bazy mierz, a integracje zabezpieczaj rozsądnymi timeoutami i kontrolowanymi ponowieniami. Zmiany serwera oraz WordPressa testuj na stagingu.

Dobra reakcja operacyjna rozdziela dwa cele: szybkie przywrócenie usługi oraz późniejsze usunięcie pierwotnej przyczyny. Oba powinny zostać udokumentowane.

Podsumowanie

502 wskazuje na nieprawidłową odpowiedź upstreamu, 503 na czasową niedostępność, a 504 na brak odpowiedzi upstreamu w czasie. Kod określa kategorię i miejsce w łańcuchu, ale dopiero godzina, zakres, nagłówki, logi oraz metryki pokazują rzeczywistą przyczynę. To właśnie taki pakiet danych pozwala administratorowi naprawić problem, zamiast tylko ukryć jego objaw.