Błąd HTTP 500: przyczyny i naprawa (nginx, Apache)

Czym jest błąd HTTP 500?

Błąd HTTP 500 (Internal Server Error) oznacza, że na serwerze WWW coś się zepsuło podczas obsługi Twojego żądania, a serwer nie powiedział co. To najbardziej ogólny błąd serwera.

Standard HTTP definiuje go jednym zdaniem: „The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request” (RFC 9110 §15.6.1), czyli serwer napotkał nieoczekiwaną sytuację, która uniemożliwiła mu zrealizowanie żądania. W odróżnieniu od 503 nie mówi nic o tym, czy problem jest tymczasowy.

Prawie zawsze jest to błąd w kodzie po stronie serwera, zła konfiguracja albo awaria, a nie coś, co zrobił odwiedzający. Naprawić to musi właściciel lub administrator strony.

Jak wygląda błąd 500

Treść komunikatu zależy od serwera i aplikacji:

• 500 Internal Server Error — standardowy wiersz statusu
• 500 Internal Server Error z napisem „nginx” poniżej — własna strona błędu nginx
• The server encountered an internal error or misconfiguration and was unable to complete your request. — domyślna strona Apache
• W witrynie wystąpił krytyczny błąd. — strona błędu krytycznego WordPressa w polskiej wersji (po angielsku: „There has been a critical error on this website.”)
• HTTP Error 500.19 - Internal Server Error — IIS, gdzie liczba po kropce wskazuje powód (500.19: nieprawidłowe dane konfiguracji)
• Ta strona nie działa · Serwer example.com nie może teraz obsłużyć tego żądania. · HTTP ERROR 500 — Chrome, gdy odpowiedź 500 nie ma własnej strony
• Request failed with status code 500 — Axios i inny kod JavaScript wywołujący API
• 500. That's an error. — własna strona błędu Google

Błąd 500 Internal Server Error w nginx

Najczęściej nginx tylko przekazuje błąd 500 zwrócony przez aplikację za nim (PHP-FPM, Node.js, Python); w przypadku PHP-FPM komunikat błędu PHP trafia do logu nginx. nginx sam zwraca 500 tylko w kilku sytuacjach. Wiersze logu błędów, których warto szukać:

# What did nginx log?
sudo tail -n 50 /var/log/nginx/error.log

# Look for loops in the loaded config
sudo nginx -T | grep -nE 'try_files|rewrite'

(Źródło: kod nginx; awaria lub przeciążenie backendu daje 502 lub 504, a nie 500.)

Najczęstsze przyczyny błędu HTTP 500

Błąd 500 może mieć dziesiątki przyczyn po stronie serwera. Najczęstsze:

• Uszkodzony plik .htaccess — jedna nieprawidłowa dyrektywa lub zła reguła RewriteRule sprawia, że Apache odpowiada 500 dla tego katalogu i wszystkiego pod nim.
• Błędy krytyczne PHP — błędy składni, nieprzechwycone wyjątki lub wywołania niezdefiniowanych funkcji zatrzymują skrypt.
• Limity pamięci lub czasu PHP — skrypt, który przekroczy memory_limit (domyślnie 128M) lub max_execution_time (30 sekund), zostaje zatrzymany.
• Wiersze php_value na serwerze z PHP-FPM — działają tylko z mod_php Apache; pod PHP-FPM Apache odrzuca je błędem 500.
• Złe uprawnienia plików — PHP nie może odczytać dołączanego pliku albo hosting suPHP/suEXEC odrzuca pliki zapisywalne dla wszystkich (777). (Plik, którego nie może odczytać sam serwer WWW, daje 403.)
• Wtyczka lub motyw — nowe albo zaktualizowane rozszerzenie WordPressa, Joomli lub Drupala, które wywraca całą stronę.
• Błędy połączenia z bazą danych — złe dane logowania, zatrzymany serwer bazy danych lub zbyt wiele połączeń.
• Uszkodzone pliki rdzenia — po nieudanej aktualizacji lub przerwanym przesyłaniu plików.
• Pełny dysk — serwer nie może zapisywać logów, sesji ani plików tymczasowych.
• Własne przyczyny nginx — pętla przepisywania adresów, nieczytelny plik z hasłami albo nieudany zapis pliku tymczasowego (często przez pełny dysk); zobacz sekcję o nginx powyżej.

