Błędy serwera 5xx – czym różnią się kody 500, 502, 503 i 504?

Kiedy przeglądarka zamiast strony pokazuje suchy komunikat o błędzie, przyczyna może leżeć w wielu miejscach: w samej aplikacji, w konfiguracji hostingu, w warstwie pośredniczącej między użytkownikiem a serwerem albo w bazie danych. Błędy serwera 5xx to sygnał, że problem powstał po stronie serwera, a nie po stronie użytkownika czy jego łącza.

To rozróżnienie ma znaczenie praktyczne, bo od niego zależy, gdzie w ogóle warto szukać rozwiązania. Niedziałająca witryna bywa efektem właśnie takich odpowiedzi, a szerszy przegląd możliwych powodów opisuje osobny materiał o tym, dlaczego strona internetowa nie działa.

Cztery najczęściej spotykane kody z tej rodziny to 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable oraz 504 Gateway Timeout. Wyglądają podobnie, każdy zaczyna się od cyfry 5, a mimo to każdy wskazuje inny etap i inny rodzaj usterki. Umiejętność ich odróżnienia potrafi skrócić diagnostykę z godzin do minut, ponieważ od razu zawęża obszar poszukiwań do konkretnej warstwy: aplikacji, serwera pośredniczącego albo serwera nadrzędnego.

Co oznaczają błędy serwera 5xx?

Każda odpowiedź serwera w protokole HTTP zawiera trzycyfrowy kod statusu. Pierwsza cyfra określa klasę odpowiedzi. Kody z zakresu 2xx oznaczają powodzenie, 3xx dotyczą przekierowań, 4xx wskazują na błąd po stronie klienta (np. nieistniejący adres albo brak uprawnień), a 5xx to błędy po stronie serwera. Zgodnie z obowiązującą specyfikacją RFC 9110 klasa 5xx obejmuje kody od 500 do 599 i opisuje sytuacje, w których serwer jest świadomy, że napotkał problem lub nie jest w stanie obsłużyć poprawnie sformułowanego żądania.

Najważniejsza różnica praktyczna dotyczy odpowiedzialności. Przy błędach 4xx to żądanie klienta jest wadliwe, więc naprawa zwykle leży po stronie osoby lub programu wysyłającego zapytanie. Przy błędach HTTP 5xx żądanie może być całkowicie poprawne, a i tak serwer nie potrafi go obsłużyć. Oznacza to, że odświeżanie strony rzadko pomaga w trwały sposób, a rozwiązania trzeba szukać w konfiguracji, kodzie aplikacji, zasobach maszyny albo w warstwie pośredniczącej.

Choć wszystkie kody błędów 5xx łączy wspólny mianownik, każdy z nich niesie inną informację diagnostyczną. Jeden mówi o awarii wewnątrz aplikacji, drugi o problemie w komunikacji między serwerami, trzeci o przeciążeniu lub przerwie technicznej, a czwarty o przekroczonym czasie oczekiwania. Dalsze sekcje omawiają po kolei błędy HTTP 500, 502, 503 i 504, a następnie zestawiają je ze sobą, bo to właśnie różnice między nimi są tu najbardziej użyteczne.

Warto od razu odnotować jedną rzecz techniczną. W większości nowoczesnych wdrożeń ruch nie trafia bezpośrednio do aplikacji. Najpierw dociera do serwera pośredniczącego, na przykład Nginx działającego jako reverse proxy, do systemu CDN typu Cloudflare albo do load balancera. Dopiero ta warstwa przekazuje żądanie dalej, do serwera nadrzędnego (określanego jako upstream lub backend), na którym działa właściwa aplikacja i baza danych. Znajomość tego łańcucha bardzo ułatwia zrozumienie, dlaczego kody 502 i 504 w ogóle istnieją i czym różnią się od kodu 500.

Błąd 500 Internal Server Error: co oznacza?

