„500 Internal Server Error“ na stronie w PHP – przyczyny i rozwiązanie

W skrócie: „500 Internal Server Error“ to komunikat zbiorczy. Serwer mówi nim tylko tyle: „coś poszło nie tak“. Na stronach w PHP prawie zawsze chodzi o jedną z czterech przyczyn: błędny plik .htaccess, nową wersję PHP po zmianie wprowadzonej przez hostingodawcę, złe uprawnienia plików albo błąd krytyczny PHP (Fatal Error), którego nie widać, bo wyświetlanie błędów jest wyłączone. Dokładna przyczyna jest zapisana w logu błędów (Error-Log). Warto go przeczytać, zanim cokolwiek zostanie zmienione.

Błąd 500 jest irytujący, bo niczego nie zdradza. Przeglądarka pokazuje pustą stronę, krótki komunikat hostingu albo stronę standardową. Dla klientów i dla Google strona wygląda na zepsutą. Dla Państwa jako właścicieli oznacza to jedno: nie zgadywać, tylko sprawdzić.

Co oznacza ten błąd

Kod statusu 500 informuje, że serwer nie był w stanie obsłużyć zapytania. Celowo bez szczegółów: komunikaty ze ścieżkami, nazwami baz danych czy fragmentami kodu nie powinny trafiać do odwiedzających. Dlatego na serwerach produkcyjnych wyświetlanie błędów PHP jest zwykle wyłączone (display_errors = Off). Tak powinno być – ale przez to awaria PHP widoczna jest na zewnątrz tylko jako błąd 500 albo biała strona.

Najpierw: przeczytać log błędów

Gdzie znaleźć Error-Log

Na hostingu współdzielonym nie ma bezpośredniego dostępu do serwera, ale prawie każdy hostingodawca udostępnia logi. W panelu klienta warto szukać haseł „Logs“, „Protokolle“, „Fehlerprotokoll“ albo „Error-Log“ – u niemieckich firm hostingowych menu jest zwykle po niemiecku. W Plesku logi są przy danej domenie w zakładce „Logs“, w cPanelu w sekcji „Errors“. U niektórych hostingodawców log błędów trzeba najpierw włączyć, a przechowywany jest często tylko przez kilka dni.

Zazwyczaj są dwa rodzaje logów:

• Log błędów serwera WWW (Apache): tu trafiają błędy w .htaccess i problemy z uprawnieniami.
• Log błędów PHP: tu trafiają Fatal Errors, Parse Errors i ostrzeżenia z kodu.

Własny log PHP

Jeśli hosting nie udostępnia logu PHP, można go zapisywać samemu. Gdy PHP działa jako FastCGI lub PHP-FPM, wystarczy plik .user.ini w katalogu głównym:

log_errors = On
error_log = /bezwzgledna/sciezka/poza/katalogiem/www/php-error.log

Ścieżkę bezwzględną widać w programie FTP albo w wyniku phpinfo() przy DOCUMENT_ROOT. Jeśli plik leży poza katalogiem publicznym, nikt nie pobierze go z zewnątrz.

Do szybkiej diagnozy można też na chwilę włączyć wyświetlanie błędów. Na samej górze index.php, zaraz po <?php:

ini_set( 'display_errors', '1' );
error_reporting( E_ALL );

Dwa zastrzeżenia: błędu składni w tym samym pliku to nie pokaże, bo PHP w ogóle go wtedy nie wykona. I te linie trzeba usunąć zaraz po diagnozie.

Jak czytać log

Proszę otworzyć niedziałającą stronę i spojrzeć na najnowsze wpisy z pasującą godziną. Liczą się linie z PHP Fatal error albo PHP Parse error. Komunikaty „Deprecated“ czy „Warning“ nie powodują błędu 500. Na razie można je pominąć, nawet jeśli jest ich dużo.

Przyczyna 1: plik .htaccess

Plik .htaccess steruje przekierowaniami, przyjaznymi adresami URL i regułami bezpieczeństwa. Literówka albo dyrektywa, której serwer nie zna, wyłącza całą stronę. Najszybszy test: zmienić nazwę pliku przez FTP na .htaccess_off. Jeśli strona główna znów się ładuje (podstrony mogą nie działać), błąd siedzi w .htaccess.

Typowe wpisy w logu Apache:

• Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration – php_value działa tylko wtedy, gdy PHP jest modułem Apache. Przy PHP-FPM lub FastCGI kończy się błędem 500. Wartość należy przenieść do .user.ini.
• Invalid command 'Header' albo Invalid command 'RewriteEngine' – odpowiedni moduł Apache nie jest włączony.
• Request exceeded the limit of 10 internal redirects – pętla przekierowań w regułach Rewrite.

Reguły dla opcjonalnych modułów zabezpiecza się blokiem IfModule. Gdy modułu brak, blok jest po prostu pomijany:

<IfModule mod_headers.c>
    Header set X-Content-Type-Options "nosniff"
