En 503 Service Unavailable-fejl betyder, at webserveren modtog forespørgslen, men ikke kan håndtere den lige nu. Serveren kan nås, så DNS og netværket virker, men applikationen bag den er overbelastet, under vedligeholdelse eller ude af stand til at nå en tjeneste, den er afhængig af. En 503 er ment som midlertidig. Varer den mere end et par minutter, er der noget, der skal rettes: som regel for meget trafik, for få workers, en stoppet applikationsproces eller en backend, der er nede.
Denne guide forklarer, hvad der udløser en 503, hvordan du finder årsagen på din egen server, hvordan du løser hver enkelt, og hvordan du sikrer dig, at du hører om den næste, før dine kunder gør.
Hvad en 503 egentlig fortæller dig
HTTP-statuskoder i 5xx-området betyder, at det er serveren, der fejlede, ikke den besøgende. Inden for den familie har 503 en bestemt betydning: tjenesten er utilgængelig for nu, og klienten må prøve igen senere. Sammenlign den med naboerne:
500 Internal Server Error: applikationen gik ned under håndteringen af forespørgslen.
502 Bad Gateway: en proxy eller load balancer fik et ugyldigt svar fra serveren bag sig.
503 Service Unavailable: serveren, eller noget foran den, nægter at behandle forespørgslen, fordi den er overbelastet, under vedligeholdelse eller ikke har noget sundt at sende den videre til.
504 Gateway Timeout: en proxy ventede på serveren bag sig og gav op.
Forskellen er vigtig, fordi den viser, hvor du skal lede. En 503 er sjældent en fejl på én side. Den handler næsten altid om kapacitet eller tilgængelighed for en hel tjeneste. Se vores snydeark over HTTP-statuskoder til overvågning for et fuldt overblik over koderne, og hvilke en overvågning bør behandle som nede.
Almindelige årsager til en 503
Trafikspidser og overbelastning
Enhver server kan kun håndtere et begrænset antal forespørgsler ad gangen. En kampagnemail, en omtale på sociale medier eller en bot, der crawler tusindvis af sider, kan skubbe den over grænsen. Når køen er fuld, begynder webserveren eller applikationen at afvise nye forespørgsler med 503. Sitet virker ofte igen et par minutter senere og fejler så igen ved næste spidsbelastning.
Planlagt vedligeholdelse
Mange systemer returnerer 503 med vilje under vedligeholdelse. WordPress gør det, mens det installerer opdateringer: det skriver en .maintenance-fil og viser en kort “Briefly unavailable for scheduled maintenance”-side med status 503. Hvis en opdatering bliver afbrudt, kan filen blive liggende, og sitet bliver ved med at returnere 503, til nogen sletter den.
Stoppet applikationsproces eller app pool
På Windows-servere med IIS giver en stoppet eller nedbrudt application pool den klassiske “HTTP Error 503. The service is unavailable.” Poolen kan stoppe på grund af gentagne nedbrud, en forkert adgangskode til identiteten eller en ændret konfiguration. På Linux svarer det til en Node-, Python- eller Java-proces, der er afsluttet, så reverse proxyen ikke har noget at sende videre til.
PHP-FPM er løbet tør for workers
PHP-sites bag nginx eller Apache kører som regel PHP-FPM med et fast antal worker-processer, sat med pm.max_children. Når alle workers er optaget, for eksempel fordi hver forespørgsel venter på en langsom databaseforespørgsel eller et eksternt API, stiller nye forespørgsler sig i kø. Afhængigt af opsætningen får den besøgende en 503, en 502 eller en 504. PHP-FPM-loggen fortæller dig, om det sker:
WARNING: [pool www] server reached pm.max_children setting (10), consider raising it
Rate limiting
Rate limits beskytter en server mod misbrug, men de returnerer også fejl til rigtige brugere, hvis de er sat for stramt. nginx returnerer som standard 503, når en forespørgsel overskrider en limit_req-zone. Web application firewalls og nogle hostingplatforme gør det samme. Hvis et kontor, en API-klient eller en overvågningstjeneste deler IP-adresse med mange brugere, kan de ramme grænsen sammen.
Upstream eller backend er nede
Load balancere og reverse proxyer returnerer 503, når de ikke har nogen sund server at sende trafik til. Hvis health checks markerer alle backends som usunde, efter et dårligt deploy eller fordi databasen er nede, og health-endpointet melder det, svarer proxyen 503 på hver eneste forespørgsel.
Problemer med CDN og origin
Hvis dit site ligger bag et CDN, kan 503-fejlen komme fra CDN’et og ikke fra din server. CDN’et kan returnere den, når din origin er overbelastet eller ikke kan nås, eller når CDN’et selv har problemer i en region. Svarets headers fortæller som regel, hvem der svarede: kig efter CDN’ets egen server-header eller request-id, og sammenlign med en forespørgsel sendt direkte til originen.
Sådan finder du årsagen
Start med selve svaret. Hent den URL, der fejler, og se på headers:
curl -sS -o /dev/null -D – https://northwind.shop/checkout
Server-headeren og eventuelle CDN-specifikke headers viser, hvilket lag der svarede. En Retry-After-header tyder på bevidst vedligeholdelse. Arbejd dig derefter indad:
Tjek, om det sker overalt. Fejler forsiden også, eller kun én sti? Én sti peger på en enkelt route i applikationen eller en worker-pool; fejler alt, peger det på serveren eller proxyen.
Læs webserverens fejllog. nginx og Apache logger fejl i upstream, afvisninger på grund af rate limits og forbindelsesfejl med tidsstempler.
Læs applikationens eller PHP-FPM’s log. Kig efter advarsler om max_children, nedbrud, processer dræbt på grund af manglende hukommelse og spor af langsomme forespørgsler.
Tjek serverens ressourcer. CPU, load, hukommelse og swap i det øjeblik, fejlen opstod. En server, der swapper, er en server, der svarer langsomt, og langsomme svar fylder worker-pools.
Tjek afhængigheder. Svarer databasen? Kører cachen? Svarer et eksternt API, som du kalder synkront, langsomt?
Tjek nylige ændringer. Et deploy, en plugin-opdatering, en ændret konfiguration eller en ny rate limit omkring det tidspunkt, fejlene begyndte, er den mest sandsynlige årsag.
Sådan løser du en 503
Løsningen følger årsagen. Her er de almindelige i den rækkefølge, de fleste teams møder dem.
Fastlåst vedligeholdelsestilstand: fjern .maintenance-filen i WordPress-roden, eller slå dit frameworks vedligeholdelsesflag fra, og gør derefter opdateringen færdig eller prøv igen.
Overbelastning fra rigtig trafik: cache, hvad du kan, på edge og i applikationen, så de fleste forespørgsler aldrig når PHP eller databasen. Tilføj derefter kapacitet: flere workers, hvis hukommelsen tillader det, en større server eller flere servere bag load balanceren.
Overbelastning fra bots: find user agents og IP-områder i din access-log, og rate limit eller bloker dem i CDN’et eller firewallen, før de når applikationen.
PHP-FPM-workers: hæv kun pm.max_children så langt, hukommelsen tillader. Find den gennemsnitlige hukommelse for én worker, og del den hukommelse, du kan undvære, med den. Hvis dine workers er optaget på grund af langsomme forespørgsler, så ret forespørgslerne først, ellers flytter du bare flaskehalsen.
Stoppet app pool eller proces: genstart den, og find så ud af, hvorfor den stoppede. Tjek event-loggen eller systemjournalen for nedbrud, og sæt en procesmanager op, der genstarter tjenesten automatisk.
For stramme rate limits: hæv grænsen eller burst-størrelsen, undtag kendte IP-adresser som dit kontor eller din overvågningstjeneste, og returnér 429 i stedet for 503 til klienter, der er rate limited, så årsagen er tydelig i logs.
Usunde backends: tjek, hvad load balancerens health check henter, og hvorfor det fejler. Rul et dårligt deploy tilbage først, og undersøg bagefter.
Her er en typisk ændring af en PHP-FPM-pool på en server med plads til flere workers. Tallene er et eksempel, ikke en anbefaling til din server:
; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 24
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log
Slow-loggen er den nyttige del: den viser, hvilke scripts der holder på dine workers længst, og det er dér, du skal kigge næste gang.
Brug Retry-After under planlagt vedligeholdelse
Når du tager et site ned med vilje, så returnér 503 med en Retry-After-header. Den fortæller browsere, API-klienter og søgemaskinernes crawlere, at nedetiden er midlertidig, og hvornår de skal komme tilbage. Værdien er enten et antal sekunder eller en HTTP-dato:
HTTP/1.1 503 Service Unavailable
Retry-After: 1800
Content-Type: text/html; charset=utf-8
I nginx kan en simpel vedligeholdelseskontakt se sådan ud:
if (-f /var/www/maintenance.flag) {
return 503;
}
error_page 503 @maintenance;
location @maintenance {
add_header Retry-After 1800 always;
root /var/www/maintenance;
rewrite ^ /index.html break;
}
To regler gør planlagt vedligeholdelse smertefri. Returnér 503, aldrig 200 med en “vi er snart tilbage”-side, for en 200 fortæller crawlere og overvågninger, at vedligeholdelsessiden er dit rigtige indhold. Og hold det kort: en 503 i en time er fint, en 503 i flere dage risikerer, at sider falder ud af søgeresultaterne.
Giv også kunderne besked på forhånd. En note på din statusside besvarer “er det kun mig?”, før nogen når at spørge.
Sådan fanger overvågning 503-fejl
En 503 kommer og går ofte. Sitet fejler i to minutter på toppen af en kampagne, kommer sig og fejler igen en time senere. Ingen i teamet ser det, for når nogen åbner sitet, virker det. Det gjorde kunderne dog.
En HTTP-overvågning henter dine sider efter en fast plan og registrerer statuskoden og svartiden for hvert tjek. En 503 er et fejlet tjek. God overvågning gør derefter tre ting:
Bekræfter fejlen. Et ekstra tjek udelukker et enkeltstående blip, og et tjek fra en anden lokation udelukker også et problem på én netværkssti. Uptimecheck tjekker fra Stockholm, London og New York og bekræfter hver fejl fra en anden lokation, før en hændelse oprettes.
Alarmerer de rigtige personer. Alarmen indeholder statuskoden, URL’en og tidspunktet, hvor det begyndte, så den, der tager den, ved, at det er en 503 og ikke en DNS-fejl. I Uptimecheck indeholder hændelsen også det fejlende svar og et skærmbillede, så du ser den fejlside, dine besøgende så, eller en traceroute, når serveren slet ikke svarede. Se alarmer og notifikationer for kanalerne.
Registrerer mønsteret. Hændelseshistorikken viser, om 503-fejl samler sig omkring trafikspidser, deploys eller natlige jobs, og det fortæller dig, hvilken løsning du skal prøve først.
Overvåg mere end forsiden. Forsiden er ofte cachet og bliver ved med at virke, mens checkout, login eller API’et fejler. Tilføj oppetidsovervågninger for de sider, der tjener penge, og hold øje med udviklingen i svartiden: en side, der bliver langsommere hver dag på samme tidspunkt, er ofte en 503, der venter på at ske. Vores guide til, hvad en god svartid for et website er, forklarer, hvad du skal kigge efter.
Servermålinger lukker cirklen. Når en 503-alarm kommer ind, er det første spørgsmål, om serveren løb tør for CPU, hukommelse eller disk. Med serverovervågning ved siden af dine oppetidstjek ser du årsagen og symptomet side om side.
Tjekliste til 503-fejl
Se på svarets headers for at finde ud af, hvilket lag der returnerede 503.
Tjek webserverens, applikationens og PHP-FPM’s logs for samme tidsstempel.
Tjek CPU, hukommelse, swap og disk på serveren.
Kig efter deploys, opdateringer og konfigurationsændringer lige før fejlene begyndte.
Løs årsagen: caching, flere workers, en genstartet proces, en løsere rate limit eller en sund backend.
Brug 503 med Retry-After til planlagt vedligeholdelse, aldrig 200.
Overvåg vigtige sider hvert minut, og bekræft hver fejl med et ekstra tjek, før der sendes alarm.
Opsummering
En 503 betyder, at serveren er der, men ikke kan betjene dig lige nu. Det er et problem med kapacitet eller tilgængelighed, ikke en ødelagt side, og loggene for samme tidsstempel peger som regel direkte på årsagen. Løs årsagen frem for symptomet, brug Retry-After, når nedetiden er planlagt, og lad overvågningen fortælle dig om de korte 503-fejl, du ellers aldrig ville se.
Uptimecheck overvåger websites, API’er og servere i én konto og sender dig en alarm, når en side begynder at returnere 503. Start din gratis prøveperiode på 14 dage, uden kreditkort.