Błąd 503 Service Unavailable oznacza, że serwer działa, ale chwilowo nie może obsłużyć żądania: jest przeciążony, przekroczył limity zasobów albo jest w trybie prac technicznych. To jedyny błąd z grupy 5xx, który z założenia ma być tymczasowy, i jedyny, który celowo zwracam, gdy wyłączam stronę na czas prac. W tym wpisie pokazuję, jak odróżniam 503 zaplanowany od awaryjnego, jak znajduję przyczynę przeciążenia i jak ustawiam tryb prac technicznych tak, żeby nie stracić widoczności w Google.
Skąd bierze się błąd 503
| Przyczyna | Typowa sytuacja |
|---|---|
| zawieszony tryb prac w WordPressie | aktualizacja przerwała się w połowie, a w katalogu głównym został plik .maintenance |
| limity zasobów na hostingu | hosting współdzielony ogranicza liczbę jednoczesnych procesów, pamięć lub czas procesora i po ich przekroczeniu zwraca 503 |
| limit zapytań na serwerze | reguła limit_req w Nginx domyślnie odrzuca nadmiarowe żądania właśnie kodem 503 |
| nagły wzrost ruchu | kampania, wysyłka newslettera, promocja, wejście z mediów |
| intensywne skanowanie przez boty | roboty narzędzi SEO, scrapery i boty AI pobierają setki stron na minutę |
| zaplanowane prace | celowo włączony tryb prac technicznych podczas migracji lub wdrożenia |
Jak diagnozuję i naprawiam błąd 503
1. Sprawdzam, czy to nie zawieszony tryb prac
Jeśli strona na WordPressie pokazuje komunikat o pracach technicznych po aktualizacji, a nikt ich nie prowadzi, usuwam plik
.maintenance z katalogu głównego. Potem sprawdzam w panelu, czy aktualizacja wtyczki lub motywu dokończyła się poprawnie,
bo przerwana aktualizacja potrafi zostawić niekompletne pliki.
2. Sprawdzam limity zasobów
Na hostingu współdzielonym w panelu szukam statystyk wykorzystania zasobów. Gdy wykresy pokazują dobicie do limitu procesów lub pamięci w czasie, gdy pojawiał się błąd, przyczyna jest jasna. Na własnym serwerze sprawdzam obciążenie, zużycie pamięci i log Nginx:
uptime
free -m
grep "limiting requests" /var/log/nginx/error.log | tail -n 20Wpisy o ograniczaniu żądań oznaczają, że 503 zwraca moja własna reguła limit_req. Wtedy sprawdzam, czy limit nie jest za
ostry dla zwykłych użytkowników, np. przy stronach, które ładują wiele zasobów przez PHP. Dla żądań odrzuconych przez limit ustawiam kod
429 zamiast domyślnego 503, bo lepiej opisuje sytuację.
3. Sprawdzam, kto generuje ruch
Z logu dostępu wyciągam adresy IP i nazwy klientów, które wysyłają najwięcej żądań:
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | headJeśli przeważają boty narzędzi SEO, scrapery albo boty AI, ograniczam je w robots.txt, a te, które go nie respektują,
blokuję w zaporze lub CDN. Zanim zablokuję coś, co przedstawia się jako Googlebot, weryfikuję jego adres, bo podszywanie się pod roboty
wyszukiwarek jest częste. Jak odróżniać ruch ludzi i robotów w logach, pokazuje
analiza logów serwera.
4. Zmniejszam obciążenie zamiast tylko podnosić limity
Przy przeciążeniu przez prawdziwy ruch największą różnicę daje pamięć podręczna całych stron. Strona serwowana z cache lub CDN nie uruchamia PHP ani zapytań do bazy, więc serwer obsługuje wielokrotnie więcej odwiedzin. Ustawienia, od których zaczynam, opisuje konfiguracja CDN. Jeśli mimo pamięci podręcznej strona regularnie dobija do limitów, wracam do pytania, jaki hosting pasuje do projektu.
Jak ustawiam tryb prac technicznych
Na czas migracji lub dużego wdrożenia zwracam 503 z nagłówkiem Retry-After, który informuje roboty, kiedy wrócić. Pliki
statyczne i strona z komunikatem dla użytkowników działają normalnie:
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteCond %{REQUEST_URI} !^/prace-techniczne\.html$
RewriteRule ^ - [R=503,L]
ErrorDocument 503 /prace-techniczne.html
Header always set Retry-After "3600"Pierwszy warunek przepuszcza mój adres IP, żebym mógł sprawdzić stronę przed ponownym otwarciem. Nigdy nie wyłączam strony na czas prac przez zwykłą stronę z kodem 200, bo Google mógłby zaindeksować komunikat o pracach zamiast treści.
Błąd 503 a indeksowanie
Krótka przerwa z kodem 503 jest dla Google bezpieczna: robot ogranicza tempo odwiedzin i wraca później. Problem pojawia się, gdy 503 trwa dłużej niż dzień lub dwa, bo Google zaczyna traktować takie adresy jak trwale niedostępne i może je usunąć z indeksu. Częste, krótkie błędy 503 przy wizytach robota także spowalniają indeksowanie, co na dużych serwisach widać od razu w raporcie statystyk indeksowania. Dlatego stabilność serwera to jeden z pierwszych punktów, które sprawdzam, gdy zajmuję się optymalizacją crawl budgetu dużej strony. Gdy błąd nie wynika z przeciążenia, tylko z awarii aplikacji, serwer zwraca zwykle błąd 500.
Pozostałe błędy HTTP
Każdy kod błędu wskazuje na inną warstwę, więc diagnozę zaczynam od innego miejsca: