Błąd 500 Internal Server Error oznacza, że aplikacja na serwerze napotkała problem, z którym nie poradziła sobie podczas budowania odpowiedzi. W przeciwieństwie do większości innych błędów nie mówi, co poszło nie tak. To sposób serwera na powiedzenie: „coś się zepsuło, ale nie zdradzę odwiedzającemu co”.
Prawdziwy komunikat o błędzie jednak istnieje. Jest w logu. W tym poradniku pokazujemy, gdzie go znaleźć, jakie przyczyny stoją za większością błędów 500 i jak sprawić, by to Ty dowiadywał się o nich pierwszy.
Co mówi Ci błąd 500
Błąd 500 pochodzi z samej aplikacji albo z serwera WWW, na którym działa. Oznacza, że żądanie dotarło do Twojego kodu, a kod zawiódł: nieprzechwycony wyjątek, błąd krytyczny, konfiguracja, której serwer nie potrafił odczytać. To odróżnia go od błędów bramy, w których problem leży między dwoma serwerami:
500 Internal Server Error: aplikacja zawiodła podczas obsługi żądania.
502 Bad Gateway: proxy otrzymało od aplikacji nieprawidłową odpowiedź. Zobacz nasz poradnik o błędzie 502.
503 Service Unavailable: usługa jest przeciążona lub trwa konserwacja. Zobacz nasz poradnik o błędzie 503.
504 Gateway Timeout: aplikacja odpowiadała zbyt wolno. Zobacz nasz poradnik o błędzie 504.
Błąd 500 na jednej stronie zwykle oznacza błąd w jej kodzie. Błąd 500 na każdej stronie zwykle oznacza, że zepsuło się coś wspólnego: konfiguracja, połączenie z bazą danych, plik ładowany przez całą aplikację.
Zacznij od tego, co się zmieniło
Większość błędów 500 pojawia się tuż po jakiejś zmianie. Zanim przeczytasz choćby jeden log, zapytaj, co wydarzyło się w ciągu ostatniej godziny:
Wdrożenie lub merge do głównej gałęzi
Aktualizacja wtyczki, motywu, frameworka lub języka
Edycja pliku konfiguracyjnego, .htaccess lub zmiennych środowiskowych
Zmienione hasło lub klucz API
Serwer, któremu zapełnił się dysk albo zmieniono uprawnienia
Jeśli czas się zgadza, wycofanie zmiany jest często najszybszym sposobem na przywrócenie strony. Przyczynę znajdziesz później, już bez klientów patrzących Ci na ręce.
Znajdź prawdziwy komunikat o błędzie
Strona błędu 500 jest ogólnikowa, log jest konkretny. Gdzie szukać, zależy od stosu technologicznego:
# nginx and Apache
tail -n 50 /var/log/nginx/error.log
tail -n 50 /var/log/apache2/error.log
# PHP-FPM
tail -n 50 /var/log/php8.3-fpm.log
# Applications run by systemd
journalctl -u myapp –since „15 min ago”
# Docker
docker logs –since 15m myapp
Szukaj znacznika czasu nieudanego żądania. Wpis obok zwykle podaje plik, linię i przyczynę: niezdefiniowaną funkcję, brakującą klasę, bazę danych, która odrzuciła hasło.
W WordPressie włącz log debugowania w wp-config.php. Zapisuje on błędy do wp-content/debug.log, nie pokazując ich odwiedzającym:
define( 'WP_DEBUG’, true );
define( 'WP_DEBUG_LOG’, true );
define( 'WP_DEBUG_DISPLAY’, false );
Po skończonej pracy wyłącz go z powrotem, bo log może mocno urosnąć i zawierać wrażliwe dane.
Najczęstsze przyczyny i jak je naprawić
Błąd w kodzie
Nieprzechwycony wyjątek lub błąd krytyczny w kodzie, który buduje stronę. Log pokazuje plik i linię. Typowe przyczyny to funkcja wywołana z danymi, których się nie spodziewała, wartość, która niespodziewanie okazała się pusta, oraz kod, który działa na komputerze programisty, ale wymaga rozszerzenia PHP lub wersji biblioteki, których na serwerze nie ma. Popraw kod albo wróć do ostatniej działającej wersji.
Aktualizacja wtyczki lub motywu
W WordPressie i innych systemach CMS najczęstszą przyczyną jest aktualizacja wtyczki lub motywu. Log podaje nazwę folderu wtyczki. Jeśli nie możesz dostać się do panelu administracyjnego, zmień nazwę tego folderu przez SSH lub SFTP, aby ją wyłączyć:
mv wp-content/plugins/some-plugin wp-content/plugins/some-plugin.disabled
Strona wraca do działania bez niej. Następnie zaktualizuj ją ponownie, zastąp inną albo skontaktuj się z jej autorem, przesyłając błąd z logu.
Uszkodzony plik .htaccess
W Apache jedna błędna linia w .htaccess kładzie całą stronę błędem 500. Log błędów zgłasza Invalid command albo podaje dyrektywę, której nie zrozumiał. Na próbę zmień nazwę pliku, a potem przywracaj linie jedna po drugiej. W WordPressie zapisanie ustawień bezpośrednich odnośników tworzy nowy plik.
PHP zabrakło pamięci
Allowed memory size of 134217728 bytes exhausted oznacza, że żądanie potrzebowało więcej pamięci, niż pozwala memory_limit. Podniesienie limitu może pomóc, ale żądanie, które potrzebuje setek megabajtów, zwykle ładuje naraz zbyt dużo danych. Zanim dasz mu więcej pamięci, sprawdź, co właściwie ładuje.
Uprawnienia i właściciel plików
Po wdrożeniu, przywróceniu kopii lub ręcznym kopiowaniu pliki mogą należeć do niewłaściwego użytkownika. Serwer WWW nie może wtedy odczytać kodu ani zapisywać do folderów cache i uploadów, a w logu pojawia się Permission denied. Przywróć właściciela na użytkownika, jako który działa serwer WWW lub PHP. Katalogi zwykle potrzebują 755, a pliki 644; nigdy nie naprawiaj tego przez 777.
Pełny dysk
Gdy dysk jest pełny, aplikacje nie mogą zapisywać sesji, cache, przesłanych plików ani logów i zawodzą w sposób, który kończy się błędem 500. Sprawdź wolne miejsce i i-węzły:
df -h
df -i
Zwykle winne są stare logi, kopie zapasowe i cache. Monitorowanie serwera z alertem o zajętości dysku na poziomie 80 lub 90 procent wychwyci to na kilka dni, zanim strona przestanie działać.
Błędy połączenia z bazą danych
Zmienione hasło, niedziałający serwer bazy danych albo osiągnięty limit połączeń. Aplikacja nie może niczego załadować i zawodzi na każdej stronie. Log podaje błąd bazy danych. Sprawdź, czy baza działa, czy dane logowania w konfiguracji są aktualne i ile połączeń jest otwartych w porównaniu z limitem.
Błąd 500, który zwraca 200
Nie każda zepsuta strona się do tego przyznaje. Niektóre aplikacje przechwytują błąd i pokazują przyjazną stronę „Coś poszło nie tak” ze statusem 200, a CMS potrafi bez słowa skargi wyrenderować pustą listę produktów. Dla monitora, który patrzy tylko na kod statusu, wszystko wygląda dobrze.
Sprawdzaj też treść. Monitor dostępności może wymagać, aby strona zawierała słowo, które zawsze się na niej pojawia, gdy działa, na przykład nazwę produktu albo „Dodaj do koszyka”, i traktować jego brak jako awarię. Nasza lista kontrolna tego, co monitorować podpowiada, które strony zasługują na taką kontrolę.
Jak monitorowanie wychwytuje błędy 500
Błąd 500 po wdrożeniu może pozostać niezauważony przez wiele godzin, jeśli dotyczy tylko jednej strony. Koszyk przestaje działać, strona główna wciąż działa, a zespół dowiaduje się o problemie z maila od klienta albo ze spadku sprzedaży.
Sprawdzaj strony, które zarabiają. Dodaj monitory dostępności dla koszyka, logowania, rejestracji i API, nie tylko dla strony głównej, z kontrolą treści tam, gdzie status 200 może ukrywać błąd.
Potwierdzaj przed alertem. Uptimecheck sprawdza nawet co minutę ze Sztokholmu, Londynu i Nowego Jorku i potwierdza każdą awarię z drugiej lokalizacji, więc pojedyncze nieudane żądanie nikogo nie budzi.
Zobacz, co się zepsuło. Incydent zawiera nieudaną odpowiedź, w tym kod statusu i stronę błędu, oraz zrzut ekranu tego, co zobaczył odwiedzający.
Testuj całe ścieżki. Logowanie lub zakup, który zawodzi na trzecim kroku, na pierwszym zwraca 200. Wieloetapowe ścieżki przechodzą przez kolejne kroki i mówią Ci, który z nich zawiódł.
Lista kontrolna dla błędu 500
Zapytaj, co zmieniło się w ciągu ostatniej godziny, i wycofaj zmianę, jeśli czas się zgadza.
Znajdź w logu błędów znacznik czasu nieudanego żądania.
Przeczytaj błąd: plik, linię i przyczynę.
Wyklucz typowe przyczyny: wtyczkę, .htaccess, pamięć, uprawnienia, dysk, bazę danych.
Usuń przyczynę, a potem wyłącz wszystkie włączone ustawienia debugowania.
Monitoruj kluczowe strony co minutę, z kontrolą treści tam, gdzie status 200 może ukrywać błąd.
Testuj logowanie i zakupy jako ścieżki, a nie pojedyncze strony.