Błąd 503 Service Unavailable oznacza, że serwer w danym momencie nie jest gotowy obsłużyć żądania. Sam kod nie mówi jeszcze, czy przyczyną jest przeciążenie, przerwa techniczna, limit zasobów konta, problem z PHP albo niedostępny backend. Najpierw zapisz godzinę błędu i sprawdź, czy 503 dotyczy całej strony, jednej funkcji czy konkretnego adresu.
HTTP 503 jest kodem przeznaczonym dla sytuacji tymczasowych, takich jak przeciążenie lub prace serwisowe w typowych zastosowaniach tego statusu. Na hostingu współdzielonym 503 może również pojawić się przy niektórych limitach CloudLinux, ale nie wolno rozpoznawać konkretnego limitu na podstawie samego numeru błędu.
Co oznacza 503 Service Unavailable?
Kod 503 należy do odpowiedzi 5xx, czyli błędów po stronie serwera. Informuje, że usługa jest chwilowo niedostępna, a nie że żądany adres zniknął. Przy planowanej przerwie serwer może dodatkowo zwrócić nagłówek Retry-After określający, kiedy warto ponowić próbę. Nagłówek Retry-After jest przewidziany między innymi dla odpowiedzi 503.
Dla właściciela strony najważniejsze jest jednak ustalenie, która warstwa zwróciła 503. Taki kod może pochodzić z serwera WWW, proxy, aplikacji PHP, mechanizmu maintenance albo ograniczenia zasobów. Ten sam komunikat w przeglądarce może więc wymagać zupełnie innej naprawy.
Co sprawdzić od razu po pojawieniu się 503?
Zapisz dokładną godzinę, URL i czynność wykonywaną tuż przed błędem. Jeżeli możesz, sprawdź też inny adres strony, panel WordPressa oraz prosty statyczny plik. Nie chodzi o długi test, tylko o ustalenie zakresu problemu.
| Obserwacja | Co sugeruje do dalszego sprawdzenia |
|---|---|
| 503 na całej stronie, także na prostym pliku statycznym | Warstwa serwera WWW/proxy, tryb maintenance albo problem infrastruktury przed PHP |
| 503 tylko przy stronach PHP, a plik statyczny działa | PHP, backend aplikacji, limity procesów lub pamięci |
| 503 tylko przy jednej czynności | Konkretny skrypt, zapytanie, integracja albo operacja administracyjna |
| 503 pojawia się w tych samych godzinach co wzrost wykorzystania zasobów | Porównaj PMEM, NPROC, CPU, EP i logi z tego samego czasu |
| 503 pojawił się po aktualizacji lub zmianie konfiguracji | Sprawdź tę zmianę i log błędów przed zakupem większego pakietu |
Jeżeli błąd znika po kilku sekundach, nadal warto zapisać czas. Krótkotrwały problem jest trudny do odtworzenia później, a operator może mieć w historii serwera dane z konkretnej minuty.
Czy 503 może oznaczać przekroczenie RAM-u lub liczby procesów?
Tak — w CloudLinux przekroczenie niektórych limitów może prowadzić do 503. Po przekroczeniu limitu pamięci fizycznej PMEM system może zakończyć część procesów konta, co może skutkować odpowiedziami 500 lub 503. Podobny efekt może wystąpić po osiągnięciu NPROC, czyli maksymalnej liczby procesów. Oba przypadki są rozróżnione w opisie limitów CloudLinux.
To nie znaczy, że każdy 503 na hostingu CloudLinux oznacza brak RAM-u albo zbyt mały NPROC. Potwierdzenia szukaj w historii zasobów z tej samej godziny. Jeżeli panel pokazuje PMEM lub NPROC dochodzące do limitu i odpowiadające im faults, masz technicznie uzasadniony kierunek diagnozy. Nie dowodzi to jeszcze, że każdy 503 w tym okresie został wygenerowany właśnie przez ten limit.
CloudLinux raportuje osobno maksymalne wykorzystanie oraz liczniki między innymi PMemF i NprocF. Narzędzia CloudLinux rozdzielają pamięć, liczbę procesów, EP, CPU, I/O i IOPS. Dzięki temu nie trzeba zgadywać, że każda niedostępność jest „brakiem RAM-u”.
A CPU, I/O i EP?
CPU i I/O w CloudLinux są zwykle dławione po osiągnięciu przydziału, więc częstym skutkiem jest wolniejsze wykonywanie pracy. CPU lub I/O mogą więc pogorszyć warunki, w których później pojawia się 503, na przykład przez wydłużenie obsługi żądań albo timeout w innej warstwie. Sam wysoki odczyt CPU lub I/O nie wskazuje jednak mechanizmu, który zwrócił kod 503.
EP, czyli Entry Processes, jest natomiast bezpośrednio związane ze współbieżnością wejść aplikacji do środowiska konta. W konfiguracji CloudLinux z Apache przekroczenie EP jest typowo kojarzone z 508 Resource Limit Reached, a nie z 503. Jeżeli widzisz właśnie 508, przejdź do poradnika o błędzie 508, zamiast mieszać oba kody.
Szersze znaczenie CPU, PMEM, NPROC, I/O, IOPS i EP opisuje poradnik o limitach zasobów hostingu.
503 po aktualizacji WordPressa — od czego zacząć?
Jeżeli 503 pojawił się bezpośrednio po aktualizacji wtyczki, motywu, WordPressa albo zmianie wersji PHP, najpierw sprawdź log błędów z tego momentu. Sprawdź także, czy nie pozostał mechanizm maintenance i czy log PHP nie pokazuje błędu fatalnego. Taka zbieżność nie dowodzi jeszcze winy ostatniej zmiany, ale daje bardziej konkretny trop niż natychmiastowe zwiększanie pakietu.
Sprawdź też zakres problemu. Jeśli plik statyczny działa, ale wszystkie żądania PHP kończą się 503, skup się na warstwie PHP i aplikacji. Jeśli 503 dotyczy tylko jednej funkcji, np. importu, wyszukiwania albo zapisu dużego formularza, potrzebne są logi tej operacji i dane o zasobach z tego samego czasu.
Nie wyłączaj seryjnie wszystkich wtyczek na działającej stronie bez kopii i planu powrotu. Przy stronie produkcyjnej lepiej najpierw zebrać logi, wykonać kontrolowaną zmianę lub odtworzyć problem w bezpiecznej kopii, jeśli taka istnieje.
503 podczas dużego ruchu — czy hosting jest za mały?
Powtarzalny 503 przy zwykłym, potrzebnym ruchu może wskazywać, że obecna konfiguracja nie zapewnia wystarczającego zapasu, ale nadal trzeba ustalić ograniczenie. Inaczej ocenia się limit PMEM, inaczej NPROC, a jeszcze inaczej niedostępny backend albo problem aplikacyjny.
Hipotetycznie jednorazowy 503 podczas masowego importu nie daje takiej samej podstawy do stałego zwiększenia abonamentu jak seria błędów występujących codziennie w godzinach normalnego ruchu. Nie ma uniwersalnego progu liczby 503, po którym zmiana hostingu staje się obowiązkowa.
Jeżeli operator proponuje wyższy plan, poproś o wskazanie, który parametr był osiągnięty w czasie błędu i jak zmieni się jego limit po przejściu na nowy pakiet. To pozwala odróżnić technicznie uzasadnione zwiększenie zasobów od ogólnego zalecenia „proszę kupić większy hosting”.
503 a przerwa techniczna i tryb maintenance
503 może być całkowicie zamierzony. Przy krótkiej przerwie serwisowej jest właściwym sposobem poinformowania klienta, że usługa jest czasowo niedostępna. Specyfikacyjne objaśnienie 503 obejmuje właśnie stan tymczasowej niedostępności, np. z powodu maintenance.
Jeżeli błąd pojawił się podczas aktualizacji albo wdrożenia, sprawdź, czy aplikacja nie została pozostawiona w trybie maintenance. W WordPressie warto zweryfikować, czy proces aktualizacji rzeczywiście się zakończył oraz czy nie pozostał mechanizm blokujący normalne żądania. Nie zakładaj jednak, że każda plansza „maintenance” pochodzi z samego WordPressa — hosting lub proxy może mieć własny mechanizm.
Gdy operator planował prace techniczne, sprawdź komunikat o awarii lub maintenance i podany czas zakończenia. W takim przypadku zwiększanie zasobów konta nie ma związku z problemem.
503 z reverse proxy lub backendu — co to znaczy dla właściciela strony?
Warstwa proxy może przekazać 503 zwrócone przez backend albo sama zwrócić błąd, gdy nie może prawidłowo obsłużyć połączenia z aplikacją. nginx rozpoznaje odpowiedzi HTTP 503 z upstream jako osobny przypadek błędu. Dla właściciela strony najważniejsze są logi proxy i aplikacji z tej samej minuty; jeśli nie masz do nich dostępu, operator powinien wskazać, czy 503 pochodził z jego warstwy, PHP/backendu czy samej aplikacji.
Jak napisać do operatora w sprawie 503?
Podaj dane pozwalające sprawdzić konkretny przypadek:
Około [data i godzina] pod adresem [URL] pojawił się błąd 503 Service Unavailable podczas [zwykłego wejścia / konkretnej czynności]. Proszę sprawdzić, która warstwa zwróciła 503 oraz czy w tym czasie konto osiągnęło PMEM, NPROC, CPU, EP, I/O, IOPS lub inny limit. Jeżeli tak, proszę podać limit, maksymalne użycie i zarejestrowane zdarzenia jego osiągnięcia. Jeśli zalecany jest wyższy pakiet, proszę wskazać, który konkretny parametr zwiększy się i z jakiej wartości do jakiej. Jeśli 503 pochodził z PHP, proxy, backendu lub maintenance, proszę wskazać tę warstwę.
Taka wiadomość nie zakłada z góry, że hosting ma za mało zasobów. Zmusza za to do rozdzielenia czterech różnych scenariuszy: limitu konta, problemu aplikacji, problemu infrastruktury i planowanej niedostępności.
Kiedy większy pakiet lub zmiana hostingu mają sens?
Najmocniejszą podstawą jest powtarzalny 503 podczas normalnej pracy strony oraz dane wskazujące konkretny zasób, którego limit jest wtedy osiągany. W takim przypadku można porównać pakiety właśnie według tego parametru, a nie wyłącznie według ceny czy pojemności.
Jeżeli problem wynika z maintenance operatora, błędu po aktualizacji albo niedostępnego backendu, większy limit PMEM czy NPROC może nie mieć żadnego związku z rozwiązaniem. Jeżeli natomiast limit jest osiągany wyłącznie podczas sporadycznej operacji administracyjnej, porównaj koszt stałego zwiększenia pakietu z możliwością wykonania tej operacji inaczej.
Pakiety możesz zestawić w porównywarce hostingu. Jeżeli rozważasz przeprowadzkę, policz koszt w kalkulatorze opłacalności zmiany hostingu i przygotuj etapy w planerze migracji.
503 jest informacją o niedostępnej usłudze, a nie nazwą przyczyny. Najpierw ustal godzinę, zakres problemu i warstwę, która zwróciła błąd. Dopiero potem zestaw logi z PMEM, NPROC i pozostałymi zasobami. Taki wynik daje technicznie uzasadnioną podstawę do naprawy aplikacji, zgłoszenia problemu operatorowi albo zmiany pakietu.