En 500 Internal Server Error betyder att applikationen på servern stötte på ett problem den inte kunde hantera medan den byggde svaret. Till skillnad från de flesta andra fel säger den inte vad som gick snett. Det är serverns sätt att säga ”något gick sönder, och jag tänker inte berätta vad för besökaren”.
Det riktiga felmeddelandet finns dock. Det ligger i en logg. Den här guiden visar var du hittar det, vad som orsakar de flesta 500-fel och hur du ser till att du är först med att få veta när ett dyker upp.
Vad en 500 berättar
En 500 kommer från applikationen själv, eller från webbservern som kör den. Den betyder att förfrågan nådde din kod och att koden fallerade: ett undantag som ingen fångade, ett fatalt fel, en konfiguration som servern inte kunde läsa. Det skiljer den från gateway-felen, där problemet sitter mellan två servrar:
500 Internal Server Error: applikationen fallerade när den hanterade förfrågan.
502 Bad Gateway: en proxy fick ett ogiltigt svar från applikationen. Se vår guide om 502.
503 Service Unavailable: tjänsten är överbelastad eller under underhåll. Se vår guide om 503.
504 Gateway Timeout: applikationen var för långsam att svara. Se vår guide om 504.
En 500 på en enskild sida betyder oftast en bugg i den sidans kod. En 500 på alla sidor betyder oftast att något gemensamt har gått sönder: konfigurationen, databasanslutningen, en fil som hela applikationen laddar.
Börja med vad som har ändrats
De flesta 500-fel dyker upp direkt efter en ändring. Innan du läser en enda logg, fråga dig vad som hänt den senaste timmen:
En deploy eller en merge till huvudgrenen
En uppdatering av ett plugin, tema, ramverk eller språk
En ändring i en konfigurationsfil, .htaccess eller miljövariabler
Ett bytt lösenord eller en ny API-nyckel
En server vars disk blev full eller vars behörigheter ändrades
Om tidpunkten stämmer är det ofta snabbast att rulla tillbaka ändringen för att få upp sajten igen. Leta efter orsaken efteråt, utan kunder som tittar på.
Hitta det riktiga felmeddelandet
500-sidan är generell, loggen är specifik. Var du ska leta beror på din stack:
# 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
Leta upp tidsstämpeln för förfrågan som fallerade. Raden bredvid anger oftast filen, raden och orsaken: en odefinierad funktion, en klass som saknas, en databas som inte godtog lösenordet.
I WordPress slår du på felsökningsloggen i wp-config.php. Den skriver fel till wp-content/debug.log utan att visa dem för besökarna:
define( ’WP_DEBUG’, true );
define( ’WP_DEBUG_LOG’, true );
define( ’WP_DEBUG_DISPLAY’, false );
Stäng av den igen när du är klar, eftersom loggen kan bli stor och kan innehålla känsliga uppgifter.
Vanliga orsaker och hur du åtgärdar dem
Ett fel i koden
Ett ofångat undantag eller ett fatalt fel i koden som bygger sidan. Loggen visar fil och rad. Typiska utlösare är en funktion som anropas med data den inte förväntade sig, ett värde som oväntat är tomt och kod som fungerar på utvecklarens dator men kräver ett PHP-tillägg eller en biblioteksversion som servern saknar. Rätta koden, eller rulla tillbaka till den senaste versionen som fungerade.
En uppdatering av ett plugin eller tema
I WordPress och andra CMS är en uppdatering av ett plugin eller tema den vanligaste orsaken. Loggen anger pluginets mapp. Om du inte kommer åt adminpanelen kan du byta namn på mappen via SSH eller SFTP för att inaktivera det:
mv wp-content/plugins/some-plugin wp-content/plugins/some-plugin.disabled
Sajten kommer tillbaka utan det. Uppdatera det sedan igen, byt ut det eller kontakta utvecklaren med felet från loggen.
En trasig .htaccess-fil
På Apache räcker en felaktig rad i .htaccess för att hela sajten ska svara med 500. Felloggen säger Invalid command eller anger direktivet den inte förstod. Byt namn på filen för att testa och lägg sedan tillbaka raderna en i taget. I WordPress skrivs en ny fil när du sparar inställningarna för permalänkar.
PHP har slut på minne
Allowed memory size of 134217728 bytes exhausted betyder att en förfrågan behövde mer minne än memory_limit tillåter. Att höja gränsen kan hjälpa, men en förfrågan som behöver hundratals megabyte laddar oftast för mycket data på en gång. Ta reda på vad den laddar innan du ger den mer.
Filbehörigheter och ägarskap
Efter en deploy, en återställning eller en manuell kopiering kan filerna få fel ägare. Då kan webbservern inte läsa koden eller skriva till sina cache- och uppladdningsmappar, och loggen säger Permission denied. Sätt tillbaka ägarskapet till den användare som webbservern eller PHP körs som. Kataloger behöver normalt 755 och filer 644; lös det aldrig med 777.
En full disk
När disken är full kan applikationer inte skriva sessioner, cache, uppladdningar eller loggar, och de fallerar på sätt som slutar i en 500. Kontrollera utrymmet och inoderna:
df -h
df -i
Gamla loggar, säkerhetskopior och cachefiler är de vanliga bovarna. Serverövervakning med ett disklarm vid 80 eller 90 procent fångar det här flera dagar innan sajten går sönder.
Fel i databasanslutningen
Ett ändrat lösenord, en databasserver som ligger nere eller en anslutningsgräns som är nådd. Applikationen kan inte ladda något och fallerar på varje sida. Loggen anger databasfelet. Kontrollera att databasen körs, att inloggningsuppgifterna i konfigurationen är aktuella och hur många anslutningar som är öppna jämfört med gränsen.
500-felet som svarar 200
Alla trasiga sidor säger inte att de är trasiga. Vissa applikationer fångar felet och visar en vänlig ”Något gick fel”-sida med status 200, och ett CMS kan visa en tom produktlista utan att klaga. För en övervakare som bara tittar på statuskoden ser allt bra ut.
Kontrollera innehållet också. En upptidsövervakare kan kräva att en sida innehåller ett ord som alltid finns där när den fungerar, till exempel produktnamnet eller ”Lägg i varukorgen”, och räkna det som ett fel när ordet saknas. Vår checklista över vad du ska övervaka visar vilka sidor som förtjänar en sådan kontroll.
Så fångar övervakning 500-fel
En 500 efter en deploy kan gå obemärkt förbi i timmar om den bara drabbar en sida. Kassan slutar fungera, startsidan fungerar fortfarande och teamet får veta det genom ett mejl från en kund eller en dipp i försäljningen.
Kontrollera sidorna som drar in pengar. Lägg till upptidsövervakare för kassan, inloggningen, registreringen och API:et, inte bara startsidan, med innehållskontroller där en 200 kan dölja ett fel.
Bekräfta innan du larmar. Uptimecheck kontrollerar så ofta som varje minut från Stockholm, London och New York och bekräftar varje fel från en andra plats, så att en enda misslyckad förfrågan inte larmar någon.
Se vad som gick sönder. Incidenten innehåller svaret som fallerade, med statuskoden och felsidan, och en skärmbild av vad en besökare såg.
Testa hela flöden. En inloggning eller ett köp som fallerar i steg tre svarar 200 i steg ett. Flöden i flera steg går igenom stegen och talar om vilket som fallerade.
Checklista för 500-fel
Fråga dig vad som ändrats den senaste timmen, och rulla tillbaka om tidpunkten stämmer.
Hitta tidsstämpeln för förfrågan som fallerade i felloggen.
Läs felet: fil, rad och orsak.
Uteslut de vanliga orsakerna: ett plugin, .htaccess, minne, behörigheter, disk, databas.
Åtgärda orsaken och ta sedan bort felsökningsinställningar du slagit på.
Övervaka viktiga sidor varje minut, med innehållskontroller där en 200 kan dölja ett fel.
Testa inloggningar och köp som flöden, inte som enskilda sidor.