Jak naprawić błąd 500 (jako odwiedzający)

Jeśli widzisz błąd 500 na czyjejś stronie, problem leży po stronie serwera — nie Twojej. Jest jednak kilka rzeczy, które możesz spróbować, zanim się poddasz.

• Przeładuj stronę raz po minucie (F5 lub Cmd+R na Macu). Wiele błędów 500 trwa tylko tyle, co wdrożenie lub restart.
• Sprawdź, czy strona nie działa dla wszystkich — Sprawdzanie, czy strona działa otwiera stronę z 11 miejsc, a Checker nagłówków HTTP pokazuje dokładny kod statusu, który dostaje nasz serwer.
• Usuń ciasteczka tej strony albo spróbuj w oknie prywatnym. Uszkodzone ciasteczko sesji może sprawić, że niektóre aplikacje zawodzą na każdej stronie, ale tylko u Ciebie.
• Spróbuj ponownie później — naprawa jest po stronie serwera, więc daj właścicielowi czas.
• Powiadom właściciela strony, jeśli problem trwa godzinami, podając adres strony i godzinę, o której wystąpił.

Rozwiązanie 1: sprawdź logi błędów serwera

Logi błędów to najważniejsze narzędzie do debugowania błędów 500. Powiedzą Ci dokładnie, co poszło nie tak, łącznie ze ścieżką pliku, numerem linii i komunikatem błędu. Zawsze sprawdzaj logi, zanim spróbujesz czegokolwiek innego.

# Apache (PHP errors appear here too, as "AH01071: Got error 'PHP message: …'")
sudo tail -n 100 /var/log/apache2/error.log      # Debian/Ubuntu
sudo tail -n 100 /var/log/httpd/error_log        # RHEL/Alma/Rocky

# nginx (PHP errors appear here as "FastCGI sent in stderr")
sudo tail -n 100 /var/log/nginx/error.log

# PHP errors on RHEL-family PHP-FPM
sudo tail -n 100 /var/log/php-fpm/www-error.log

# PHP-FPM process log (pool restarts, pm.max_children)
sudo tail -n 100 /var/log/php8.3-fpm.log         # Debian/Ubuntu

# WordPress debug log (with WP_DEBUG_LOG on)
tail -n 100 /path/to/wordpress/wp-content/debug.log

Rozwiązanie 2: przetestuj i napraw .htaccess

Uszkodzony plik .htaccess to klasyczna przyczyna błędów 500 w Apache: jedna literówka, dyrektywa, której serwer nie obsługuje, lub zła reguła RewriteRule wyłącza cały katalog. Log błędów Apache podaje plik .htaccess i błędną dyrektywę, na przykład Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration.

Najszybszy test to tymczasowa zmiana nazwy pliku. Jeśli po zmianie nazwy strona się ładuje, problemem był .htaccess.

# Rename to disable .htaccess
mv .htaccess .htaccess_backup

# If site loads, regenerate a clean .htaccess
# For WordPress, go to Settings > Permalinks and click Save

Rozwiązanie 3: napraw uprawnienia plików

Uprawnienia powodują błąd 500, gdy PHP nie może odczytać dołączanego pliku albo na hostingach suPHP/suEXEC, które odrzucają pliki zapisywalne dla wszystkich. Zwykle ustawia się 644 dla plików i 755 dla folderów. Nigdy nie używaj 777: to ryzyko dla bezpieczeństwa, a na hostingach suEXEC/suPHP samo w sobie powoduje błąd 500.

# Set correct directory permissions
find /path/to/webroot -type d -exec chmod 755 {} \;

