Chyba 500 znamená, že server při vyřizování požadavku narazil na neočekávaný problém. Není to diagnóza konkrétní závady ani důkaz, že potřebujete dražší hosting. Může jít o chybu aplikace, konfiguraci nebo vyčerpané prostředky. Dokumentace MDN ke stavu 500 jej popisuje jako obecnou odpověď pro situace, pro které server nemá vhodnější chybový kód.
Jste návštěvník, nebo správce webu?
Jako návštěvník zkuste stránku načíst později a provozovateli pošlete adresu a čas chyby. Pokud hlášení vzniklo při platbě nebo odeslání objednávky, nejprve ověřte, zda operace neproběhla. Opakované odesílání může vytvořit duplicitu. Změna DNS v počítači ani přeinstalování prohlížeče serverovou závadu zpravidla nevyřeší.
Jako správce si před první úpravou zaznamenejte rozsah problému. Selhává celý web, pouze administrace, konkrétní formulář nebo jediná adresa? Funguje existující obrázek či statická HTML stránka na stejné doméně? Rozdíl pomůže zúžit hledání, sám ale příčinu nepotvrdí. Obrázek může například obsloužit cache, zatímco aplikace už nefunguje.
1. Ověřte skutečný HTTP stav
Text „Internal Server Error“ na stránce nemusí odpovídat skutečnému stavovému kódu. V prohlížeči otevřete vývojářské nástroje, kartu Síť (Network), znovu načtěte stránku a zkontrolujte stav požadavku na dokument. Poznamenejte také případné ID požadavku z odpovědi. Pokud používáte příkazovou řádku s curl, pro veřejnou stránku lze zobrazit hlavičky i tělo odpovědi:
curl -i https://example.com/
Ukázkovou adresu nahraďte postiženou URL. Ve Windows použijte případně curl.exe, aby se nespustil stejnojmenný alias PowerShellu. Výstup může obsahovat cookies nebo osobní údaje; před předáním podpoře je odstraňte. Pokud web přesměruje jinam, ověřte také výslednou adresu. Chybový stav jednotlivého obrázku nebo analytického skriptu nezaměňujte za stav celé stránky.
2. Najděte odpovídající událost v logu
V administraci hostingu hledejte chybový log webserveru, PHP a aplikace. Jejich umístění i dostupnost závisí na poskytovateli. Vyfiltrujte čas konkrétního neúspěšného požadavku a ověřte časové pásmo. Access log obvykle pomůže dohledat URL a stav, error log pak podrobnosti selhání. U aplikace za proxy může být potřeba sledovat stejný požadavek ve více vrstvách.
UncaughtneboFatal error: hledejte soubor, řádek a návaznost na poslední změnu aplikace.Allowed memory size exhausted: prověřte operaci, která paměť vyčerpala, a dostupný limit PHP.Permission denied: ověřte vlastníka a potřebná práva konkrétního souboru nebo adresáře.Invalid commandv souvislosti s.htaccess: zkontrolujte direktivu a podporu na daném serveru.
Jde o orientační příklady, nikoli univerzální překlad kódu 500. Uložte relevantní výřez logu ještě před opravou. Citlivé hodnoty neposílejte do veřejných diskusí.
3. Porovnejte výpadek s poslední změnou
Sepište, co proběhlo těsně před prvním selháním: nasazení nové verze, aktualizace doplňku, změna PHP, úprava přepisovacích pravidel nebo přesun webu. Pokud čas a log ukazují na stejnou změnu, máte konkrétní hypotézu k ověření. Měňte vždy jednu věc a znovu zkuste původní scénář.
Příklad: po aktualizaci rozšíření padá pouze export a log odkazuje na jeho soubor. Nejprve ověřte kompatibilitu rozšíření s aplikací a PHP, ideálně v testovacím prostředí. Návrat předchozí verze může obnovit provoz, ale pouze pokud je slučitelný se současnou databází. Zpětná obnova staré databáze by mohla odstranit nové objednávky či příspěvky. Před zásahem proto zachovejte aktuální data a ověřte možnosti zálohování a obnovy webu.
4. Zkontrolujte konfiguraci, práva a limity
U Apache může nepovolená nebo chybná direktiva v .htaccess vyvolat interní chybu. Oficiální návod Apache pro .htaccess doporučuje při těchto potížích zkontrolovat error log. Pokud jste soubor právě upravili, porovnejte změnu s funkční verzí. Nesmažte celý soubor naslepo: může obsahovat také omezení přístupu a pravidla důležitá pro aplikaci. Na Nginxu se tento soubor nepoužívá.
U práv ověřte požadavky hostingu a vlastníka souborů. Nastavení 777 na celý web není bezpečná oprava. U limitů sledujte paměť, volné místo a dostupné procesy v administraci hostingu. Navýšení limitu bez zjištění příčiny může závadu pouze odložit. Pokud problém začal po přesunu, projděte i kontroly při migraci webu, zejména verzi PHP, rozšíření a cesty k souborům.
Chybové podrobnosti patří do logu
Na veřejném webu nezapínejte zobrazování detailních PHP chyb návštěvníkům. Mohou odhalit interní cesty nebo části konfigurace. Dokumentace PHP k chybovým hlášením pro produkční prostředí doporučuje logování místo zobrazování chyb. Nastavení display_errors, log_errors a cílového logu řešte podle možností hostingu. Log má být dostupný správci, nikoli přes veřejnou URL.
Co poslat podpoře hostingu
Pokud k logům nemáte přístup nebo z nich příčina není zřejmá, pošlete podpoře konkrétní podklady. Pouhé „web nefunguje“ prodlužuje první kolo hledání.
- Doménu, postiženou URL a přesný čas včetně časového pásma.
- Naměřený HTTP stav a případné ID požadavku.
- Zda selhává celý web, nebo jen určitá akce, a jak ji zopakovat.
- Poslední změnu a výřez logu bez hesel, tokenů a osobních údajů.
- Co jste již ověřili a zda jste provedli návrat předchozí verze.
Jak poznat, že je oprava hotová
- Znovu projděte původně chybující URL nebo akci a ověřte očekávaný HTTP stav.
- Vyzkoušejte také přihlášení a důležité formuláře; u objednávek použijte bezpečný testovací postup.
- Zkontrolujte, zda při testu nepřibyly stejné chyby v logu.
- Odstraňte dočasnou diagnostiku a ověřte, že podrobnosti nejsou veřejné.
- Zapište příčinu a opravu a nastavte kontrolu dostupnosti postižené části webu.
Funkční úvodní stránka sama nestačí, pokud původně padalo odeslání formuláře. Rozhodující je úspěšné zopakování konkrétního scénáře a kontrola logu. Tím získáte použitelný postup i pro další výpadek.