Błąd 503: przeciążenie, konserwacja czy limit hostingu?

Co oznacza ten błąd

503 to serwer WWW mówiący „jestem, ale w tej chwili nie mogę Cię obsłużyć”. W odróżnieniu od błędu 502 niekoniecznie coś za nim jest zepsute. Serwer wysyła 503 celowo w trzech sytuacjach: jest w trybie konserwacji, osiągnął limit, którego ma przestrzegać (połączenia, procesy robocze, przepustowość, limit zapytań), albo jest tak przeciążony, że odrzuca żądania, żeby przetrwać. Odpowiedź 503 może nieść nagłówek Retry-After, który mówi klientom, kiedy wrócić; wyszukiwarki traktują krótki 503 jako stan tymczasowy i nie usuwają strony z indeksu.

Częste przyczyny

1. Włączony tryb konserwacji. WordPress zapisuje plik .maintenance podczas aktualizacji i odpowiada 503, dopóki aktualizacja się nie skończy. Jeśli aktualizacja zostanie przerwana, plik zostaje, a z nim błąd. Laravel, Magento, Drupal i większość frameworków mają odpowiednik.
2. Przeciążenie. Więcej żądań, niż skonfigurowane procesy robocze mogą obsłużyć. Osiągnięte MaxRequestWorkers w Apache, wyczerpane pm.max_children w PHP-FPM albo baza danych tak wolna, że każdy proces czeka.
3. Limit hostingu. Hostingi współdzielone ograniczają sekundy CPU, równoległe procesy albo „entry processes” na konto. Po przekroczeniu brama dostawcy odpowiada 503 tylko dla Twojej strony.
4. Backend wyłączony z rotacji. Za load balancerem albo CDN błąd 503 oznacza, że wszystkie backendy nie przeszły health checku. Cloudflare pokazuje własną stronę 503, gdy serwer źródłowy jest przeciążony albo ograniczony limitem.
5. Boty i scrapery. Crawler pobierający tysiące stron albo atak brute force na wp-login.php lub xmlrpc.php wyczerpuje procesy, a prawdziwi odwiedzający dostają 503.
6. Pełny dysk albo wyczerpana pamięć. Usługa działa, ale nie może zapisać sesji, plików cache ani logów, a część aplikacji odpowiada wtedy 503.

Jeśli odwiedzasz cudzą stronę

Odczekaj minutę i odśwież; 503 jest zwykle krótki. Jeśli strona tkwi na 503 godzinami, właściciel ma zablokowany tryb konserwacji albo problem z wydajnością i tylko on może to naprawić.

Jeśli to Twoja strona: najpierw sprawdź

Uruchom narzędzie Is it down?, żeby potwierdzić 503 z zewnątrz i zobaczyć, czy wysłał go CDN, czy Twój serwer. Potem zdecyduj: czy w ostatnich minutach ruszyła aktualizacja, Twoja albo Twojego CMS-a? Jeśli tak, to tryb konserwacji. Jeśli nie, to wydajność.

Na własnym serwerze:

# czy serwer WWW w ogóle działa?
systemctl status nginx
systemctl status apache2

# obciążenie, pamięć, dysk: trzy liczby za większością błędów 503
uptime
free -m
df -h

# kto w tej chwili wali w stronę?
sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

Średnie obciążenie znacznie powyżej liczby rdzeni CPU, mniej niż 100 MB wolnej pamięci albo jeden adres IP z tysiącami żądań w ostatnich minutach: każde z nich tłumaczy 503.

Naprawy na własnym serwerze

1. Zakończ zablokowany tryb konserwacji

WordPress: usuń plik .maintenance w katalogu głównym strony, potem otwórz stronę. Jeśli aktualizacja, która go utworzyła, została przerwana, wtyczka albo rdzeń mogą być zainstalowane w połowie; uruchom aktualizację ponownie z kokpitu albo przez WP-CLI:

rm /var/www/przyklad.pl/.maintenance
wp core verify-checksums
wp plugin update --all

Laravel: php artisan up. Magento: bin/magento maintenance:disable. Drupal: ustaw $settings['maintenance_mode'] na false albo użyj drush state:set system.maintenance_mode 0.

2. Zatrzymaj zalew

Zablokuj winny adres IP albo sieć, potem dodaj limit zapytań, żeby następny nie mógł zrobić tego samego.

# blokada jednego adresu (Debian/Ubuntu z ufw)
sudo ufw deny from 203.0.113.45

# albo z nftables
sudo nft add rule inet filter input ip saddr 203.0.113.45 drop

Limit zapytań nginx dla stron logowania (w bloku http, potem w bloku server):

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /wp-login.php {
    limit_req zone=login burst=5 nodelay;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Apache: mod_evasive albo mod_qos robią to samo; fail2ban z jailem apache-badbots (i własnym jailem dla wp-login.php) automatycznie blokuje adresy, które wciąż wracają.

3. Daj serwerowi wydajność

Jeśli obciążenie to prawdziwy ruch, nie nadużycie, podnieś limity procesów w granicach pamięci. Apache (mpm_event): MaxRequestWorkers. PHP-FPM: pm.max_children. Najpierw sprawdź pamięć na proces: ps -ylC php-fpm8.3 --sort:rss. Potem test i przeładowanie:

sudo apachectl configtest && sudo systemctl reload apache2
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm

Włącz cache stron (WordPress: wtyczka cache albo FastCGI cache w nginx), żeby skok ruchu nie uruchamiał PHP przy każdym żądaniu. Strona z cache kosztuje ułamek milisekundy; strona WordPress bez cache kosztuje setki.

4. Zwolnij dysk

sudo du -xh --max-depth=1 /var | sort -h | tail
sudo journalctl --vacuum-size=200M
sudo apt clean

Stare logi, kopie zapasowe trzymane na tym samym dysku i rozpędzony log debugowania to zwykli podejrzani.

5. Za load balancerem

Wszystkie backendy oblewające health check naraz oznaczają zwykle, że zepsuty jest sam adres sprawdzania (usunięta strona health, przekierowanie na HTTPS, za którym checker nie podąża), a nie każdy backend. Pobierz adres health ręcznie z balancera.

Gdy to problem dostawcy hostingu

Na hostingu współdzielonym nie podniesiesz limitów. Zapytaj dostawcę, jaki limit został przekroczony i czy to Twój ruch, czy inne konto na tym samym serwerze:

Dzień dobry, moja strona przyklad.pl odpowiada „503 Service Unavailable” od około 09:10 UTC. Nie uruchamiano aktualizacji i strona nie jest w trybie konserwacji. Czy mogliby Państwo powiedzieć, czy moje konto przekroczyło limit zasobów (CPU, procesy, pamięć), czy serwer jest przeciążony, i jakie są liczby? Jeśli to moje konto, to który limit i od kiedy?

Jeśli odpowiedź „Twoje konto przekroczyło limity” powtarza się regularnie, albo porządnie włącz cache, albo przejdź na plan lub serwer o większej wydajności.

Jak zapobiec następnemu

Błąd 503 zapowiada się: obciążenie rośnie, pamięć się kończy, jeden adres IP zaczyna zalewać. Sprawdzanie stron wyłapuje 503 w ciągu minuty; agent serwerowy pokazuje obciążenie, pamięć i dysk, zanim do tego dojdzie. Awaria? Naprawiamy: na własnym serwerze Quick Fix zwalnia miejsce na dysku i restartuje zablokowaną usługę w stałej cenie, a Deep Fix konfiguruje limity zapytań i cache, żeby następnym razem serwer wytrzymał. Zobacz naprawa serwera.