Pingveraблог ← Блог
Главная › Блог › Ошибка 502 на сайте интернет-магазина: причины и что делать до распродаж

Ошибка 502 на сайте интернет-магазина: причины и что делать до распродаж

7 ноября 2026 · 11 мин чтения

Ошибка 502 на сайте интернет-магазина: причины и что делать до распродаж

Ошибка 502 Bad Gateway значит, что веб-сервер на входе (чаще всего nginx) обратился к приложению за страницей и получил неверный ответ или не получил ничего. Сам сервер работает, домен открывается, но PHP, Node.js или другой бэкенд за ним упал, перезапускается или занят. Для покупателя разницы нет: вместо каталога или корзины он видит серую страницу и уходит.

Найти причину помогают три вещи: время, когда появилась ошибка, страницы, на которых она появляется, и журналы nginx и PHP-FPM за эти минуты. Обычно 502 появляется под нагрузкой, после обновления или во время тяжёлой фоновой задачи. До «Чёрной пятницы», которая в 2026 году выпадает на 27 ноября, осталось меньше трёх недель. Сейчас удобное время проверить, где у сайта предел, пока ошибка не случилась в пиковый час.

Коротко

  • 502 отдаёт прокси, когда бэкенд ответил неправильно или оборвал соединение. 504 отдаёт прокси, когда бэкенд не ответил вовремя. 503 сервер отдаёт сам, когда временно перегружен или на обслуживании.
  • Частые причины в магазине: заняты все процессы PHP-FPM, процесс убит по тайм-ауту или из-за нехватки памяти, бэкенд перезапускается после обновления, неверный адрес сокета в конфигурации.
  • Первым делом смотрите error.log nginx и журнал PHP-FPM за минуты ошибки, а не перезагружайте сервер вслепую.
  • Короткая 502 на главной заметна сразу. 502 только на оформлении заказа или в оплате может неделями оставаться незамеченной.
  • Страницы, которые возвращают роботу 5xx, Яндекс может исключить из поиска. После исправления их нужно вернуть на переобход.

Что означают 502, 503 и 504

Коды описаны в стандарте HTTP, RFC 9110. В переводе определения выглядят так:

  • 502 Bad Gateway: сервер, работая как шлюз или прокси, получил неверный ответ от сервера, к которому обращался, чтобы выполнить запрос.
  • 503 Service Unavailable: сервер сейчас не может обработать запрос из-за временной перегрузки или планового обслуживания. Он может передать заголовок Retry-After с подсказкой, когда повторить.
  • 504 Gateway Timeout: сервер, работая как шлюз или прокси, не дождался своевременного ответа от сервера, к которому обращался.

У типичного магазина на WordPress или 1С-Битрикс два звена: nginx принимает запрос и передаёт его PHP-FPM. Если PHP-FPM вернул мусор, закрыл соединение или к нему нельзя подключиться, nginx отдаёт 502. Если PHP-FPM долго молчит, nginx ждёт до своего тайм-аута и отдаёт 504. По документации nginx, fastcgi_read_timeout и proxy_read_timeout по умолчанию равны 60 секундам, причём это время между двумя последовательными чтениями, а не на весь ответ. Если перед сайтом стоит CDN или защита от DDoS, появляется третье звено, и 502 может отдавать уже оно.

Почему это важно сейчас

В ноябре нагрузка растёт сразу с нескольких сторон: 11.11, рассылки перед «Чёрной пятницей», реклама, обмен с 1С, который чаще гоняет остатки. У PHP-FPM есть жёсткий потолок: параметр pm.max_children ограничивает число одновременно обслуживаемых запросов. Когда все процессы заняты, новые запросы встают в очередь сокета. На Linux её размер listen.backlog по умолчанию 511. Дальше запросы начинают получать ошибки. Сайт, который спокойно держит будний день, в час распродажи упирается в этот потолок.

Есть и поисковая сторона. В справке Яндекс Вебмастера сказано, что страница исключается из поиска при ошибке загрузки, если сервер вернул 3XX, 4XX или 5XX. Там же предупреждают: если роботу не удалось подключиться к сайту из-за ошибки сервера, сайт может полностью пропасть из поиска. Инструмент «Проверка ответа сервера» ждёт ответ не дольше трёх секунд. Медленная страница, которая для человека «просто долго грузится», для робота уже ошибка.

Что делать при ошибке 502: порядок на сегодня

  1. Зафиксируйте время и масштаб. Запишите, когда началась ошибка, на каких адресах она есть (главная, каталог, корзина, оформление, личный кабинет, админка) и у всех ли. Проверьте сайт с мобильного интернета и из другого региона. Если ошибка только у вас, это другая история: разбор есть в статье «Сайт не работает только у меня».
  2. Определите, кто отдаёт 502. Посмотрите на страницу ошибки и заголовок Server в ответе. Страница CDN или защиты от DDoS означает, что сломалось звено между ними и вашим сервером. Страница nginx означает, что проблема за nginx, на вашем сервере.
  3. Откройте error.log nginx за эти минуты. Рядом с каждой 502 nginx пишет, что произошло с upstream: соединение отклонено, оборвано, сокет не найден, вышел тайм-аут. Это сразу сужает поиск.
  4. Проверьте PHP-FPM. Запущен ли сервис, не перезапускается ли он по кругу, есть ли в журнале записи о достижении pm.max_children. Посмотрите системный журнал: если ядру не хватило памяти, оно убивает процессы, и это тоже выглядит как 502.
  5. Сопоставьте с изменениями. Обновление плагина, модуля Битрикса или версии PHP, выкладка, очистка кеша, запуск импорта из 1С или генерации фида за последние часы. Если ошибка началась сразу после изменения, откат часто быстрее поиска.
  6. Проверьте ресурсы. Загрузка процессора, свободная память, место на диске, число соединений к базе данных. Переполненный диск ломает сессии, кеш и логи, а это тоже даёт 502.
  7. Включите журнал медленных запросов. В PHP-FPM он выключен по умолчанию: request_slowlog_timeout равен 0. С журналом видно, какой скрипт держит процесс: поиск по каталогу, расчёт доставки, запрос к платёжному шлюзу.
  8. Проверьте путь покупки целиком. Когда главная снова открылась, пройдите вручную: карточка, корзина, оформление, переход к оплате, возврат на сайт. 502 часто остаётся на одном тяжёлом шаге.
  9. Проверьте, что видит робот. В Яндекс Вебмастере откройте «Инструменты → Проверка ответа сервера» для ключевых страниц и «Индексирование → Статистика обхода» с фильтром по коду ответа. Исправленные страницы отправьте на переобход.

Если сайт не открывается совсем и непонятно, с чего начать, общий порядок действий описан в статье «Сайт лежит: что делать».

Таблица: причины 502 и как их проверить

Причина Признак Кто проверяет Как проверить Как часто
Заняты все процессы PHP-FPM 502/504 в пиковые часы, в журнале PHP-FPM записи о pm.max_children Разработчик или хостинг Журнал PHP-FPM, страница статуса пула Перед каждой распродажей и после роста трафика
Процесс убит по тайм-ауту 502 на долгих операциях: импорт, выгрузка, оформление с расчётом доставки Разработчик Сравнить request_terminate_timeout и fastcgi_read_timeout, журнал медленных запросов После изменения конфигурации
Нехватка памяти 502 волнами, в системном журнале убитые процессы Администратор сервера Системный журнал, график памяти Еженедельно в сезон
Бэкенд перезапускается Короткие всплески 502 после выкладки или обновления Тот, кто выкладывает Время ошибки против времени выкладки При каждой выкладке
Неверный сокет или порт в конфигурации 502 на всех страницах сразу после правки конфигурации или смены версии PHP Разработчик error.log nginx, путь к сокету в пуле PHP-FPM После каждого обновления PHP
Сбой звена CDN или защиты Страница ошибки провайдера, сервер при прямом обращении отвечает Владелец аккаунта CDN Запрос в обход CDN, статус провайдера При инциденте
Медленный внешний сервис 504 или 502 только на шагах с доставкой, оплатой, обменом с 1С Разработчик Журнал медленных запросов, тайм-ауты HTTP-клиента Перед пиком и при смене подрядчика

Артефакт: настройки и план проверки перед пиком

Фрагмент для пула PHP-FPM. Путь к файлу зависит от системы и версии PHP, значения ниже даны как отправная точка, а не готовая норма:

; pool.d/www.conf — фрагмент
pm = dynamic
pm.max_children = 20          ; подбирайте по памяти: свободная RAM / средний размер процесса PHP
pm.status_path = /fpm-status  ; по умолчанию страница статуса выключена
request_slowlog_timeout = 5s  ; по умолчанию 0 (журнал медленных запросов выключен)
slowlog = /var/log/php-fpm/www-slow.log
request_terminate_timeout = 120s ; по умолчанию 0 (без ограничения)

И согласованный с ним фрагмент nginx:

location ~ \.php$ {
    fastcgi_read_timeout 120s;   # по умолчанию 60s
    # ...остальные fastcgi-параметры
}

location = /fpm-status {
    allow 127.0.0.1;             # закройте статус от внешнего мира
    deny all;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php-fpm.sock;  # ваш путь к сокету
}

Логика простая. Если PHP-FPM убивает процесс раньше, чем nginx перестаёт ждать, покупатель обычно видит 502. Если nginx сдаётся раньше, он отдаёт 504, а PHP продолжает работать впустую. Одинаковые значения в обоих местах упрощают разбор. Длинный тайм-аут не лечит медленный код: он только прячет проблему, пока процессы не закончатся.

План проверки на одну неделю до распродажи:

[ ] Записать текущие pm.max_children, свободную память, средний размер процесса PHP
[ ] Включить журнал медленных запросов, через 2–3 дня разобрать топ скриптов
[ ] Проверить, что статус пула доступен только изнутри
[ ] Сверить тайм-ауты PHP-FPM, nginx и CDN
[ ] Перенести импорт из 1С, генерацию фидов и тяжёлые cron-задачи с пиковых часов
[ ] Заморозить обновления плагинов и модулей на дни распродажи
[ ] Прогнать нагрузочный тест на копии или в ночное окно
[ ] Пройти путь покупки до оплаты на телефоне через мобильный интернет
[ ] Проверить ключевые страницы в «Проверке ответа сервера» Яндекс Вебмастера
[ ] Договориться, кто дежурит в день распродажи и у кого доступ к серверу

Как провести нагрузочный тест и что считать результатом, разобрано в статье «Нагрузочное тестирование сайта перед „Чёрной пятницей“».

Пример разбора

Ситуация условная, собрана для иллюстрации.

Магазин на WooCommerce в вечер распродажи получает жалобы в чат: «не оформляется заказ». Главная и каталог открываются, мониторинг главной страницы зелёный. В error.log nginx за последний час десятки 502, и почти все на адресе оформления заказа. В журнале PHP-FPM записи о достижении pm.max_children. Журнал медленных запросов был выключен, его включают. Через десять минут видно: каждый запрос оформления ждёт ответа внешнего сервиса расчёта доставки по 20–30 секунд и держит процесс PHP.

Что сделали. Временно включили фиксированную стоимость доставки вместо онлайн-расчёта, процессы освободились, 502 пропали. После распродажи разработчик добавил короткий тайм-аут на запрос к сервису доставки и кеш тарифов. Вывод для команды: проверять нужно не только главную, но и шаг оформления, потому что именно он зависит от внешних сервисов.

Частые ошибки

  • Перезагружать сервер, не сохранив логи. Ошибка пропадёт на час, а причина останется. Сначала скопируйте фрагменты журналов за минуты сбоя.
  • Поднимать pm.max_children без расчёта памяти. Больше процессов, чем помещается в память, приводят к тому, что система начинает убивать процессы, и 502 становится больше.
  • Ставить огромные тайм-ауты. Запрос на 300 секунд держит процесс так же долго. Под нагрузкой это быстрее исчерпает пул.
  • Проверять только главную. Корзина, оформление и возврат с платёжной страницы ломаются отдельно. Подробно про такие тихие остановки: «Магазин работает, а заказов нет».
  • Обновлять плагины и модули в неделю распродажи. Обновление, которое меняет версию PHP или зависимости, проще пережить в спокойный вторник.
  • Забывать про поиск. Страницы, которые отдавали роботу 5xx, проверьте в Вебмастере и отправьте на переобход.

