503 Service Unavailable: túlterhelés vagy karbantartás?

Mit jelent a hiba

A 503 az, amikor a webszerver azt mondja: „itt vagyok, de most nem tudlak kiszolgálni”. A 502-vel ellentétben nem feltétlenül romlott el semmi mögötte. A szerver szándékosan küld 503-at három helyzetben: karbantartási módban van, elérte az egyik korlátot, amelyet be kellett tartania (kapcsolatok, workerek, sávszélesség, ráta-korlát), vagy annyira túlterhelt, hogy kéréseket dob el a túlélésért. A 503 tartalmazhat Retry-After fejlécet, amely megmondja a klienseknek, mikor jöjjenek vissza; a keresőmotorok a rövid 503-at átmenetinek tekintik, és nem dobják el az oldalt.

Gyakori okok

1. Bekapcsolva maradt karbantartási mód. A WordPress frissítés közben egy .maintenance fájlt ír, és 503-mal válaszol a frissítés végéig. Ha a frissítés megszakad, a fájl marad, és vele a hiba is. A Laravelnek, a Magentónak, a Drupalnak és a legtöbb keretrendszernek van megfelelő kapcsolója.
2. Túlterhelés. Több kérés, mint amennyit a beállított workerek kezelni tudnak. Az Apache MaxRequestWorkers értéke elérve, a PHP-FPM pm.max_children értéke kimerítve, vagy az adatbázis annyira lassú, hogy minden worker vár.
3. Tárhelykorlát. A megosztott tárhelyek korlátozzák a CPU-másodperceket, az egyidejű folyamatokat vagy a fiókonkénti „entry processes” értéket. A korlát elérésekor a tárhely átjárója csak az Ön oldalára válaszol 503-mal.
4. Forgalomból kivett háttér. Terheléselosztó vagy CDN mögött a 503 azt jelenti, hogy minden háttér megbukott az állapotellenőrzésen. A Cloudflare saját 503-as oldalt mutat, ha az origin túlterhelt vagy ráta-korlátozott.
5. Botok és lekaparók. Egy bejáró, amely ezernyi oldalt kér le, vagy egy találgatásos támadás a wp-login.php vagy az xmlrpc.php ellen kimeríti a workereket, és a jogos látogatók 503-at kapnak.
6. Megtelt lemez vagy kimerült memória. A szolgáltatás fut, de nem tud munkameneteket, gyorsítótárfájlokat vagy naplókat írni, és egyes alkalmazások ebben az állapotban 503-mal válaszolnak.

Ha látogató

Várjon egy percet, és töltse újra; a 503 általában rövid. Ha egy oldal órákig 503-on marad, a tulajdonosnak elakadt karbantartási módja vagy kapacitásproblémája van, és csak ő tudja megjavítani.

Ha a saját oldala: először ellenőrizze

Futtassa a weboldal-leállás ellenőrzőt, hogy kívülről megerősítse a 503-at, és lássa, hogy a CDN vagy a saját szervere küldte-e. Aztán döntse el: Ön vagy a CMS-e indított frissítést az elmúlt percekben? Ha igen, karbantartási módról van szó. Ha nem, kapacitásról.

Saját szerveren:

# fut-e egyáltalán a webszerver?
systemctl status nginx
systemctl status apache2

# terhelés, memória, lemez: a három szám a legtöbb 503 mögött
uptime
free -m
df -h

# ki dönti az oldalt éppen most?
sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

A CPU-magok számánál jóval magasabb terhelési átlag, 100 MB-nál kevesebb szabad memória vagy egyetlen IP-cím több ezer kéréssel az elmúlt percekben mind megmagyaráz egy 503-at.

Javítások a saját szerveren

1. Szüntesse meg az elakadt karbantartási módot

WordPress: törölje a .maintenance fájlt az oldal gyökerében, majd nyissa meg az oldalt. Ha a frissítés, amely létrehozta, megszakadt, a bővítmény vagy a mag félig telepített lehet; futtassa újra a frissítést a vezérlőpultról vagy a WP-CLI-vel:

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

