Logi serwera dla początkujących: gdzie szukać przyczyny błędu 500, 403 i białej strony

Strona pokazała biały ekran albo komunikat „500 Internal Server Error" i nie wiesz, od czego zacząć. Zanim zadzwonisz do dewelopera lub supportu, w 90% przypadków odpowiedź już czeka — w logach serwera. To zapis każdego żądania i każdego błędu, jaki napotkała Twoja strona. Pokazujemy, gdzie szukać przyczyny błędów 500, 403 i białej strony, jak czytać poszczególne logi i jak bezpiecznie przekazać informacje osobie, która ma to naprawić.

Trzy logi, które rozwiązują większość problemów

Serwer prowadzi kilka dzienników. Dla diagnozy strony liczą się przede wszystkim trzy:

Na hostingu współdzielonym najłatwiej dostać się do nich przez panel (cPanel/DirectAdmin mają sekcję „Logi" i „Metryki"). Na VPS znajdziesz je w katalogach systemowych serwera (np. /var/log/). Kluczowa zasada: patrz na wpis z dokładnym znacznikiem czasu awarii — błąd, który widzi użytkownik, zostawia w error logu wpis dokładnie w momencie wystąpienia.

Błąd 500 — serwer „się wywrócił"

Kod 500 Internal Server Error to ogólny komunikat: „coś poszło nie tak po stronie serwera". Sam w sobie nic nie mówi — prawdziwa przyczyna jest w error logu. Najczęstsze źródła:

• Błąd PHP — niezgodna wtyczka, błąd składni w kodzie, wyczerpanie limitu pamięci (Allowed memory size exhausted). W logu zobaczysz PHP Fatal error z nazwą pliku i numerem linii — to bezcenna wskazówka.
• Zła wersja PHP — wtyczka lub motyw niezgodny z nowszym PHP po aktualizacji. Klasyka po migracji lub aktualizacji.
• Uszkodzony .htaccess — błędna reguła przepisywania potrafi wywalić całą stronę. W logu pojawi się wpis o nieprawidłowej dyrektywie.
• Wyczerpane limity konta — gdy kończą się procesy/CPU, serwer może zwracać 500/503/508. To nie błąd kodu, lecz zasobów.

Pierwszy ruch: otwórz error log, znajdź ostatni wpis z czasu awarii i odczytaj, czy mówi o PHP, o pamięci, o .htaccess czy o limicie.

Błąd 403 — „dostęp zabroniony"

Kod 403 Forbidden oznacza, że serwer zrozumiał żądanie, ale odmawia dostępu. Najczęstsze przyczyny:

• Błędne uprawnienia plików/katalogów (np. katalog 700 zamiast 755, plik 600 zamiast 644) — serwer nie może odczytać zasobu.
• Reguła w .htaccess blokująca dostęp (ochrona katalogu, blokada po IP, reguły bezpieczeństwa).
• Brak pliku indeksu i wyłączony listing katalogu.
• Zadziałanie WAF / reguł bezpieczeństwa (np. ModSecurity), które uznały żądanie za podejrzane — w error logu pojawi się wtedy wpis z identyfikatorem reguły, którą trzeba pokazać supportowi.

Biała strona (WSOD) — nic się nie wyświetla

„Biały ekran śmierci" (White Screen of Death) to zwykle błąd PHP, który zatrzymał wykonanie skryptu, a wyświetlanie błędów jest wyłączone (poprawnie — na produkcji). Strona nie pokazuje nic, ale error log i tak zapisuje przyczynę. W WordPressie typowe źródła to konflikt wtyczek, wyczerpanie pamięci PHP albo błąd motywu po aktualizacji. W logu szukaj PHP Fatal error z nazwą konkretnej wtyczki lub pliku — to ona prowadzi prosto do winowajcy.

Access log — kontekst, którego brakuje

Gdy error log nie wystarcza, access log dopowiada resztę. Każdy wiersz to jedno żądanie: adres IP, czas, metoda, ścieżka, kod odpowiedzi i często user-agent. Co z niego wyczytasz:

• Serię kodów 500/403 przy konkretnym adresie URL — wskazuje, która podstrona jest źródłem.
• Nagły zalew żądań z jednego IP lub bota — możliwa przyczyna przeciążenia i wyczerpania limitów (a stąd błędów 508).
• Skąd przyszedł ruch tuż przed awarią — np. skok po publikacji albo atak.

Jak bezpiecznie przekazać informacje deweloperowi

Im konkretniej, tym szybsza naprawa. Zamiast „strona nie działa", przekaż:

• Dokładny komunikat z error logu (cały wpis z czasem, nazwą pliku i numerem linii), a nie tylko „błąd 500".
• Czas wystąpienia i co działo się tuż przed (aktualizacja wtyczki, zmiana motywu, import danych).
• Adres URL, na którym błąd się pojawia, i czy dotyczy całej strony, czy jednej podstrony.

I dwie zasady bezpieczeństwa, o których łatwo zapomnieć: nigdy nie wklejaj logów publicznie (na forum, w komentarzu, w zgłoszeniu otwartym) — mogą zawierać ścieżki serwera, adresy IP, a czasem fragmenty danych. Nie wysyłaj haseł ani kluczy z plików konfiguracyjnych. Logi przekazuj kanałem prywatnym (zgłoszenie u hostingu, bezpośrednia wiadomość do dewelopera), a wrażliwe fragmenty zamaskuj.

Skąd biorą się błędy po przenosinach i jak ich uniknąć

Najczęściej zadawane pytania

Gdzie znajdę logi na hostingu współdzielonym?

W panelu (cPanel/DirectAdmin) w sekcji „Logi" lub „Metryki", albo jako plik error_log w katalogu strony. Jeśli go nie widzisz, poproś support o ścieżkę albo włączenie zapisu logów.

Błąd 500 nic mi nie mówi — jak znaleźć przyczynę?

Sam kod 500 jest ogólny. Otwórz error log i znajdź wpis z czasu awarii — to on poda konkret: błąd PHP, brak pamięci, problem z .htaccess albo limit zasobów.

Czemu widzę białą stronę zamiast komunikatu o błędzie?

Bo na produkcji wyświetlanie błędów jest (słusznie) wyłączone. Przyczyna i tak trafia do error logu — tam jej szukaj, najczęściej jako PHP Fatal error z nazwą wtyczki lub pliku.

Czy mogę wkleić log na forum, żeby ktoś pomógł?

Lepiej nie. Logi bywają pełne ścieżek serwera, adresów IP i wrażliwych danych. Przekazuj je kanałem prywatnym i zamaskuj poufne fragmenty.

Podsumowanie

Logi serwera to nie magia dla adminów — to dziennik, który niemal zawsze zawiera odpowiedź. Błąd 500 czytaj z error logu (PHP, pamięć, .htaccess, limity), 403 wiąż z uprawnieniami i regułami dostępu, a białą stronę traktuj jak ukryty błąd PHP, którego przyczyna i tak jest zapisana. Access log dorzuca kontekst: który URL, ile żądań, skąd ruch. Zanim oddasz problem deweloperowi, zbierz dokładny wpis z logu, czas i adres — i przekaż je bezpiecznie, kanałem prywatnym, bez haseł i danych. To zamienia godziny zgadywania w kilkuminutową naprawę.

Źródła i dalsza lektura