503 Service Unavailable: overbelasting, onderhoud of een limiet van de hosting?

Wat de fout betekent

Met een 503 zegt de webserver: “Ik ben er, maar ik kan je nu niet bedienen.” Anders dan bij een 502 hoeft er niets kapot te zijn, en anders dan bij een 500 is de applicatie niet vastgelopen. De server stuurt de 503 met opzet, in drie situaties: hij staat in onderhoudsmodus, hij heeft een limiet bereikt die iemand heeft ingesteld (verbindingen, workers, bandbreedte, verzoeken per seconde), of hij is zo zwaar belast dat hij verzoeken weigert om niet helemaal om te vallen. Een 503 kan een header Retry-After meesturen die clients vertelt wanneer ze terug mogen komen. Zoekmachines zien een korte 503 als tijdelijk en halen de site niet uit de index. Krijgen alleen bepaalde bezoekers een fout omdat ze te veel verzoeken sturen, dan is het geen 503 maar een 429 Too Many Requests.

Veelvoorkomende oorzaken

1. Onderhoudsmodus die is blijven hangen. Tijdens een update maakt WordPress een bestand .maintenance aan en antwoordt hij 503 zolang dat bestaat. Breekt de update af, dan blijft het bestand staan, en de fout ook. Laravel, Magento en Drupal hebben een vergelijkbare schakelaar.
2. Overbelasting. Meer verzoeken dan de workers aankunnen: MaxRequestWorkers van Apache bereikt, pm.max_children van PHP-FPM op, of een database die zo traag is dat elke worker blijft wachten.
3. Een limiet van de hosting. Shared-hostingproviders beperken CPU-seconden, gelijktijdige processen of “entry processes” per account. Limiet bereikt: de gateway van de hostingprovider antwoordt 503, alleen voor jouw site.
4. Een backend uit de roulatie. Achter een load balancer of een CDN betekent 503 dat geen enkele backend de health check doorstaat. Cloudflare toont zijn eigen 503-pagina wanneer de origin-server overbelast is of een verzoeklimiet heeft bereikt.
5. Crawlers en scrapers. Een crawler die duizenden pagina’s ophaalt of een brute-force-aanval op wp-login.php of xmlrpc.php verbruikt de workers; echte bezoekers krijgen 503.
6. Schijf of geheugen vol. De dienst draait, maar kan geen sessies, cache of logs meer schrijven; sommige applicaties antwoorden dan met 503.

Als je bezoeker bent

Wacht een minuut en herlaad; een 503 is bijna altijd kort. Blijft een site urenlang in 503, dan heeft de beheerder een vastgelopen onderhoudsmodus of een capaciteitsprobleem; alleen hij kan iets doen.

Als het je eigen site is: eerst controleren

Open de Website down checker om de 503 van buitenaf te bevestigen en te zien of een CDN of je eigen server hem stuurde. Beslis dan: is er in de laatste minuten een update gestart? Zo ja, dan is het de onderhoudsmodus. Zo nee, dan is het capaciteit.

Op je eigen server:

# draait de webserver überhaupt?
systemctl status nginx
systemctl status apache2

# belasting, geheugen, schijf
uptime
free -m
df -h

# wie hamert er op de site?
sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

Een belasting ver boven het aantal cores, minder dan 100 MB vrij geheugen of één IP-adres met duizenden verzoeken: elk daarvan verklaart een 503.

Oplossingen op je eigen server

1. Uit een vastgelopen onderhoudsmodus komen

WordPress: verwijder het bestand .maintenance in de hoofdmap van de site en open de pagina. Is de update afgebroken, dan kan een plugin of de core half geïnstalleerd zijn achtergebleven; herhaal de update met 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: zet $settings['maintenance_mode'] op false of gebruik drush state:set system.maintenance_mode 0.

2. De stortvloed stoppen

Blokkeer het verdachte IP-adres of netwerk en beperk daarna het tempo van de verzoeken, zodat de volgende keer niet zo ver komt.

# een adres blokkeren (Debian/Ubuntu met ufw)
sudo ufw deny from 203.0.113.45

# of met nftables
sudo nft add rule inet filter input ip saddr 203.0.113.45 drop

Een verzoeklimiet in nginx voor de inlogpagina (de zone in het http-blok, de location in het server-blok):

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 of mod_qos doen hetzelfde; fail2ban blokkeert met de jails apache-badbots en wordpress herhaalde overtreders automatisch.

3. De server capaciteit geven

Komt de belasting van echte bezoekers en niet van misbruik, verhoog dan de workerlimieten zover het geheugen het toelaat. Apache (mpm_event): MaxRequestWorkers. PHP-FPM: pm.max_children. Controleer eerst het geheugen per worker (ps -ylC php-fpm8.3 --sort:rss), test daarna en herlaad:

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

Zet een paginacache aan (WordPress: een cacheplugin of de FastCGI-cache van nginx), zodat een piek niet bij elk verzoek PHP start. Een pagina uit de cache kost een fractie van een milliseconde; zonder cache honderden.

4. Schijfruimte vrijmaken

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

Oude logs, back-ups op dezelfde schijf, een debuglog dat blijft groeien: de gebruikelijke verdachten.

5. Achter een load balancer

Zakken alle backends tegelijk voor de health check, dan is meestal de URL van de check kapot (pagina verwijderd, doorverwijzing naar HTTPS die niet wordt gevolgd), niet elke backend apart. Vraag de URL van de health check handmatig op vanaf de load balancer.

Ligt het bij je hostingprovider?

Op shared hosting kun je geen enkele limiet verhogen. Vraag je hostingprovider welke limiet je hebt bereikt, en of het door jouw verkeer kwam of door een ander account op dezelfde server:

Goedemorgen, mijn website example.com antwoordt sinds ongeveer 9:10 (UTC) met “503 Service Unavailable”. Ik heb geen update gestart en de site staat niet in onderhoudsmodus. Kunt u mij laten weten of mijn account een resourcelimiet (CPU, processen, geheugen) heeft bereikt of dat de server overbelast is? Als het mijn account is: welke limiet, en sinds wanneer?

Is het antwoord steeds “limiet bereikt”, zet de site dan in de cache of stap over op een ruimer pakket.

Zo gebeurt het niet opnieuw

Een 503 kondigt zich aan: de belasting stijgt, het geheugen raakt op, een IP-adres begint te overspoelen. De websitecontroles vangen de 503 op zodra hij verschijnt; de serveragent laat belasting, geheugen en schijf eerder zien.

Down? Wij fixen het. Op je eigen server of op shared hosting met SSH-toegang maakt de Quick Fix, de automatische reparatie tegen een vaste prijs, schijfruimte vrij en herstart hij een vastgelopen dienst; de Deep Fix stelt de verzoeklimiet en de cache in, per blok van 15 minuten, 24 uur per dag, ook in het weekend, zodat de server het de volgende keer wél houdt; de schatting is de bovengrens.