Błąd 500 lub 522 w PrestaShop: jakie dane przygotować do diagnozy?

Zapisz dokładny adres, godzinę ze strefą czasową i czynność, po której pojawił się błąd. Te trzy informacje pozwalają szukać tego samego zdarzenia w logach. Sam numer 500 lub 522 nie wskazuje jeszcze modułu, który trzeba zmienić.

Ten poradnik pomaga przygotować zgłoszenie do diagnozy. Nie opisuje naprawy konkretnego sklepu ani nie przedstawia przykładowych przyczyn jako ustalonego wyniku.

Co zapisać podczas awarii?

1. Adres i czynność: np. otwarcie produktu, zapis ustawienia w panelu albo przejście z koszyka do dostawy. Nie zapisuj w publicznym zgłoszeniu tokenów z adresu panelu.
2. Czas: data, godzina i strefa, np. 2026-09-26 14:32 Europe/Warsaw. Jeżeli problem wraca, zapisz dwa lub trzy konkretne wystąpienia.
3. Odpowiedź: kod HTTP, widoczny komunikat oraz identyfikator żądania, jeżeli strona błędu go podaje. Zrzut ekranu uzupełnij tekstem komunikatu.
4. Zasięg: jeden adres czy cały sklep, front czy panel, użytkownik zalogowany czy gość, jedna sieć czy także druga.
5. Ostatnia zmiana: aktualizacja, instalacja modułu, import, zmiana ustawienia hostingu. Podaj datę; sama kolejność wydarzeń nie dowodzi przyczyny.

Błąd 500 i błąd 522 wymagają innych punktów zaczepienia

Opis 522 i zalecenia dla połączenia z serwerem źródłowym: dokumentacja Cloudflare. Ogólne znaczenie statusu 500: HTTP Semantics, RFC 9110.

Jak przygotować prostą próbę odtworzenia?

Przykład demonstracyjny zgłoszenia: „O 14:32 otwieram kartę produktu jako gość. Dokument ma status 500. Strona główna w tej samej przeglądarce działa. O 14:35 ten sam produkt działa z drugiej sieci”. Taki zapis nie diagnozuje przyczyny, ale wskazuje konkretne żądania do porównania.

Przy każdym powtórzeniu zmieniaj jeden warunek i zapisuj wynik. Jeżeli jednocześnie wyczyścisz cache, zmienisz PHP i wyłączysz kilka modułów, trudno będzie ustalić, która zmiana wpłynęła na zachowanie sklepu.

Jakie logi przekazać osobie diagnozującej?

Poproś o sprawdzenie krótkiego przedziału czasu wokół zdarzenia: logu aplikacji, błędów PHP i serwera WWW, a przy warstwie pośredniej także jej zdarzeń. Miejsce zapisania logów zależy od wersji sklepu i konfiguracji hostingu. Zamiast zakładać ścieżkę, podaj administratorowi dokładny czas, adres oraz metodę żądania, jeśli ją znasz.

Fragmenty logów mogą zawierać adresy e-mail, identyfikatory sesji i dane zamówień. Przekazuj potrzebny wycinek uzgodnionym kanałem i usuń sekrety. Pełny plik HAR również może zawierać takie informacje; nie publikuj go jako zwykłego załącznika na forum.

Jak porównywać warstwy bez zmiany ochrony całego sklepu?

Porównanie odpowiedzi przez CDN i bezpośrednio z serwera powinien przygotować administrator znający konfigurację domeny, TLS i dostępu do origin. Różnica między odpowiedziami jest wskazówką do dalszych testów, a nie automatycznym dowodem winy WAF lub PrestaShop.

Tryb debugowania stosuj na kopii roboczej lub w kontrolowanym dostępie. Globalne wyłączenie ochrony albo pokazanie szczegółowych wyjątków wszystkim odwiedzającym nie jest potrzebne do sporządzenia użytecznego zgłoszenia.

Gotowy wzór zgłoszenia do pobrania

Pobierz formularz opisu awarii — TXT. Wypełnij pola, a brakującą informację oznacz „nie sprawdzono”. Formularz nie wymaga haseł ani kluczy API.

Co sprawdzić po poprawce?

Powtórz zapisane kroki w tych samych warunkach, sprawdź rezultat działania i nowe wpisy w logach. Przy problemie sporadycznym jedno poprawne otwarcie strony potwierdza tylko tę próbę. Ustal z wykonawcą okres obserwacji, zakres testów oraz sygnał ponownego zgłoszenia.

Jeżeli problem pojawił się przy zmianie wersji, wykorzystaj też listę przygotowania aktualizacji PrestaShop. Osobny poradnik wyjaśnia rolę nagłówków bezpieczeństwa HTTP.