Jak czytać log błędów serwera i znaleźć przyczynę awarii strony?

Log nie jest wyrocznią ani automatyczną diagnozą. Jest chronologicznym zapisem zdarzeń, z którego trzeba wybrać wpis odpowiadający czasowi, adresowi i objawowi awarii. Najnowsza linia nie zawsze dotyczy Twojego testu, a słowo „warning” nie musi oznaczać przyczyny niedziałającej strony.

Krótka odpowiedź: odtwórz błąd jeden raz, zapisz dokładną godzinę, strefę czasową, URL i wykonane działanie. Następnie sprawdź log błędów serwera WWW, log PHP oraz — jeśli dotyczy — log aplikacji WordPress. Szukaj pierwszego błędu krytycznego w tym samym przedziale czasu, odczytaj ścieżkę pliku i stos wywołań, a potem potwierdź hipotezę kontrolowanym testem. Przed zmianami wykonaj kopię i nie publikuj surowego logu, ponieważ może zawierać adresy, ścieżki, parametry lub inne dane wrażliwe.

Który log właściwie czytasz?

Na typowym hostingu możesz spotkać kilka osobnych źródeł:

access log — zapisuje żądania, adresy, metody, statusy i często czas odpowiedzi;
error log serwera WWW — błędy Apache lub Nginx, reguł, dostępu i komunikacji z aplikacją;
log PHP — ostrzeżenia, wyjątki i błędy wykonywanego kodu;
log aplikacji — np. wp-content/debug.log, jeśli został świadomie włączony;
log proxy lub CDN — ważny przy odpowiedziach 502, 503 i 504;
log bezpieczeństwa — blokady WAF, limitów logowania albo reguł antybotowych.

Apache określa error log jako najważniejszy dziennik diagnostyczny serwera, ale aplikacje i moduły mogą zapisywać komunikaty w różnych miejscach. Brak wpisu w jednym pliku nie oznacza braku błędu.

Gdzie znaleźć log na hostingu?

Nazwy zależą od operatora. Szukaj sekcji „Logi”, „Error log”, „Błędy PHP”, „Statystyki”, „Menedżer plików” albo narzędzia diagnostycznego. Na serwerze zarządzanym log może być dostępny przez panel, SSH lub systemowy dziennik usługi.

Przed pobraniem ustal:

jaką strefę czasową stosuje log;
czy pokazuje bieżące wpisy, czy dane z opóźnieniem;
jak długo są przechowywane;
czy dotyczy właściwej domeny i wersji PHP;
czy rotacja nie przeniosła wpisu do starszego pliku.

Nie zmieniaj uprawnień katalogów systemowych tylko po to, aby samodzielnie dostać się do logu. Na hostingu współdzielonym poproś operatora o fragment dla konkretnej godziny.

Procedura: od objawu do właściwej linii

1. Zapisz stan przed testem

Zanotuj pełny URL, urządzenie, konto użytkownika, godzinę ze strefą czasową i kroki prowadzące do błędu. Jeśli awaria dotyczy formularza, użyj testowych danych bez informacji osobowych.

2. Odtwórz błąd tylko raz

Jedno kontrolowane żądanie tworzy czytelniejszy ślad niż dwadzieścia odświeżeń. Jeśli operacja może zapisać płatność, rezerwację lub zamówienie, nie powtarzaj jej na produkcji bez planu testowego.

3. Sprawdź status odpowiedzi

Ustal, czy przeglądarka otrzymała 403, 404, 500, 502, 503 czy 504. Status zawęża warstwę problemu, ale sam nie wskazuje przyczyny. Zapisz również identyfikator żądania, jeżeli odpowiedź lub panel go udostępnia.

4. Otwórz mały przedział czasu

Zacznij od kilkudziesięciu sekund przed testem i po nim. Dopiero gdy niczego nie znajdziesz, rozszerz zakres. Porównaj access log z error logiem: pierwsze źródło potwierdza, że żądanie dotarło, drugie może opisać niepowodzenie.

5. Znajdź pierwszy istotny błąd

Kolejne komunikaty mogą być skutkiem pierwszego problemu. Przykładowo błąd połączenia z bazą może wywołać później ostrzeżenia o braku danych. Czytaj od najwcześniejszego wpisu w badanym żądaniu.

Jak rozłożyć wpis logu na części?

