Ошибки 502 и 504 на Битрикс: как найти причину и что проверить

Ошибка 502 504 на Битрикс — это сигнал от промежуточного сервера, а не сообщение самого движка. Он означает, что шлюз не дождался корректного ответа от приложения. Разбираться нужно по цепочке: где оборвался ответ, что этому предшествовало и как убедиться, что причина устранена, а не замаскирована.

Что означают 502 и 504 на Битрикс и где граница задачи

Код 502 Bad Gateway появляется, когда промежуточный сервер (обычно nginx) не получил от backend корректный и полный ответ: backend недоступен, оборвал соединение или вернул что-то, что шлюз не смог принять. Код 504 Gateway Timeout означает, что backend не ответил за отведённое ему время ожидания. В обоих случаях код формирует шлюз, а не ядро Битрикс. Движок может быть вообще ни при чём, если запрос до него не дошёл.

Это важно для границ задачи. Ошибка 502 504 на Битрикс относится к эксплуатации веб-окружения: связке шлюза, приложения и зависимостей, к которым приложение обращается. Её не стоит путать с ошибкой 500, которая приходит изнутри приложения, и с 404, которая говорит об отсутствии страницы. Если вы видите именно 502 или 504, искать нужно на стыке «шлюз — backend», а не в контенте и не в настройках отображения.

Граница ответственности обычно проходит так: за стабильность окружения отвечает тот, кто его эксплуатирует, за корректность кода и данных — разработчик, за нагрузку и её пики — тот, кто планирует маркетинговые активности. Пока эти роли не разведены, диагностика превращается в перекладывание задачи.

Как запрос проходит через сервер и приложение: схема запроса

Чтобы искать причину предметно, полезно держать перед глазами путь запроса. Он выглядит так: браузер посетителя → шлюз (nginx) → backend (PHP-FPM или Apache) → ядро Битрикс → база данных и кеш → ответ, который возвращается тем же путём в обратном порядке. Ошибка 502 или 504 возникает на одном из стыков этой цепочки, и от того, на каком именно, зависит, что проверять.

Отдельно стоит учитывать композитный кеш. Готовую страницу может отдавать сам шлюз, минуя PHP: кеш хранится либо в файлах, либо в memcached. Если кеш доступен и условия отдачи выполнены, запрос до приложения вообще не доходит — и тогда сбой backend на такую страницу не влияет. Если кеша нет или условия не выполнены, запрос уходит на backend.

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

Что видит посетитель и что видит администратор

Посетитель видит страницу с кодом 502 или 504 либо пустой экран. Администратор видит то же самое, но у него есть доступ к журналам шлюза и приложения. Именно журналы показывают, дошёл ли запрос до backend, сколько он там провёл времени и чем закончился. Без журналов любые выводы — это догадки.

Почему один и тот же код может означать разное

Один и тот же 502 может появиться и когда backend перезапускается, и когда он перегружен, и когда между шлюзом и backend разорвалось соединение. Один и тот же 504 может означать и медленный запрос к базе данных, и долгую внешнюю интеграцию, и нехватку ресурсов. Поэтому код — это только направление поиска, а не диагноз.

Первичная диагностика: что зафиксировать до любых изменений

Первое действие при сбое — не менять настройки, а зафиксировать картину. Нужно записать время появления и, если сбой повторяется, его периодичность. Затем — конкретные адреса страниц, на которых он проявляется, и охват: страдает весь сайт, отдельный раздел или единичная страница. Дальше — воспроизводимость: ошибка возникает у всех посетителей или только у части, у авторизованных или у анонимных, при обычном просмотре или при определённом действии.

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

Какие журналы смотреть

Смотреть нужно журналы шлюза и журналы приложения. Журнал шлюза показывает, был ли ответ от backend и с каким кодом. Журнал приложения показывает, что происходило внутри: успел ли запрос выполниться, на каком шаге он остановился, были ли обращения к внешним сервисам. Сопоставление двух журналов по времени и адресу — основной способ отделить проблему окружения от проблемы кода.

Что считать нормой, а что отклонением

Норма — это когда типичный запрос укладывается в обычное для проекта время и не оставляет ошибок в журналах. Отклонение — это рост времени ответа, повторяющиеся обрывы, всплески кодов 502 и 504 в определённые часы. Полезно заранее знать, как выглядит нормальный профиль нагрузки, иначе не с чем сравнивать.

Поиск причины до увеличения лимитов

Самая частая ошибка — сразу увеличивать время ожидания. Это может убрать симптом, но не причину: если запрос стал медленным из-за тяжёлой операции или внешней зависимости, увеличение лимита лишь отложит сбой и увеличит время, которое посетитель проводит в ожидании. Сначала классифицируем, потом меняем.

Первая развилка — какой именно код. 502 чаще указывает на недоступность или обрыв связи с backend, 504 — на то, что backend работает, но не успевает. Вторая развилка — стабильность: сбой постоянный или периодический. Постоянный обычно связан с конфигурацией или недоступной зависимостью, периодический — с нагрузкой, пиками или внешними сервисами. Третья развилка — охват: весь сайт, раздел или отдельные страницы. Если страдает весь сайт, причина, скорее всего, общая; если отдельные страницы — локальная.

Когда причина в окружении

Признаки: ошибка появляется на всех страницах сразу, включая простые; в журнале шлюза видно, что ответа от backend нет вовсе; сбой совпал с перезапуском или изменением окружения. Здесь проверяют доступность backend, его ресурсы и связность компонентов.

Когда причина в приложении или данных

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

Когда причина в нагрузке

