Błąd HTTP 503 Service Unavailable: przyczyny i sposoby naprawy

Czym jest błąd HTTP 503?

503 Service Unavailable oznacza, że serwer lub coś przed nim nie może teraz obsłużyć Twojego żądania: jest przeciążony, w trakcie prac konserwacyjnych, ogranicza liczbę żądań albo nie ma sprawnego backendu, któremu mógłby je przekazać. RFC 9110 definiuje go jako stan tymczasowy, który prawdopodobnie ustąpi po pewnym czasie.

Serwer może dodać nagłówek Retry-After, który podaje, jak długo czekać. W przeciwieństwie do 500, który oznacza, że coś się zepsuło, 503 mówi „nie teraz”, dlatego strony używają go przy planowanej konserwacji.

Często odpowiada nie sam serwer WWW, lecz warstwa przed nim: load balancer, taki jak HAProxy, cache, taki jak Varnish, CDN, taki jak Cloudflare, albo ingress Kubernetes. Dokładne brzmienie komunikatu pokazuje, która z nich (patrz niżej).

Jak wygląda błąd 503

Komunikat pokazuje, która warstwa odpowiedziała. Oto najczęstsze z nich, razem z oprogramowaniem, które je generuje:

Niezależnie od brzmienia komunikatu sens jest ten sam: tego żądania nie da się teraz obsłużyć, a warstwa wskazana w tabeli to miejsce, w którym trzeba szukać.

Najczęstsze przyczyny błędu HTTP 503

Najczęstsze powody, dla których serwer lub warstwa przed nim zwraca 503:

• Przeciążenie — wyczerpane limity CPU, pamięci lub połączeń podczas skoku ruchu, głośnego wpisu albo agresywnego crawlera
• Planowana konserwacja — strona jest celowo wyłączona na czas aktualizacji lub migracji; zrobione dobrze, z nagłówkiem Retry-After
• Brak sprawnego backendu — load balancer, proxy lub ingress nie ma działającego serwera, do którego mógłby wysłać żądanie (aplikacja padła, nieudane health checki, brak gotowych podów)
• Limity żądań i połączeń — limit_req i limit_conn w nginx domyślnie odpowiadają 503, więc zajęty klient lub crawler może go wywołać
• Zatrzymana lub zawieszona aplikacja — PHP-FPM, Node.js lub Python nie działa za działającym serwerem WWW; w IIS zatrzymana pula aplikacji
• Limity zasobów hostingu — hosting współdzielony ogranicza CPU, pamięć i liczbę procesów na konto
• Wtyczka, motyw lub aktualizacja — w WordPressie i innych CMS zła aktualizacja może zawiesić aplikację albo zostawić stronę w trybie konserwacji
• Atak — DDoS lub fala botów wyczerpuje te same zasoby co skok ruchu

Rozwiązanie dla odwiedzających: co możesz zrobić

Jeśli odwiedzasz cudzą stronę, problem leży po jej stronie. Co możesz zrobić:

• Poczekaj i spróbuj ponownie — 503 ma być tymczasowy; odczekaj minutę i odśwież raz. Jeśli strona pokazuje czas Retry-After lub komunikat o konserwacji, odczekaj tyle
• Sprawdź, czy strona nie działa dla wszystkich — Sprawdzanie, czy strona działa od DNS Robot testuje stronę spoza Twojej sieci
• Zajrzyj na stronę statusu lub profile społecznościowe serwisu — planowaną konserwację i awarie zwykle się ogłasza
• Spróbuj innej sieci — jeśli strona ładuje się przez dane komórkowe, to albo VPN lub proxy w Twojej zwykłej sieci odpowiada tym 503, albo strona ogranicza liczbę żądań z Twojego adresu IP

Rozwiązanie 1: ustal, która warstwa wysłała 503

