5xx-statuscodes uitgelegd: wanneer uw server het probleem is
Een 5xx-statuscode betekent dat uw infrastructuur faalde, niet het verzoek van de bezoeker. De server accepteerde het verzoek, begreep het, en kon vervolgens geen geldig antwoord produceren, dus elke 5xx op uw site is een incident dat u zelf bezit.
Wat 5xx van 4xx onderscheidt
RFC 9110 definieert 5xx als "Server Error": de server weet dat hij een fout maakte of niet in staat is de gevraagde methode uit te voeren. Dat is het hele verschil. Een 404 zegt "hier is niets". Een 500 zegt "hier is iets en ik ging kapot terwijl ik het produceerde".
Daar volgen twee gevolgen uit. Ten eerste is een 5xx meestal opnieuw te proberen, want hetzelfde verzoek kan best een seconde later slagen zodra het falende onderdeel herstelt. Ten tweede behandelen zoekmachines een 5xx als een tijdelijk signaal en bouwen ze het crawlen af in plaats van meteen te deïndexeren, terwijl een aanhoudende 5xx over meerdere dagen u uiteindelijk toch geïndexeerde pagina's kost.
Welke schakel faalde
Lees een 5xx-code als een kaart van waar het verzoek stierf. Vrijwel elke moderne site zet minstens één proxy voor de applicatie, dus de code vertelt u aan welke kant van die grens het faalde.
| Code | Wie hem produceerde | Wat er gebeurde |
|---|---|---|
| 500 Internal Server Error | De applicatie zelf | Onafgehandelde uitzondering of onverwachte toestand binnen de app |
| 501 Not Implemented | De server | De verzoekmethode wordt helemaal niet ondersteund |
| 502 Bad Gateway | De proxy, CDN of load balancer | De backend antwoordde, maar met iets ongeldigs, of sloot de verbinding |
| 503 Service Unavailable | De server of proxy, met opzet | Overbelast of in onderhoud, en weigert bewust werk |
| 504 Gateway Timeout | De proxy, CDN of load balancer | De backend antwoordde nooit op tijd |
| 505 HTTP Version Not Supported | De server | De protocolversie in het verzoek wordt niet ondersteund |
502, 503 en 504 dragen de meeste diagnostische waarde, want elk noemt een andere mislukking van dezelfde backend: ongeldig antwoord, geweigerd antwoord, geen antwoord. De 502 Bad Gateway-handleiding behandelt de eerste daarvan diepgaand, inclusief de proxy-logregels die de exacte fout identificeren.
Veelvoorkomende oorzaken achter 5xx-antwoorden
- Applicatiecrashes. Een onafgehandelde uitzondering, een mislukte databaseverbinding of een null-waarde op een onverwachte plek produceert 500 op elke route die het kapotte codepad raakt.
- Backendproces draait niet. Een gestopte appserver, een dode PHP-FPM-pool of een container die zijn health check niet doorstond, geeft de proxy niets om mee te praten, wat als 502 naar boven komt.
- Uitputting van resources. Geen geheugen meer, geen file descriptors meer, geen workerthreads meer, of geen databaseverbindingen meer. Begint meestal als onregelmatige fouten onder belasting voordat het constant wordt.
- Trage afhankelijkheden. Een trage query, een trage API van een derde partij of een koude start duwt de responstijd voorbij de time-out van de proxy en wordt een 504.
- Deployments en herstarts. Elk venster waarin het oude proces is gestopt en het nieuwe nog niet is begonnen met bedienen, produceert een uitbarsting van 502 of 503.
- Configuratiefouten. Een verkeerd upstream-adres, een slechte TLS-opzet tussen proxy en backend, of een protocolmismatch zoals HTTP spreken tegen een HTTPS-poort.
- Volle schijf. Een ondergewaardeerde oorzaak. Logs of tijdelijke bestanden vullen het volume, sessies of caches stoppen met schrijven, en de applicatie begint op manieren te falen die willekeurig lijken.
Hoe u een 5xx doorwerkt
- Bevestig de code en zijn herkomst. Haal headers rechtstreeks op en kijk welk onderdeel het antwoord ondertekende:
Eencurl -sS -o /dev/null -D - https://example.com/Server:-header of CDN-header op de fout vertelt u of de edge of de origin hem genereerde. - Test de origin rechtstreeks, langs de proxy heen. Antwoordt de backend met 200 op zijn eigen poort terwijl de publieke URL met 502 antwoordt, dan zit de fout in de proxylaag of de verbinding daartussen.
- Lees vervolgens het proxy-foutlog, niet het applicatielog. Reverse proxy's noemen de mislukking precies, bijvoorbeeld
connect() failed (111: Connection refused)ofupstream timed out, wat meteen "backend down" scheidt van "backend traag". - Lees dan het applicatielog. Voor een 500 is de stacktrace het antwoord. Bij 502 en 504 logt de applicatie vaak helemaal niets, en die afwezigheid is zelf al informatief.
- Controleer resources op de host. Geheugen, schijf, verbindingsaantallen en workerverzadiging. Onregelmatige 5xx onder verkeer is vrijwel altijd een bereikte limiet.
- Kijk naar wat er veranderde. Deployments, configuratiepushes, certificaatvernieuwingen en updates van afhankelijkheden verklaren een groot deel van plotselinge 5xx-uitbraken.
Onregelmatige 5xx-fouten opsporen
5xx-fouten zijn vaak onregelmatig, wat ze moeilijk maakt om met de hand te vangen: de pagina die u herlaadt werkt, en die uw klant laadde deed dat niet. Een geplande HTTP-controle draait continu en bemonstert de site veel vaker dan u kunt, zodat een reeks fouten zichtbaar wordt als patroon in plaats van als verspreide klachten. Controleren vanaf veel locaties scheidt ook een echte serverfout van een routerings- of edgeprobleem dat maar een deel van de wereld treft, en dat is waarom gedistribueerde beschikbaarheidsmonitoring controlepunten gebruikt die over regio's zijn verspreid in plaats van één waarnemingspunt. Blijkt de falende code in plaats daarvan 403, 404 of 429 te zijn, dan bereikte het verzoek nooit een kapotte backend, en is de 4xx-familiehandleiding het juiste startpunt.