503 Service Unavailable -virhe tarkoittaa, että verkkopalvelin vastaanotti pyynnön mutta ei pysty käsittelemään sitä juuri nyt. Palvelin on tavoitettavissa, joten DNS ja verkko toimivat, mutta sen takana oleva sovellus on ylikuormittunut, huoltotilassa tai ei tavoita palvelua, josta se on riippuvainen. 503 on tarkoitettu tilapäiseksi. Jos se kestää muutamaa minuuttia pidempään, jokin on korjattava: yleensä liian suuri liikenne, liian vähän workereita, pysähtynyt sovellusprosessi tai alhaalla oleva taustajärjestelmä.
Tämä opas kertoo, mikä laukaisee 503-virheen, miten löydät syyn omalta palvelimeltasi, miten korjaat kunkin syyn ja miten varmistat, että kuulet seuraavasta ennen asiakkaitasi.
Mitä 503-virhe oikeastaan kertoo
5xx-alueen HTTP-tilakoodit tarkoittavat, että vika on palvelimessa, ei kävijässä. Tässä joukossa 503:lla on tarkka merkitys: palvelu ei ole toistaiseksi käytettävissä, ja asiakas voi yrittää myöhemmin uudelleen. Vertaa sitä naapureihinsa:
500 Internal Server Error: sovellus kaatui pyyntöä käsitellessään.
502 Bad Gateway: välityspalvelin tai kuormantasaaja sai virheellisen vastauksen takanaan olevalta palvelimelta.
503 Service Unavailable: palvelin tai jokin sen edessä kieltäytyy käsittelemästä pyyntöä, koska se on ylikuormittunut, huoltotilassa tai sillä ei ole toimivaa kohdetta, jolle pyynnön voisi lähettää.
504 Gateway Timeout: välityspalvelin odotti takanaan olevaa palvelinta ja luovutti.
Ero on tärkeä, koska se kertoo, mistä etsiä. 503 on harvoin yksittäisen sivun bugi. Se liittyy lähes aina koko palvelun kapasiteettiin tai saatavuuteen. Kattava yleiskatsaus koodeista ja siitä, mitkä niistä valvonnan kannattaa tulkita katkoksi, löytyy HTTP-tilakoodien lunttilapustamme valvontaan.
503-virheen yleiset syyt
Liikennepiikit ja ylikuormitus
Jokainen palvelin pystyy käsittelemään vain rajallisen määrän pyyntöjä kerrallaan. Kampanjasähköposti, maininta sosiaalisessa mediassa tai tuhansia sivuja läpikäyvä botti voi ylittää tämän rajan. Kun jono on täynnä, verkkopalvelin tai sovellus alkaa hylätä uusia pyyntöjä 503-koodilla. Sivusto toimii usein taas muutaman minuutin kuluttua ja kaatuu uudelleen seuraavassa piikissä.
Suunniteltu huolto
Monet järjestelmät palauttavat 503-koodin tarkoituksella huollon aikana. WordPress tekee niin päivityksiä asentaessaan: se kirjoittaa .maintenance-tiedoston ja näyttää lyhyen ”Briefly unavailable for scheduled maintenance” -sivun tilakoodilla 503. Jos päivitys keskeytyy, tiedosto voi jäädä paikalleen, ja sivusto palauttaa 503-koodia, kunnes joku poistaa sen.
Pysähtynyt sovellusprosessi tai sovelluspooli
IIS:ää ajavilla Windows-palvelimilla pysähtynyt tai kaatunut sovelluspooli tuottaa klassisen ilmoituksen ”HTTP Error 503. The service is unavailable.” Pooli voi pysähtyä toistuvien kaatumisten, identiteetin väärän salasanan tai asetusmuutoksen vuoksi. Linuxissa vastaava tilanne on Node-, Python- tai Java-prosessi, joka on päättynyt, jolloin käänteisellä välityspalvelimella ei ole minne välittää pyyntöjä.
PHP-FPM:n workerit loppuvat
nginxin tai Apachen takana olevat PHP-sivustot ajavat yleensä PHP-FPM:ää kiinteällä määrällä worker-prosesseja, jonka asetus pm.max_children määrää. Kun jokainen worker on varattuna, esimerkiksi koska jokainen pyyntö odottaa hidasta tietokantakyselyä tai ulkoista API:a, uudet pyynnöt jonottavat. Kokoonpanosta riippuen kävijä saa 503-, 502- tai 504-virheen. PHP-FPM:n loki kertoo, onko näin käymässä:
WARNING: [pool www] server reached pm.max_children setting (10), consider raising it
Pyyntörajoitus
Pyyntörajat suojaavat palvelinta väärinkäytöltä, mutta liian tiukoiksi asetettuina ne palauttavat virheitä myös oikeille käyttäjille. nginx palauttaa oletuksena 503-koodin, kun pyyntö ylittää limit_req-vyöhykkeen. Verkkosovellusten palomuurit ja jotkin hosting-alustat tekevät samoin. Jos yksi toimisto, yksi API-asiakas tai yksi valvontapalvelu jakaa IP-osoitteen monen käyttäjän kanssa, he voivat yhdessä osua rajaan.
Taustapalvelin tai taustajärjestelmä alhaalla
Kuormantasaajat ja käänteiset välityspalvelimet palauttavat 503-koodin, kun niillä ei ole toimivaa palvelinta, jolle liikenteen voisi ohjata. Jos terveystarkistukset merkitsevät jokaisen taustapalvelimen epäkuntoiseksi, epäonnistuneen julkaisun jälkeen tai koska tietokanta on alhaalla ja health-päätepiste ilmoittaa siitä, välityspalvelin vastaa jokaiseen pyyntöön 503-koodilla.
CDN- ja alkuperäpalvelinongelmat
Jos sivustosi on CDN:n takana, 503-virhe voi tulla CDN:ltä eikä palvelimeltasi. CDN voi palauttaa sen, kun alkuperäpalvelimesi on ylikuormittunut tai tavoittamattomissa tai kun CDN:llä itsellään on ongelmia jollakin alueella. Vastausotsakkeet kertovat yleensä, kuka vastasi: etsi CDN:n oma server-otsake tai pyyntötunniste ja vertaa suoraan alkuperäpalvelimelle lähetettyyn pyyntöön.
Näin löydät syyn
Aloita itse vastauksesta. Pyydä epäonnistuvaa URL-osoitetta ja katso otsakkeita:
curl -sS -o /dev/null -D – https://northwind.shop/checkout
Server-otsake ja mahdolliset CDN-kohtaiset otsakkeet näyttävät, mikä kerros vastasi. Retry-After-otsake viittaa tarkoitukselliseen huoltoon. Etene sitten sisäänpäin:
Tarkista, näkyykö virhe kaikkialla. Kaatuuko myös etusivu vai vain yksi polku? Yksittäinen polku viittaa yhteen sovelluksen reittiin tai worker-pooliin; jos kaikki kaatuu, syy on palvelimessa tai välityspalvelimessa.
Lue verkkopalvelimen virheloki. nginx ja Apache kirjaavat taustapalvelinvirheet, pyyntörajojen hylkäykset ja yhteysvirheet aikaleimoineen.
Lue sovelluksen tai PHP-FPM:n loki. Etsi max_children-varoituksia, kaatumisia, muistin loppumisesta johtuvia lopetuksia ja hitaiden pyyntöjen jälkiä.
Tarkista palvelimen resurssit. Suoritin, kuorma, muisti ja swap virheen hetkellä. Swappaava palvelin vastaa hitaasti, ja hitaat vastaukset täyttävät worker-poolit.
Tarkista riippuvuudet. Vastaako tietokanta? Onko välimuisti käynnissä? Vastaako synkronisesti kutsumasi ulkoinen API hitaasti?
Tarkista viimeaikaiset muutokset. Julkaisu, lisäosan päivitys, asetusmuutos tai uusi pyyntöraja virheiden alkamisen aikoihin on todennäköisin syy.
Näin korjaat 503-virheen
Korjaus riippuu syystä. Tässä yleisimmät siinä järjestyksessä, jossa useimmat tiimit kohtaavat ne.
Jumiin jäänyt huoltotila: poista .maintenance-tiedosto WordPressin juurihakemistosta tai kytke sovelluskehyksesi huoltotila pois päältä ja vie päivitys sitten loppuun tai yritä uudelleen.
Todellisen liikenteen aiheuttama ylikuormitus: tallenna välimuistiin reunalla ja sovelluksessa kaikki mahdollinen, jotta useimmat pyynnöt eivät koskaan päädy PHP:lle tai tietokantaan. Lisää sitten kapasiteettia: enemmän workereita, jos muisti riittää, isompi palvelin tai lisää palvelimia kuormantasaajan taakse.
Bottien aiheuttama ylikuormitus: tunnista käyttäjäagentit ja IP-alueet käyttölokistasi ja rajoita tai estä ne CDN:ssä tai palomuurissa ennen kuin ne saavuttavat sovelluksen.
PHP-FPM:n workerit: nosta pm.max_children-arvoa vain niin paljon kuin muisti sallii. Laske yhden workerin keskimääräinen muistinkulutus ja jaa sillä muisti, jonka voit antaa käyttöön. Jos workerit ovat varattuina hitaiden kyselyjen vuoksi, korjaa kyselyt ensin, muuten vain siirrät pullonkaulaa.
Pysähtynyt sovelluspooli tai prosessi: käynnistä se uudelleen ja selvitä sitten, miksi se pysähtyi. Etsi kaatumisia tapahtumalokista tai järjestelmän journalista ja ota käyttöön prosessinhallinta, joka käynnistää palvelun automaattisesti uudelleen.
Liian tiukat pyyntörajat: nosta rajaa tai purskekokoa, vapauta tunnetut IP-osoitteet, kuten toimistosi tai valvontapalvelusi, ja palauta rajoitetuille asiakkaille 429 eikä 503, jotta syy näkyy lokeissa selvästi.
Epäkuntoiset taustapalvelimet: tarkista, mitä kuormantasaajan terveystarkistus pyytää ja miksi se epäonnistuu. Peru epäonnistunut julkaisu ensin ja tutki vasta sitten.
Tässä tyypillinen PHP-FPM-poolin muutos palvelimelle, jolla on tilaa useammalle workerille. Luvut ovat esimerkki, eivät suositus juuri sinun palvelimellesi:
; /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
Hyödyllisin osa on slow log: se näyttää, mitkä skriptit pitävät workereita varattuina pisimpään, ja juuri sieltä kannattaa jatkaa.
Käytä Retry-After-otsaketta suunniteltujen huoltojen aikana
Kun otat sivuston tarkoituksella pois käytöstä, palauta 503 ja Retry-After-otsake. Se kertoo selaimille, API-asiakkaille ja hakukoneiden indeksoijille, että katko on tilapäinen ja milloin kannattaa palata. Arvo on joko sekuntimäärä tai HTTP-päivämäärä:
HTTP/1.1 503 Service Unavailable
Retry-After: 1800
Content-Type: text/html; charset=utf-8
nginxissä yksinkertainen huoltokytkin voi näyttää tältä:
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;
}
Kaksi sääntöä tekee suunnitellusta huollosta kivuttoman. Palauta 503, älä koskaan 200 ja ”palaamme pian” -sivua, koska 200 kertoo indeksoijille ja valvonnalle, että huoltosivu on oikeaa sisältöäsi. Ja pidä huolto lyhyenä: tunnin 503 on kunnossa, päiviä kestävä 503 voi pudottaa sivuja hakutuloksista.
Kerro asiakkaille myös etukäteen. Ilmoitus tilasivullasi vastaa kysymykseen ”onko vika vain minulla?” ennen kuin kukaan ehtii kysyä.
Miten valvonta havaitsee 503-virheet
503-virhe tulee ja menee usein. Sivusto kaatuu kahdeksi minuutiksi kampanjan huippuhetkellä, toipuu ja kaatuu taas tuntia myöhemmin. Kukaan tiimistä ei huomaa sitä, koska kun joku avaa sivuston, se toimii. Asiakkaat kuitenkin näkivät sen.
HTTP-valvonta pyytää sivujasi aikataulun mukaan ja tallentaa jokaisen tarkistuksen tilakoodin ja vasteajan. 503-virhe on epäonnistunut tarkistus. Hyvä valvonta tekee sen jälkeen kolme asiaa:
Varmistaa virheen. Toinen tarkistus sulkee pois kertaluonteisen häiriön, ja tarkistus toisesta sijainnista sulkee pois myös yksittäisen verkkoreitin ongelman. Uptimecheck tarkistaa Tukholmasta, Lontoosta ja New Yorkista ja varmistaa jokaisen virheen toisesta sijainnista ennen kuin häiriö avataan.
Hälyttää oikeat ihmiset. Hälytyksessä ovat tilakoodi, URL-osoite ja alkamisaika, joten sen vastaanottaja tietää, että kyse on 503-virheestä eikä DNS-virheestä. Uptimecheckissä häiriön mukana tulevat myös epäonnistunut vastaus ja kuvakaappaus, joten näet saman virhesivun kuin kävijäsi, tai traceroute, kun palvelin ei vastannut lainkaan. Kanavat löydät sivulta hälytykset ja ilmoitukset.
Tallentaa toistuvan kuvion. Häiriöhistoria näyttää, kasautuvatko 503-virheet liikennepiikkien, julkaisujen vai yöllisten ajojen ympärille, mikä kertoo, mikä korjaus kannattaa kokeilla ensin.
Valvo muutakin kuin etusivua. Etusivu on usein välimuistissa ja toimii yhä, vaikka kassa, kirjautuminen tai API kaatuvat. Lisää käytettävyysvalvonta sivuille, jotka tuovat rahaa, ja seuraa vasteajan kehitystä: sivu, joka hidastuu joka päivä samaan aikaan, on usein tuleva 503-virhe. Oppaamme siitä, millainen on hyvä verkkosivuston vasteaika, kertoo, mihin kannattaa kiinnittää huomiota.
Palvelinmittarit täydentävät kuvan. Kun 503-hälytys saapuu, ensimmäinen kysymys on, loppuiko palvelimelta suoritinteho, muisti vai levytila. Kun palvelinvalvonta toimii käytettävyystarkistusten rinnalla, näet syyn ja oireen vierekkäin.
503-virheen tarkistuslista
Katso vastausotsakkeista, mikä kerros palautti 503-virheen.
Tarkista verkkopalvelimen, sovelluksen ja PHP-FPM:n lokit samalta ajanhetkeltä.
Tarkista palvelimen suoritin, muisti, swap ja levy.
Etsi julkaisuja, päivityksiä ja asetusmuutoksia juuri ennen virheiden alkamista.
Korjaa syy: välimuisti, lisää workereita, uudelleen käynnistetty prosessi, löysempi pyyntöraja tai toimiva taustapalvelin.
Käytä suunnitelluissa huolloissa 503-koodia ja Retry-After-otsaketta, älä koskaan 200-koodia.
Valvo tärkeitä sivuja minuutin välein ja varmista jokainen virhe toisella tarkistuksella ennen hälytystä.
Yhteenveto
503 tarkoittaa, että palvelin on olemassa mutta ei pysty palvelemaan sinua juuri nyt. Kyse on kapasiteetti- tai saatavuusongelmasta, ei rikkinäisestä sivusta, ja saman ajanhetken lokit osoittavat yleensä suoraan syyn. Korjaa syy eikä oiretta, käytä Retry-After-otsaketta, kun katko on suunniteltu, ja anna valvonnan kertoa lyhyistä 503-virheistä, joita et muuten koskaan näkisi.
Uptimecheck valvoo verkkosivustoja, API-rajapintoja ja palvelimia yhdellä tilillä ja hälyttää, kun sivu alkaa palauttaa 503-virhettä. Aloita 14 päivän ilmainen kokeilu, luottokorttia ei tarvita.