500 Internal Server Error: příčiny, logy a rozdíl od 502

Proč vám 500 řekne tak málo

RFC 9110 definuje 500 jako neočekávaný stav, který serveru zabránil požadavek splnit. Je to záměrně obecné. Cokoli, co aplikace nepředpokládala, od null reference přes selhané připojení k databázi až po konfigurační soubor, který se nepodaří zpracovat, skončí pod stejným číslem.

Ta neurčitost je zároveň bezpečnostní prvek. Stránka 500 by nikdy neměla veřejnosti prozradit stack trace, cesty k souborům, fragmenty SQL nebo verze knihoven, protože přesně to útočník chce vědět. Kód proto v odpovědi zůstává obecný a podrobnosti jdou jen do logu, který si přečtete jen vy. Tato výměna je správná a dělá z jedné znalosti užitečnější věc než cokoli jiného: vědět, kde vaše logy žijí.

500 versus 502, 503 a 504

Všechny čtyři jsou chyby serveru, ale produkují je různé komponenty a ukazují na různé problémy. Správné rozlišení ušetří většinu času při ladění.

• 500 pochází ze samotné aplikace. Něco se spustilo a vyhodilo výjimku. Log aplikace má stack trace.
• 502 pochází z proxy před aplikací, která od backendu dostala neplatnou odpověď nebo uzavřené spojení. Backend často nezaznamená nic, protože požadavek nikdy nedokončil. Viz návod k 502.
• 503 je odmítnutí, ne pád. Server je přetížený nebo v údržbě a práci záměrně odmítá, obvykle s hlavičkou Retry-After.
• 504 je timeout. Backend byl dostupný, ale neodpověděl v limitu proxy. Požadavek často pořád běží na pozadí.

Zjednodušená pomůcka: 500 znamená, že se rozbil váš kód, 502 znamená, že váš backend je mrtvý nebo se chová divně, 503 znamená, že váš server záměrně odmítá, 504 znamená, že je váš backend příliš pomalý. Celá rodina je porovnaná v přehledu 5xx.

Co 500 způsobuje

• Neošetřené výjimky v kódu aplikace. Zdaleka největší kategorie. Hodnota null, selhaná konverze typu, index pole mimo rozsah, dělení nulou na cestě, kterou nikdo netestoval.
• Selhání databáze. Vyčerpaný pool spojení, obměněné přihlašovací údaje, restart databáze, dotaz, který uvázne v deadlocku nebo vyprší.
• Chybějící nebo rozbité závislosti po nasazení. Balíček, který se nenainstaloval, soubor, který sestavení nezkopírovalo, proměnná prostředí, která existuje na staging, ale ne v produkci.
• Chyby syntaxe v konfiguraci. Na Apache jedna neplatná direktiva v souboru .htaccess vyprodukuje 500 pro každý požadavek v daném adresáři.
• Oprávnění a vlastnictví souborů. Aplikace nemůže přečíst konfigurační soubor nebo zapisovat do adresáře mezipaměti, relací nebo nahrávání.
• Limity zdrojů. Limit paměti, limit doby běhu nebo plný disk. Ty obvykle produkují přerušovaná 500, která kopírují provoz.
• Selhání API třetí strany, které kód volá bez záložního plánu, takže se vzdálený výpadek stane vaší chybovou stránkou.

Jak diagnostikovat 500

1. Ověřte kód a kdo ho vyprodukoval. Brandovaná chybová stránka může skutečný stav skrýt:

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

   Zkontrolujte stavový řádek a jakoukoli hlavičku Server nebo CDN. Pokud chybu podepisuje okrajová síť a původní server odpovídá 200, nedíváte se na 500 z vaší aplikace vůbec.
2. Nejdřív otevřete log aplikace. Tam je stack trace. Logy frameworku, log stream platformy nebo stdout kontejneru, cokoli váš stack používá, a spárujte podle časového razítka a cesty požadavku.
3. Poté log chyb webového serveru. Apache error_log, nginx error.log, nebo Windows Event Log pro IIS. Pokud aplikace nezaznamenala vůbec nic, selhání se stalo dřív, než se váš kód spustil, což ukazuje na konfiguraci nebo runtime.
4. Reprodukujte to záměrně. Zjistěte, zda 500 postihuje jednu URL adresu, jednu HTTP metodu, jednoho uživatele nebo úplně vše. 500 jen na POST obvykle znamená zpracování formuláře nebo zápisovou cestu. 500 pro jednoho uživatele obvykle znamená jeho data.
5. Zapněte podrobné chyby v neveřejném prostředí. Nikdy na produkci. Reprodukujte na staging s plným chybovým výstupem, což obecné 500 promění na konkrétní číslo řádku.
6. Zkontrolujte, co se změnilo. Poslední nasazení, push konfigurace, obnova certifikátu, aktualizace závislosti nebo migrace databáze. Pokud byl web v pořádku před hodinou, odpověď bývá skoro vždy v poslední změně.
7. Zkontrolujte zdroje hostitele. Místo na disku, paměť a počet spojení. Disk, který se zaplnil logy, produkuje 500, která vypadají naprosto nesouvisle s kódem.

500, které vrací jen jedna stránka

Většina 500 nesrazí celý web. Jedna trasa, jeden formulář nebo jeden region se rozbije, zatímco domovská stránka se dál načítá, takže zvenčí nic nevypadá špatně a chyby se objeví o dny později jako ztracené registrace. Naplánovaná HTTP kontrola na stránkách, na kterých záleží, ne jen na domovské stránce, porovná vrácený kód s očekávaným a upozorní ve chvíli, kdy trasa začne odpovídat 500. Upozornění mohou chodit e-mailem, SMS, hlasovým hovorem, přes Slack, Telegram a další, takže noční selhání zastihne toho, kdo má službu, místo aby čekalo na ráno. HostTracker monitoruje weby od roku 2004.