Ошибка 502 Bad Gateway: причины и пошаговое решение

Ошибка 502 Bad Gateway появляется тогда, когда запрос дошёл до сервера, но один из серверов на его пути не получил корректного ответа от другого. Страница при этом не открывается, хотя интернет у посетителя работает, а домен указан правильно. Чаще всего причина на стороне сайта, и именно поэтому сообщение одинаково беспокоит и посетителей, и владельцев ресурсов.

Код ошибки 502 не называет конкретную неисправность, он лишь указывает место, где оборвался обмен данными. Разбираем, что значит 502 Bad Gateway, как отличить локальный сбой от серверного, что может сделать посетитель и в какой последовательности искать причину владельцу сайта.

Что означает ошибка 502 Bad Gateway

502 Bad Gateway – это код состояния протокола HTTP (status code 502) из группы 5xx, то есть из группы серверных ошибок. Дословно название переводится как «плохой шлюз», поэтому её ещё называют ошибкой шлюза. Сервер, который работает как шлюз или прокси, передал запрос дальше, но в ответ получил что-то некорректное или столкнулся с обрывом соединения до получения корректного ответа. Если же ответ не пришёл в установленное время, обычно применяется код 504 Gateway Timeout.

Чтобы понять смысл ошибки, стоит представить путь запроса. Современный сайт редко состоит из одного сервера. Перед приложением обычно стоит обратный прокси, чаще всего Nginx, который принимает соединения от посетителей и пересылает запросы обработчику: PHP-FPM, серверу приложения на Node.js или Python либо другому веб-серверу. Ещё раньше в этой цепочке могут стоять CDN, балансировщик нагрузки и сетевой экран.

Ошибку 502 возвращает шлюз или прокси, который не смог получить корректный ответ от следующего сервера. Поэтому текст на экране бывает разным: «502 Bad Gateway nginx», «502 Bad Gateway openresty», «HTTP Error 502», «502 Proxy Error», «Не удалось выполнить запрос (HTTP 502)» или фирменная страница CDN. Оформление страницы может подсказать, какой компонент сформировал сообщение, но не всегда однозначно определяет источник неисправности.

Сам по себе код 502 не доказывает потери данных, взлома сайта или неисправности домена, но и не исключает сопутствующих проблем. Для установления причины нужно проверить состояние серверов, сетевых соединений и журналы ошибок. После устранения сбоя доступность страниц обычно восстанавливается.

Отличие 502 от ошибок 500, 503 и 504

Коды группы 5xx указывают, что сервер не смог выполнить запрос из-за ошибки или недоступности необходимого компонента. Они не подтверждают, что сам запрос был корректным. Однако каждый код описывает другую ситуацию, и от этого зависит, где искать неисправность. Соседние коды проще всего различить, когда они стоят рядом.

На практике 502 и 504 ближе всего друг к другу, потому что оба возникают на стыке двух серверов. Разница в том, что при 504 обработчик просто не успел ответить, а при 502 соединение было отклонено, разорвано или ответ оказался повреждённым. Если на сайте чередуются оба кода, стоит проверить состояние обработчика, ресурсы и сетевые соединения: причины могут быть связанными, но это не обязательно один сбой.

Код 500, напротив, чаще всего связан с самим приложением: ошибкой в скрипте, неправильной директивой или правами на файлы. В то же время код 500 может формироваться и другими компонентами, поэтому диагностика должна опираться на журналы, а не только на номер ошибки. Точное считывание кода ещё до начала проверок экономит время и сужает круг поиска.

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

Причины ошибки 502

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

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

Перегрузка сервера

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

Отдельный случай – полное исчерпание памяти. Операционная система в такой ситуации принудительно завершает процессы, которые потребляют больше всего, и среди них часто оказываются процессы PHP или базы данных. Для посетителя это выглядит как внезапная ошибка 502, которая исчезает после автоматического перезапуска сервиса и возвращается при следующем всплеске нагрузки.

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

Сбой PHP-FPM или сервера приложения