Zanim cokolwiek zrestartujesz, spójrz na komunikat i nagłówki odpowiedzi: pokazują, która warstwa odpowiedziała. Sprawdź to z zewnątrz narzędziem Checker nagłówków HTTP od DNS Robot albo poleceniem curl -sI, i przyjrzyj się nagłówkowi server oraz treści odpowiedzi (patrz tabela wyżej).

Następnie zrestartuj warstwę, która zawodzi, a nie tylko serwer WWW:

# Restart Nginx
sudo systemctl restart nginx

# Restart Apache
sudo systemctl restart apache2      # Debian/Ubuntu
sudo systemctl restart httpd         # CentOS/RHEL

# Restart PHP-FPM
sudo systemctl restart php8.2-fpm    # Adjust version as needed

# Restart Node.js (PM2)
pm2 restart all

# Restart entire server (last resort)
sudo reboot

Jeśli 503 wraca w ciągu kilku minut od restartu, przyczyna nadal istnieje: przejdź do zasobów i logów.

Rozwiązanie 2: sprawdź zasoby serwera (CPU, RAM, dysk)

Jeśli serwer jest przeciążony, restart przyniesie tylko tymczasową ulgę. Sprawdź, co zużywa zasoby.

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space
df -h

# Check memory in detail
free -m

# Check active connections
ss -s

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

Jeśli CPU lub RAM przekracza 90%, musisz zoptymalizować aplikację, zabić niekontrolowane procesy lub ulepszyć serwer. Jeśli dysk jest pełny, wyczyść pliki logów, stare kopie zapasowe lub pliki tymczasowe.

Rozwiązanie 3: sprawdź logi błędów

Logi mówią dokładnie, dlaczego wystąpił 503. Przeczytaj ostatnie linie poleceniami poniżej, a potem poszukaj w nich tych wpisów:

# Nginx error log
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log      # Debian/Ubuntu
tail -50 /var/log/httpd/error_log         # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.2-fpm.log

# WordPress debug log (if WP_DEBUG_LOG is enabled)
tail -50 /var/www/html/wp-content/debug.log

# System log
tail -50 /var/log/syslog

„limiting requests” lub „limiting connections” (nginx) — limit_req lub limit_conn odrzuciło żądanie; odpowiada 503, chyba że ustawisz limit_req_status lub limit_conn_status.

„max_children” (PHP-FPM, np. „server reached pm.max_children setting”) — wszystkie procesy PHP są zajęte: Apache odpowiada 503, a nginx 502 lub 504.

„AH01114” / „failed to make connection to backend” (Apache mod_proxy) — Apache nie mógł połączyć się z backendem i odpowiedział 503.

„Too many connections” (MySQL) — wyczerpany limit połączeń z bazą danych.

nginxowe „no live upstreams” i „upstream timed out” należą do 502 Bad Gateway i 504 Gateway Timeout, a nie do 503.

Rozwiązanie 4: wyłącz wtyczki i motywy (WordPress / CMS)

W WordPressie i innych CMS ciężka wtyczka może wyczerpać procesy PHP lub limity zasobów hostingu, co daje 503 (wtyczka, która się wywala, daje zamiast tego 500). Jeśli 503 zaczął się po aktualizacji lub instalacji wtyczki, zacznij od niej.

Jeśli nie możesz wejść do panelu administracyjnego WordPressa, wyłącz wtyczki przez system plików lub bazę danych.

# Disable all plugins by renaming the plugins folder
cd /var/www/html/wp-content
mv plugins plugins_disabled

# If the site loads, rename it back and re-enable plugins one by one
mv plugins_disabled plugins

# To disable a single plugin
mv plugins/problem-plugin plugins/problem-plugin.disabled

Po znalezieniu wadliwej wtyczki zaktualizuj ją, zastąp alternatywą albo skontaktuj się z jej autorem. Sprawdź też, czy Twoja wersja PHP jest zgodna: niektóre wtyczki przestają działać po aktualizacji PHP na serwerze.