Ограничения. Фрагменты конфигурации выше подходят для связки nginx и PHP-FPM. На виртуальном хостинге этих файлов может не быть под рукой: параметры меняет хостинг, и разговор стоит начинать с времени ошибки и адресов страниц. Сайты на Tilda или InSales работают на инфраструктуре платформы: при 502 там проверяют статус платформы и пишут в её поддержку. Ни один набор настроек не гарантирует, что 502 не случится. Он делает так, что предел станет известен заранее, а причину можно найти за минуты.

Вопросы и ответы

Чем ошибка 502 отличается от 504?

502 значит, что прокси получил от бэкенда неверный ответ или соединение оборвалось. 504 значит, что бэкенд не ответил за отведённое время. На практике 502 чаще указывает на упавший или убитый процесс, 504 на медленный код или медленный внешний сервис.

Может ли ошибка 502 быть на стороне покупателя?

Код 502 формирует сервер, а не браузер. Но если ошибку видит только один человек, причина может быть в его маршруте: провайдер, VPN, корпоративный прокси. Проверьте сайт из другой сети и другого региона.

Сколько ждать, пока страницы вернутся в поиск после 502?

Точного срока Яндекс не называет. В справке Вебмастера советуют проверить, что страница отвечает 200 OK, отправить её на переобход и дождаться нового визита робота. Статистика обхода обновляется ежедневно.

Источники

  • RFC 9110, HTTP Semantics, разделы 15.6.3–15.6.5 (502, 503, 504): https://www.rfc-editor.org/rfc/rfc9110.html
  • Документация nginx, модуль ngx_http_fastcgi_module (fastcgi_read_timeout, fastcgi_connect_timeout): https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html
  • Документация nginx, модуль ngx_http_proxy_module (proxy_read_timeout, proxy_next_upstream): https://nginx.org/en/docs/http/ngx_http_proxy_module.html
  • Документация nginx, модуль ngx_http_upstream_module (max_fails, fail_timeout): https://nginx.org/en/docs/http/ngx_http_upstream_module.html
  • Руководство PHP, конфигурация FPM (pm.max_children, request_terminate_timeout, request_slowlog_timeout, pm.status_path, listen.backlog): https://www.php.net/manual/en/install.fpm.configuration.php
  • Яндекс Вебмастер, «Почему страницы исключены из поиска»: https://yandex.ru/support/webmaster/site-indexing/excluded-pages.html
  • Яндекс Вебмастер, «Как проверить, что сайт доступен для посетителей и поисковых роботов»: https://yandex.ru/support/webmaster/ru/robot-workings/availability
  • Яндекс Вебмастер, «Проверка ответа сервера»: https://yandex.ru/support/webmaster/indexing-options/server-response.html
  • Яндекс Вебмастер, «Статистика обхода»: https://yandex.ru/support/webmaster/service/site-indexing.html

Проверено: 7 ноября 2026 года.


Шаг «узнать о 502 раньше покупателей» можно автоматизировать. Pingvera раз в минуту проверяет доступность сайта по HTTP из нескольких регионов, подтверждает сбой повторными проверками и присылает алерт в Telegram, MAX, VK, на почту или в webhook. Для WooCommerce сервис следит и за потоком заказов: если сайт отвечает, а заказы перестали приходить, придёт отдельный алерт. Бесплатный тариф покрывает до 5 сайтов, а разовую проверку можно сделать без регистрации на https://pingvera.ru/check.

Узнавайте о проблеме раньше клиента

Pingvera следит за сайтами клиентов «снаружи и изнутри» — доступность из регионов, формы, оплата, домен, SSL, сервер — и предупреждает в Telegram, email и Max раньше, чем напишет клиент.

Попробовать Pingvera бесплатно

Читайте также: Ошибка 504 на сайте: причины и что делать магазину · Ошибка 403 на сайте: что значит и что делать магазину · Ошибка 404 на сайте: что значит и что делать магазину · Ошибка 503 на сайте: что значит и что делать · Бесплатно проверить сайт.

← Все статьи · Политика конфиденциальности · pingvera.ru · Telegram-канал

На сайте осуществляется обработка пользовательских данных с использованием Cookie в соответствии с Политикой конфиденциальности.