503 Service Unavailable: överbelastad eller under underhåll?
· 6 min läsning
Vad felet betyder
503 är webbservern som säger ”jag är här, men jag kan inte betjäna dig just nu”. Till skillnad från ett 502 är inget bakom den nödvändigtvis trasigt. Servern skickar ett 503 med avsikt i tre situationer: den är i underhållsläge, den har nått en gräns som den ska respektera (anslutningar, arbetare, bandbredd, en hastighetsgräns), eller den är så överbelastad att den kastar bort förfrågningar för att hålla sig vid liv. Ett 503 kan innehålla en Retry-After-rubrik som talar om för klienter när de ska komma tillbaka; sökmotorer behandlar ett kort 503 som tillfälligt och tar inte bort sidan.
Vanliga orsaker
- Underhållsläget lämnades på. WordPress skriver en
.maintenance-fil under uppdateringar och svarar med 503 tills uppdateringen är klar. Om uppdateringen avbryts blir filen kvar, och felet med den. Laravel, Magento, Drupal och de flesta ramverk har en motsvarande brytare. - Överbelastning. Fler förfrågningar än de konfigurerade arbetarna klarar. Apaches
MaxRequestWorkersnådd, PHP-FPM:spm.max_childrenslut, eller databasen så långsam att varje arbetare väntar. - En gräns hos webbhotellet. Delade webbhotell begränsar CPU-sekunder, samtidiga processer eller ”entry processes” per konto. När du når gränsen svarar webbhotellets gateway med 503 bara för din hemsida.
- En backend som tagits ur rotation. Bakom en lastbalanserare eller ett CDN betyder ett 503 att alla backends misslyckades med sin hälsokontroll. Cloudflare visar sin egen 503-sida när origin är överbelastad eller har en hastighetsgräns.
- Botar och skrapare. En crawler som hämtar tusentals sidor, eller en brute force-attack mot
wp-login.phpellerxmlrpc.php, förbrukar arbetarna och legitima besökare får 503. - En full disk eller slut på minne. Tjänsten är uppe men kan inte skriva sessioner, cachefiler eller loggar, och vissa applikationer svarar 503 i det läget.
Om du är besökare
Vänta en minut och ladda om; ett 503 är oftast kort. Om en hemsida ligger kvar på 503 i timmar har ägaren ett fastnat underhållsläge eller ett kapacitetsproblem, och bara hen kan åtgärda det.
Om det är din hemsida: kontrollera först
Kör kontrollen av om hemsidan ligger nere för att bekräfta 503 utifrån och se om ett CDN eller din egen server skickade det. Avgör sedan: har du eller ditt CMS startat en uppdatering de senaste minuterna? Om ja är det underhållsläget. Om inte är det kapacitet.
På din egen server:
# är webbservern uppe alls?
systemctl status nginx
systemctl status apache2
# belastning, minne, disk: de tre siffrorna bakom de flesta 503
uptime
free -m
df -h
# vem hamrar på hemsidan just nu?
sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
En genomsnittlig belastning långt över antalet CPU-kärnor, mindre än 100 MB ledigt minne, eller en enskild IP med tusentals förfrågningar de senaste minuterna förklarar var och en ett 503.
Åtgärder på din egen server
1. Avsluta ett fastnat underhållsläge
WordPress: radera .maintenance-filen i hemsidans rot och öppna sedan hemsidan. Om uppdateringen som skapade den avbröts kan pluginet eller core vara halvinstallerat; kör uppdateringen igen från instrumentpanelen 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ätt $settings['maintenance_mode'] till false eller använd drush state:set system.maintenance_mode 0.
2. Stoppa floden
Blockera den störande IP-adressen eller det störande nätverket och lägg sedan till en hastighetsgräns så att nästa inte kan göra om det.
# blockera en adress (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
Hastighetsgräns i nginx för inloggningssidor (i http-blocket, sedan i server-blocket):
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 samma sak; fail2ban med jails apache-badbots och wordpress blockerar återfallsförbrytare automatiskt.
3. Ge servern kapacitet
Om belastningen är verklig trafik, inte missbruk, höj arbetargränserna inom det som minnet tillåter. Apache (mpm_event): MaxRequestWorkers. PHP-FPM: pm.max_children. Kontrollera först minnet per arbetare: ps -ylC php-fpm8.3 --sort:rss. Testa och ladda sedan om:
sudo apachectl configtest && sudo systemctl reload apache2
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm
Slå på sidcachning (WordPress: ett cacheplugin eller FastCGI-cache i nginx) så att en topp inte längre kör PHP för varje förfrågan. En cachad sida kostar en bråkdel av en millisekund; en WordPress-sida utan cache kostar hundratals.
4. Frigör disken
sudo du -xh --max-depth=1 /var | sort -h | tail
sudo journalctl --vacuum-size=200M
sudo apt clean
Gamla loggfiler, säkerhetskopior som sparas på samma disk och en skenande debugglogg är de vanliga misstänkta.
5. Bakom en lastbalanserare
Att alla backends misslyckas med hälsokontrollen samtidigt betyder oftast att kontroll-URL:en själv är trasig (raderad hälsosida, omdirigering till HTTPS som kontrollen inte följer) snarare än varje backend. Hämta hälso-URL:en för hand från balanseraren.
När det är ditt webbhotells problem
På delat webbhotell kan du inte höja gränser. Fråga ditt webbhotell vilken gräns du nådde och om det är din trafik eller ett annat konto på samma server:
Hej, min hemsida example.com svarar ”503 Service Unavailable” sedan ungefär 09:10 UTC. Jag har inte startat någon uppdatering och hemsidan är inte i underhållsläge. Kan ni säga om mitt konto nådde en resursgräns (CPU, processer, minne) eller om servern är överbelastad, och vilka siffrorna är? Om det är mitt konto, vilken gräns och sedan när?
Om svaret regelbundet är ”ditt konto nådde sina gränser” bör du antingen cacha hemsidan ordentligt eller flytta till en plan eller server med mer kapacitet.
Förhindra nästa
Ett 503 aviserar sig självt: belastningen kryper uppåt, minnet tar slut, en IP börjar översvämma. Hemsidekontroller fångar 503 inom en minut; serveragenten visar belastning, minne och disk innan det går så långt. På din egen server frigör en Quick Fix diskutrymme och startar om en fastnad tjänst till fast pris, och en Deep Fix sätter upp hastighetsgränser och cachning så att servern håller sig uppe nästa gång.
Vad nu
Kontrollera utifrån
Ligger hemsidan nere för alla eller bara för dig, och vad svarar servern? Gratis, ingen registrering.
Kontroll av om hemsidan ligger nereNere? Vi går in.
På din egen server eller i ett webbutrymme med SSH-åtkomst: en Quick Fix till fast pris för de vanliga orsakerna, en Deep Fix som debiteras i block om 15 minuter för resten, dygnet runt. Pris innan du beställer.
Få det åtgärdatFler guider
- Din hemsida ligger nere. Så här gör du de första 15 minuterna.
- Server nere: vad du kontrollerar först, och i vilken ordning
- 502 Bad Gateway: orsaker och hur du åtgärdar det
- 504 Gateway Timeout: vad det betyder och hur du åtgärdar det
- DNS_PROBE_FINISHED_NXDOMAIN: orsaker och åtgärder
- ERR_CONNECTION_REFUSED: orsaker och hur du åtgärdar det
- ”Anslutningen är inte privat”: varningen för SSL-certifikat