# Set correct file permissions
find /path/to/webroot -type f -exec chmod 644 {} \;

# WordPress wp-config.php (extra security; 440 only if the PHP user owns the file or is in its group)
chmod 440 wp-config.php

Rozwiązanie 4: zwiększ limit pamięci i czas wykonywania PHP

PHP zatrzymuje skrypty, które przekroczą limit pamięci lub maksymalny czas wykonania, a odwiedzający dostaje błąd 500. Wartości domyślne, 128M pamięci i 30 sekund, są często za niskie dla ciężkich stron.

Podnieś je tam, gdzie czyta je Twój serwer. Dla PHP-FPM edytuj php.ini PHP-FPM (na przykład /etc/php/8.3/fpm/php.ini) i przeładuj php-fpm; zmiany w .user.ini mogą zacząć działać dopiero po 5 minutach.

# Option 1: php.ini (best)
memory_limit = 256M
max_execution_time = 300

# Option 2: .htaccess (Apache with mod_php only; under PHP-FPM these lines cause a 500)
php_value memory_limit 256M
php_value max_execution_time 300

# Option 3: .user.ini (PHP-FPM and other FastCGI setups)
memory_limit = 256M

# Option 4: wp-config.php (WordPress)
define( 'WP_MEMORY_LIMIT', '256M' );

Rozwiązanie 5: wyłącz wtyczki i motyw (CMS)

Jeśli używasz WordPressa, Joomli lub innego systemu CMS, wadliwa wtyczka lub motyw to jedna z najczęstszych przyczyn błędów 500. Najszybszym sposobem na przetestowanie jest wyłączenie wszystkich wtyczek naraz, a następnie ponowne włączanie ich jedna po drugiej.

# Disable all WordPress plugins (via the file system)
cd /path/to/wordpress/wp-content
mv plugins plugins_disabled

# Or with WP-CLI, without loading the plugin that crashes the site
wp plugin deactivate --all --skip-plugins --skip-themes

# Switch to a default theme (installs it if it was deleted)
wp theme install twentytwentyfive --activate --skip-plugins --skip-themes

# Check WordPress's own files, and reinstall them without touching wp-content
wp core verify-checksums
wp core download --skip-content --force

Rozwiązanie 6: sprawdź połączenie z bazą danych i napraw ją

Błąd 500 może wystąpić, gdy aplikacja nie może połączyć się ze swoją bazą danych. Dzieje się tak, gdy dane uwierzytelniające są błędne, serwer bazy danych nie działa lub tabele są uszkodzone.

Najpierw zweryfikuj dane uwierzytelniające bazy danych w pliku konfiguracyjnym (wp-config.php dla WordPressa, .env dla Laravela). Następnie przetestuj połączenie i w razie potrzeby napraw uszkodzone tabele.

# Test the MySQL connection
mysql -u username -p -h localhost database_name -e "SELECT 1;"

# Check tables (REPAIR only fixes MyISAM/Aria tables; for InnoDB, restore from a backup)
mysqlcheck -u username -p --check --auto-repair database_name

# WordPress: add to wp-config.php, then visit /wp-admin/maint/repair.php
# Remove this line when you're done: the repair page needs no login.
define( 'WP_ALLOW_REPAIR', true );

Rozwiązanie 7: sprawdź kompatybilność wersji PHP

Kod napisany dla starszej wersji PHP może powodować błędy krytyczne w nowszej (lub odwrotnie). Po aktualizacji PHP zwykle winne są usunięte funkcje i zmienione zachowanie; przestarzałe funkcje powodują tylko powiadomienia.

Sprawdź, jaką wersję PHP faktycznie uruchamia Twoja strona. php -v w wierszu poleceń może pokazać inny PHP niż ten, którego używa strona, więc zajrzyj też do panelu hostingu lub na tymczasową stronę phpinfo():

# Command-line PHP (may differ from the site's PHP-FPM)
php -v

# PHP-FPM versions installed (Debian/Ubuntu)
ls /etc/php/

