En 500 Internal Server Error betyr at applikasjonen på serveren møtte et problem den ikke klarte å håndtere mens den bygde svaret. I motsetning til de fleste andre feil sier den ingenting om hva som gikk galt. Det er serverens måte å si «noe gikk i stykker, og jeg forteller ikke besøkende hva».
Den faktiske feilmeldingen finnes likevel. Den ligger i en logg. Denne guiden viser hvor du finner den, hva som forårsaker de fleste 500-feil, og hvordan du sørger for at du er den første som får vite det når en dukker opp.
Hva en 500 forteller deg
En 500 kommer fra selve applikasjonen, eller fra webserveren som kjører den. Den betyr at forespørselen nådde koden din, og at koden feilet: et unntak ingen fanget opp, en fatal feil, en konfigurasjon serveren ikke kunne lese. Det skiller den fra gateway-feilene, der problemet ligger mellom to servere:
500 Internal Server Error: applikasjonen feilet mens den håndterte forespørselen.
502 Bad Gateway: en proxy fikk et ugyldig svar fra applikasjonen. Se guiden vår om 502.
503 Service Unavailable: tjenesten er overbelastet eller under vedlikehold. Se guiden vår om 503.
504 Gateway Timeout: applikasjonen brukte for lang tid på å svare. Se guiden vår om 504.
En 500 på én side betyr som regel en feil i koden til akkurat den siden. En 500 på alle sider betyr som regel at noe felles har gått i stykker: konfigurasjonen, databasetilkoblingen eller en fil hele applikasjonen laster inn.
Begynn med det som er endret
De fleste 500-feil dukker opp rett etter en endring. Før du leser en eneste logg, spør deg selv hva som har skjedd den siste timen:
En deploy eller en merge til hovedgrenen
En oppdatering av en plugin, et tema, et rammeverk eller et programmeringsspråk
En endring i en konfigurasjonsfil, .htaccess eller miljøvariabler
Et byttet passord eller en ny API-nøkkel
En server som har fylt opp disken eller fått endrede tilganger
Hvis tidspunktet stemmer, er det ofte raskest å rulle tilbake endringen for å få nettstedet opp igjen. Finn årsaken etterpå, uten at kundene ser på.
Finn den faktiske feilmeldingen
500-siden er generell, loggen er konkret. Hvor du skal lete, avhenger av stacken:
# 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
Se etter tidsstempelet til forespørselen som feilet. Oppføringen ved siden av nevner som regel filen, linjen og årsaken: en udefinert funksjon, en klasse som mangler, en database som avviste passordet.
I WordPress slår du på feilsøkingsloggen i wp-config.php. Den skriver feil til wp-content/debug.log uten å vise dem til besøkende:
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
Slå den av igjen når du er ferdig, siden loggen kan bli stor og kan inneholde sensitive opplysninger.
Vanlige årsaker og hvordan du løser dem
En feil i koden
Et unntak som ikke fanges opp, eller en fatal feil i koden som bygger siden. Loggen viser filen og linjen. Typiske utløsere er en funksjon som kalles med data den ikke forventet, en verdi som uventet er tom, og kode som fungerer på utviklerens maskin, men som trenger en PHP-utvidelse eller bibliotekversjon serveren ikke har. Rett koden, eller rull tilbake til siste versjon som fungerte.
En oppdatering av en plugin eller et tema
I WordPress og andre publiseringsløsninger er en oppdatering av en plugin eller et tema den vanligste årsaken. Loggen nevner mappen til pluginen. Hvis du ikke kommer inn i adminpanelet, kan du gi mappen nytt navn over SSH eller SFTP for å deaktivere den:
mv wp-content/plugins/some-plugin wp-content/plugins/some-plugin.disabled
Nettstedet kommer tilbake uten den. Oppdater den deretter på nytt, bytt den ut, eller kontakt utvikleren med feilen fra loggen.
En ødelagt .htaccess-fil
På Apache er én feil linje i .htaccess nok til å ta ned hele nettstedet med en 500. Feilloggen sier Invalid command eller nevner direktivet den ikke forsto. Gi filen nytt navn for å teste, og legg deretter tilbake linjene én etter én. I WordPress skrives en ny fil når du lagrer permalenkeinnstillingene.
PHP går tom for minne
Allowed memory size of 134217728 bytes exhausted betyr at en forespørsel trengte mer minne enn memory_limit tillater. Det kan hjelpe å heve grensen, men en forespørsel som trenger flere hundre megabyte, laster som regel for mye data på én gang. Finn ut hva den laster før du gir den mer.
Filtilganger og eierskap
Etter en deploy, en gjenoppretting eller en manuell kopiering kan filer ende opp med feil eier. Da kan ikke webserveren lese koden eller skrive til hurtigbuffer- og opplastingsmappene sine, og loggen sier Permission denied. Sett eierskapet tilbake til brukeren webserveren eller PHP kjører som. Mapper trenger normalt 755 og filer 644; løs det aldri med 777.
Full disk
Når disken er full, kan ikke applikasjoner skrive økter, hurtigbuffer, opplastinger eller logger, og de feiler på måter som ender i en 500. Sjekk ledig plass og inoder:
df -h
df -i
Gamle logger, sikkerhetskopier og hurtigbuffere er de vanlige synderne. Serverovervåking med et diskvarsel ved 80 eller 90 prosent fanger opp dette flere dager før det tar ned nettstedet.
Feil med databasetilkoblingen
Et endret passord, en databaseserver som er nede, eller en tilkoblingsgrense som er nådd. Applikasjonen får ikke lastet noe og feiler på alle sider. Loggen nevner databasefeilen. Sjekk at databasen kjører, at innloggingsopplysningene i konfigurasjonen er oppdaterte, og hvor mange tilkoblinger som er åpne sammenlignet med grensen.
500-feilen som svarer 200
Ikke alle ødelagte sider sier ifra. Noen applikasjoner fanger opp feilen og viser en vennlig «Noe gikk galt»-side med status 200, og et publiseringssystem kan vise en tom produktliste uten å klage. For en overvåking som bare ser på statuskoden, ser alt greit ut.
Sjekk innholdet også. En oppetidsovervåking kan kreve at en side inneholder et ord som alltid er der når den fungerer, for eksempel produktnavnet eller «Legg i handlekurven», og regne det som en feil når ordet mangler. Sjekklisten vår over hva du bør overvåke viser hvilke sider som fortjener en slik sjekk.
Slik fanger overvåking opp 500-feil
En 500 etter en deploy kan gå ubemerket i timevis hvis den bare rammer én side. Kassen slutter å virke, forsiden fungerer fortsatt, og teamet får vite det fra en kunde-e-post eller et fall i salget.
Sjekk sidene som tjener penger. Legg til oppetidsovervåking for kassen, innlogging, registrering og API-et, ikke bare forsiden, med innholdssjekker der en 200 kan skjule en feil.
Bekreft før du varsler. Uptimecheck sjekker så ofte som hvert minutt fra Stockholm, London og New York, og bekrefter hver feil fra en annen lokasjon, slik at én enkelt mislykket forespørsel ikke vekker noen.
Se hva som gikk i stykker. Hendelsen inneholder svaret som feilet, med statuskoden og feilsiden, og et skjermbilde av det en besøkende så.
Test hele flyter. En innlogging eller et kjøp som feiler på trinn tre, svarer 200 på trinn én. Flertrinnsflyter går gjennom trinnene og forteller deg hvilket som feilet.
Sjekkliste for 500-feil
Spør hva som er endret den siste timen, og rull tilbake hvis tidspunktet stemmer.
Finn tidsstempelet til forespørselen som feilet i feilloggen.
Les feilen: fil, linje og årsak.
Utelukk de vanlige årsakene: en plugin, .htaccess, minne, tilganger, disk, database.
Rett årsaken, og fjern deretter feilsøkingsinnstillinger du har slått på.
Overvåk viktige sider hvert minutt, med innholdssjekker der en 200 kan skjule en feil.
Test innlogging og kasse som flyter, ikke som enkeltsider.