Czym są logi serwera i co można z nich wyczytać

Logi serwera to automatycznie zapisywane dzienniki zdarzeń, które pokazują, co dzieje się z witryną na poziomie HTTP, aplikacji i samego serwera. Dzięki nim można sprawdzić, kiedy strona przestała działać, jaki adres był wywoływany, jaki kod odpowiedzi zwrócił serwer i czy pojawił się błąd po stronie hostingu, konfiguracji albo skryptu.

W praktyce najczęściej korzysta się z dwóch typów logów:

• logi dostępu (np. access.log) — zapisują każde żądanie do strony, wraz z adresem IP, czasem, URL-em, metodą HTTP i kodem odpowiedzi;
• logi błędów (np. error.log, php_error.log) — zawierają ostrzeżenia, błędy krytyczne i komunikaty pomocne przy diagnozie awarii.

To właśnie w logach najłatwiej znaleźć odpowiedź na pytania: czy problem dotyczy całej strony, tylko jednego adresu, konkretnej wtyczki, pliku czy konfiguracji serwera. Jeśli witryna pokazuje błąd 500, 502, 503 albo 504, logi zwykle wskazują, czy źródłem jest przeciążenie, limit pamięci, zła reguła w konfiguracji, awaria PHP, brak uprawnień czy błąd aplikacji.

Warto pamiętać, że log nie zawsze podaje gotową diagnozę. Często pokazuje jedynie objaw, a nie bezpośrednią przyczynę. Na przykład wpis o błędzie PHP może wynikać z konfliktu wtyczek, a 403 z nieprawidłowych uprawnień albo blokady w pliku konfiguracyjnym. Dlatego analiza logów polega na łączeniu kilku informacji: czasu, kodu błędu, adresu URL i kolejnych wpisów przed oraz po awarii.

Jeśli chcesz szybko ocenić, co się stało, zwróć uwagę przede wszystkim na:

• kod HTTP zwrócony przez serwer;
• dokładny czas wystąpienia problemu;
• ścieżkę do pliku lub zasobu, którego dotyczy błąd;
• komunikaty o braku pamięci, uprawnień, przekroczeniu limitu lub błędzie składni;
• powtarzające się wpisy, które pojawiają się tuż przed awarią.

Właśnie dlatego analiza logów jest jednym z najszybszych sposobów diagnozy błędów strony — pozwala zawęzić problem bez zgadywania i bez zgadywania, czy winny jest hosting, konfiguracja czy sama aplikacja.

Gdzie znaleźć logi na hostingu, VPS i serwerze dedykowanym

Lokalizacja logów zależy od rodzaju usługi i panelu administracyjnego, ale zasada jest podobna: najpierw szukasz logów przypisanych do konkretnej domeny, a dopiero potem do całego serwera. W praktyce najwygodniej zacząć od panelu hostingu, bo tam często znajdziesz gotową sekcję z plikami diagnostycznymi, bez konieczności logowania się przez SSH.

Na hostingu współdzielonym logi zwykle są dostępne w panelu klienta albo w menedżerze plików. Najczęściej spotkasz tam:

• error_log lub php_error.log — logi błędów PHP i aplikacji;
• access.log — logi dostępu, czyli historię żądań HTTP;
• oddzielne logi dla każdej domeny, subdomeny lub katalogu publicznego;
• sekcję typu „Logi”, „Dzienniki”, „Diagnostyka” albo „Błędy serwera”.

Jeśli panel hostingu nie pokazuje logów od razu, sprawdź ustawienia domeny lub strony. Często trzeba włączyć podgląd błędów, pobrać archiwum logów albo wskazać konkretny katalog witryny. W niektórych usługach logi są rotowane i dostępne tylko z ostatnich godzin lub dni, więc warto reagować szybko po wystąpieniu awarii.

Na VPS i serwerze dedykowanym najczęściej korzysta się z dostępu przez SSH. Tam logi znajdują się zwykle w katalogach systemowych serwera WWW i zależą od używanego oprogramowania:

• dla Apache — najczęściej w katalogach typu /var/log/apache2/ lub /var/log/httpd/;
• dla Nginx — zwykle /var/log/nginx/;
• dla PHP-FPM — osobne logi puli lub pliki błędów usługi;
• dla konkretnych aplikacji — dodatkowe logi w katalogu projektu lub w folderze logs.

W środowiskach zarządzanych przez panele typu Plesk, cPanel, DirectAdmin czy podobne rozwiązania, logi mogą być widoczne zarówno w panelu, jak i w plikach na serwerze. Warto wtedy sprawdzić, czy interesują Cię logi całego hosta, czy tylko jednej strony. To ważne, bo ten sam serwer może obsługiwać wiele witryn, a problem jednej z nich nie zawsze pojawi się w głównym logu systemowym.

Jeżeli diagnozujesz konkretną awarię, szukaj logów w tej kolejności:

1. panel hostingu i sekcja logów domeny;
2. log błędów serwera WWW;
3. log PHP lub PHP-FPM;
4. log aplikacji lub CMS;
5. log systemowy, jeśli problem dotyczy wydajności, połączeń lub uprawnień.

Wskazówka praktyczna: jeśli nie wiesz, od czego zacząć, sprawdź najpierw log błędów przypisany do domeny, a dopiero potem access.log. To zwykle najszybsza droga do znalezienia momentu, w którym strona zaczęła zwracać błędy 500, 502, 503 lub 504.

Jak czytać wpis w logu i rozpoznać, co jest ważne

Sam wpis w logu na początku może wyglądać jak ciąg przypadkowych znaków, ale zwykle zawiera kilka stałych elementów, które pozwalają szybko ocenić sytuację. Najważniejsze są: data i godzina, adres URL, kod odpowiedzi HTTP, komunikat błędu oraz informacja o pliku, module lub procesie, który wywołał problem.

Przykładowy wpis z logów serwera może zawierać informację, że żądanie do konkretnej podstrony zakończyło się kodem 500, a tuż obok pojawił się komunikat o błędzie PHP, braku pamięci albo nieudanej operacji na pliku. To właśnie te szczegóły są ważniejsze niż sam fakt, że strona „nie działa”.

Podczas analizy logów zwracaj uwagę na kilka rzeczy naraz, a nie na pojedynczy komunikat:

• czas zdarzenia — czy wpis pojawia się dokładnie w momencie awarii;
• powtarzalność — czy błąd występuje wielokrotnie dla tego samego URL;
• ścieżkę do pliku — czy problem dotyczy konkretnego skryptu, obrazu, zasobu lub katalogu;
• kod HTTP — 200 oznacza poprawną odpowiedź, 301 i 302 przekierowanie, 403 brak dostępu, 404 brak pliku, 500 błąd serwera, a 502, 503 i 504 zwykle wskazują na problem z usługą, przeciążeniem lub komunikacją między komponentami;
• treść komunikatu — słowa takie jak „permission denied”, „allowed memory size exhausted”, „timeout”, „undefined function” czy „failed to open stream” często od razu podpowiadają źródło problemu.

Warto też rozumieć, że access.log i error.log pokazują różne rzeczy. W logu dostępu zobaczysz, że użytkownik wszedł na stronę i dostał konkretny kod odpowiedzi. W logu błędów pojawi się natomiast przyczyna, na przykład wyjątek aplikacji, problem z uprawnieniami albo błąd składni w konfiguracji. Jeśli w access.log widać wiele żądań do tej samej podstrony z kodem 500, a w error.log tuż obok pojawia się komunikat PHP, masz już mocną wskazówkę, gdzie szukać dalej.

Pomocne jest również odróżnianie wpisów istotnych od szumu. Nie każdy warning oznacza awarię, a nie każdy komunikat o dostępie musi być problemem. W praktyce najważniejsze są wpisy, które:

• pojawiają się tuż przed pierwszym błędem widocznym dla użytkownika;
• powtarzają się w krótkim czasie;
• dotyczą tej samej domeny, katalogu lub skryptu;
• zawierają konkretny kod błędu lub nazwę modułu;
• wskazują zmianę stanu, na przykład przejście z poprawnych odpowiedzi 200 do błędów 500 albo 403.

Najprostsza zasada: jeśli masz wiele wpisów, najpierw szukaj tego pierwszego, który odróżnia się od poprzednich. To często właśnie on pokazuje moment, w którym zaczęła się awaria, nawet jeśli kolejne komunikaty są już tylko skutkiem ubocznym. W ten sposób analiza logów staje się dużo szybsza i bardziej precyzyjna.

Krok po kroku: jak namierzyć źródło błędu strony

Najlepsza diagnoza zaczyna się od prostej zasady: najpierw ustal moment awarii, potem sprawdź logi w tym samym przedziale czasu. Nie analizuj całego pliku od początku do końca, jeśli problem pojawił się o konkretnej godzinie. W praktyce wystarczy zawęzić okno do kilku minut przed i po błędzie, aby zobaczyć pierwszy wpis, który uruchomił lawinę kolejnych komunikatów.

W pierwszym kroku odtwórz objaw. Zapisz:

• dokładną godzinę wystąpienia problemu;
• adres URL, który przestał działać;
• kod błędu widoczny w przeglądarce, na przykład 500, 502, 503, 504 albo 403;
• czy awaria dotyczy całej strony, czy tylko jednej podstrony;
• jakie zmiany wykonano tuż przed problemem, na przykład aktualizację wtyczki, zmianę konfiguracji lub migrację plików.

Następnie przejdź do logów dostępu i logów błędów. W access.log sprawdź, czy żądanie do problematycznego adresu kończy się kodem innym niż 200. Jeśli widzisz serię 500 lub 503 dla jednego URL, porównaj te wpisy z error.log. To właśnie tam często znajdziesz komunikat o braku pamięci, błędzie PHP, timeoutcie, problemie z uprawnieniami albo niedostępnym pliku.

Dobrym nawykiem jest porównanie kilku kolejnych wpisów. Szukaj momentu, w którym sytuacja się zmienia, na przykład:

• z odpowiedzi 200 na 500;
• z poprawnego ładowania strony na timeout;
• z jednego konkretnego pliku na serię błędów w tym samym katalogu;
• z działania po aktualizacji do awarii po uruchomieniu konkretnego skryptu lub wtyczki.

Jeśli log pokazuje błąd 500, nie zatrzymuj się na samym kodzie. Sprawdź, czy obok nie ma informacji typu allowed memory size exhausted, permission denied, failed to open stream albo syntax error. Każdy z tych komunikatów wskazuje inny kierunek diagnozy: pamięć, uprawnienia, ścieżki do plików lub błąd składni.

W przypadku 502 i 504 skup się na komunikacji między komponentami. Tego typu błędy często oznaczają, że serwer WWW nie dostał odpowiedzi od PHP-FPM, backendu aplikacji, proxy albo zewnętrznej usługi. Wtedy sprawdź także logi usług pomocniczych, a nie tylko log domeny.

Przy błędzie 403 szukaj problemów z dostępem. Przyczyny zwykle są proste: zbyt restrykcyjne uprawnienia do plików, blokada w .htaccess, reguła bezpieczeństwa, błędna konfiguracja katalogu lub filtr po stronie hostingu. Gdy pojawia się 404, sprawdź, czy plik naprawdę istnieje, czy link nie jest stary i czy aplikacja generuje poprawne ścieżki do zasobów.

W diagnostyce pomaga też metoda eliminacji:

1. Sprawdź, czy problem dotyczy jednej strony czy wielu. Jeśli tylko jednej, winny jest częściej plik, wtyczka albo reguła dla konkretnego adresu.
2. Porównaj czas błędu z ostatnimi zmianami. Jeśli awaria zaczęła się zaraz po aktualizacji, masz mocną wskazówkę.
3. Przejrzyj pierwszy nietypowy wpis. Często to on ujawnia prawdziwe źródło problemu, a kolejne błędy są już skutkiem ubocznym.
4. Sprawdź, czy błąd powtarza się po odświeżeniu strony. Jeśli tak, łatwiej namierzyć stały element, a nie jednorazowy incydent.
5. Jeśli trzeba, wyłączaj elementy po kolei. W aplikacji może to oznaczać test wtyczek, modułów, reguł cache lub ostatnio dodanego kodu.

W praktyce dobra diagnoza to połączenie trzech danych: czasu, kodu błędu i pierwszego komunikatu w logu. Gdy te elementy pasują do siebie, zwykle da się bardzo szybko ustalić, czy źródłem jest aplikacja, konfiguracja, uprawnienia, zasoby serwera czy zewnętrzna usługa.

Krótka checklista diagnozy:

• ustal godzinę awarii;
• sprawdź access.log i error.log dla tego samego przedziału czasu;
• znajdź pierwszy wpis różniący się od pozostałych;
• zwróć uwagę na kod HTTP i komunikaty typu memory, timeout, permission, syntax, stream;
• porównaj log z ostatnimi zmianami w aplikacji lub konfiguracji.

Jeśli po tej analizie nadal nie widać przyczyny, zrób zrzut najważniejszych wpisów i przekaż je supportowi hostingu lub osobie utrzymującej aplikację. Najlepiej podać dokładny czas, adres URL, kod błędu i krótki fragment logu z okolicy awarii.

Najczęstsze błędy w logach i co zwykle oznaczają

W logach serwera najczęściej pojawiają się powtarzalne kody i komunikaty, które już na pierwszy rzut oka zawężają zakres problemu. Nie zawsze oznaczają one dokładną przyczynę, ale zwykle wskazują, gdzie zacząć szukanie: w plikach aplikacji, konfiguracji serwera, uprawnieniach, bazie danych albo po stronie hostingu.

Najlepiej odczytywać błąd w kontekście: czy dotyczy jednej podstrony, całej domeny, konkretnego pliku, a może pojawił się dopiero po aktualizacji. Ten sam kod HTTP może mieć różne źródła, ale pewne wzorce powtarzają się bardzo często.

• 500 Internal Server Error — najczęściej ogólny błąd aplikacji lub konfiguracji. W logach często widać obok niego syntax error, allowed memory size exhausted, permission denied albo failed to open stream. To sygnał, że problem leży w skrypcie, uprawnieniach, pliku konfiguracyjnym lub limicie zasobów.
• 502 Bad Gateway — zwykle oznacza, że serwer WWW nie dostał poprawnej odpowiedzi od backendu, np. PHP-FPM, proxy lub innej usługi pośredniczącej. Często towarzyszy mu timeout, restart usługi albo przeciążenie.
• 503 Service Unavailable — najczęściej wskazuje na chwilową niedostępność usługi, tryb konserwacji, przeciążenie albo limit zasobów. Na hostingu współdzielonym bywa związany z dużym ruchem lub limitami konta.
• 504 Gateway Timeout — backend odpowiedział zbyt wolno albo wcale. To typowy ślad problemów z wydajnością, bazą danych, zewnętrznym API lub zbyt ciężkim zapytaniem.
• 403 Forbidden — problem z dostępem. Zwykle chodzi o uprawnienia plików, regułę w .htaccess, blokadę bezpieczeństwa, błędną konfigurację katalogu albo filtr hostingu.
• 404 Not Found — zasób nie został znaleziony. Może to oznaczać brak pliku, złą ścieżkę, uszkodzony link, błędny rewrite albo problem z generowaniem adresów przez aplikację.

W logach PHP często pojawiają się też komunikaty, które są bardziej konkretne niż sam kod HTTP. Do najważniejszych należą:

• allowed memory size exhausted — skrypt zużył za dużo pamięci; możliwy ciężki plugin, pętla, duży import lub zbyt niski limit PHP;
• maximum execution time exceeded lub timeout — proces trwał za długo, co bywa skutkiem wolnej bazy danych, zewnętrznej usługi lub źle zoptymalizowanego kodu;
• permission denied — brak uprawnień do pliku lub katalogu;
• failed to open stream — aplikacja nie może otworzyć pliku, zwykle z powodu złej ścieżki, braku pliku lub ograniczeń uprawnień;
• undefined function albo call to undefined method — aplikacja wywołuje funkcję, która nie istnieje, często po aktualizacji wtyczki, biblioteki lub PHP;
• syntax error — błąd składni w pliku PHP, konfiguracji lub regule serwera.

Warto też zwrócić uwagę na komunikaty z logów serwera WWW, bo potrafią zdradzić problem infrastrukturalny. Jeśli widzisz wpisy o zamkniętym połączeniu, braku odpowiedzi backendu, błędach proxy lub nieudanym przekazaniu żądania, prawdopodobnie nie jest to błąd samej strony, tylko warstwy pośredniej.

Praktyczna interpretacja wygląda tak:

• jeśli błąd pojawia się tylko przy jednym adresie, podejrzewaj konkretny skrypt, szablon lub regułę przepisywania;
• jeśli dotyczy całej witryny, sprawdzaj konfigurację serwera, PHP, limity zasobów i dostępność usług;
• jeśli błąd zaczął się po zmianie, porównaj logi sprzed i po wdrożeniu;
• jeśli komunikat powtarza się cyklicznie, szukaj zadania cron, importu, kopii zapasowej albo zewnętrznego wywołania, które wywołuje awarię.

Najważniejsza zasada: sam kod błędu nie wystarcza. Dopiero połączenie go z treścią komunikatu i momentem wystąpienia pozwala odróżnić zwykły objaw od rzeczywistej przyczyny. Dlatego w analizie logów serwera warto traktować każdy wpis jak wskazówkę, a nie gotowy wyrok.

Jak odróżnić problem aplikacji od problemu hostingu lub konfiguracji

Gdy strona przestaje działać, najważniejsze pytanie brzmi nie tylko co się zepsuło, ale też na jakiej warstwie. Inaczej diagnozuje się błąd wynikający z kodu aplikacji, inaczej problem z konfiguracją serwera, a jeszcze inaczej awarię po stronie hostingu. Logi serwera pomagają to rozdzielić, jeśli patrzysz na nie w odpowiedniej kolejności.

Najprostszy podział wygląda tak:

• problem aplikacji — dotyczy konkretnego skryptu, wtyczki, modułu, szablonu lub zapytania do bazy danych;
• problem konfiguracji — wynika z reguł w .htaccess, ustawień PHP, przekierowań, uprawnień albo błędnej ścieżki;
• problem hostingu — obejmuje limity zasobów, niedostępność usługi, przeciążenie, błąd PHP-FPM, proxy lub innego komponentu infrastruktury.

Jeśli błąd dotyczy jednej podstrony, a reszta serwisu działa poprawnie, bardzo często winna jest aplikacja. W logach widać wtedy powtarzające się wpisy tylko dla jednego adresu, ten sam plik PHP albo ten sam moduł. Typowe ślady to syntax error, undefined function, call to undefined method, failed to open stream lub allowed memory size exhausted. To zwykle wskazuje na błąd w kodzie, wtyczce, motywie albo na niezgodność wersji PHP z aplikacją.

Jeżeli problem pojawia się po zmianie konfiguracji, na przykład po edycji .htaccess, zmianie wersji PHP albo włączeniu reguł bezpieczeństwa, podejrzewaj konfigurację. W logach często widać wtedy kody 403, 500 lub błędy związane z interpretacją reguł. W praktyce oznacza to, że sama aplikacja może być poprawna, ale serwer nie potrafi jej uruchomić z powodu blokady, złej ścieżki, nieprawidłowego uprawnienia albo konfliktu reguł przepisywania.

Inaczej wygląda sytuacja, gdy problem obejmuje całą witrynę lub wiele niezależnych stron. Jeśli jednocześnie rosną czasy odpowiedzi, pojawiają się 502, 503 albo 504, a w logach widać timeouty, restart usługi lub brak odpowiedzi backendu, bardziej prawdopodobny jest problem hostingu lub warstwy serwerowej. Wtedy warto sprawdzić nie tylko logi domeny, ale też logi PHP-FPM, proxy, bazy danych i ewentualnie status usługi na serwerze.

Dobrym sposobem na rozróżnienie źródła awarii jest porównanie objawów według schematu:

1. Tylko jeden URL nie działa — najpierw sprawdź kod strony, reguły dla tego adresu, wtyczkę, szablon lub konkretny plik.
2. Wszystkie strony zwracają ten sam błąd — szukaj w konfiguracji serwera, PHP, limicie pamięci, uprawnieniach lub usługach pośrednich.
3. Błąd pojawił się zaraz po aktualizacji — porównaj logi sprzed i po zmianie; często problemem jest niekompatybilność wersji albo nowa reguła konfiguracyjna.
4. Awaria znika po wyłączeniu jednego elementu — to wskazuje na konflikt wtyczek, modułów, cache lub integracji zewnętrznej.

Warto też patrzeć na to, gdzie pierwszy raz pojawia się błąd. Jeśli access.log pokazuje poprawne żądanie, a error.log tuż po nim zawiera komunikat z PHP, problem najpewniej leży w aplikacji. Jeśli natomiast w logach serwera widać brak odpowiedzi, timeout albo błąd komunikacji z backendem, źródło leży raczej niżej — w usłudze pośredniczącej, bazie danych, PHP-FPM albo samym hostingu.

Przydatna jest też prosta checklista rozdzielająca warstwy:

• sprawdź, czy błąd występuje na jednej stronie czy na całej domenie;
• porównaj czas awarii z ostatnimi zmianami w aplikacji i konfiguracji;
• zobacz, czy w logach pojawia się komunikat typowo aplikacyjny, np. o funkcji, pliku lub pamięci;
• sprawdź, czy są sygnały problemu infrastrukturalnego, np. timeout, 502, 503, 504 lub brak odpowiedzi backendu;
• zweryfikuj, czy po cofnięciu ostatniej zmiany sytuacja się poprawia.

Praktyczna zasada: jeśli błąd dotyczy konkretnej treści, formularza, wtyczki lub endpointu, zaczynaj od aplikacji. Jeśli dotyczy całej domeny, wielu adresów albo zmienia się po stronie serwera, sprawdzaj hosting i konfigurację. Takie podejście znacznie skraca diagnozę błędów strony i pozwala uniknąć zgadywania.

Dobre praktyki pracy z logami i jak nie pogubić się w diagnozie

Praca z logami serwera daje najlepsze efekty wtedy, gdy jest uporządkowana. Nawet bardzo dobry zapis diagnostyczny nie pomoże, jeśli analizujesz go chaotycznie, bez czasu zdarzenia, bez porównania z ostatnimi zmianami i bez rozróżnienia między objawem a przyczyną.

Najważniejsza zasada: nie próbuj wyciągać wniosków z jednego wpisu. Logi warto czytać w kontekście kilku minut przed awarią i kilku minut po niej, a także razem z informacją, co zmieniano na stronie tuż przed wystąpieniem problemu.

Żeby nie pogubić się w diagnozie, stosuj prosty schemat pracy:

1. zapisz dokładny czas błędu oraz adres URL, którego dotyczy;
2. sprawdź jednocześnie access.log i error.log dla tego samego przedziału czasu;
3. szukaj pierwszego nietypowego wpisu, a nie tylko najgłośniejszego komunikatu;
4. porównaj log z ostatnimi zmianami w aplikacji, konfiguracji lub wtyczkach;
5. zwróć uwagę, czy błąd dotyczy jednej podstrony, całej domeny czy wielu usług naraz.

Pomaga też ograniczenie szumu. Jeśli w logu pojawiają się setki podobnych wpisów, nie czytaj wszystkiego od początku. Zawęź zakres do konkretnej minuty, a potem sprawdź, co pojawiło się jako pierwsze: kod 500, timeout, brak uprawnień, problem z plikiem czy komunikacja z backendem. To zwykle szybciej prowadzi do źródła problemu niż przeglądanie całego pliku linijka po linijce.

Warto rozdzielać trzy typowe scenariusze:

• awaria po zmianie w aplikacji — najpierw sprawdź wtyczkę, moduł, motyw, nowy kod lub aktualizację biblioteki;
• awaria po zmianie konfiguracji — wróć do ustawień .htaccess, PHP, przekierowań i uprawnień;
• awaria całej usługi — szukaj sygnałów przeciążenia, timeoutów, restartów i błędów po stronie hostingu.

Jeśli chcesz przyspieszyć diagnozę, zapisuj najważniejsze informacje w jednej notatce: godzina błędu, kod HTTP, pełny adres, fragment logu i ostatnia zmiana wykonana na stronie. Taki zestaw pozwala szybciej wrócić do problemu, porównać go z kolejnymi próbami i łatwiej przekazać sprawę supportowi.

Praktyczna checklista na koniec:

• sprawdzaj logi wąsko czasowo, zamiast analizować cały plik;
• szukaj pierwszego komunikatu, który różni się od pozostałych;
• łącz informacje z access.log, error.log i historii zmian;
• nie zakładaj od razu winy hostingu ani aplikacji;
• po każdej zmianie ponownie testuj stronę i porównuj nowe wpisy z poprzednimi.

Dzięki takiemu podejściu analiza logów staje się powtarzalnym procesem, a nie zgadywaniem. To właśnie ono najczęściej prowadzi do szybkiego odnalezienia źródła błędu strony.

FAQ

Gdzie najczęściej znajdują się logi błędów strony?

Najczęściej w panelu hostingu, w katalogu logs, error_log, php_error.log albo w dedykowanej sekcji diagnostycznej. Na VPS i serwerze dedykowanym logi są zwykle dostępne przez SSH w katalogach systemowych i konfiguracji serwera WWW.

Czy błąd 500 zawsze oznacza problem z serwerem?

Nie. Błąd 500 może wynikać zarówno z serwera, jak i z aplikacji: błędnego skryptu, konfliktu wtyczek, braku pamięci, niepoprawnej konfiguracji .htaccess albo problemu z bazą danych.

Jak znaleźć konkretny moment awarii w logach?

Najlepiej odtworzyć godzinę wystąpienia problemu, a następnie przefiltrować logi wokół tej chwili. Warto sprawdzić kilka minut przed awarią i kilka minut po niej, bo pierwszy błąd często pokazuje właściwą przyczynę.

Czy logi dostępu i logi błędów pokazują to samo?

Nie. Logi dostępu pokazują wszystkie żądania do strony, a logi błędów zawierają informacje o problemach, ostrzeżeniach i awariach. Do diagnozy najlepiej używać obu rodzajów jednocześnie.

Co przekazać supportowi hostingu, żeby szybciej pomógł?

Najlepiej podać dokładny czas błędu, adres URL, kod błędu, fragment logu, nazwę domeny oraz opis ostatnich zmian na stronie. To znacznie przyspiesza diagnozę.