Utknąłeś na „Briefly unavailable for scheduled maintenance”? WordPress tworzy plik .maintenance w katalogu głównym witryny podczas aktualizacji i ignoruje go, gdy ma ponad 10 minut. Usuń go, żeby wrócić szybciej; jeśli komunikat zostaje, poszukaj pliku wp-content/maintenance.php albo zapisanej w cache kopii strony.

Rozwiązanie 5: zwiększ limity PHP i serwera

Jeśli na serwerze kończą się procesy robocze PHP lub osiąga on limity pamięci, musisz zwiększyć limity w konfiguracji.

; PHP-FPM pool (e.g. /etc/php/8.2/fpm/pool.d/www.conf); the default ships with pm.max_children = 5
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

; php.ini (defaults: memory_limit = 128M, max_execution_time = 30)
memory_limit = 256M
max_execution_time = 300

Po zmianie zrestartuj PHP-FPM (sudo systemctl restart php8.2-fpm, z Twoją wersją), aby nowe limity zostały wczytane.

Rozwiązanie 6: sprawdź swój CDN lub load balancer

Jeśli używasz Cloudflare, innego CDN lub load balancera, 503 może pochodzić od niego, a nie z Twojego serwera.

Reguła Cloudflare (jego poradnik o błędzie 503):

• Strona zawiera „cloudflare” lub „cloudflare-nginx” — wygenerował ją Cloudflare: sprawdź, czy Worker nie przekracza limitów CPU lub pamięci, a potem skontaktuj się z pomocą Cloudflare, podając wynik /cdn-cgi/trace
• Brak znacznika Cloudflare — 503 zwrócił Twój serwer origin, a Cloudflare tylko je przekazał: sprawdź logi origin i zapytaj hosting, czy nie ogranicza adresów IP Cloudflare

W HAProxy, chmurowym load balancerze lub ingressie Kubernetes sprawdź backendy: 503 oznacza tam zwykle, że żaden backend nie mógł przyjąć żądania (w AWS Application Load Balancer — że grupa docelowa nie ma zarejestrowanych celów). „Sprawdź rekordy DNS” od DNS Robot potwierdzi, że domena nadal wskazuje tam, gdzie oczekujesz.

Rozwiązanie 7: sprawdź, czy nie ma ataku DDoS lub botów

Nagły skok ruchu od botów lub atak DDoS mogą przeciążyć Twój serwer. Sprawdź logi dostępu pod kątem podejrzanych wzorców.

# Count requests per IP in the last 1000 lines
tail -1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Requests per minute (use -f1-4 for per second)
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-3 | uniq -c | sort -rn | head -10

# Block an abusive IP (-I puts the rule first, before any ACCEPT rules)
sudo iptables -I INPUT -s 1.2.3.4 -j DROP

# Or in nginx's server block:
# deny 1.2.3.4;

Jeśli jeden adres lub niewielki zakres wysyła tysiące żądań, zablokuj go na firewallu. Za Cloudflare lub innym CDN najpierw spraw, żeby logi pokazywały prawdziwe IP odwiedzającego (set_real_ip_from plus real_ip_header CF-Connecting-IP w nginx), bo inaczej zablokujesz CDN zamiast atakującego. Przy dużym ataku tryb „I'm Under Attack” w Cloudflare lub ochrona DDoS u hostingu odfiltruje ruch, zanim do Ciebie dotrze.

Rozwiązanie 8: napraw problemy z połączeniem do bazy danych

Gdy baza danych wyczerpie połączenia albo się zatrzyma, aplikacja przed nią może przestać działać. Niektóre aplikacje odpowiadają 503; WordPress zamiast tego pokazuje „Error establishing a database connection”. Sprawdź bazę bezpośrednio:

# Check if MySQL/MariaDB is running (the unit is mysqld on RHEL, mariadb for MariaDB)
sudo systemctl status mysql

# Restart MySQL
sudo systemctl restart mysql

# Check current connections vs limit
mysql -e "SHOW STATUS LIKE 'Threads_connected';"
mysql -e "SHOW VARIABLES LIKE 'max_connections';"