</IfModule>

Przyczyna 2: nowa wersja PHP po zmianie na hostingu

Hostingodawcy przełączają przestarzałe wersje PHP, bo nie dostają one już poprawek bezpieczeństwa. PHP 7.4 nie ma wsparcia od 28.11.2022, PHP 8.0 od 26.11.2023, PHP 8.1 od 31.12.2025. Zwykle wcześniej przychodzi e-mail – po niemiecku, często z tematem, który łatwo przeoczyć. Potem stary kod przestaje działać. Typowe linie w logu:

PHP Fatal error:  Uncaught Error: Call to undefined function mysql_connect()
PHP Fatal error:  Uncaught Error: Call to undefined function each()
PHP Fatal error:  Uncaught Error: Call to undefined function create_function()

Funkcji mysql_* nie ma od PHP 7.0, a each() i create_function() usunięto w PHP 8.0. Od PHP 8.2 dynamiczne właściwości (dynamic properties) są oznaczone jako przestarzałe. To nie daje błędu 500, ale zapycha log komunikatami Deprecated.

Zdarza się też odwrotna sytuacja: nowoczesne oprogramowanie instalowane przez Composer samo sprawdza wersję PHP. Jeśli działa starsza wersja, niż jest wymagana, w logu pojawia się np. „Composer detected issues in your platform“.

Doraźnie można często wybrać w panelu hostingu starą wersję PHP, czasem tylko za dopłatą. To daje czas, ale nie rozwiązuje problemu: stara wersja nie dostaje poprawek bezpieczeństwa i kiedyś zostanie całkiem wyłączona. Na stałe kod trzeba dostosować do nowej wersji.

Przyczyna 3: złe uprawnienia plików

Na wielu serwerach współdzielonych PHP działa jako Państwa własny użytkownik. Ze względów bezpieczeństwa serwer odrzuca wtedy pliki i foldery, do których mogą zapisywać inni. Efekt: błąd 500 – często po przeprowadzce strony albo gdy ktoś „na wszelki wypadek“ ustawił wszystkiemu 777. W logu pojawiają się wtedy wpisy ze słowami „suexec“ lub „writeable by group“.

Typowe wartości:

• foldery: 755
• pliki: 644
• pliki konfiguracyjne z hasłami: jeśli hosting pozwala, 640 lub 600

Z dostępem SSH ustawia się je tak:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Bez SSH da się to zrobić w programie FTP, np. w FileZilli: prawy przycisk myszy, „Uprawnienia do pliku“, z opcją zastosowania zmian w podkatalogach – osobno dla folderów i plików. Wartość 777 praktycznie nigdy nie jest potrzebna.

Przyczyna 4: Fatal Error przy wyłączonym wyświetlaniu błędów

Wszystko, co zatrzymuje PHP, przy wyłączonym wyświetlaniu błędów wygląda z zewnątrz jak błąd 500. Częste przypadki:

• Parse Error po zmianie w kodzie, np. brakujący średnik albo nawias.
• Niepełny upload: plik dotarł tylko w połowie albo go brakuje. W logu widać wtedy „Failed opening required“ lub „failed to open stream“.
• Brak pamięci: „Allowed memory size of … bytes exhausted“.
• Brakujące rozszerzenie PHP: np. „Call to undefined function imagecreatefromjpeg()“, gdy brakuje GD. Zdarza się to często po zmianie wersji PHP, jeśli w nowej wersji włączone są inne rozszerzenia.

Właściwa kolejność działań

1. Otworzyć Error-Log i znaleźć najnowszy wpis Fatal Error albo komunikat Apache.
2. Jeśli logu brak: testowo zmienić nazwę .htaccess.
3. Sprawdzić w panelu hostingu, czy zmieniła się wersja PHP.
4. Wyrywkowo sprawdzić uprawnienia, zwłaszcza index.php i folderu głównego.
5. Dopiero potem zmieniać kod – i zawsze najpierw zrobić kopię zmienianego pliku.

Czego unikać

• Ustawiania wszystkiego na 777. Na wielu serwerach to dopiero psuje stronę – i otwiera ją na ataki.
• Usuwania .htaccess zamiast zmiany nazwy. Bez niej znikają przekierowania i reguły ochronne, a kopii już nie ma.
• Zostawiania włączonego display_errors na stałe.
• Cofnięcia wersji PHP i zapomnienia o temacie.

Profesjonalna pomoc

Jeśli przyczyny nie da się znaleźć albo log wskazuje błędy głęboko w kodzie, mogę się tym zająć. W ramach naprawy błędów PHP analizuję logi i usuwam błąd w kodzie – analiza 150 € netto, naprawa od 290 € netto. Jeśli błąd 500 pojawił się zaraz po zmianie wersji PHP na hostingu, na stronie zmiana PHP na hostingu opisuję, jak dostosowuję starsze aplikacje do nowej wersji.