„Internal Server Error” jest frustrujący właśnie dlatego, że sam kod 500 mówi niewiele. Nie jest diagnozą, tylko informacją, że serwer nie zdołał poprawnie zakończyć obsługi żądania. W WordPressie przyczyną może być fatal error PHP, brak pamięci, błędna reguła serwera, uszkodzony plik, konflikt rozszerzenia albo problem z usługą, od której aplikacja zależy.
Szybka odpowiedź
Najbardziej wartościową rzeczą po błędzie 500 jest log z tej samej sekundy. Jeżeli widzisz nazwę pliku i wyjątek PHP, rozwiązujesz konkretny problem. Jeżeli log PHP milczy, sprawdź log serwera i proxy. Dopiero potem testuj zmiany. Artykuł o „błędzie krytycznym” dotyczy komunikatu generowanego przez WordPressa; tutaj skupiamy się na samym kodzie HTTP 500 i warstwach, które mogą go wygenerować.
Sprawdź, czy 500 dotyczy całej strony
Otwórz stronę główną, prostą podstronę, /wp-login.php oraz statyczny plik, na przykład obraz. Jeśli plik statyczny działa, a PHP zwraca 500, zawężasz problem do aplikacji lub interpretera. Jeśli również statyczne zasoby nie działają, problem może leżeć w konfiguracji vhosta, prawach dostępu albo serwerze WWW.
Log PHP zwykle daje najkrótszą drogę
Fatal error z nazwą funkcji, pliku i linią często od razu wskazuje wtyczkę, motyw albo kod własny. Przy produkcji lepiej logować błędy niż pokazywać je publicznie. WP_DEBUG i WP_DEBUG_LOG są przydatne w kontrolowanej diagnostyce, ale przed zmianą wp-config.php zrób kopię i po zakończeniu przywróć bezpieczne ustawienia.
Pamięć i czas wykonania
Błąd 500 może pojawić się, gdy proces PHP przekroczy limit pamięci lub zakończy się w sposób nieobsłużony. Zwiększenie limitu „na ślepo” nie zawsze jest naprawą. Jeśli pojedyncze żądanie potrzebuje setek megabajtów, trzeba sprawdzić, co tę pamięć zużywa: zapytanie, import, generator obrazów, backup, wtyczka albo pętla w kodzie.
Reguły serwera i .htaccess
W Apache literówka albo niedozwolona dyrektywa w .htaccess może spowodować 500 zanim WordPress się uruchomi. W Nginx analogiczny problem będzie w konfiguracji serwera, nie w .htaccess, którego Nginx nie interpretuje. Jeżeli błąd pojawił się zaraz po zmianie reguł, przywróć ostatnią znaną działającą wersję i porównaj różnice.
Jeśli błąd pojawia się tylko czasami
Okresowy 500 może oznaczać przeciążenie, wyczerpanie workerów, błąd zależny od danych albo zadanie wykonywane cyklicznie. Porównaj godziny błędów z cronem, backupem, importem, ruchem botów i wykorzystaniem zasobów. Jeden pomyślny reload nie oznacza, że problem został rozwiązany.
Jak potwierdzić, że naprawa naprawdę działa?
Po naprawie wykonaj serię testów na adresach, które korzystają z różnych części WordPressa: homepage, wpis, wyszukiwarka, formularz, wp-admin i zadanie AJAX/REST. Jeśli 500 występował tylko przy jednym scenariuszu, odtwórz go kilkukrotnie. W logach nie powinny pojawiać się nowe fatale ani rosnąca liczba warningów związanych z tym samym komponentem. Dobrze jest zachować fragment logu „przed” i „po”, aby później potwierdzić, co faktycznie usunięto.
Co obserwować po zmianie?
Jeżeli przyczyną był limit pamięci lub czas wykonania, sprawdź zachowanie przy kilku równoległych żądaniach. Naprawa, która działa dla jednego administratora, może nie wytrzymać normalnego ruchu. Jeśli winna była reguła serwera, przejrzyj także 404 i redirecty — przywrócenie starego pliku konfiguracyjnego mogło usunąć potrzebne przekierowanie razem z błędem 500.
Kiedy przekazać temat dalej?
W przypadku powtarzających się 500 bez czytelnego stack trace potrzebna jest szersza diagnostyka: PHP-FPM, baza, storage, system plików i procesy w tle. Nie warto prowadzić wielogodzinnych eksperymentów na produkcji, gdy masz staging lub możliwość wykonania snapshotu. Celem jest przyczyna, nie samo chwilowe zniknięcie kodu 500.
Praktyczny scenariusz diagnostyczny
Praktyczny przykład: błąd 500 pojawia się tylko podczas zapisu konkretnej podstrony w edytorze. Frontend działa, więc restart całego serwera niczego nie wyjaśnia. Włącz kontrolowane logowanie błędów i ponów zapis. Jeżeli log wskazuje fatal error w jednej wtyczce, sprawdź jej wersję, ostatnie zmiany i minimalne wymagania PHP. Na stagingu odtwórz stronę z tą samą wersją wtyczki i motywu, a następnie sprawdź aktualizację lub konflikt. Po poprawce zapisz stronę kilka razy, wyczyść cache i przejrzyj log ponownie. Jeśli błąd nie wraca, masz znacznie mocniejszy dowód niż po samym odświeżeniu strony. Przy WordPressie kod 500 jest tylko objawem; wartość diagnostyki polega na wskazaniu dokładnej operacji i komponentu, który go generował.
Bezpieczna kolejność działań
- Zapisz URL i godzinę błędu.
- Sprawdź log PHP, error log serwera i ewentualnie reverse proxy.
- Ustal ostatnią zmianę przed awarią.
- Jeśli log wskazuje komponent, wyłącz lub cofnij tylko ten element.
- Sprawdź limity pamięci, czas wykonania i stan usług.
- Po naprawie wykonaj kilka testów i obserwuj, czy 500 nie wraca.
Czego nie robić
Nie instaluj kolejnej wtyczki „do naprawy 500” na stronie, która już jest niestabilna. Nie zmieniaj równocześnie PHP, bazy i reguł serwera. Bez logów łatwo zamienić jeden błąd na drugi i stracić punkt odniesienia.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
Jeżeli serwis firmowy zwraca 500 i potrzebujesz szybko ustalić przyczynę, HeatLogic może przeanalizować logi PHP i serwera, odtworzyć ostatnie zmiany i przywrócić działanie bez przypadkowej przebudowy środowiska.
Źródła techniczne
Najczęściej zadawane pytania
Czy błąd 500 zawsze oznacza błąd WordPressa?
Nie. Kod 500 może wygenerować PHP, serwer WWW, konfiguracja aplikacji lub inna warstwa infrastruktury.
Czy błąd krytyczny i 500 to to samo?
Nie zawsze. Błąd krytyczny jest komunikatem WordPressa, a 500 jest kodem HTTP. Mogą wystąpić razem, ale nie muszą.
Czy warto włączyć WP_DEBUG?
Tak, w kontrolowanej diagnostyce. Na produkcji lepiej logować błędy niż wyświetlać je publicznie.
Czy zwiększenie memory_limit naprawi 500?
Tylko jeśli przyczyną jest rzeczywiście brak pamięci. Nadal warto ustalić, dlaczego żądanie potrzebuje tak dużego limitu.