Typowy wpis może zawierać:

[data i czas] [poziom] [proces lub moduł] komunikat, plik:linia

Interpretuj kolejno:

czas — czy odpowiada testowi i jakiej strefy używa;
poziom — informacja, ostrzeżenie, błąd lub zdarzenie krytyczne;
moduł/proces — Apache, PHP-FPM, proxy, aplikacja;
komunikat — rodzaj niepowodzenia;
plik i linia — miejsce ujawnienia błędu, nie zawsze jego pierwotna przyczyna;
request ID / PID — sposób połączenia wpisów jednego żądania;
stack trace — kolejność wywołań prowadząca do wyjątku.

Ścieżka w katalogu wtyczki jest ważną wskazówką, ale nie zawsze dowodzi winy tej wtyczki. Mogła otrzymać nieprawidłowe dane z innego komponentu albo ujawnić konflikt wersji.

Fatal error, warning i notice — nie traktuj ich jednakowo

Fatal error albo nieobsłużony wyjątek może zatrzymać wykonanie żądania i bezpośrednio prowadzić do 500 lub krytycznego błędu WordPressa.

Warning oznacza problem, przy którym kod często działa dalej. Powtarzające się ostrzeżenia wymagają analizy, ale wpis sprzed tygodnia nie wyjaśnia dzisiejszej awarii.

Notice/deprecated sygnalizuje niepoprawną praktykę albo funkcję przewidzianą do wycofania. To cenna informacja przed aktualizacją, lecz zwykle nie jest samodzielną przyczyną nagłego wyłączenia strony.

Wzorce, które pomagają, ale nie zastępują diagnozy

Fragment komunikatu	Możliwy kierunek	Co sprawdzić dalej
`Allowed memory size exhausted`	limit pamięci lub niekontrolowane zużycie	proces, wtyczkę, rozmiar operacji i metryki pamięci
`Maximum execution time exceeded`	proces trwał zbyt długo	zapytania, zewnętrzne API, cron i limity warstw
`Permission denied`	prawa, właściciel albo reguła dostępu	konkretną ścieżkę i użytkownika procesu
`Call to undefined function`	niezgodność kodu, brak rozszerzenia lub kolejność ładowania	wersje PHP, komponent i moment aktualizacji
`Table ... doesn't exist`	brak lub zły prefiks tabeli	właściwą bazę, migrację i kopię
`upstream timed out`	backend nie odpowiedział na czas	log aplikacji w tej samej sekundzie i obciążenie

Nie zwiększaj automatycznie limitu tylko dlatego, że pojawia się jego nazwa. Limit może ujawniać pętlę lub ciężkie zapytanie, które trzeba naprawić.

Jak potwierdzić hipotezę?

Połącz przynajmniej trzy elementy: identyczny czas, zgodny URL lub identyfikator oraz objaw pasujący do komunikatu. Następnie na stagingu wykonaj najmniejszą odwracalną zmianę — np. wróć do poprzedniej wersji jednego komponentu — i powtórz ten sam test.

Nie usuwaj logu przed potwierdzeniem naprawy. Zapisz fragment „przed”, zmianę i wynik „po”. Dzięki temu kolejna osoba nie zacznie diagnozy od zera.

Bezpieczeństwo i prywatność logów

Log może zawierać adres IP, pełny URL z parametrami, adres e-mail, nazwę konta, ścieżkę serwera, user-agent, identyfikator sesji albo fragment żądania. Przed wysłaniem:

wytnij tylko potrzebny przedział;
zamaskuj dane osobowe i sekrety;
nie publikuj logów na forum w pełnej postaci;
przekaż plik bezpiecznym kanałem;
zachowaj oryginał z kontrolowanym dostępem;
ustal rozsądny czas retencji.

Co przekazać hostingowi lub wykonawcy?

Przygotuj: czas ze strefą, URL, kroki, status HTTP, wpływ na użytkowników, ostatnie zmiany, fragment logu przed i po zdarzeniu oraz informację, czy błąd jest powtarzalny. Nie wysyłaj samego zrzutu komunikatu „strona nie działa”.

Dobry log nie naprawia strony, ale zamienia zgadywanie w testowalną hipotezę. Największą wartość daje wtedy, gdy został skorelowany z jednym kontrolowanym żądaniem i zachowany jako dowód diagnozy.