Błąd 500 Internal Server Error to najbardziej ogólna odpowiedź z całej rodziny. Zgodnie z RFC 9110 kod 500 oznacza, że serwer napotkał nieoczekiwany warunek, który uniemożliwił obsłużenie żądania. Sam w sobie nie wskazuje konkretnej przyczyny, bo jest komunikatem zbiorczym dla sytuacji, których serwer nie potrafi opisać precyzyjniej. Z tego powodu wewnętrzny błąd serwera bywa najbardziej frustrujący w diagnostyce: mówi, że coś poszło nie tak, ale nie mówi co.

W praktyce przyczyny błędu 500 najczęściej leżą wewnątrz aplikacji lub w konfiguracji serwera. Do typowych źródeł należą:

• Błąd w kodzie aplikacji, na przykład nieobsłużony wyjątek albo błąd składni. W środowiskach PHP objawia się to jako błąd PHP 500, gdy skrypt kończy działanie awaryjnie.
• Nieprawidłowa konfiguracja serwera, w tym błędy w pliku .htaccess na serwerach Apache, złe reguły przepisywania adresów albo odwołania do niedostępnych modułów.
• Błędne uprawnienia plików i katalogów, przez które serwer nie może odczytać lub wykonać potrzebnych zasobów.
• Wyczerpanie limitu pamięci przydzielonego procesowi, przez co skrypt zostaje przerwany w połowie wykonania.
• Konflikt komponentów aplikacji, klasyczny przy błędzie 500 w WordPress, gdzie wadliwa wtyczka lub motyw potrafi wywrócić całą witrynę.

Cechą wspólną tych sytuacji jest to, że serwer odebrał żądanie i próbował je obsłużyć samodzielnie, lecz przetwarzanie zakończyło się niepowodzeniem wewnątrz jego własnej logiki. Nie ma tu mowy o warstwie pośredniczącej ani o serwerze nadrzędnym, bo problem powstaje w miejscu, które faktycznie generuje odpowiedź.

Dlatego gdy strona zwraca kod 500, pierwszym miejscem do sprawdzenia są logi błędów aplikacji oraz dziennik serwera WWW, gdzie zwykle zapisywany jest znacznie bardziej szczegółowy komunikat niż ten widoczny w przeglądarce.

Ważna uwaga dotyczy bezpieczeństwa i użyteczności zarazem. Domyślnie serwer ukrywa szczegóły techniczne przed odwiedzającymi, żeby nie ujawniać budowy aplikacji. To rozsądne z punktu widzenia bezpieczeństwa, ale utrudnia diagnozę osobie postronnej. Prawdziwa treść komunikatu, łącznie z numerem linii i nazwą pliku, czeka w logach po stronie serwera, i to tam kryje się właściwa odpowiedź na pytanie o przyczynę błędu 500.

Błąd 502 Bad Gateway: problem z bramą lub proxy

Błąd 502 Bad Gateway pojawia się w innym momencie łańcucha przetwarzania. Powstaje wtedy, gdy serwer działający jako brama lub proxy otrzymuje nieprawidłową odpowiedź z serwera nadrzędnego, do którego przekazał żądanie. Innymi słowy warstwa pośrednicząca zadziałała poprawnie, wysłała zapytanie dalej, ale odpowiedź, która wróciła, była uszkodzona, pusta albo niezgodna z protokołem.

Kluczowa różnica względem kodu 500 polega na tym, że 502 Bad Gateway to komunikat od pośrednika, a nie od maszyny wykonującej właściwą pracę. Serwer proxy w istocie mówi: przekazałem żądanie dalej, lecz to, co dostałem w zamian, nie nadaje się do przekazania klientowi. Z tego wynika, że przyczyny błędu 502 niemal zawsze leżą w komunikacji między pośrednikiem a backendem.

Do najczęstszych źródeł należą:

• Serwer nadrzędny nie odpowiada albo uległ awarii, na przykład proces aplikacji przestał działać. W środowisku PHP typowym winowajcą jest zatrzymana lub przeciążona usługa PHP-FPM.
• Backend zwraca odpowiedź niezgodną z protokołem, uszkodzoną lub przerwaną w połowie transmisji.
• Błędna konfiguracja reverse proxy, na przykład wskazanie na nieistniejący port albo niepoprawny adres serwera upstream. Stąd częsty błąd 502 w Nginx przy pomyłkach w sekcji upstream.
• Restart lub wdrożenie aplikacji w trakcie obsługi ruchu, gdy pośrednik trafia na moment, w którym backend jest chwilowo niedostępny.
• Problem po stronie CDN, widoczny jako błąd 502 na Cloudflare, gdy serwer nadrzędny obsługiwany przez Cloudflare zwraca niepoprawną odpowiedź.

Charakterystyczne dla błędu bramy jest to, że sama warstwa pośrednicząca działa i potrafi wygenerować stronę błędu, natomiast serwer, który miał dostarczyć treść, zawiódł. Dlatego diagnostyka powinna skupić się na kondycji serwera upstream: czy proces aplikacji żyje, czy nasłuchuje na właściwym porcie, czy nie zabrakło mu zasobów oraz co pokazują jego własne logi w momencie wystąpienia błędu.

Błąd 503 Service Unavailable: przeciążenie lub niedostępność

Błąd 503 Service Unavailable różni się od poprzednich tym, że zwykle jest stanem zamierzonym lub przynajmniej rozpoznanym przez sam serwer. Kod 503 oznacza, że usługa jest tymczasowo niedostępna, najczęściej z powodu przeciążenia albo prowadzonych prac technicznych. To komunikat mówiący: teraz nie mogę obsłużyć żądania, ale nie dlatego, że coś się zepsuło na stałe, tylko dlatego, że chwilowo brakuje warunków do pracy.

Taka natura kodu 503 ma jedną istotną konsekwencję. Odpowiedzi tego typu często zawierają nagłówek Retry-After, który sugeruje, po jakim czasie warto ponowić próbę. Dobrze skonfigurowana przerwa techniczna korzysta właśnie z tego mechanizmu, dzięki czemu zarówno przeglądarki, jak i roboty wyszukiwarek rozumieją, że niedostępność jest przejściowa.

Typowe przyczyny błędu 503:

• Przeciążenie serwera, gdy liczba jednoczesnych żądań przekracza możliwości maszyny lub aplikacji. Widać wtedy gwałtowny wzrost obciążenia procesora oraz kolejkowanie zapytań.
• Wyczerpanie zasobów, w tym brak pamięci albo przekroczony limit procesów roboczych, przez co serwer odmawia przyjmowania kolejnych połączeń.
• Zbyt wiele połączeń naraz, na przykład podczas nagłej fali ruchu, ataku wolumetrycznego albo błędnie działającego skryptu generującego lawinę zapytań.
• Prace konserwacyjne, celowo wprowadzone przez administratora na czas aktualizacji. W tym przypadku błąd 503 w WordPress pojawia się na przykład podczas aktualizacji rdzenia, wtyczek lub motywu, gdy system aktywuje tryb konserwacji.
• Przeciążona aplikacja ograniczona przez własne mechanizmy zabezpieczające, które odrzucają część ruchu, żeby uchronić resztę przed całkowitą awarią.

W odróżnieniu od kodu 500, przy którym coś zawiodło wewnątrz przetwarzania, oraz kodu 502, przy którym zawiodła komunikacja z backendem, 503 Service Unavailable zwykle sygnalizuje, że wszystkie elementy w zasadzie działają, tylko nie mają w danym momencie mocy przerobowej albo świadomie wstrzymały obsługę. Dlatego naprawa polega częściej na skalowaniu zasobów, optymalizacji obciążenia albo cierpliwym odczekaniu na koniec prac niż na poszukiwaniu wadliwej linii kodu.

Błąd 504 Gateway Timeout: przekroczony czas odpowiedzi

