503 Service Unavailable: suprasolicitat sau în mentenanță?

Ce înseamnă eroarea

503 este serverul web care spune „Sunt aici, dar nu te pot servi acum”. Spre deosebire de un 502, nu este neapărat stricat ceva în spate. Serverul trimite intenționat un 503 în trei situații: este în mod de mentenanță, a atins o limită pe care i s-a spus să o respecte (conexiuni, workeri, lățime de bandă, un rate limit) sau este atât de suprasolicitat încât respinge cereri ca să rămână în viață. Un 503 poate purta un antet Retry-After care le spune clienților când să revină; motoarele de căutare tratează un 503 scurt ca temporar și nu elimină pagina.

Cauze frecvente

1. Modul de mentenanță rămas activat. WordPress scrie un fișier .maintenance în timpul actualizărilor și răspunde cu 503 până se termină actualizarea. Dacă actualizarea este întreruptă, fișierul rămâne, și odată cu el eroarea. Laravel, Magento, Drupal și majoritatea framework-urilor au un comutator echivalent.
2. Suprasolicitare. Mai multe cereri decât pot gestiona workerii configurați. S-a atins MaxRequestWorkers la Apache, s-a epuizat pm.max_children la PHP-FPM sau baza de date este atât de lentă încât fiecare worker așteaptă.
3. O limită de hosting. Furnizorii de hosting partajat limitează secundele de CPU, procesele concurente sau „entry processes” per cont. Când atingi limita, gateway-ul furnizorului răspunde cu 503 doar pentru site-ul tău.
4. Un backend scos din rotație. În spatele unui load balancer sau CDN, un 503 înseamnă că toate backend-urile au picat verificarea de sănătate. Cloudflare afișează propria pagină 503 când originea este suprasolicitată sau limitată ca rată.
5. Boți și scraper-e. Un crawler care preia mii de pagini sau un atac brute-force asupra wp-login.php sau xmlrpc.php epuizează workerii, iar vizitatorii legitimi primesc 503.
6. Disc plin sau memorie epuizată. Serviciul funcționează, dar nu poate scrie sesiuni, fișiere cache sau loguri, iar unele aplicații răspund cu 503 în această stare.

Dacă ești vizitator

Așteaptă un minut și reîncarcă; un 503 este de obicei scurt. Dacă un site rămâne la 503 ore în șir, proprietarul are un mod de mentenanță blocat sau o problemă de capacitate, iar numai el o poate repara.

Dacă e site-ul tău: verifică mai întâi

Rulează website down checker ca să confirmi 503 din exterior și să vezi dacă l-a trimis un CDN sau propriul tău server. Apoi decide: ai pornit tu sau CMS-ul tău o actualizare în ultimele minute? Dacă da, este modul de mentenanță. Dacă nu, este capacitate.

Pe propriul server:

# serverul web funcționează deloc?
systemctl status nginx
systemctl status apache2

# încărcare, memorie, disc: cele trei cifre din spatele majorității 503
uptime
free -m
df -h

# cine bombardează site-ul chiar acum?
sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

O încărcare medie mult peste numărul de nuclee CPU, mai puțin de 100 MB memorie liberă sau o singură adresă IP cu mii de cereri în ultimele minute explică fiecare un 503.

Remedieri pe propriul server

1. Încheie un mod de mentenanță blocat

WordPress: șterge fișierul .maintenance din rădăcina site-ului, apoi deschide site-ul. Dacă actualizarea care l-a creat a fost întreruptă, pluginul sau nucleul pot fi instalate pe jumătate; rulează din nou actualizarea din panou sau cu WP-CLI:

rm /var/www/example.com/.maintenance
wp core verify-checksums
wp plugin update --all

Laravel: php artisan up. Magento: bin/magento maintenance:disable. Drupal: setează $settings['maintenance_mode'] pe false sau folosește drush state:set system.maintenance_mode 0.

2. Oprește inundația

Blochează adresa IP sau rețeaua vinovată, apoi adaugă un rate limit ca următorul să nu mai poată face același lucru.

# blochează o adresă (Debian/Ubuntu cu ufw)
sudo ufw deny from 203.0.113.45

# sau cu nftables
sudo nft add rule inet filter input ip saddr 203.0.113.45 drop

Rate limit nginx pentru paginile de autentificare (în blocul http, apoi în blocul 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 sau mod_qos fac același lucru; fail2ban cu jail-urile apache-badbots și wordpress blochează automat recidiviștii.

3. Dă serverului capacitate

Dacă încărcarea este trafic real, nu abuz, mărește limitele workerilor în măsura în care o permite memoria. Apache (mpm_event): MaxRequestWorkers. PHP-FPM: pm.max_children. Verifică mai întâi memoria per worker: ps -ylC php-fpm8.3 --sort:rss. Apoi testează și reîncarcă:

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

Activează cache-ul de pagini (WordPress: un plugin de cache sau FastCGI cache în nginx), ca un vârf de trafic să nu mai ruleze PHP pentru fiecare cerere. O pagină din cache costă o fracțiune de milisecundă; o pagină WordPress fără cache costă sute.

4. Eliberează discul

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

Fișierele de log vechi, copiile de siguranță ținute pe același disc și un log de debug scăpat de sub control sunt de obicei vinovații.

5. În spatele unui load balancer

Dacă toate backend-urile pică deodată verificarea de sănătate, de obicei URL-ul de verificare însuși este defect (pagină de sănătate ștearsă, redirecționare către HTTPS pe care verificatorul nu o urmează), nu fiecare backend. Preia manual URL-ul de sănătate de pe load balancer.

Când e problema furnizorului tău de hosting

Pe hosting partajat nu poți mări limitele. Întreabă-ți furnizorul ce limită ai atins și dacă e vorba de traficul tău sau de alt cont de pe același server:

Bună ziua, site-ul meu example.com răspunde „503 Service Unavailable” începând cu aproximativ 09:10 UTC. Nu am pornit nicio actualizare, iar site-ul nu este în mod de mentenanță. Ați putea să-mi spuneți dacă contul meu a atins o limită de resurse (CPU, procese, memorie) sau dacă serverul este suprasolicitat, și care sunt cifrele? Dacă este contul meu, ce limită și din ce moment?

Dacă răspunsul este în mod repetat „contul tău a atins limitele”, fie pui site-ul în cache cum trebuie, fie treci la un plan sau la un server cu mai multă capacitate.

Prevenirea următorului

Un 503 se anunță singur: încărcarea crește treptat, memoria se epuizează, o adresă IP începe să inunde. Verificările de site prind 503 în decurs de un minut; agentul de server arată încărcarea, memoria și discul înainte să se ajungă acolo. Pe propriul server, un Quick Fix eliberează spațiu pe disc și repornește un serviciu blocat la preț fix, iar un Deep Fix configurează rate limit-uri și cache, ca serverul să rămână în picioare data viitoare.