500 Internal Server Error tarkoittaa, että palvelimella toimiva sovellus kohtasi vastausta muodostaessaan ongelman, jota se ei osannut käsitellä. Toisin kuin useimmat muut virheet, se ei kerro, mikä meni pieleen. Palvelin sanoo sillä käytännössä: ”jokin hajosi, enkä kerro kävijälle mikä”.
Varsinainen virheilmoitus on kuitenkin olemassa. Se löytyy lokista. Tämä opas näyttää, mistä sen löydät, mitkä syyt ovat useimpien 500-virheiden takana ja miten varmistat, että kuulet seuraavasta ensimmäisenä.
Mitä 500-virhe kertoo
500-virhe tulee sovellukselta itseltään tai sitä ajavalta verkkopalvelimelta. Se tarkoittaa, että pyyntö saavutti koodisi ja koodi epäonnistui: kukaan ei napannut poikkeusta, tapahtui fataali virhe tai palvelin ei pystynyt lukemaan asetuksia. Siksi se eroaa yhdyskäytävävirheistä, joissa ongelma on kahden palvelimen välissä:
500 Internal Server Error: sovellus epäonnistui pyyntöä käsitellessään.
502 Bad Gateway: välityspalvelin sai sovellukselta virheellisen vastauksen. Lue 502-oppaamme.
503 Service Unavailable: palvelu on ylikuormittunut tai huoltotilassa. Lue 503-oppaamme.
504 Gateway Timeout: sovellus vastasi liian hitaasti. Lue 504-oppaamme.
Jos 500-virhe näkyy yhdellä sivulla, syy on yleensä sen sivun koodissa. Jos se näkyy kaikilla sivuilla, jokin yhteinen on yleensä rikki: asetukset, tietokantayhteys tai tiedosto, jonka koko sovellus lataa.
Aloita siitä, mikä muuttui
Useimmat 500-virheet ilmestyvät heti jonkin muutoksen jälkeen. Ennen kuin luet yhtäkään lokia, kysy, mitä viimeisen tunnin aikana tapahtui:
Julkaisu tai yhdistäminen päähaaraan
Lisäosan, teeman, sovelluskehyksen tai ohjelmointikielen päivitys
Muutos asetustiedostoon, .htaccess-tiedostoon tai ympäristömuuttujiin
Vaihdettu salasana tai API-avain
Palvelin, jonka levy täyttyi tai jonka käyttöoikeuksia muutettiin
Jos ajoitus täsmää, muutoksen peruminen on usein nopein tapa saada sivusto takaisin. Etsi syy vasta sen jälkeen, ilman että asiakkaat katsovat vierestä.
Etsi varsinainen virheilmoitus
500-sivu on yleinen, loki on täsmällinen. Se, mistä etsit, riippuu käyttämästäsi teknologiasta:
# nginx and Apache
tail -n 50 /var/log/nginx/error.log
tail -n 50 /var/log/apache2/error.log
# PHP-FPM
tail -n 50 /var/log/php8.3-fpm.log
# Applications run by systemd
journalctl -u myapp –since ”15 min ago”
# Docker
docker logs –since 15m myapp
Etsi epäonnistuneen pyynnön aikaleima. Sen vieressä oleva merkintä kertoo yleensä tiedoston, rivin ja syyn: määrittelemätön funktio, puuttuva luokka tai tietokanta, joka hylkäsi salasanan.
WordPressissä ota virheloki käyttöön tiedostossa wp-config.php. Se kirjoittaa virheet tiedostoon wp-content/debug.log näyttämättä niitä kävijöille:
define( ’WP_DEBUG’, true );
define( ’WP_DEBUG_LOG’, true );
define( ’WP_DEBUG_DISPLAY’, false );
Poista se käytöstä, kun olet valmis, sillä loki voi kasvaa suureksi ja sisältää arkaluonteisia tietoja.
Yleiset syyt ja niiden korjaaminen
Virhe koodissa
Käsittelemätön poikkeus tai fataali virhe koodissa, joka muodostaa sivun. Loki näyttää tiedoston ja rivin. Tyypillisiä laukaisijoita ovat funktio, joka saa odottamatonta dataa, arvo, joka on yllättäen tyhjä, ja koodi, joka toimii kehittäjän koneella mutta tarvitsee PHP-laajennuksen tai kirjastoversion, jota palvelimella ei ole. Korjaa koodi tai palaa viimeiseen toimineeseen versioon.
Lisäosan tai teeman päivitys
WordPressissä ja muissa julkaisujärjestelmissä yleisin syy on lisäosan tai teeman päivitys. Loki kertoo lisäosan kansion nimen. Jos et pääse hallintapaneeliin, poista lisäosa käytöstä nimeämällä sen kansio uudelleen SSH:n tai SFTP:n kautta:
mv wp-content/plugins/some-plugin wp-content/plugins/some-plugin.disabled
Sivusto palaa ilman sitä. Päivitä lisäosa sitten uudelleen, vaihda se toiseen tai ota yhteyttä sen kehittäjään ja liitä mukaan lokin virhe.
Rikkinäinen .htaccess-tiedosto
Apachessa yksi virheellinen rivi .htaccess-tiedostossa kaataa koko sivuston 500-virheeseen. Virheloki sanoo Invalid command tai nimeää direktiivin, jota se ei ymmärtänyt. Testaa nimeämällä tiedosto uudelleen ja palauta rivit sitten yksi kerrallaan. WordPressissä kestolinkkiasetusten tallentaminen kirjoittaa uuden tiedoston.
PHP:n muisti loppuu
Allowed memory size of 134217728 bytes exhausted tarkoittaa, että pyyntö tarvitsi enemmän muistia kuin memory_limit sallii. Rajan nostaminen voi auttaa, mutta pyyntö, joka tarvitsee satoja megatavuja, lataa yleensä liikaa dataa kerralla. Selvitä, mitä se lataa, ennen kuin annat sille lisää.
Tiedostojen käyttöoikeudet ja omistajuus
Julkaisun, palautuksen tai käsin tehdyn kopioinnin jälkeen tiedostojen omistajana voi olla väärä käyttäjä. Verkkopalvelin ei silloin pysty lukemaan koodia tai kirjoittamaan välimuisti- ja latauskansioihinsa, ja loki sanoo Permission denied. Palauta omistajuus käyttäjälle, jona verkkopalvelin tai PHP toimii. Hakemistot tarvitsevat yleensä oikeudet 755 ja tiedostot 644; älä koskaan korjaa ongelmaa oikeuksilla 777.
Täysi levy
Kun levy on täynnä, sovellukset eivät pysty kirjoittamaan istuntoja, välimuistia, latauksia tai lokeja, ja ne kaatuvat tavoilla, jotka päättyvät 500-virheeseen. Tarkista vapaa tila ja inodet:
df -h
df -i
Tavallisia syyllisiä ovat vanhat lokit, varmuuskopiot ja välimuistit. Palvelinvalvonta, jossa levyhälytys laukeaa 80 tai 90 prosentin kohdalla, huomaa tämän päiviä ennen kuin sivusto hajoaa.
Tietokantayhteyden virheet
Vaihdettu salasana, kaatunut tietokantapalvelin tai täyttynyt yhteysraja. Sovellus ei pysty lataamaan mitään ja kaatuu jokaisella sivulla. Loki nimeää tietokantavirheen. Tarkista, että tietokanta on käynnissä, että asetusten tunnukset ovat ajan tasalla ja kuinka monta yhteyttä on auki suhteessa rajaan.
500-virhe, joka palauttaa 200
Kaikki rikkinäiset sivut eivät kerro siitä. Jotkin sovellukset nappaavat virheen ja näyttävät ystävällisen ”Jokin meni pieleen” -sivun tilakoodilla 200, ja julkaisujärjestelmä voi näyttää tyhjän tuotelistan valittamatta. Valvonnalle, joka katsoo vain tilakoodia, kaikki näyttää olevan kunnossa.
Tarkista siis myös sisältö. Käytettävyyden valvonta voi vaatia, että sivulla on sana, joka on aina näkyvissä sivun toimiessa, kuten tuotteen nimi tai ”Lisää ostoskoriin”, ja tulkita sen puuttumisen virheeksi. Tarkistuslistamme siitä, mitä kannattaa valvoa, kertoo, mitkä sivut ansaitsevat tällaisen tarkistuksen.
Miten valvonta havaitsee 500-virheet
Julkaisun jälkeinen 500-virhe voi jäädä huomaamatta tunneiksi, jos se osuu vain yhteen sivuun. Kassa hajoaa, etusivu toimii yhä, ja tiimi kuulee asiasta asiakkaan sähköpostista tai myynnin notkahduksesta.
Valvo sivuja, jotka tuovat rahaa. Lisää käytettävyysvalvonta kassalle, kirjautumiselle, rekisteröitymiselle ja API:lle, ei vain etusivulle, ja sisältötarkistukset sinne, missä 200 voi kätkeä virheen.
Varmista ennen hälytystä. Uptimecheck tarkistaa jopa minuutin välein Tukholmasta, Lontoosta ja New Yorkista ja varmistaa jokaisen virheen toisesta sijainnista, joten yksittäinen epäonnistunut pyyntö ei herätä ketään.
Näe, mikä hajosi. Häiriön mukana tulee epäonnistunut vastaus, tilakoodi ja virhesivu mukaan lukien, sekä kuvakaappaus siitä, mitä kävijä näki.
Testaa kokonaisia polkuja. Kirjautuminen tai kassa, joka kaatuu kolmannessa vaiheessa, palauttaa ensimmäisessä vaiheessa 200. Monivaiheiset polut käyvät vaiheet läpi ja kertovat, mikä niistä epäonnistui.
500-virheen tarkistuslista
Kysy, mikä muuttui viimeisen tunnin aikana, ja peru muutos, jos ajoitus täsmää.
Etsi epäonnistuneen pyynnön aikaleima virhelokista.
Lue virhe: tiedosto, rivi ja syy.
Sulje pois tavalliset syyt: lisäosa, .htaccess, muisti, käyttöoikeudet, levy, tietokanta.
Korjaa syy ja poista sitten käyttöön ottamasi debug-asetukset.
Valvo tärkeitä sivuja minuutin välein ja käytä sisältötarkistuksia siellä, missä 200 voi kätkeä virheen.
Testaa kirjautumiset ja kassat kokonaisina polkuina, ei yksittäisinä sivuina.