Błąd 504 Gateway Timeout dotyczy czasu. Powstaje, gdy brama lub proxy wysłało żądanie do serwera nadrzędnego, lecz nie otrzymało odpowiedzi w wyznaczonym limicie czasu. Pośrednik czekał, aż w końcu przerwał oczekiwanie i zwrócił kod 504, informując, że serwer nie odpowiedział na czas.

Tu leży najczęściej mylona granica między dwoma kodami. Przy błędzie 502 odpowiedź z backendu przyszła, ale była nieprawidłowa. Przy błędzie 504 odpowiedź w ogóle nie przyszła w wymaganym oknie czasowym. Pierwszy przypadek to zła odpowiedź, drugi to brak odpowiedzi na czas. To subtelna, ale bardzo praktyczna różnica, bo prowadzi do zupełnie innych działań naprawczych.

Najczęstsze przyczyny błędu 504:

• Zbyt wolne przetwarzanie po stronie backendu, na przykład kosztowna operacja, która trwa dłużej niż dopuszczalny timeout aplikacji.
• Powolne zapytanie do bazy danych, blokujące odpowiedź do momentu, aż baza zwróci wynik lub przekroczy limit.
• Timeout połączenia z backendem ustawiony zbyt nisko względem realnego czasu pracy aplikacji przy dużym obciążeniu.
• Przeciążony serwer nadrzędny, który wprawdzie działa, lecz odpowiada tak wolno, że nie mieści się w limicie pośrednika. Stąd typowy błąd 504 w Nginx przy niedopasowanych wartościach proxy_read_timeout.
• Problem po stronie CDN, obserwowany jako błąd 504 na Cloudflare, gdy serwer origin nie zdąży odpowiedzieć w czasie oczekiwanym przez sieć dostarczania treści.

Diagnostyka przekroczonego czasu bramy koncentruje się więc na wydajności: co konkretnie trwa zbyt długo, czy winne jest pojedyncze wolne zapytanie, brak indeksów w bazie, zewnętrzne API, na które aplikacja czeka, czy po prostu chwilowe przeciążenie. Samo podniesienie limitów czasu bywa doraźnym obejściem, jednak trwałe rozwiązanie zwykle wymaga przyspieszenia tego, co dziś odpowiada zbyt wolno.

Czym różnią się błędy 500, 502, 503 i 504?

To jest sedno całego zestawienia. Wszystkie cztery kody należą do błędów po stronie serwera, jednak każdy wskazuje inny etap obsługi żądania i inny rodzaj usterki. Najkrócej można ująć to tak:

• 500 Internal Server Error: serwer sam próbował obsłużyć żądanie i zawiódł wewnętrznie. Problem tkwi w aplikacji lub konfiguracji tej maszyny, która generuje odpowiedź.
• 502 Bad Gateway: pośrednik przekazał żądanie do serwera nadrzędnego i otrzymał od niego nieprawidłową odpowiedź. Problem leży w komunikacji z backendem albo w samym backendzie.
• 503 Service Unavailable: usługa jest tymczasowo niedostępna z powodu przeciążenia lub prac technicznych. Elementy w zasadzie działają, ale chwilowo nie obsługują ruchu.
• 504 Gateway Timeout: pośrednik czekał na odpowiedź z backendu i nie otrzymał jej na czas. Problem dotyczy wydajności i limitów czasowych.

Najczęściej mylone pary warto rozpisać osobno, bo tu popełnia się najwięcej pomyłek diagnostycznych.

Różnica między błędem 500 a 502 sprowadza się do tego, kto zgłasza problem. Kod 500 pochodzi od serwera, który sam wykonywał pracę i poległ w jej trakcie. Kod 502 pochodzi od pośrednika, który jedynie przekazywał żądanie i dostał w zamian wadliwą odpowiedź od kogoś innego. Jeśli więc w łańcuchu w ogóle nie ma warstwy proxy, kod 502 zwykle nie wystąpi, a znacznie bardziej prawdopodobny jest kod 500.