Обработчик может быть остановлен, завис или занят полностью. В PHP-FPM количество одновременных процессов ограничено параметром pm.max_children. Когда все процессы заняты медленными запросами, новые запросы ожидают свободный процесс. В зависимости от конфигурации и характера отказа это может завершиться 502, 504 или другим кодом.

Процесс также может аварийно завершиться во время выполнения скрипта: из-за сбоя расширения, нехватки системной памяти или принудительного завершения по параметру request_terminate_timeout. Обычное превышение PHP memory_limit не обязательно завершает процесс и само по себе не означает 502. Соединение разрывается до того, как ответ сформирован, и прокси получает оборванные данные. Похоже ведут себя серверы приложений на Node.js, Python или Java, если процесс упал и не был перезапущен.

Ещё один источник зависаний – внешние сервисы. Страница может ожидать ответа от платёжной системы, CRM, службы доставки или другого API. Если такой запрос выполняется во время формирования страницы и не имеет собственного ограничения времени, процесс обработчика остаётся занятым, пока внешний сервис не ответит. Несколько таких запросов одновременно способны занять все свободные процессы.

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

Конфигурация Nginx и тайм-ауты

Ошибка может быть заложена в самих настройках. Прокси обращается не на тот адрес или порт, путь к сокету PHP-FPM изменился после обновления версии PHP, а конфигурацию не поправили. К тому же результату приводят слишком маленькие буферы для заголовков ответа: если приложение передаёт большие cookie или длинные заголовки, Nginx отбрасывает такой ответ как некорректный.

С тайм-аутами ситуация менее очевидна. Когда Nginx сам не дождался ответа, он возвращает 504, а не 502. Однако если время выполнения ограничено на стороне обработчика, тот завершает процесс и разрывает соединение, и тогда возникает именно 502. Поэтому увеличение тайм-аутов помогает не всегда: оно лишь скрывает медленный запрос и дольше удерживает занятые процессы.

К этой же группе относится несоответствие протоколов. Если прокси обращается к обработчику через HTTPS, а тот ожидает обычный HTTP, возникает ошибка протокола. Проблемы с сертификатом внутреннего сервера также могут нарушить соединение, когда настроена проверка TLS. Обработчик при этом работает исправно, и без просмотра журнала прокси понять причину отказа сложно.

Отдельной проверки требует связка, в которой веб-серверы Apache и Nginx работают вместе: один принимает запросы, второй их обрабатывает, и ошибка в настройках любого из них даёт тот же код 502.

CDN, файрвол и защита от DDoS

Если сайт подключён к сети доставки контента, одним из промежуточных шлюзов может быть узел CDN. Он обращается к серверу, на котором размещён сайт, и при неудачной попытке сам показывает страницу с кодом 502. Некоторые CDN предоставляют дополнительную диагностику, но страница ошибки не всегда точно устанавливает виновный компонент. Это помогает понять, куда обращаться.

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

Ещё одна причина связана с адресами. После переноса сайта на другой сервер в настройках CDN или балансировщика может остаться старый IP-адрес. Промежуточный сервис продолжает обращаться туда, где сайта уже нет, и получает отказ. То же происходит, когда запись в DNS обновлена, а часть сети ещё пользуется прежним значением из кеша.

Масштаб проблемы с ошибкой 502

Первое, что стоит выяснить, – видят ли ошибку все посетители или только кто-то один. Для этого достаточно открыть сайт с другого устройства и через другую сеть, например через мобильный интернет. Если страница открывается только из другой сети, стоит проверить кеш DNS, VPN, прокси и маршрутизацию. Различие также может быть связано с CDN, региональным узлом или правилами фильтрации на сервере.

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

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

Владельцу сайта стоит дополнительно проверить ответ сервера без браузера, например командой curl -I с адресом страницы. Она показывает код состояния и заголовки, которые иногда помогают определить промежуточный компонент, но не гарантируют установления источника сбоя. Для адресов, не поддерживающих метод HEAD, стоит проверить обычный GET-запрос. Если сайт размещён у провайдера, полезно также посмотреть страницу состояния его сервисов и сообщения о плановых работах, чтобы не искать неисправность там, где её нет.

Действия пользователя при ошибке 502

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

