503 Service Unavailable: overbelastet eller i vedligeholdelse?

Hvad fejlen betyder

503 er webserveren, der siger “jeg er her, men jeg kan ikke betjene dig lige nu”. I modsætning til en 502 er noget bag den ikke nødvendigvis gået i stykker. Serveren sender med vilje en 503 i tre situationer: den er i vedligeholdelsestilstand, den har ramt en grænse, den fik besked på at overholde (forbindelser, workers, båndbredde, en rate limit), eller den er så overbelastet, at den afviser forespørgsler for at holde sig i live. En 503 kan have en Retry-After-header, der fortæller klienter, hvornår de skal komme igen; søgemaskiner behandler en kort 503 som midlertidig og dropper ikke siden.

Almindelige årsager

1. Vedligeholdelsestilstand efterladt slået til. WordPress skriver en .maintenance-fil under opdateringer og svarer 503, indtil opdateringen er færdig. Afbrydes opdateringen, bliver filen liggende, og det gør fejlen også. Laravel, Magento, Drupal og de fleste frameworks har en tilsvarende kontakt.
2. Overbelastning. Flere forespørgsler, end de konfigurerede workers kan håndtere. Apaches MaxRequestWorkers nået, PHP-FPM’s pm.max_children opbrugt, eller databasen så langsom, at hver worker venter.
3. En hostinggrænse. Delte hostingudbydere sætter loft over CPU-sekunder, samtidige processer eller “entry processes” pr. konto. Rammer du loftet, svarer hostingudbyderens gateway 503 kun for din hjemmeside.
4. En backend taget ud af rotation. Bag en load balancer eller et CDN betyder en 503, at alle backends fejlede deres health check. Cloudflare viser sin egen 503-side, når origin er overbelastet eller rate-limited.
5. Bots og scrapere. En crawler, der henter tusindvis af sider, eller et brute force-angreb på wp-login.php eller xmlrpc.php, opbruger workers, og legitime besøgende får 503.
6. En fuld disk eller opbrugt hukommelse. Tjenesten er oppe, men kan ikke skrive sessioner, cachefiler eller logs, og nogle applikationer svarer 503 i den tilstand.

Hvis du er besøgende

Vent et minut, og genindlæs; en 503 er som regel kort. Bliver en hjemmeside ved med at vise 503 i timevis, har ejeren en hængende vedligeholdelsestilstand eller et kapacitetsproblem, og kun ejeren kan rette det.

Hvis det er din hjemmeside: tjek først

Kør tjekket af, om hjemmesiden er nede for at bekræfte 503’en udefra og se, om et CDN eller din egen server sendte den. Afgør så: har du eller dit CMS startet en opdatering inden for de seneste minutter? Hvis ja, er det vedligeholdelsestilstand. Hvis ikke, er det kapacitet.

På din egen server:

# er webserveren overhovedet oppe?
systemctl status nginx
systemctl status apache2

# belastning, hukommelse, disk: de tre tal bag de fleste 503'er
uptime
free -m
df -h

# hvem hamrer løs på hjemmesiden lige nu?
sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

En load average langt over antallet af CPU-kerner, mindre end 100 MB ledig hukommelse eller en enkelt IP med tusindvis af forespørgsler de seneste minutter forklarer hver for sig en 503.

Rettelser på din egen server

1. Afslut en hængende vedligeholdelsestilstand

WordPress: slet filen .maintenance i hjemmesidens rod, og åbn så hjemmesiden. Hvis opdateringen, der oprettede den, blev afbrudt, kan plugin’et eller kernen være halvt installeret; kør opdateringen igen fra dashboardet eller med 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: sæt $settings['maintenance_mode'] til false, eller brug drush state:set system.maintenance_mode 0.

2. Stop oversvømmelsen

Bloker den skyldige IP eller det skyldige netværk, og tilføj så en rate limit, så den næste ikke kan gøre det igen.

# bloker én adresse (Debian/Ubuntu med ufw)
sudo ufw deny from 203.0.113.45

# eller med nftables
sudo nft add rule inet filter input ip saddr 203.0.113.45 drop

nginx rate limit til loginsider (i http-blokken, derefter i server-blokken):

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 eller mod_qos gør det samme; fail2ban med jails til apache-badbots og wordpress blokerer gengangere automatisk.

3. Giv serveren kapacitet

Er belastningen reel trafik og ikke misbrug, så hæv worker-grænserne inden for det, hukommelsen tillader. Apache (mpm_event): MaxRequestWorkers. PHP-FPM: pm.max_children. Tjek først hukommelsen pr. worker: ps -ylC php-fpm8.3 --sort:rss. Test og genindlæs så:

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

Slå sidecaching til (WordPress: et caching-plugin eller FastCGI-cache i nginx), så en spids ikke længere kører PHP ved hver forespørgsel. En cachet side koster en brøkdel af et millisekund; en WordPress-side uden cache koster hundredvis.

4. Frigør disken

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

Gamle logfiler, backups gemt på samme disk og en løbsk debug-log er de sædvanlige mistænkte.

5. Bag en load balancer

Hvis alle backends fejler health checket på én gang, er det som regel selve check-URL’en, der er ødelagt (slettet health-side, omdirigering til HTTPS, som checkeren ikke følger), og ikke hver backend. Hent health-URL’en i hånden fra balanceren.

Når det er din hostingudbyders problem

Hos delt hosting kan du ikke hæve grænser. Spørg din hostingudbyder, hvilken grænse du ramte, og om det er din trafik eller en anden konto på den samme server:

Hej, min hjemmeside example.com svarer “503 Service Unavailable” siden ca. kl. 09:10 UTC. Jeg har ikke startet en opdatering, og hjemmesiden er ikke i vedligeholdelsestilstand. Kan I fortælle, om min konto ramte en ressourcegrænse (CPU, processer, hukommelse), eller om serveren er overbelastet, og hvad tallene er? Hvis det er min konto, hvilken grænse og siden hvornår?

Hvis svaret regelmæssigt er “din konto ramte sine grænser”, så cache enten hjemmesiden ordentligt, eller flyt til et abonnement eller en server med mere kapacitet.

Forebyg den næste

En 503 varsler sig selv: belastningen kryber op, hukommelsen løber tør, én IP begynder at oversvømme. Hjemmesidetjek fanger 503’en inden for et minut; serveragenten viser belastning, hukommelse og disk, før det når så vidt. På din egen server frigør en Quick Fix diskplads og genstarter en hængende tjeneste til fast pris, og en Deep Fix sætter rate limits og caching op, så serveren holder næste gang.