Błąd 503 Service Unavailable oznacza, że serwer WWW otrzymał żądanie, ale w tej chwili nie może go obsłużyć. Serwer jest osiągalny, więc DNS i sieć działają, ale aplikacja za nim jest przeciążona, trwa konserwacja albo nie może połączyć się z usługą, od której zależy. Błąd 503 z założenia jest tymczasowy. Jeśli trwa dłużej niż kilka minut, coś wymaga naprawy: zwykle zbyt duży ruch, zbyt mało workerów, zatrzymany proces aplikacji albo niedziałający backend.
W tym poradniku wyjaśniamy, co wywołuje błąd 503, jak znaleźć przyczynę na własnym serwerze, jak usunąć każdą z nich i jak dowiedzieć się o kolejnym błędzie, zanim zauważą go Twoi klienci.
Co naprawdę mówi Ci błąd 503
Kody statusu HTTP z zakresu 5xx oznaczają, że zawiódł serwer, a nie odwiedzający. W tej rodzinie 503 ma konkretne znaczenie: usługa jest chwilowo niedostępna, a klient może spróbować ponownie później. Porównaj go z sąsiadami:
500 Internal Server Error: aplikacja uległa awarii podczas obsługi żądania.
502 Bad Gateway: proxy lub load balancer otrzymał nieprawidłową odpowiedź od serwera, który za nim stoi.
503 Service Unavailable: serwer albo coś przed nim odmawia przetworzenia żądania, bo jest przeciążony, trwa konserwacja albo nie ma sprawnego serwera, do którego można je przekazać.
504 Gateway Timeout: proxy czekało na serwer za sobą i zrezygnowało.
To rozróżnienie jest ważne, bo podpowiada, gdzie szukać. Błąd 503 rzadko jest błędem na jednej stronie. Niemal zawsze chodzi o wydajność lub dostępność całej usługi. Pełny przegląd kodów i tego, które z nich monitor powinien traktować jako awarię, znajdziesz w naszej ściądze z kodami statusu HTTP do monitorowania.
Najczęstsze przyczyny błędu 503
Skoki ruchu i przeciążenie
Każdy serwer może obsłużyć jednocześnie ograniczoną liczbę żądań. Mailing kampanii, wzmianka w mediach społecznościowych albo bot przeszukujący tysiące stron mogą przepchnąć go ponad ten limit. Gdy kolejka się zapełni, serwer WWW lub aplikacja zaczyna odrzucać nowe żądania błędem 503. Strona często po kilku minutach znów działa, a potem pada przy kolejnym szczycie.
Planowana konserwacja
Wiele systemów celowo zwraca 503 podczas konserwacji. WordPress robi tak w trakcie instalowania aktualizacji: zapisuje plik .maintenance i serwuje krótką stronę „Briefly unavailable for scheduled maintenance” ze statusem 503. Jeśli aktualizacja zostanie przerwana, plik może zostać na serwerze, a strona będzie zwracać 503, dopóki ktoś go nie usunie.
Zatrzymany proces aplikacji lub pula aplikacji
Na serwerach Windows z IIS zatrzymana lub niedziałająca pula aplikacji daje klasyczny komunikat „HTTP Error 503. The service is unavailable.” Pula może się zatrzymać z powodu powtarzających się awarii, błędnego hasła tożsamości albo zmiany konfiguracji. W Linuksie odpowiednikiem jest proces Node, Pythona lub Javy, który zakończył działanie, przez co reverse proxy nie ma dokąd przekazywać żądań.
PHP-FPM bez wolnych workerów
Strony w PHP za nginx lub Apache zwykle korzystają z PHP-FPM ze stałą liczbą procesów roboczych, ustawianą przez pm.max_children. Gdy wszystkie workery są zajęte, na przykład dlatego, że każde żądanie czeka na wolne zapytanie do bazy danych lub zewnętrzne API, nowe żądania trafiają do kolejki. W zależności od konfiguracji odwiedzający dostaje 503, 502 lub 504. Log PHP-FPM powie Ci, czy tak się dzieje:
WARNING: [pool www] server reached pm.max_children setting (10), consider raising it
Rate limiting
Limity żądań chronią serwer przed nadużyciami, ale gdy są ustawione zbyt ciasno, zwracają błędy także prawdziwym użytkownikom. nginx domyślnie zwraca 503, gdy żądanie przekroczy strefę limit_req. Tak samo działają zapory aplikacji webowych i niektóre platformy hostingowe. Jeśli jedno biuro, jeden klient API lub jedna usługa monitorująca dzieli adres IP z wieloma użytkownikami, mogą wspólnie dojść do limitu.
Niedziałający upstream lub backend
Load balancery i reverse proxy zwracają 503, gdy nie mają sprawnego serwera, do którego mogą wysłać ruch. Jeśli health checki oznaczą wszystkie backendy jako niesprawne, po nieudanym wdrożeniu albo dlatego, że baza danych nie działa, a endpoint health check to zgłasza, proxy odpowiada 503 na każde żądanie.
Problemy z CDN i serwerem źródłowym
Jeśli Twoja strona działa za CDN, błąd 503 może pochodzić z CDN, a nie z Twojego serwera. CDN może go zwrócić, gdy serwer źródłowy jest przeciążony lub nieosiągalny albo gdy sam CDN ma problemy w jednym regionie. Nagłówki odpowiedzi zwykle mówią, kto odpowiedział: szukaj własnego nagłówka server lub identyfikatora żądania CDN i porównaj wynik z żądaniem wysłanym bezpośrednio do serwera źródłowego.
Jak znaleźć przyczynę
Zacznij od samej odpowiedzi. Wyślij żądanie pod niedziałający URL i przyjrzyj się nagłówkom:
curl -sS -o /dev/null -D – https://northwind.shop/checkout
Nagłówek Server i nagłówki specyficzne dla CDN pokazują, która warstwa odpowiedziała. Nagłówek Retry-After sugeruje celową konserwację. Potem przechodź coraz głębiej:
Sprawdź, czy błąd występuje wszędzie. Czy strona główna też nie działa, czy tylko jedna ścieżka? Pojedyncza ścieżka wskazuje na jedną trasę aplikacji lub pulę workerów; awaria wszystkiego wskazuje na serwer lub proxy.
Przeczytaj log błędów serwera WWW. nginx i Apache zapisują błędy upstreamu, odrzucenia przez rate limiting i błędy połączeń ze znacznikami czasu.
Przeczytaj log aplikacji lub PHP-FPM. Szukaj ostrzeżeń max_children, awarii, procesów zabitych z braku pamięci i śladów wolnych żądań.
Sprawdź zasoby serwera. CPU, obciążenie, pamięć i swap w chwili błędu. Serwer, który korzysta ze swapu, odpowiada wolno, a wolne odpowiedzi zapełniają pule workerów.
Sprawdź zależności. Czy baza danych odpowiada? Czy działa cache? Czy zewnętrzne API, które wywołujesz synchronicznie, odpowiada wolno?
Sprawdź niedawne zmiany. Wdrożenie, aktualizacja wtyczki, zmiana konfiguracji albo nowy limit żądań w okolicach momentu, w którym zaczęły się błędy, to najbardziej prawdopodobna przyczyna.
Jak naprawić błąd 503
Rozwiązanie zależy od przyczyny. Oto najczęstsze z nich w kolejności, w jakiej spotyka je większość zespołów.
Zawieszony tryb konserwacji: usuń plik .maintenance z katalogu głównego WordPressa albo wyłącz flagę konserwacji w swoim frameworku, a potem dokończ lub powtórz aktualizację.
Przeciążenie przez prawdziwy ruch: cache’uj, co się da, na brzegu sieci i w aplikacji, aby większość żądań w ogóle nie docierała do PHP ani bazy danych. Potem dodaj zasoby: więcej workerów, jeśli pozwala na to pamięć, większy serwer albo więcej serwerów za load balancerem.
Przeciążenie przez boty: zidentyfikuj w logu dostępu user agenty i zakresy IP, a potem ogranicz lub zablokuj je w CDN albo na zaporze, zanim dotrą do aplikacji.
Workery PHP-FPM: podnoś pm.max_children tylko na tyle, na ile pozwala pamięć. Oblicz średnie zużycie pamięci jednego workera i podziel przez nie pamięć, którą możesz przeznaczyć. Jeśli workery są zajęte przez wolne zapytania, najpierw popraw zapytania, bo inaczej tylko przeniesiesz wąskie gardło.
Zatrzymana pula aplikacji lub proces: zrestartuj go, a potem ustal, dlaczego się zatrzymał. Sprawdź dziennik zdarzeń lub dziennik systemowy pod kątem awarii i skonfiguruj menedżera procesów, który automatycznie restartuje usługę.
Zbyt restrykcyjne limity żądań: podnieś limit lub rozmiar burst, wyłącz z limitu znane adresy IP, takie jak Twoje biuro czy usługa monitorująca, i zwracaj ograniczonym klientom 429 zamiast 503, aby przyczyna była oczywista w logach.
Niesprawne backendy: sprawdź, o co pyta health check load balancera i dlaczego kończy się niepowodzeniem. Najpierw wycofaj nieudane wdrożenie, a dopiero potem szukaj przyczyny.
Oto typowa zmiana puli PHP-FPM na serwerze, który ma miejsce na więcej workerów. Liczby są przykładem, a nie rekomendacją dla Twojego serwera:
; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 24
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log
Najcenniejszy jest tu slow log: pokazuje, które skrypty najdłużej zajmują workery, a więc gdzie szukać dalej.
Używaj Retry-After podczas planowanej konserwacji
Gdy celowo wyłączasz stronę, zwracaj 503 z nagłówkiem Retry-After. Informuje on przeglądarki, klientów API i roboty wyszukiwarek, że przerwa jest tymczasowa i kiedy wrócić. Wartością jest liczba sekund albo data HTTP:
HTTP/1.1 503 Service Unavailable
Retry-After: 1800
Content-Type: text/html; charset=utf-8
W nginx prosty przełącznik konserwacji może wyglądać tak:
if (-f /var/www/maintenance.flag) {
return 503;
}
error_page 503 @maintenance;
location @maintenance {
add_header Retry-After 1800 always;
root /var/www/maintenance;
rewrite ^ /index.html break;
}
Dwie zasady sprawiają, że planowana konserwacja przebiega bezboleśnie. Zwracaj 503, nigdy 200 ze stroną „zaraz wracamy”, bo status 200 mówi robotom i monitorom, że strona konserwacji to Twoja prawdziwa treść. I nie przeciągaj jej: 503 przez godzinę to nic złego, 503 przez kilka dni grozi wypadnięciem stron z wyników wyszukiwania.
Uprzedź też klientów. Informacja na Twojej stronie statusu odpowiada na pytanie „czy to tylko u mnie?”, zanim ktokolwiek je zada.
Jak monitorowanie wychwytuje błędy 503
Błąd 503 często pojawia się i znika. Strona pada na dwie minuty w szczycie kampanii, wraca i znów pada godzinę później. Nikt w zespole tego nie widzi, bo zanim ktoś otworzy stronę, ta działa. Klienci jednak to widzieli.
Monitor HTTP odpytuje Twoje strony według harmonogramu i zapisuje kod statusu oraz czas odpowiedzi każdego sprawdzenia. Błąd 503 to nieudane sprawdzenie. Dobre monitorowanie robi wtedy trzy rzeczy:
Potwierdza awarię. Drugie sprawdzenie wyklucza jednorazowe zakłócenie, a sprawdzenie z innej lokalizacji wyklucza też problem na jednej ścieżce sieciowej. Uptimecheck sprawdza ze Sztokholmu, Londynu i Nowego Jorku i potwierdza każdą awarię z drugiej lokalizacji, zanim otworzy incydent.
Powiadamia właściwe osoby. Alert zawiera kod statusu, URL i czas rozpoczęcia, więc osoba, która go odbierze, wie, że to błąd 503, a nie błąd DNS. W Uptimecheck incydent zawiera też nieudaną odpowiedź i zrzut ekranu, więc widzisz stronę błędu, którą zobaczyli odwiedzający, albo traceroute, gdy serwer w ogóle nie odpowiedział. Kanały znajdziesz w sekcji alerty i powiadomienia.
Zapisuje wzorzec. Historia incydentów pokazuje, czy błędy 503 skupiają się wokół szczytów ruchu, wdrożeń czy nocnych zadań, co podpowiada, którą poprawkę wypróbować najpierw.
Monitoruj nie tylko stronę główną. Często jest ona cache’owana i działa dalej, gdy koszyk, logowanie lub API zawodzą. Dodaj monitory dostępności dla stron, które zarabiają, i obserwuj trend czasu odpowiedzi: strona, która codziennie o tej samej godzinie zwalnia, to często błąd 503, który tylko czeka, by się wydarzyć. Nasz poradnik o tym, jaki czas odpowiedzi strony jest dobry, wyjaśnia, na co zwracać uwagę.
Metryki serwera domykają całość. Gdy przychodzi alert o błędzie 503, pierwsze pytanie brzmi: czy serwerowi zabrakło CPU, pamięci lub dysku? Dzięki monitorowaniu serwera obok sprawdzeń dostępności widzisz przyczynę i objaw obok siebie.
Lista kontrolna dla błędu 503
Sprawdź nagłówki odpowiedzi, aby ustalić, która warstwa zwróciła 503.
Przejrzyj logi serwera WWW, aplikacji i PHP-FPM z tego samego momentu.
Sprawdź CPU, pamięć, swap i dysk na serwerze.
Poszukaj wdrożeń, aktualizacji i zmian konfiguracji tuż przed pojawieniem się błędów.
Usuń przyczynę: cache, więcej workerów, zrestartowany proces, łagodniejszy limit żądań albo sprawny backend.
Podczas planowanej konserwacji używaj 503 z Retry-After, nigdy 200.
Monitoruj kluczowe strony co minutę i potwierdzaj każdą awarię drugim sprawdzeniem przed wysłaniem alertu.
Podsumowanie
Błąd 503 oznacza, że serwer jest na miejscu, ale w tej chwili nie może Cię obsłużyć. To problem z wydajnością lub dostępnością, a nie zepsuta strona, a logi z tego samego momentu zwykle wskazują przyczynę wprost. Usuwaj przyczynę, a nie objaw, używaj Retry-After, gdy przerwa jest planowana, i pozwól, by monitorowanie informowało Cię o krótkich błędach 503, których inaczej nigdy byś nie zobaczył.
Uptimecheck monitoruje strony internetowe, API i serwery w jednym koncie i powiadamia Cię, gdy strona zaczyna zwracać 503. Rozpocznij 14-dniowy bezpłatny okres próbny – bez karty kredytowej.