Błąd 500 a 503 różni się intencją. Kod 500 to nieoczekiwana awaria, coś zepsuło się wbrew założeniom. Kod 503 to stan często kontrolowany: przeciążenie rozpoznane przez serwer albo świadomie włączona przerwa techniczna. Pierwszy wymaga naprawy usterki, drugi zwykle ustępuje samoczynnie po odciążeniu maszyny lub zakończeniu prac.

Błąd 502 a 503 dzieli to, gdzie kończy się droga żądania. Przy kodzie 502 żądanie dotarło do backendu, ale odpowiedź była zła. Przy kodzie 503 usługa świadomie odmawia obsługi, bo nie ma na nią warunków. W jednym przypadku backend odpowiedział wadliwie, w drugim komunikuje własną niedostępność.

Różnica między 502 a 504 jest najbardziej praktyczna z całej grupy. Oba kody generuje pośrednik i oba dotyczą serwera nadrzędnego, jednak przy kodzie 502 odpowiedź przyszła i była nieprawidłowa, a przy kodzie 504 odpowiedź nie przyszła w wymaganym czasie. Uproszczając: 502 to zła odpowiedź, 504 to brak odpowiedzi na czas.

Błąd 503 a 504 również bywa mylony, choć oba dotyczą pewnej formy niedostępności. Kod 503 mówi wprost o tymczasowym braku możliwości obsługi, często z sugestią ponowienia próby. Kod 504 nie deklaruje niedostępności, lecz wynika z tego, że oczekiwanie na odpowiedź trwało zbyt długo i zostało przerwane przez pośrednika.

Poniższa tabela zbiera te różnice w jednym miejscu, tak aby dało się szybko przypisać kod do warstwy i typowej przyczyny.

Kod	Znaczenie	Gdzie powstaje	Typowa przyczyna	Kto zgłasza
500	Internal Server Error	Serwer generujący odpowiedź	Błąd aplikacji, konfiguracji lub uprawnień	Serwer wykonujący żądanie
502	Bad Gateway	Pośrednik (proxy, brama)	Nieprawidłowa odpowiedź z backendu	Warstwa proxy
503	Service Unavailable	Serwer lub aplikacja	Przeciążenie, brak zasobów, prace techniczne	Serwer świadomy niedostępności
504	Gateway Timeout	Pośrednik (proxy, brama)	Brak odpowiedzi backendu w limicie czasu	Warstwa proxy

Odpowiedź na częste pytanie, który błąd oznacza przeciążenie serwera, brzmi zwykle: kod 503, choć skrajne przeciążenie potrafi wtórnie wywołać także kod 504, gdy odpowiedzi zaczynają się spóźniać. Który błąd oznacza problem z proxy: przede wszystkim 502 oraz 504, bo oba generuje warstwa pośrednicząca. Który błąd oznacza timeout: jednoznacznie 504.

Jak zdiagnozować błędy serwera 5xx?

Skuteczna diagnoza opiera się na jednej zasadzie: najpierw ustalić warstwę, w której powstał błąd, a dopiero potem szukać szczegółów. Sam kod odpowiedzi wskazuje kierunek, natomiast konkretną przyczynę ujawniają dane z serwera.

Podstawowym źródłem informacji są logi. W zależności od architektury warto zajrzeć w kilka miejsc:

1. Error log serwera WWW, na przykład logi Nginx lub logi Apache, gdzie zapisywane są kody odpowiedzi oraz komunikaty warstwy pośredniczącej.
2. Logi aplikacji, w których znajdują się szczegóły błędów wewnętrznych, pełna treść wyjątków oraz numery linii kodu. To najważniejsze miejsce przy diagnozie kodu 500.
3. Logi bazy danych i backendu, przydatne przy kodach 502 i 504, gdy trzeba ustalić, czy serwer nadrzędny odpowiadał, jak długo trwały zapytania i czy nie zabrakło zasobów.