1. Обновить страницу через минуту-две. Короткие сбои во время перезапуска сервисов проходят сами.
2. Открыть сайт в режиме инкогнито или в другом браузере. Так исключаются кеш, cookie и расширения.
3. Очистить кеш и cookie для этого сайта, если в приватном окне страница открывается.
4. Отключить VPN или прокси и попробовать другую сеть.
5. Очистить кеш DNS, если не открывается только этот сайт и только на вашем устройстве. В Windows для этого в командной строке выполняют ipconfig /flushdns, в macOS в терминале – sudo killall -HUP mDNSResponder.
6. Перезагрузить роутер и проверить, открываются ли другие сайты.

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

Ошибка 502 на телефоне устраняется в том же порядке, только короче. Стоит обновить страницу, переключиться с Wi-Fi на мобильный интернет или наоборот, открыть сайт в другом браузере и очистить данные браузера для этого сайта. Если ошибку показывает не сайт, а приложение, помогает его перезапуск, а когда сбой массовый, остаётся дождаться, пока сервис восстановит работу.

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

Диагностика ошибки 502 для владельца сайта

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

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

Журналы Nginx и PHP-FPM

Самый точный ответ дают журналы сервера. В типовой конфигурации Nginx записывает ошибки в файл /var/log/nginx/error.log, а расположение журнала PHP-FPM зависит от дистрибутива и версии PHP. Искать нужно записи за то время, когда посетители видели ошибку, и обращать внимание на слово upstream, которым Nginx обозначает сервер-обработчик.

Формулировка записи прямо указывает на характер сбоя. Строка «connect() failed (111: Connection refused)» означает, что обработчик не принимает соединений: он остановлен или слушает другой адрес. Запись «upstream prematurely closed connection» говорит о том, что процесс завершился во время обработки запроса. Сообщение «upstream sent too big header» указывает на слишком маленькие буферы.

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

На сайтах с WordPress дополнительную информацию даёт собственный журнал системы. Он включается в файле wp-config.php параметрами WP_DEBUG и WP_DEBUG_LOG, а параметр WP_DEBUG_DISPLAY со значением false не даёт сообщениям попадать на страницы. Записи сохраняются в файле debug.log в папке wp-content и могут помочь выявить проблемный компонент. Журнал следует защитить от публичного доступа и отключить подробную отладку после проверки. Не каждая PHP-ошибка вызывает 502.

Полезно сопоставить журнал ошибок с журналом доступа. В нём видно, какие именно адреса получали ответ 502, сколько таких запросов было и из каких источников они поступали. Концентрация ошибок на определённых URL может указывать на конкретную операцию или модуль, а массовые сбои – на общий компонент инфраструктуры. Окончательный вывод делают после сопоставления журналов.

Ресурсы сервера под нагрузкой

Второе направление – состояние самого сервера. Утилиты top или htop показывают загрузку процессора и процессы, которые потребляют больше всего, команда free -m – состояние оперативной памяти и подкачки, а df -h – свободное место на диске. Заполненный диск нередко становится неочевидной причиной: сервисы не могут записать временные файлы или сессии и завершаются с ошибкой.

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

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

Последние изменения на сайте

Третье направление – всё, что менялось незадолго до появления ошибки. Это обновления PHP, CMS, плагинов и тем, правки конфигурации Nginx, новые правила сетевого экрана, подключение или перенастройка CDN. После обновления версии PHP, например, часто меняется путь к сокету, а в конфигурации веб-сервера остаётся старый.

Правильность конфигурации Nginx проверяет команда nginx -t, а состояние сервисов показывает systemctl status. Если конфигурация корректна и все сервисы запущены, внимание переносят на сам сайт: обновлённые плагины, темы и модули системы управления.

Чтобы проверить влияние CDN, сервис временно переводят в режим без проксирования или обращаются к серверу напрямую, в обход сети доставки. Если напрямую сайт отвечает, проверяют настройки CDN, правила доступа, TLS и маршрутизацию. Прямое обращение следует выполнять контролируемо, не открывая origin-сервер для постороннего трафика. Когда причина найдена в свежем изменении, самый быстрый путь – откатить его и повторить уже после проверки на тестовой копии.