Признаки: сбой привязан ко времени суток или к маркетинговой активности; в часы пиков растёт время ответа; после спада нагрузки ошибки исчезают. Здесь смотрят на профиль нагрузки и на то, как ведёт себя кеш.

Таблица: симптом, зона поиска и что проверить

Таблица помогает не распыляться: сначала определяем строку, которая ближе всего к наблюдаемой картине, и только потом идём в соответствующую зону.

Учебный пример: разбор сбоя на тестовых данных

Учебный пример. Данные условные и приведены только для иллюстрации порядка действий.

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

Шаг первый — фиксация. Записываем время, адреса страниц, охват и то, что менялось. Выясняется, что ошибки привязаны к каталогу и к пиковым часам, а простые страницы не затронуты.

Шаг второй — сопоставление журналов. В журнале шлюза видно, что часть запросов к каталогу завершается кодом 504, то есть backend не успевает ответить. В журнале приложения видно, что эти запросы действительно выполняются долго.

Шаг третий — проверка кеша. Часть страниц каталога отдаётся из кеша и работает стабильно. Проблема проявляется там, где кеш не срабатывает и запрос уходит на backend. Это объясняет, почему сбой не сплошной.

Шаг четвёртый — локализация причины. Долгие запросы связаны с операциями, которые выполняются при отсутствии готовой страницы в кеше. Причина не в шлюзе и не в лимите времени, а в том, что часть страниц регулярно требует полного построения.

Шаг пятый — решение и проверка. Сначала на копии проверяют, что изменение поведения кеша и оптимизация тяжёлых операций снижают время ответа. Затем изменения переносят на рабочий контур по плану с возможностью возврата. После этого в течение нескольких дней наблюдают за журналами: доля кодов 502 и 504 должна снизиться, а время ответа — вернуться к обычному профилю.

Наблюдаемый результат в учебном примере: ошибки перестали быть регулярными, а оставшиеся единичные случаи совпадали с внешними причинами. Ответственный за результат — тот, кто эксплуатирует окружение, совместно с разработчиком, если причина в коде.

Как проверить результат и принять работу

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

Приёмка должна включать период наблюдения, а не один момент. Разумно договориться заранее, сколько времени наблюдаем и какие признаки считаем достаточными. Если сбой был привязан к пиковой нагрузке, проверять нужно именно в пик, а не в спокойные часы.

Что фиксировать в отчёте

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

Когда работу нельзя считать завершённой

Если после изменений ошибки стали реже, но не исчезли, и при этом нет понимания, почему оставшиеся случаи происходят, работа не завершена. Если причина устранена только на одном контуре, а на остальных осталась, это тоже не завершение. Если наблюдение не проводилось, результат не подтверждён.

Типичные ошибки и ограничения

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

Ограничения тоже нужно называть честно. Часть причин лежит вне зоны веб-окружения: это могут быть внешние сервисы, сеть или оборудование. Часть сбоев связана с нагрузкой, которую нельзя устранить настройкой — её нужно планировать. И часть ошибок может быть следствием кода, который требует отдельной работы разработчика.

Почему нельзя обещать, что ошибок не будет никогда

Любое окружение имеет пределы. Задача — не «ноль ошибок навсегда», а предсказуемое поведение: понятные причины, наблюдаемые признаки, известные пределы и план действий при сбое. Если эти элементы есть, сбой перестаёт быть неожиданностью.

Какие исходные данные подготовить для оценки

Чтобы оценить задачу, нужны конкретные входные данные. Чем точнее они собраны, тем меньше времени уйдёт на диагностику.

• Описание симптома: какие коды, на каких страницах, как часто, с какого времени.
• Охват: весь сайт, раздел или отдельные страницы; все посетители или часть.
• Что менялось перед появлением сбоя: обновления, переносы, изменения настроек, рост нагрузки.
• Как устроено окружение в общих чертах: используется ли композитный кеш и где он хранится.
• Есть ли доступ к журналам шлюза и приложения и за какой период они сохраняются.
• Есть ли тестовый контур, на котором можно проверить изменения до рабочего.
• Кто отвечает за окружение и кто — за код, чтобы развести зоны ответственности.

Если каких-то данных нет, это тоже результат: он показывает, что сначала нужно наладить наблюдаемость, а уже потом браться за устранение.

Чек-лист: что проверить при ошибках 502 и 504

• Зафиксированы время, адреса страниц, частота и охват сбоя
• Отмечено, что менялось перед появлением ошибок
• Проверено, воспроизводится ли сбой у всех посетителей или у части
• Сопоставлены журналы шлюза и приложения по времени и адресу
• Определено, на каком участке цепочки теряется ответ
• Проверено, как ведёт себя кеш и переходит ли запрос на backend
• Причина классифицирована: окружение, приложение, нагрузка или внешняя зависимость
• Изменения сначала проверены на копии, с планом возврата
• Проведено наблюдение за журналами в течение согласованного периода
• Время ответа вернулось к обычному профилю проекта
• Оставшиеся ограничения и незакрытые случаи названы прямо

Если по итогам проверки видно, что задача выходит за рамки разового вмешательства и требует постоянного наблюдения за окружением, разумно обсудить поддержку сайта на Битрикс как формат, в котором диагностика и реакция на сбои становятся регулярными. Полезно заранее понимать, что входит в техническую поддержку сайта на Битрикс, чтобы разделить разовые работы и постоянные. А если стоит вопрос о бюджете и объёме, пригодится материал о том, Сколько стоит поддержка сайта на Битрикс: тарифы и что входит.