En 503 Service Unavailable-feil betyr at webserveren tok imot forespørselen, men ikke kan håndtere den akkurat nå. Serveren kan nås, så DNS og nettverket fungerer, men applikasjonen bak er overbelastet, under vedlikehold eller får ikke kontakt med en tjeneste den er avhengig av. En 503 er ment å være midlertidig. Varer den mer enn noen få minutter, er det noe som må rettes: som regel for mye trafikk, for få workers, en stoppet applikasjonsprosess eller en backend som er nede.
Denne guiden forklarer hva som utløser en 503, hvordan du finner årsaken på din egen server, hvordan du løser hver av dem, og hvordan du sørger for å få vite om neste 503 før kundene dine gjør det.
Hva en 503 egentlig forteller deg
HTTP-statuskoder i 5xx-området betyr at det er serveren som feilet, ikke den besøkende. Innenfor den familien har 503 en bestemt betydning: tjenesten er utilgjengelig inntil videre, og klienten kan prøve igjen senere. Sammenlign den med naboene:
500 Internal Server Error: applikasjonen krasjet mens den håndterte forespørselen.
502 Bad Gateway: en proxy eller lastbalanserer fikk et ugyldig svar fra serveren bak seg.
503 Service Unavailable: serveren, eller noe foran den, nekter å behandle forespørselen fordi den er overbelastet, under vedlikehold eller ikke har noe friskt å sende den til.
504 Gateway Timeout: en proxy ventet på serveren bak seg og ga opp.
Forskjellen er viktig fordi den viser hvor du skal lete. En 503 er sjelden en feil på én enkelt side. Den handler nesten alltid om kapasiteten eller tilgjengeligheten til en hel tjeneste. For en fullstendig oversikt over kodene og hvilke en overvåking bør regne som nede, se juksearket vårt over HTTP-statuskoder for overvåking.
Vanlige årsaker til en 503
Trafikktopper og overbelastning
Alle servere kan bare håndtere et begrenset antall forespørsler samtidig. En kampanje-e-post, en omtale i sosiale medier eller en bot som gjennomsøker tusenvis av sider, kan presse den over grensen. Når køen er full, begynner webserveren eller applikasjonen å avvise nye forespørsler med 503. Nettstedet fungerer ofte igjen noen minutter senere, og feiler så på nytt ved neste topp.
Planlagt vedlikehold
Mange systemer returnerer 503 med vilje under vedlikehold. WordPress gjør det mens oppdateringer installeres: det skriver en .maintenance-fil og viser en kort «Briefly unavailable for scheduled maintenance»-side med status 503. Hvis en oppdatering blir avbrutt, kan filen bli liggende igjen, og nettstedet fortsetter å returnere 503 til noen sletter den.
Stoppet applikasjonsprosess eller app pool
På Windows-servere med IIS gir en stoppet eller krasjet application pool den klassiske meldingen «HTTP Error 503. The service is unavailable.» Poolen kan stoppe på grunn av gjentatte krasj, feil passord for identiteten eller en konfigurasjonsendring. På Linux er det tilsvarende en Node-, Python- eller Java-prosess som har avsluttet, slik at reverse proxyen ikke har noe å sende videre til.
PHP-FPM er tom for workers
PHP-nettsteder bak nginx eller Apache kjører som regel PHP-FPM med et fast antall worker-prosesser, satt med pm.max_children. Når alle workers er opptatt, for eksempel fordi hver forespørsel venter på en treg databasespørring eller et eksternt API, havner nye forespørsler i kø. Avhengig av oppsettet får den besøkende en 503, en 502 eller en 504. PHP-FPM-loggen viser om dette skjer:
WARNING: [pool www] server reached pm.max_children setting (10), consider raising it
Rate limiting
Rate limiting beskytter en server mot misbruk, men gir også ekte brukere feil hvis grensene er satt for stramt. nginx returnerer som standard 503 når en forespørsel overskrider en limit_req-sone. Brannmurer for webapplikasjoner og enkelte hostingplattformer gjør det samme. Hvis ett kontor, én API-klient eller én overvåkingstjeneste deler IP-adresse med mange brukere, kan de nå grensen sammen.
Upstream eller backend er nede
Lastbalanserere og reverse proxyer returnerer 503 når de ikke har noen frisk server å sende trafikken til. Hvis helsesjekkene merker alle backender som usunne, etter en mislykket deploy eller fordi databasen er nede og helseendepunktet melder det, svarer proxyen 503 på alle forespørsler.
Problemer med CDN og origin-server
Hvis nettstedet ditt ligger bak et CDN, kan 503-feilen komme fra CDN-et i stedet for serveren din. CDN-et kan returnere den når origin-serveren er overbelastet eller utilgjengelig, eller når selve CDN-et har problemer i én region. Svarheaderne forteller som regel hvem som svarte: se etter CDN-ets egen server-header eller forespørsels-ID, og sammenlign med en forespørsel sendt rett til origin-serveren.
Slik finner du årsaken
Begynn med selve svaret. Be om URL-en som feiler, og se på headerne:
curl -sS -o /dev/null -D – https://northwind.shop/checkout
Server-headeren og eventuelle CDN-spesifikke headere viser hvilket lag som svarte. En Retry-After-header tyder på bevisst vedlikehold. Jobb deg deretter innover:
Sjekk om det gjelder overalt. Feiler forsiden også, eller bare én sti? Én enkelt sti peker mot én rute i applikasjonen eller én worker-pool; feiler alt, peker det mot serveren eller proxyen.
Les feilloggen til webserveren. nginx og Apache logger upstream-feil, avvisninger fra rate limiting og tilkoblingsfeil med tidsstempel.
Les loggen til applikasjonen eller PHP-FPM. Se etter max_children-advarsler, krasj, prosesser drept på grunn av tomt minne og spor etter trege forespørsler.
Sjekk serverressursene. CPU, last, minne og swap i øyeblikket feilen oppstod. En server som swapper, er en server som svarer tregt, og trege svar fyller opp worker-pooler.
Sjekk avhengighetene. Svarer databasen? Kjører hurtigbufferen? Svarer et eksternt API du kaller synkront, tregt?
Sjekk nylige endringer. En deploy, en plugin-oppdatering, en konfigurasjonsendring eller en ny rate limit rundt tidspunktet feilene startet, er den mest sannsynlige årsaken.
Slik løser du en 503
Løsningen følger årsaken. Her er de vanligste, i den rekkefølgen de fleste team møter dem.
Vedlikeholdsmodus som henger: fjern .maintenance-filen i WordPress-roten, eller slå av vedlikeholdsflagget i rammeverket ditt, og fullfør eller prøv oppdateringen på nytt.
Overbelastning fra ekte trafikk: mellomlagre det du kan i CDN-et og i applikasjonen, slik at de fleste forespørsler aldri når PHP eller databasen. Legg deretter til kapasitet: flere workers hvis minnet tillater det, en større server eller flere servere bak lastbalansereren.
Overbelastning fra boter: finn brukeragentene og IP-områdene i tilgangsloggen, og begrens eller blokker dem i CDN-et eller brannmuren før de når applikasjonen.
PHP-FPM-workers: hev pm.max_children bare så langt minnet tillater. Regn ut gjennomsnittlig minnebruk for én worker, og del minnet du har til overs på det. Hvis workers er opptatt på grunn av trege spørringer, bør du rette spørringene først, ellers flytter du bare flaskehalsen.
Stoppet app pool eller prosess: start den på nytt, og finn så ut hvorfor den stoppet. Sjekk hendelsesloggen eller systemjournalen for krasj, og sett opp en prosessbehandler som starter tjenesten på nytt automatisk.
For strenge grenser for rate limiting: hev grensen eller burst-størrelsen, unnta kjente IP-adresser som kontoret ditt eller overvåkingstjenesten din, og returner 429 i stedet for 503 til klienter som begrenses, slik at årsaken er tydelig i loggene.
Usunne backender: sjekk hva helsesjekken til lastbalansereren ber om, og hvorfor den feiler. Rull tilbake en mislykket deploy først, og undersøk etterpå.
Her er en typisk endring i en PHP-FPM-pool for en server med plass til flere workers. Tallene er et eksempel, ikke en anbefaling for 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
Det er slow-loggen som er nyttig: den viser hvilke skript som holder workers lengst, og det er der du bør lete videre.
Bruk Retry-After ved planlagt vedlikehold
Når du tar ned et nettsted med vilje, bør du returnere 503 med en Retry-After-header. Den forteller nettlesere, API-klienter og søkemotorenes crawlere at nedetiden er midlertidig, og når de kan komme tilbake. Verdien er enten et antall 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 enkel vedlikeholdsbryter se slik ut:
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 gjør planlagt vedlikehold smertefritt. Returner 503, aldri 200 med en «snart tilbake»-side, fordi en 200 forteller crawlere og overvåking at vedlikeholdssiden er det egentlige innholdet ditt. Og hold det kort: en 503 i en time er greit, en 503 i flere dager kan føre til at sider faller ut av søkeresultatene.
Gi kundene beskjed på forhånd også. En melding på statussiden din svarer på «er det bare meg?» før noen spør.
Slik fanger overvåking opp 503-feil
En 503 kommer og går ofte. Nettstedet feiler i to minutter på toppen av en kampanje, kommer seg, og feiler igjen en time senere. Ingen i teamet ser det, for når noen åpner nettstedet, fungerer det. Kundene så det likevel.
En HTTP-overvåking ber om sidene dine etter en fast plan og registrerer statuskoden og responstiden for hver sjekk. En 503 er en mislykket sjekk. God overvåking gjør deretter tre ting:
Bekrefter feilen. En ny sjekk utelukker et enkeltstående blaff, og en sjekk fra en annen lokasjon utelukker også et problem på én nettverksvei. Uptimecheck sjekker fra Stockholm, London og New York, og bekrefter hver feil fra en annen lokasjon før en hendelse åpnes.
Varsler de rette personene. Varselet inneholder statuskoden, URL-en og når det startet, slik at den som tar det, vet at det er en 503 og ikke en DNS-feil. I Uptimecheck inneholder hendelsen også svaret som feilet og et skjermbilde, så du ser feilsiden de besøkende så, eller en traceroute når serveren ikke svarte i det hele tatt. Se varsler og varslinger for kanalene.
Registrerer mønsteret. Hendelseshistorikken viser om 503-feilene samler seg rundt trafikktopper, deployer eller nattlige jobber, og det forteller deg hvilken løsning du bør prøve først.
Overvåk mer enn forsiden. Forsiden ligger ofte i hurtigbufferen og fortsetter å fungere mens kassen, innloggingen eller API-et feiler. Legg til oppetidsovervåking for sidene som tjener penger, og følg med på utviklingen i responstid: en side som blir tregere hver dag på samme tid, er ofte en 503 som bare venter på å skje. Guiden vår om hva som er en god responstid for et nettsted forklarer hva du bør se etter.
Servermålinger fullfører bildet. Når et 503-varsel kommer, er det første spørsmålet om serveren gikk tom for CPU, minne eller disk. Med serverovervåking ved siden av oppetidssjekkene ser du årsaken og symptomet side om side.
Sjekkliste for 503-feil
Se på svarheaderne for å finne ut hvilket lag som returnerte 503-feilen.
Sjekk loggene til webserveren, applikasjonen og PHP-FPM for samme tidsstempel.
Sjekk CPU, minne, swap og disk på serveren.
Se etter deployer, oppdateringer og konfigurasjonsendringer rett før feilene startet.
Rett årsaken: mellomlagring, flere workers, en omstartet prosess, en romsligere rate limit eller en frisk backend.
Bruk 503 med Retry-After ved planlagt vedlikehold, aldri 200.
Overvåk viktige sider hvert minutt, og bekreft hver feil med en ny sjekk før du varsler.
Oppsummering
En 503 betyr at serveren er der, men ikke kan betjene deg akkurat nå. Det er et problem med kapasitet eller tilgjengelighet, ikke en ødelagt side, og loggene for samme tidsstempel peker som regel rett på årsaken. Rett årsaken i stedet for symptomet, bruk Retry-After når nedetiden er planlagt, og la overvåkingen fortelle deg om korte 503-feil du ellers aldri ville sett.
Uptimecheck overvåker nettsteder, API-er og servere i én konto og varsler deg når en side begynner å returnere 503. Start den gratis prøveperioden på 14 dager, uten kredittkort.