Drugim filarem jest sprawdzenie obciążenia serwera. Analiza wykorzystania procesora i pamięci pozwala rozpoznać przeciążenie prowadzące do kodu 503 oraz spowolnienia skutkujące kodem 504. Nagły wzrost zużycia zasobów zbieżny w czasie z falą błędów zwykle wskazuje na przyczynę wydajnościową, a nie na wadę kodu.

Trzecim elementem jest test odpowiedzi HTTP. Bezpośrednie sprawdzenie kodu zwracanego przez serwer, na przykład narzędziem wiersza poleceń, ujawnia, czy problem jest stały, czy sporadyczny, oraz na którym etapie łańcucha się pojawia. Analiza kolejnych warstw, od CDN przez reverse proxy aż po backend, pozwala precyzyjnie odpowiedzieć na pytanie, czy problem dotyczy serwera, aplikacji czy proxy.

Pojedynczy, jednorazowy błąd 5xx bywa efektem chwilowego zbiegu okoliczności, na przykład restartu usługi w trakcie wdrożenia. Znacznie groźniejsze są powtarzające się odpowiedzi 5xx, bo świadczą o utrzymującej się usterce lub systematycznym przeciążeniu. Ręczne wyłapywanie takich sytuacji jest zawodne, dlatego w praktyce sprawdza się stały monitoring dostępności oraz monitoring błędów 5xx, który rejestruje kody odpowiedzi w czasie i uruchamia alert, gdy ich udział przekracza próg.

Sposoby na wczesne wykrywanie awarii, zanim zauważą ją odwiedzający, omawia szerzej osobny materiał o monitoringu strony internetowej, gdzie monitorowanie błędów 5xx wpisuje się w szerszą praktykę obserwowania kondycji witryny.

Warto na koniec dodać, że kolejność diagnozy powinna wynikać z kodu. Przy 500 pierwsze kroki prowadzą do logów aplikacji. Przy 502 i 504 uwaga kieruje się na serwer nadrzędny oraz konfigurację proxy. Przy 503 liczy się obciążenie i informacja, czy nie trwają prace techniczne. Takie dopasowanie działań do kodu skraca czas przywracania sprawności i ogranicza liczbę zbędnych zmian wprowadzanych po omacku.

Najczęstsze pytania o błędy 5xx

Zebraliśmy odpowiedzi na najczęściej powtarzające się wątpliwości dotyczące błędów HTTP 5xx. Część z nich porządkuje różnice między kodami, część wskazuje, gdzie szukać przyczyny, a pozostałe dotyczą praktycznych skutków, od wpływu na indeksowanie po moment, w którym warto sięgnąć po pomoc administratora hostingu.

Kody błędów 5xx w praktyce: co warto zapamiętać

Błędy HTTP 500, 502, 503 i 504 łączy wspólne pochodzenie po stronie serwera, lecz dzieli je etap, na którym powstają, oraz rodzaj usterki. Kod 500 wskazuje na awarię wewnątrz aplikacji lub jej konfiguracji. Kod 502 zgłasza pośrednik, który otrzymał nieprawidłową odpowiedź z backendu. Kod 503 mówi o tymczasowej niedostępności wynikającej z przeciążenia lub prac technicznych. Kod 504 oznacza, że odpowiedź z serwera nadrzędnego nie nadeszła w wyznaczonym czasie.

Praktyczna wartość tej wiedzy polega na tym, że sam kod od razu zawęża obszar poszukiwań. Zamiast sprawdzać wszystko naraz, warto skierować diagnozę tam, gdzie prawdopodobieństwo znalezienia przyczyny jest największe: do logów aplikacji przy kodzie 500, do serwera nadrzędnego i konfiguracji proxy przy kodach 502 i 504, do obciążenia i harmonogramu prac przy kodzie 503.

Stały monitoring błędów 5xx domyka ten obraz, bo pozwala wychwycić powtarzające się odpowiedzi serwera i zareagować, zanim skala problemu urośnie. Dzięki takiemu podejściu diagnostyka błędów serwera 5xx przestaje być zgadywaniem, a staje się uporządkowanym procesem prowadzącym prosto do źródła usterki.