Помилка 500 або 522 у PrestaShop: які дані підготувати для діагностики?

Помилка 500 або 522 у магазині PrestaShop? Почніть із фактів, які можна порівняти

Коли в магазині з’являється HTTP 500, Cloudflare 522 або порожня сторінка, спокуса «швидко щось перемкнути» велика. Для діагностики корисніші кілька точних даних: що саме відкривали, о котрій годині, яка була відповідь і чи проблема стосується всього магазину, чи лише окремого шляху. Такий опис полегшує порівняння події з логами та відокремлює симптом від припущення про причину.

Що варто записати перед змінами?

1. Адреса і дія: наприклад, відкриття товару, збереження налаштування в панелі або перехід із кошика до доставки. Не записуйте в публічному зверненні токени з адреси панелі.
2. Час: дата, година і часова зона, наприклад, 2026-09-26 14:32 Europe/Warsaw. Якщо проблема повторюється, запишіть два або три конкретні випадки.
3. Відповідь: код HTTP, видиме повідомлення та ідентифікатор запиту, якщо сторінка помилки його показує. Доповніть знімок екрана текстом повідомлення.
4. Охоплення: одна адреса чи весь магазин, фронт чи панель, авторизований користувач чи гість, одна мережа чи також інша.
5. Остання зміна: оновлення, встановлення модуля, імпорт, зміна налаштування хостингу. Вкажіть дату; сама послідовність подій не доводить причину.

Помилка 500 і помилка 522 потребують різних точок опори

Опис 522 і рекомендації для з’єднання з сервером-джерелом: документація Cloudflare. Загальне значення статусу 500: HTTP Semantics, RFC 9110.

Як підготувати просту спробу відтворення?

Демонстраційний приклад звернення: «О 14:32 я відкриваю картку товару як гість. Документ має статус 500. Головна сторінка в тому самому браузері працює. О 14:35 той самий товар працює з іншої мережі». Такий запис не діагностує причину, але вказує конкретні запити для порівняння.

Під час кожного повторення змінюйте одну умову і записуйте результат. Якщо одночасно очистити кеш, змінити PHP і вимкнути кілька модулів, буде важко встановити, яка саме зміна вплинула на поведінку магазину.

Які логи передати особі, що проводить діагностику?

Попросіть перевірити короткий проміжок часу навколо події: лог застосунку, помилки PHP і вебсервера, а за наявності проміжного шару — також його події. Місце збереження логів залежить від версії магазину та конфігурації хостингу. Замість того щоб припускати шлях, надайте адміністратору точний час, адресу та метод запиту, якщо ви його знаєте.

Фрагменти логів можуть містити адреси електронної пошти, ідентифікатори сесій і дані замовлень. Передавайте потрібний фрагмент узгодженим каналом і видаляйте секрети. Повний файл HAR також може містити таку інформацію; не публікуйте його як звичайний вкладений файл на форумі.

Як порівнювати шари без зміни захисту всього магазину?

Порівняння відповідей через CDN і безпосередньо із сервера має підготувати адміністратор, який знає конфігурацію домену, TLS і доступу до origin. Різниця між відповідями є підказкою для подальших тестів, а не автоматичним доказом вини WAF або PrestaShop.

Режим налагодження застосовуйте на робочій копії або в контрольованому доступі. Глобальне вимкнення захисту або показ помилок усьому світу ускладнює діагностику та може створити додатковий ризик.

Що перевірити після виправлення?

Повторіть записані кроки в тих самих умовах, перевірте результат роботи та нові записи в логах. У разі періодичної проблеми одне правильне відкриття сторінки підтверджує лише цю спробу. Узгодьте з виконавцем період спостереження, обсяг тестів і сигнал для повторного звернення.

Якщо проблема з’явилася під час зміни версії, скористайтеся також списком підготовки до оновлення PrestaShop. Окремий посібник пояснює роль заголовків безпеки HTTP.