Błąd 500 (Internal Server Error) - co oznacza i jak go naprawić?

Dlaczego serwer zwraca błąd 500

Błąd 500 to kod ogólny, do którego trafia wszystko, co zatrzymało aplikację po stronie serwera. W praktyce przyczyny układają się w kilka powtarzalnych grup:

Jak diagnozuję i naprawiam błąd 500

1. Sprawdzam zasięg awarii

Najpierw ustalam, czy błąd dotyczy całej strony, czy tylko wybranych adresów, np. panelu administracyjnego albo koszyka. Sprawdzam to poleceniem, które pokazuje sam kod odpowiedzi:

curl -I https://example.pl/
curl -I https://example.pl/koszyk/

Błąd na całej stronie wskazuje zwykle na konfigurację serwera, .htaccess albo błąd ładowany przy każdym żądaniu, np. we wtyczce. Błąd na jednym adresie wskazuje na kod konkretnej funkcji.

2. Czytam log błędów

To najważniejszy krok, bo log niemal zawsze podaje plik i linię, w której aplikacja się zatrzymała. W zależności od serwera szukam w:

• /var/log/apache2/error.log lub /var/log/httpd/error_log na Apache,
• /var/log/nginx/error.log oraz logu PHP-FPM na Nginx,
• zakładce z logami w panelu hostingu, gdy nie mam dostępu do serwera,
• pliku wp-content/debug.log w WordPressie po włączeniu zapisu błędów.

tail -n 50 /var/log/nginx/error.log
tail -f /var/log/php8.3-fpm.log

W WordPressie włączam zapis błędów do pliku, ale bez wyświetlania ich odwiedzającym:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Jak czytać i filtrować wpisy w logach, pokazuje analiza logów serwera, a od komunikatu do konkretnej linii kodu dochodzę tak samo, jak przy każdym zadaniu, w którym trzeba debugować kod JavaScript i PHP.

3. Wykluczam najczęstsze przyczyny

Gdy logu nie ma albo nic nie wyjaśnia, sprawdzam po kolei:

1. Ostatnią zmianę. Aktualizacja wtyczki, motywu albo wdrożenie nowego kodu to najczęstszy początek awarii. Cofam ją albo przywracam poprzednią wersję z repozytorium.
2. Wtyczki w WordPressie. Gdy panel nie działa, zmieniam nazwę katalogu wp-content/plugins. Jeśli strona wraca, włączam wtyczki pojedynczo, aż błąd się powtórzy.
3. Plik .htaccess. Zmieniam jego nazwę i sprawdzam stronę. Jeśli błąd znika, przywracam reguły po kolei. Wadliwą regułę porównuję z poprawnymi wzorcami, które stosuję w pliku .htaccess.
4. Wersję PHP. Jeśli hosting zmienił wersję PHP, tymczasowo wracam do poprzedniej i aktualizuję kod, który z nową nie działa.
5. Limity. Przy komunikacie o wyczerpaniu pamięci zwiększam memory_limit, ale równolegle szukam, co ją zużywa, bo podnoszenie limitu bez końca ukrywa problem.
6. Uprawnienia. Katalogi ustawiam na 755, pliki na 644 i sprawdzam, czy właścicielem jest użytkownik, z którego działa serwer.

Błąd 500 a widoczność w Google

Krótka awaria nie szkodzi widoczności. Gdy jednak Googlebot przez dłuższy czas dostaje błędy 5xx, ogranicza częstotliwość odwiedzin, a adresy, które zwracają błąd przez wiele dni, mogą wypaść z indeksu. Dlatego po każdej poważniejszej awarii sprawdzam raport indeksowania stron i statystyki indeksowania w Search Console. Przy planowanych pracach technicznych nie zostawiam strony z błędem 500, tylko zwracam błąd 503 z nagłówkiem Retry-After, który informuje wyszukiwarkę, że niedostępność jest chwilowa.

Pozostałe błędy HTTP

Każdy kod błędu wskazuje na inną warstwę, więc diagnozę zaczynam od innego miejsca. Diagnoza pozostałych błędów:

• Błąd 400 (Bad Request)
• Błąd 401 (Unauthorized)
• Błąd 403 (Forbidden)
• Błąd 404 (Not Found)
• Błąd 405 (Method Not Allowed)
• Błąd 502 (Bad Gateway)
• Błąd 503 (Service Unavailable)
• Błąd 504 (Gateway Timeout)