Плагины, темы и модули CMS

На сайтах с готовой системой управления причиной часто становится расширение, которое после обновления зависает или завершается с критической ошибкой. В WordPress сначала сопоставляют время сбоя с обновлениями и журналами PHP. Если есть подозрение на плагин, его временно отключают через административную панель или WP-CLI, а при отсутствии доступа – аккуратно переименовывают папку после резервного копирования. Массовое отключение плагинов и смена темы на рабочем сайте могут нарушить функциональность, поэтому такие действия желательно проверять на тестовой копии.

Далее просматривают журнал ошибок PHP, проверяют лимит памяти и очищают кеш объектов. Когда сайт заработал, расширения возвращают по одному и после каждого шага обновляют страницу. Модуль, после включения которого ошибка вернулась, обновляют, заменяют аналогом или возвращают к предыдущей версии.

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

Влияние ошибки 502 на SEO

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

Риск появляется тогда, когда сбой длится долго или регулярно повторяется. Страницы, которые стабильно возвращают серверную ошибку, со временем могут быть исключены из индекса, а новые материалы попадают в поиск с задержкой. Состояние сканирования видно в отчётах Google Search Console, где серверные ошибки вынесены в отдельную категорию.

Для плановых работ существует более корректный способ сообщить о недоступности. На время коротких плановых работ сервер можно настроить на ответ 503 с заголовком Retry-After, который указывает рекомендуемое время повторной попытки. Длительная недоступность даже с кодом 503 вредит сканированию и индексации. Так поисковик получает однозначный сигнал о временном характере перерыва, а не о неисправности сайта.

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

Профилактика ошибки 502

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

• Мониторинг. Внешняя проверка доступности и уведомления об ошибках 5xx позволяют узнать о сбое раньше посетителей.
• Запас ресурсов. Сервер должен выдерживать пиковую нагрузку, а не только среднюю, и иметь резерв памяти для фоновых задач.
• Согласованные лимиты. Количество процессов обработчика, тайм-ауты и буферы прокси должны соответствовать друг другу и объёму памяти.
• Кеширование. Готовые страницы и результаты тяжёлых запросов снимают часть нагрузки с обработчика.
• Контроль изменений. Обновления и правки конфигурации сначала проверяются на тестовой копии и имеют план отката.
• Фильтрация трафика. Ограничения для ботов и защита от атак не дают посторонним запросам исчерпать ресурсы.
• Ограничения для внешних сервисов. Запросы к сторонним API имеют собственный тайм-аут и по возможности выполняются в фоне.
• Проверка перед пиком. Нагрузочное тестирование перед рекламной кампанией или распродажей заранее определяет предел сервера.

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

Смена сервера нужна не всегда. Если ошибку вызвал один неисправный плагин, неправильный путь к сокету после обновления PHP, правило CDN или разовый сбой внешнего сервиса, переезд ничего не изменит. Сначала следует устранить конкретную причину и только потом оценивать, хватает ли серверу мощности.

Если же сайт регулярно упирается в пределы тарифа, имеет прогнозируемые пики посещаемости или требует собственных настроек обработчика, стоит рассмотреть переход на сервер с гарантированными ресурсами. Hostpark предлагает SSD VDS в Польше на инфраструктуре Atman с KVM-виртуализацией. Такой формат позволяет подобрать ресурсы под потребности приложения и администрировать сервер в соответствии с выбранной конфигурацией. Для архитектур с несколькими узлами может быть полезна балансировка нагрузки, которая требует отдельного проектирования. Для сетевой фильтрации в инфраструктуре Atman доступен отдельный управляемый сервис Atman Firewall; он не является автоматической составляющей VDS и не заменяет устранение причин ошибки 502.

Вывод

Ошибка 502 Bad Gateway означает, что прокси или шлюз не получил корректного ответа от сервера, которому передал запрос. Для посетителя это повод проверить браузер и сеть и вернуться на сайт позже. Для владельца ресурса это сигнал о том, что обработчик запросов недоступен, перегружен или неправильно связан с веб-сервером.

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

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