500 Internal Server Error: oorzaken, logs en verschil met 502

Waarom een 500 u zo weinig vertelt

RFC 9110 definieert 500 als een onverwachte toestand die de server verhinderde het verzoek in te willigen. Dat is bewust breed. Alles wat de applicatie niet voorzag, van een null-referentie tot een mislukte databaseverbinding tot een configuratiebestand dat niet te parsen is, komt onder hetzelfde nummer terecht.

De vaagheid is ook een beveiligingsmaatregel. Een 500-pagina mag nooit stacktraces, bestandspaden, SQL-fragmenten of bibliotheekversies naar buiten lekken, want dat zijn precies de details die een aanvaller wil. Dus blijft de code generiek in de respons, en gaat het detail naar een log dat alleen u kunt lezen. Die afweging is juist, en ze maakt één stuk kennis nuttiger dan al het andere: waar uw logs staan.

500 versus 502, 503 en 504

Alle vier zijn serverfouten, maar ze worden geproduceerd door verschillende componenten en wijzen op verschillende problemen. Dit goed hebben, bespaart het meeste debugtijd.

• 500 komt van de applicatie zelf. Er draaide iets en het gooide een fout. Het applicatielog heeft een stacktrace.
• 502 komt van een proxy voor de applicatie, die een ongeldig antwoord of een gesloten verbinding van de backend kreeg. De backend logt vaak niets, omdat hij het verzoek nooit afmaakte. Zie de 502-handleiding.
• 503 is een weigering, geen crash. De server is overbelast of in onderhoud en wijst werk bewust af, meestal met Retry-After.
• 504 is een time-out. De backend was bereikbaar maar antwoordde niet binnen de limiet van de proxy. Het verzoek draait achter de schermen vaak nog steeds.

Een botte vuistregel: 500 betekent dat uw code kapot is, 502 betekent dat uw backend dood is of zich misdraagt, 503 betekent dat uw server bewust nee zegt, 504 betekent dat uw backend te traag is. De hele familie wordt vergeleken in het 5xx-overzicht.

Wat een 500 veroorzaakt

• Onafgehandelde uitzonderingen in applicatiecode. De grootste enkele categorie. Een null-waarde, een mislukte typeconversie, een arrayindex buiten bereik, een deling door nul op een pad dat niemand testte.
• Databasefouten. Connection pool uitgeput, credentials geroteerd, de database herstart, een query die vastloopt (deadlock) of een time-out krijgt.
• Ontbrekende of kapotte dependencies na een deploy. Een package die niet installeerde, een bestand dat de build niet kopieerde, een omgevingsvariabele die in staging bestaat maar niet in productie.
• Syntaxisfouten in configuratie. Op Apache produceert één ongeldige directive in een bestand .htaccess 500 voor elk verzoek onder die map.
• Bestandsrechten en eigenaarschap. De applicatie kan een configuratiebestand niet lezen of niet schrijven naar een cache-, sessie- of uploadmap.
• Resourcelimieten. Een geheugenlimiet, een uitvoertijdlimiet of een volle schijf. Die produceren doorgaans intermitterende 500's die met het verkeer meebewegen.
• Fouten bij externe API's die de code aanroept zonder terugvaloptie, zodat een externe storing uw foutpagina wordt.

Hoe u een 500 diagnosticeert

1. Bevestig de code en wie hem produceerde. Een gebrande foutpagina kan de echte status verbergen:

   curl -sS -o /dev/null -D - https://example.com/failing-page

   Controleer de statusregel en elke header Server of CDN-header. Is de fout ondertekend door een edge-netwerk en antwoordt de origin met 200, dan kijkt u helemaal niet naar een 500 van uw applicatie.
2. Open eerst het applicatielog. Hier staat de stacktrace. Frameworklogs, de logstream van het platform of de stdout van de container, wat uw stack ook gebruikt, en matcht op tijdstempel en verzoekpad.
3. Dan het foutlog van de webserver. Apache error_log, nginx error.log, of het Windows-gebeurtenislogboek voor IIS. Heeft de applicatie niets gelogd, dan gebeurde de storing voordat uw code draaide, wat wijst op configuratie of de runtime.
4. Reproduceer hem bewust. Stel vast of de 500 één URL, één HTTP-methode, één gebruiker of alles treft. Een 500 alleen op POST betekent meestal formulierafhandeling of een schrijfpad. Een 500 voor één gebruiker betekent meestal diens data.
5. Zet gedetailleerde fouten aan in een niet-openbare omgeving. Nooit op productie. Reproduceer in staging met volledige foutuitvoer, wat een generieke 500 in een specifiek regelnummer verandert.
6. Controleer wat er veranderde. De laatste deploy, een configuratiewijziging, een certificaatvernieuwing, een dependency-update of een databasemigratie. Was de site een uur geleden nog in orde, dan zit het antwoord vrijwel altijd in de laatste wijziging.
7. Controleer hostresources. Schijfruimte, geheugen en het aantal verbindingen. Een schijf die volliep met logs produceert 500's die volledig los lijken te staan van de code.

De 500's die maar één pagina teruggeeft

De meeste 500's leggen niet de hele site plat. Eén route, één formulier of één regio breekt terwijl de homepage blijft laden, zodat er van buitenaf niets mis lijkt en de fouten dagen later naar boven komen als verloren aanmeldingen. Een geplande HTTP-controle op de pagina's die ertoe doen, niet alleen de homepage, vergelijkt de teruggegeven code met de verwachte en waarschuwt zodra een route 500 begint te antwoorden. Waarschuwingen kunnen aankomen via e-mail, sms, spraakoproep, Slack, Telegram en meer, zodat een storing 's nachts bij wie er dienst heeft terechtkomt in plaats van te wachten tot de ochtend. HostTracker bewaakt websites sinds 2004.