# Increase max connections (temporary)
mysql -e "SET GLOBAL max_connections = 200;"

# Check for long-running queries
mysql -e "SHOW PROCESSLIST;" | head -20

Jeśli widzisz wiele uśpionych połączeń, Twoja aplikacja nie zamyka prawidłowo połączeń z bazą danych. Jeśli długo trwające zapytania blokują inne, zoptymalizuj te zapytania lub zakończ je, aby odblokować bazę danych.

Rozwiązanie 9: skontaktuj się z dostawcą hostingu

Jeśli korzystasz z hostingu współdzielonego, zarządzanego hostingu WordPress lub platformy takiej jak Squarespace, Wix czy Shopify, możesz nie mieć dostępu do logów serwera ani możliwości restartowania usług. W takich przypadkach błąd 503 może być spowodowany infrastrukturą dostawcy hostingu.

Skontaktuj się z działem wsparcia swojego dostawcy hostingu i podaj:

• Dokładny URL, który zwraca 503
• Kiedy pojawił się błąd — zapisz datę i godzinę
• Co się zmieniło — czy zainstalowałeś wtyczkę, zaktualizowałeś motyw lub zmieniłeś ustawienia DNS?
• Czy błąd jest przerywany czy stały — przerywany 503 sugeruje limity zasobów; stały 503 sugeruje awarię lub błędną konfigurację

503 a inne błędy HTTP

Błąd 503 jest często mylony z innymi błędami serwera. Oto, czym się różnią.

Kluczowa różnica: 503 ma być tymczasowy, a nagłówek Retry-After może podać, na jak długo. Przy indeksowaniu Google traktuje błędy 5xx i 429 podobnie: jego roboty zwalniają, a zaindeksowane adresy URL są przez jakiś czas zachowywane, ale ostatecznie wypadają z indeksu, jeśli błędy trwają (Google Search Central).

Błędy po stronie proxy opisują 502 Bad Gateway i 504 Gateway Timeout; limity żądań — 429 Too Many Requests.

Jak zapobiegać błędom 503

Lepiej zapobiegać niż gasić pożary. Oto najlepsze praktyki, aby unikać błędów 503.

• Monitoruj zasoby serwera — Ustaw alerty dla CPU > 80%, RAM > 85% i dysku > 90%. Narzędzia takie jak UptimeRobot, Pingdom lub Grafana zapewniają natychmiastowe powiadomienia.
• Używaj CDN — Cloudflare, Fastly lub AWS CloudFront buforują zasoby statyczne i absorbują skoki ruchu, zmniejszając obciążenie serwera źródłowego.
• Włącz buforowanie — Używaj Redis, Memcached lub Varnish do buforowania zapytań bazodanowych i wyrenderowanych stron. Użytkownicy WordPress: zainstaluj wtyczkę buforującą, taką jak WP Super Cache lub W3 Total Cache.
• Automatyczne skalowanie — Jeśli korzystasz z hostingu w chmurze (AWS, GCP, Azure, DigitalOcean), skonfiguruj automatyczne skalowanie, aby dodawać więcej serwerów podczas skoków ruchu.
• Ogranicz boty — Skonfiguruj Nginx lub Cloudflare, aby ograniczyć prędkość agresywnych robotów i scraperów, zanim przeciążą Twój serwer.
• Optymalizuj zapytania bazodanowe — wolne zapytania utrzymują otwarte połączenia i procesy. Dodaj indeksy, zoptymalizuj złączenia i buforuj wyniki w Redis lub Memcached.
• Używaj odpowiedniej strony konserwacyjnej — Podczas wdrożeń zwracaj 503 z nagłówkiem Retry-After zamiast pozwalać serwerowi się zawiesić. Chroni to SEO i informuje użytkowników.
• Aktualizuj oprogramowanie — Aktualizuj CMS, wtyczki, PHP i bazę danych do najnowszych stabilnych wersji, aby unikać znanych błędów i luk bezpieczeństwa.