En 500 Internal Server Error betyder, at applikationen på serveren løb ind i et problem, den ikke kunne håndtere, mens den byggede svaret. I modsætning til de fleste andre fejl siger den ikke, hvad der gik galt. Det er serverens måde at sige “noget gik i stykker, og det fortæller jeg ikke den besøgende”.
Den egentlige fejlmeddelelse findes dog. Den ligger i en log. Denne guide viser, hvor du finder den, hvad der står bag de fleste 500-fejl, og hvordan du sikrer dig, at du er den første, der får besked, når en dukker op.
Hvad en 500 fortæller dig
En 500 kommer fra selve applikationen eller fra den webserver, der kører den. Den betyder, at forespørgslen nåede din kode, og at koden fejlede: en exception, som ingen fangede, en fatal fejl, en konfiguration, serveren ikke kunne læse. Det adskiller den fra gateway-fejlene, hvor problemet ligger mellem to servere:
500 Internal Server Error: applikationen fejlede under håndteringen af forespørgslen.
502 Bad Gateway: en proxy fik et ugyldigt svar fra applikationen. Se vores guide til 502.
503 Service Unavailable: tjenesten er overbelastet eller under vedligeholdelse. Se vores guide til 503.
504 Gateway Timeout: applikationen var for langsom til at svare. Se vores guide til 504.
En 500 på én side betyder som regel en fejl i den sides kode. En 500 på alle sider betyder som regel, at noget fælles er gået i stykker: konfigurationen, databaseforbindelsen, en fil, som hele applikationen indlæser.
Start med det, der er ændret
De fleste 500-fejl opstår lige efter en ændring. Før du læser en eneste log, så spørg, hvad der er sket inden for den seneste time:
En deploy eller en merge til main-branchen
En opdatering af et plugin, et tema, et framework eller sproget
En ændring i en konfigurationsfil, .htaccess eller miljøvariabler
En udskiftet adgangskode eller API-nøgle
En server, hvis disk er løbet fuld, eller hvis rettigheder er blevet ændret
Hvis tidspunktet passer, er det ofte hurtigst at rulle ændringen tilbage for at få sitet op igen. Find årsagen bagefter, uden at kunderne kigger med.
Find den egentlige fejlmeddelelse
500-siden er generisk, loggen er specifik. Hvor du skal kigge, afhænger af 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
Kig efter tidsstemplet for den fejlende forespørgsel. Linjen ved siden af nævner som regel filen, linjen og årsagen: en udefineret funktion, en manglende klasse, en database, der afviste adgangskoden.
På WordPress slår du debug-loggen til i wp-config.php. Den skriver fejl til wp-content/debug.log uden at vise dem for de besøgende:
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
Slå den fra igen, når du er færdig, da loggen kan blive stor og kan indeholde følsomme oplysninger.
Almindelige årsager, og hvordan du løser dem
En fejl i koden
En exception, der ikke bliver fanget, eller en fatal fejl i den kode, der bygger siden. Loggen viser filen og linjen. Typiske udløsere er en funktion, der kaldes med data, den ikke forventede, en værdi, der uventet er tom, og kode, der virker på udviklerens maskine, men kræver en PHP-udvidelse eller biblioteksversion, som serveren ikke har. Ret koden, eller rul tilbage til den seneste version, der virkede.
En opdatering af et plugin eller tema
På WordPress og andre CMS-platforme er en opdatering af et plugin eller tema den hyppigste årsag. Loggen nævner pluginets mappe. Hvis du ikke kan komme ind i administrationen, så omdøb mappen via SSH eller SFTP for at deaktivere det:
mv wp-content/plugins/some-plugin wp-content/plugins/some-plugin.disabled
Sitet kommer op igen uden det. Opdatér det derefter igen, udskift det, eller kontakt udvikleren med fejlen fra loggen.
En ødelagt .htaccess-fil
På Apache kan én forkert linje i .htaccess lægge hele sitet ned med en 500. Fejlloggen siger Invalid command eller nævner det direktiv, den ikke forstod. Omdøb filen for at teste, og gendan derefter linjerne én ad gangen. På WordPress skriver du en ny fil ved at gemme indstillingerne for permalinks.
PHP løber tør for hukommelse
Allowed memory size of 134217728 bytes exhausted betyder, at en forespørgsel krævede mere hukommelse, end memory_limit tillader. Det kan hjælpe at hæve grænsen, men en forespørgsel, der kræver flere hundrede megabyte, indlæser som regel for mange data på én gang. Find ud af, hvad den indlæser, før du giver den mere.
Filrettigheder og ejerskab
Efter en deploy, en gendannelse eller en manuel kopiering kan filer ende med at være ejet af den forkerte bruger. Webserveren kan så ikke læse koden eller skrive til sine cache- og upload-mapper, og loggen siger Permission denied. Sæt ejerskabet tilbage til den bruger, som webserveren eller PHP kører som. Mapper skal normalt have 755 og filer 644; løs det aldrig med 777.
En fuld disk
Når disken er fuld, kan applikationer ikke skrive sessioner, cache, uploads eller logs, og de fejler på måder, der ender i en 500. Tjek pladsen og inodes:
df -h
df -i
Gamle logs, backups og cache er de sædvanlige syndere. Serverovervågning med en diskalarm ved 80 eller 90 procent fanger det dage før, det lægger sitet ned.
Fejl i databaseforbindelsen
En ændret adgangskode, en databaseserver, der er nede, eller en forbindelsesgrænse, der er nået. Applikationen kan ikke indlæse noget og fejler på alle sider. Loggen nævner databasefejlen. Tjek, at databasen kører, at loginoplysningerne i konfigurationen er aktuelle, og hvor mange forbindelser der er åbne i forhold til grænsen.
500-fejlen, der returnerer 200
Ikke alle ødelagte sider siger det selv. Nogle applikationer fanger fejlen og viser en venlig “Noget gik galt”-side med status 200, og et CMS kan vise en tom produktliste uden at klage. For en overvågning, der kun ser på statuskoden, ser alt fint ud.
Tjek også indholdet. En oppetidsovervågning kan kræve, at en side indeholder et ord, der altid står der, når den virker, for eksempel produktnavnet eller “Læg i kurv”, og behandle det som en fejl, hvis ordet mangler. Vores tjekliste over, hvad du bør overvåge, viser, hvilke sider der fortjener den slags tjek.
Sådan fanger overvågning 500-fejl
En 500 efter en deploy kan gå ubemærket hen i timevis, hvis den kun rammer én side. Checkout går i stykker, forsiden virker stadig, og teamet hører om det fra en kundemail eller et fald i salget.
Tjek de sider, der tjener penge. Tilføj oppetidsovervågninger for checkout, login, tilmelding og API’et, ikke kun forsiden, med indholdstjek, hvor en 200 kan skjule en fejl.
Bekræft, før der sendes alarm. Uptimecheck tjekker helt ned til hvert minut fra Stockholm, London og New York og bekræfter hver fejl fra en anden lokation, så en enkelt fejlet forespørgsel ikke vækker nogen.
Se, hvad der gik i stykker. Hændelsen indeholder det fejlende svar, inklusive statuskoden og fejlsiden, og et skærmbillede af det, en besøgende så.
Test hele forløb. Et login eller en checkout, der fejler på trin tre, returnerer 200 på trin et. Forløb i flere trin går gennem trinene og fortæller dig, hvilket der fejlede.
Tjekliste til 500-fejl
Spørg, hvad der er ændret inden for den seneste time, og rul tilbage, hvis tidspunktet passer.
Find den fejlende forespørgsels tidsstempel i fejlloggen.
Læs fejlen: fil, linje og årsag.
Udeluk de sædvanlige årsager: et plugin, .htaccess, hukommelse, rettigheder, disk, database.
Løs årsagen, og fjern derefter de debug-indstillinger, du har slået til.
Overvåg vigtige sider hvert minut, med indholdstjek, hvor en 200 kan skjule en fejl.
Test login og checkout som forløb, ikke som enkeltsider.