Laravel: php artisan up. Magento: bin/magento maintenance:disable. Drupal: állítsa a $settings['maintenance_mode'] értéket hamisra, vagy használja a drush state:set system.maintenance_mode 0 parancsot.

2. Állítsa meg az áradatot

Tiltsa le a támadó IP-címet vagy hálózatot, majd adjon hozzá ráta-korlátot, hogy a következő ne tudja újra megtenni.

# egy cím letiltása (Debian/Ubuntu ufw-vel)
sudo ufw deny from 203.0.113.45

# vagy nftables-szel
sudo nft add rule inet filter input ip saddr 203.0.113.45 drop

nginx ráta-korlát a bejelentkezési oldalakhoz (az http blokkban, majd a server blokkban):

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: a mod_evasive vagy a mod_qos ugyanezt teszi; a fail2ban az apache-badbots és a wordpress jailekkel automatikusan blokkolja az ismétlődő kéréseket küldőket.

3. Adjon kapacitást a szervernek

Ha a terhelés valódi forgalom, nem visszaélés, emelje a workerkorlátokat a memória által megengedett mértékben. Apache (mpm_event): MaxRequestWorkers. PHP-FPM: pm.max_children. Előbb ellenőrizze a workerenkénti memóriát: ps -ylC php-fpm8.3 --sort:rss. Aztán teszteljen és töltsön újra:

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

Kapcsolja be az oldalgyorsítótárazást (WordPress: gyorsítótár-bővítmény vagy FastCGI-gyorsítótár az nginxben), hogy egy csúcs többé ne futtasson PHP-t minden kéréshez. Egy gyorsítótárazott oldal a milliszekundum töredékébe kerül; egy gyorsítótár nélküli WordPress-oldal százakba.

4. Szabadítsa fel a lemezt

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

A régi naplófájlok, ugyanazon a lemezen tartott mentések és egy elszabadult hibakeresési napló a szokásos gyanúsítottak.

5. Terheléselosztó mögött

Ha minden háttér egyszerre bukik meg az állapotellenőrzésen, az általában azt jelenti, hogy maga az ellenőrző URL hibás (törölt státuszoldal, HTTPS-re átirányítás, amelyet az ellenőrző nem követ), nem pedig az, hogy minden háttér hibás. Kérje le kézzel az állapot-URL-t a terheléselosztóról.

Ha a tárhelyszolgáltató problémája

Megosztott tárhelyen nem tudja emelni a korlátokat. Kérdezze meg a tárhelyszolgáltatót, melyik korlátot érte el, és hogy az Ön forgalma-e, vagy egy másik fiók ugyanazon a szerveren:

Üdvözlöm! Az example.com weboldalam kb. 09:10 UTC óta „503 Service Unavailable” hibával válaszol. Nem indítottam frissítést, és az oldal nincs karbantartási módban. Megmondanák, hogy a fiókom elért-e egy erőforráskorlátot (CPU, folyamatok, memória), vagy a szerver túlterhelt-e, és mik a számok? Ha a fiókom az, melyik korlát és mióta?

Ha a válasz rendszeresen az, hogy „a fiókja elérte a korlátait”, vagy gyorsítótárazza megfelelően az oldalt, vagy költözzön nagyobb kapacitású csomagra vagy szerverre.

A következő megelőzése

A 503 előre jelzi magát: a terhelés kúszik felfelé, a memória fogy, egy IP-cím elkezd áradni. A weboldal-ellenőrzések egy percen belül elkapják a 503-at; a szerverügynök a terhelést, a memóriát és a lemezt még azelőtt megmutatja, hogy idáig jutna. Saját szerveren a Quick Fix fix áron lemezterületet szabadít fel és újraindít egy elakadt szolgáltatást, a Deep Fix pedig ráta-korlátokat és gyorsítótárazást állít be, hogy a szerver legközelebb is fent maradjon.