Ett 503 Service Unavailable-fel betyder att webbservern tog emot förfrågan men inte kan hantera den just nu. Servern går att nå, så DNS och nätverket fungerar, men applikationen bakom är överbelastad, under underhåll eller kan inte nå en tjänst den är beroende av. En 503 är tänkt att vara tillfällig. Varar den mer än några minuter behöver något åtgärdas: oftast för mycket trafik, för få workers, en stoppad applikationsprocess eller en backend som ligger nere.
Den här guiden förklarar vad som utlöser en 503, hur du hittar orsaken på din egen server, hur du åtgärdar var och en och hur du ser till att du får veta om nästa innan dina kunder gör det.
Vad en 503 faktiskt berättar
HTTP-statuskoder i 5xx-serien betyder att servern fallerade, inte besökaren. Inom den familjen har 503 en specifik betydelse: tjänsten är otillgänglig för tillfället och klienten kan försöka igen senare. Jämför med grannarna:
500 Internal Server Error: applikationen kraschade när den hanterade förfrågan.
502 Bad Gateway: en proxy eller lastbalanserare fick ett ogiltigt svar från servern bakom den.
503 Service Unavailable: servern, eller något framför den, vägrar behandla förfrågan eftersom den är överbelastad, under underhåll eller inte har något friskt att skicka den till.
504 Gateway Timeout: en proxy väntade på servern bakom den och gav upp.
Skillnaden spelar roll eftersom den visar var du ska leta. En 503 är sällan en bugg på en enskild sida. Den handlar nästan alltid om kapacitet eller tillgänglighet för en hel tjänst. För en fullständig översikt över koderna och vilka en övervakare bör räkna som nere, se vår fusklapp över HTTP-statuskoder för övervakning.
Vanliga orsaker till en 503
Trafiktoppar och överbelastning
Varje server klarar ett begränsat antal förfrågningar samtidigt. Ett kampanjmejl, ett omnämnande i sociala medier eller en bot som crawlar tusentals sidor kan trycka den över gränsen. När kön är full börjar webbservern eller applikationen neka nya förfrågningar med 503. Sajten fungerar ofta igen några minuter senare och fallerar sedan på nytt vid nästa topp.
Planerat underhåll
Många system returnerar 503 med flit under underhåll. WordPress gör det medan uppdateringar installeras: det skriver en .maintenance-fil och visar en kort sida med texten ”Briefly unavailable for scheduled maintenance” och status 503. Om en uppdatering avbryts kan filen bli kvar, och sajten fortsätter svara 503 tills någon tar bort den.
Stoppad applikationsprocess eller app pool
På Windows-servrar med IIS ger en stoppad eller kraschad application pool det klassiska ”HTTP Error 503. The service is unavailable.” Poolen kan stoppas av upprepade krascher, ett felaktigt lösenord för identiteten eller en konfigurationsändring. På Linux motsvaras det av en Node-, Python- eller Java-process som har avslutats, så att reverse proxyn inte har något att skicka vidare till.
PHP-FPM har slut på workers
PHP-sajter bakom nginx eller Apache kör oftast PHP-FPM med ett fast antal worker-processer, satt med pm.max_children. När alla workers är upptagna, till exempel för att varje förfrågan väntar på en långsam databasfråga eller ett externt API, hamnar nya förfrågningar i kö. Beroende på uppsättningen får besökaren en 503, en 502 eller en 504. PHP-FPM-loggen visar om det är det som händer:
WARNING: [pool www] server reached pm.max_children setting (10), consider raising it
Rate limiting
Rate limits skyddar en server mot missbruk, men de ger fel även till riktiga användare om de är för snävt satta. nginx returnerar som standard 503 när en förfrågan överskrider en limit_req-zon. Brandväggar för webbapplikationer och vissa hostingplattformar gör likadant. Om ett kontor, en API-klient eller en övervakningstjänst delar IP-adress med många användare kan de nå gränsen tillsammans.
Uppströmsserver eller backend nere
Lastbalanserare och reverse proxies returnerar 503 när de inte har någon frisk server att skicka trafik till. Om hälsokontrollerna markerar varje backend som ohälsosam, efter en dålig deploy eller för att databasen ligger nere och hälsoendpointen rapporterar det, svarar proxyn 503 på varje förfrågan.
Problem med CDN och origin-server
Om din sajt ligger bakom ett CDN kan 503-felet komma från CDN:et snarare än från din server. CDN:et kan returnera det när din origin-server är överbelastad eller inte går att nå, eller när CDN:et självt har problem i en region. Svarshuvudena visar oftast vem som svarade: leta efter CDN:ets eget server-huvud eller förfrågnings-id och jämför med en förfrågan som skickas direkt till origin-servern.
Så hittar du orsaken
Börja med själva svaret. Anropa adressen som fallerar och titta på huvudena:
curl -sS -o /dev/null -D – https://northwind.shop/checkout
Huvudet Server och eventuella CDN-specifika huvuden visar vilket lager som svarade. Ett Retry-After-huvud tyder på avsiktligt underhåll. Arbeta dig sedan inåt:
Kontrollera om felet finns överallt. Fallerar startsidan också, eller bara en sökväg? En enda sökväg pekar på en route eller worker-pool i applikationen; fallerar allt pekar det på servern eller proxyn.
Läs webbserverns fellogg. nginx och Apache loggar uppströmsfel, nekanden från rate limits och anslutningsfel med tidsstämplar.
Läs applikationens eller PHP-FPM:s logg. Leta efter varningar om max_children, krascher, processer som dödats för att minnet tagit slut och spår av långsamma förfrågningar.
Kontrollera serverns resurser. CPU, last, minne och swap när felet inträffade. En server som swappar är en server som svarar långsamt, och långsamma svar fyller worker-pooler.
Kontrollera beroenden. Svarar databasen? Körs cachen? Svarar ett externt API som du anropar synkront långsamt?
Kontrollera nyliga ändringar. En deploy, en plugin-uppdatering, en konfigurationsändring eller en ny rate limit kring tiden då felen började är den troligaste orsaken.
Så åtgärdar du en 503
Lösningen följer orsaken. Här är de vanliga i den ordning de flesta team stöter på dem.
Underhållsläge som fastnat: ta bort .maintenance-filen i WordPress rotkatalog, eller slå av ramverkets underhållsflagga, och slutför eller gör om uppdateringen.
Överbelastning från riktig trafik: cacha det du kan i CDN:et och i applikationen, så att de flesta förfrågningar aldrig når PHP eller databasen. Lägg sedan till kapacitet: fler workers om minnet räcker, en större server eller fler servrar bakom lastbalanseraren.
Överbelastning från botar: identifiera user agents och IP-intervall i accessloggen och begränsa eller blockera dem i CDN:et eller brandväggen, innan de når applikationen.
PHP-FPM-workers: höj pm.max_children bara så långt minnet räcker. Räkna ut genomsnittligt minne för en worker och dela minnet du kan avvara med det. Om workerna är upptagna på grund av långsamma frågor, rätta frågorna först, annars flyttar du bara flaskhalsen.
Stoppad app pool eller process: starta om den och ta sedan reda på varför den stannade. Kontrollera händelseloggen eller systemjournalen efter krascher och sätt upp en processhanterare som startar om tjänsten automatiskt.
För strikta rate limits: höj gränsen eller burst-storleken, undanta kända IP-adresser som ditt kontor eller din övervakningstjänst, och returnera 429 i stället för 503 för begränsade klienter så att orsaken syns tydligt i loggarna.
Ohälsosamma backends: kontrollera vad lastbalanserarens hälsokontroll anropar och varför den fallerar. Rulla tillbaka en dålig deploy först och undersök efteråt.
Här är en typisk ändring av en PHP-FPM-pool för en server som har utrymme för fler workers. Siffrorna är ett exempel, inte en rekommendation för 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 är slowloggen som är användbar: den visar vilka skript som håller workers längst, och det är där du ska titta härnäst.
Använd Retry-After vid planerat underhåll
När du tar ner en sajt med flit, returnera 503 med ett Retry-After-huvud. Det talar om för webbläsare, API-klienter och sökmotorernas crawlers att avbrottet är tillfälligt och när de ska komma tillbaka. Värdet är antingen ett antal sekunder eller ett HTTP-datum:
HTTP/1.1 503 Service Unavailable
Retry-After: 1800
Content-Type: text/html; charset=utf-8
I nginx kan en enkel underhållsbrytare se ut så här:
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;
}
Två regler gör planerat underhåll smärtfritt. Returnera 503, aldrig 200 med en ”tillbaka snart”-sida, eftersom en 200 säger till crawlers och övervakare att underhållssidan är ditt riktiga innehåll. Och håll det kort: en 503 i en timme är okej, en 503 i flera dagar riskerar att sidor försvinner ur sökresultaten.
Meddela kunderna i förväg också. En notis på din statussida besvarar ”är det bara jag?” innan någon hinner fråga.
Så fångar övervakning 503-fel
En 503 kommer och går ofta. Sajten fallerar i två minuter på toppen av en kampanj, återhämtar sig och fallerar igen en timme senare. Ingen i teamet ser det, för när någon öppnar sajten fungerar den. Men kunderna såg det.
En HTTP-övervakare hämtar dina sidor enligt ett schema och registrerar statuskod och svarstid för varje kontroll. En 503 är en misslyckad kontroll. Bra övervakning gör sedan tre saker:
Bekräftar felet. En andra kontroll utesluter en tillfällig blipp, och en kontroll från en annan plats utesluter också ett problem på en enskild nätverksväg. Uptimecheck kontrollerar från Stockholm, London och New York och bekräftar varje fel från en andra plats innan en incident öppnas.
Larmar rätt personer. Larmet innehåller statuskoden, adressen och när felet började, så att den som tar det vet att det är en 503 och inte ett DNS-fel. I Uptimecheck innehåller incidenten också svaret som fallerade och en skärmbild, så att du ser felsidan dina besökare såg, eller en traceroute när servern inte svarade alls. Se larm och aviseringar för kanalerna.
Visar mönstret. Incidenthistoriken visar om 503-felen samlas kring trafiktoppar, deployer eller nattliga jobb, och det talar om vilken lösning du ska prova först.
Övervaka mer än startsidan. Startsidan cachas ofta och fortsätter fungera medan kassan, inloggningen eller API:et fallerar. Lägg till upptidsövervakare för sidorna som drar in pengar och håll koll på hur svarstiden utvecklas: en sida som blir långsam varje dag vid samma tid är ofta en 503 som bara väntar på att hända. Vår guide om vad som är en bra svarstid för en webbplats förklarar vad du ska titta efter.
Servermätvärden sluter cirkeln. När ett 503-larm kommer är den första frågan om servern fick slut på CPU, minne eller disk. Med serverövervakning bredvid dina upptidskontroller ser du orsaken och symtomet sida vid sida.
Checklista för 503-fel
Titta på svarshuvudena för att se vilket lager som returnerade 503-felet.
Kontrollera webbserverns, applikationens och PHP-FPM:s loggar för samma tidsstämpel.
Kontrollera CPU, minne, swap och disk på servern.
Leta efter deployer, uppdateringar och konfigurationsändringar strax innan felen började.
Åtgärda orsaken: cachning, fler workers, en omstartad process, en mindre strikt rate limit eller en frisk backend.
Använd 503 med Retry-After vid planerat underhåll, aldrig 200.
Övervaka viktiga sidor varje minut och bekräfta varje fel med en andra kontroll innan du larmar.
Sammanfattning
En 503 betyder att servern finns där men inte kan betjäna dig just nu. Det är ett problem med kapacitet eller tillgänglighet, inte en trasig sida, och loggarna vid samma tidsstämpel pekar oftast rakt på orsaken. Åtgärda orsaken i stället för symtomet, använd Retry-After när nertiden är planerad och låt övervakningen berätta om korta 503-fel som du annars aldrig skulle se.
Uptimecheck övervakar webbplatser, API:er och servrar i ett och samma konto och larmar dig när en sida börjar returnera 503. Starta din kostnadsfria provperiod på 14 dagar, inget kreditkort krävs.