# Modules loaded in the command-line PHP
php -m

Rozwiązanie 8: sprawdź miejsce na dysku

Gdy serwerowi zabraknie miejsca na dysku (lub inodów), nie może zapisywać logów, plików tymczasowych ani danych sesji, a żądania zaczynają kończyć się błędami 500.

# Check disk space, and inodes (they can run out too)
df -h
df -i

# What's using the space?
sudo du -sh /var/log /tmp

# Free space without deleting the log you're reading
sudo find /var/log -name "*.gz" -mtime +14 -delete
sudo journalctl --vacuum-size=200M

500 vs 502 vs 503 vs 504: jaka jest różnica?

Kluczowa różnica: 500 = serwer zepsuł się wewnętrznie. 502 = proxy dostało od backendu bezsensowną odpowiedź. 503 = serwer działa, ale jest zajęty. 504 = proxy przestało czekać. Dokładny kod statusu zwracany przez Twój serwer sprawdzisz w Checkerze nagłówków HTTP DNS Robot.

Jeśli błędem jest 502, aplikacja może działać prawidłowo, a problem leży między proxy a aplikacją. Opisuje to nasz poradnik o błędzie 502 Bad Gateway.

Jak błędy 500 wpływają na SEO

Własna dokumentacja Google opisuje, co się dzieje (dokumentacja robotów Google):

• Skanowanie zwalnia. Przy błędach 5xx Google zmniejsza tempo skanowania witryny, proporcjonalnie do liczby adresów URL zwracających błędy.
• Zaindeksowane strony na początku zostają. Już zaindeksowane adresy URL są przez jakiś czas zachowywane, ale te, które stale zwracają błąd serwera, są usuwane.
• Powrót do normy jest stopniowy. Gdy serwer znów odpowiada kodem 2xx, Google stopniowo zwiększa skanowanie.
• Użyj 503 przy planowanej przerwie na dzień lub dwa, z nagłówkiem Retry-After (Google), aby przerwa była odczytana jako tymczasowa (poradnik o 503).

Jak zapobiegać błędom 500

Zapobieganie jest zawsze lepsze niż debugowanie. Stosuj te najlepsze praktyki, aby zminimalizować ryzyko błędów 500 na swojej stronie.

• Ustaw monitoring dostępności — Użyj narzędzi takich jak UptimeRobot lub Pingdom, aby sprawdzać stronę co 1-5 minut. Otrzymuj natychmiastowe alerty, gdy wystąpi błąd 500.
• Zawsze testuj zmiany na środowisku stagingowym — Nigdy nie wdrażaj bezpośrednio na produkcję. Testuj aktualizacje wtyczek, uaktualnienia PHP i zmiany konfiguracji na środowisku testowym.
• Używaj kontroli wersji (Git) — Commituj każdą zmianę, abyś mógł natychmiast cofnąć wadliwe wdrożenie jednym poleceniem.
• Implementuj prawidłową obsługę błędów — Otaczaj zapytania bazodanowe i wywołania API blokami try-catch. Loguj pełne ścieżki stosu po stronie serwera dla każdego błędu.
• Monitoruj miejsce na dysku i zasoby serwera — Ustaw alerty dla zużycia dysku powyżej 80%, wysokiego CPU i nacisku na pamięć.
• Aktualizuj oprogramowanie — Przestarzałe wersje CMS, wtyczek i oprogramowania serwera zawierają znane błędy powodujące awarie.
• Utrzymuj automatyczne kopie zapasowe — Regularnie testuj procedurę przywracania. Kopia zapasowa, której nigdy nie testowałeś, nie jest kopią zapasową.
• Ustaw odpowiednie limity PHP — Skonfiguruj memory_limit i max_execution_time na podstawie faktycznego obciążenia, a nie domyślnych wartości.
• Używaj pipelinów CI/CD — Automatyzuj testowanie przed wdrożeniem. Jeśli testy zawiodą, wdrożenie nie powinno być kontynuowane.