Вы открываете сайт и вместо привычной страницы видите 502 Bad Gateway. Иногда достаточно обновить вкладку, и все снова работает. В другой ситуации ошибка появляется на несколько минут каждый день или вообще не исчезает.
Проблема неприятная еще и потому, что по одной надписи 502 невозможно сразу понять виновника. Причина может находиться в PHP, веб-сервере, приложении, настройках VPS, прокси-сервере или инфраструктуре хостинга.
При этом 502 довольно хорошо поддается диагностике, если понимать, что происходит с запросом посетителя до появления страницы сайта.
Что означает ошибка 502 Bad Gateway
Сайт далеко не всегда обслуживается одним процессом, который получает запрос браузера и сразу отправляет готовую страницу.
В реальной инфраструктуре между посетителем и приложением могут находиться несколько компонентов.
Упрощенно цепочка может выглядеть так:
- браузер отправляет запрос;
- его принимает Nginx или другой веб-сервер;
- запрос передается PHP-FPM, приложению или другому внутреннему сервису;
- приложение формирует результат;
- веб-сервер возвращает страницу посетителю.
В более сложной конфигурации перед сервером дополнительно может находиться CDN, балансировщик нагрузки или reverse proxy.
Ошибка 502 появляется, когда сервер, выполняющий роль шлюза или прокси, не смог получить от следующего звена корректный ответ.
Отсюда и название Bad Gateway.
Представим ресторан. Официант принял заказ посетителя и передал его на кухню. Но вместо готового блюда кухня отправила что-то, что официант не может принять как нормальный результат. Для посетителя проблема выглядит так, будто ресторан в целом не смог выполнить заказ, хотя точка сбоя находится между его внутренними звеньями.
Примерно так же работает 502.
Это отличает ее от некоторых других серверных ошибок.
500 Internal Server Error обычно означает общую внутреннюю ошибку при обработке запроса. 503 Service Unavailable сообщает, что сервис сейчас не готов обслужить запрос. А 504 Gateway Timeout возникает, когда шлюз или прокси не дождался ответа от вышестоящего сервера за отведенное время.
У 502 и 504 поэтому действительно есть сходство, но это не одна и та же ошибка.
Еще один важный момент: 502 обычно является серверной проблемой. Очистка истории браузера, переустановка браузера и перезагрузка домашнего компьютера редко устраняют ее причину.
Однако посетителю полезно проверить сайт с другого подключения или устройства. Если ошибка появляется только у него, а у остальных сайт работает, ситуация уже требует другой диагностики.
Почему сайт начинает показывать 502
Одна из распространенных ситуаций на сервере с Nginx и PHP заключается в том, что веб-сервер работает, а PHP-FPM перестал нормально отвечать.
Nginx принимает запрос посетителя, поэтому соединение с самим сервером существует. Затем он пытается передать выполнение PHP-кода соответствующему процессу и не получает ожидаемого результата.
Посетитель видит 502.
Причины остановки или неправильной работы PHP-FPM бывают разными. Процесс мог завершиться после сбоя, не запуститься после изменения конфигурации или испытывать нехватку ресурсов.
На VPS стоит проверить состояние сервисов. Названия команд и служб зависят от операционной системы, установленной версии PHP и конфигурации сервера, поэтому бездумно копировать первую команду из случайной инструкции не стоит.
Особенно показателен сценарий, когда 502 появилась сразу после изменения версии PHP, конфигурации Nginx или PHP-FPM.
В таком случае сначала нужно проверять именно последние изменения.
Например, Nginx настроен передавать PHP-запросы через определенный Unix-сокет, но после обновления PHP путь к сокету изменился. Веб-сервер продолжает обращаться по старому адресу и больше не может связаться с PHP-FPM.
Похожая ситуация возникает при использовании TCP-порта. Если внутренний сервис слушает другой адрес или порт, прокси пытается обратиться туда, где нужного процесса уже нет.
Еще одна большая группа причин связана с ресурсами.
Сайт может прекрасно работать при десяти одновременных посетителях, но начать выдавать 502 при резком росте нагрузки.
Например, тяжелые PHP-процессы занимают всю доступную память. Часть процессов завершается, очередь запросов растет, а связка веб-сервера и приложения перестает нормально работать.
На VPS в такой ситуации стоит смотреть не только на процессор.
Проверьте:
- свободную оперативную память;
- использование swap;
- заполнение диска;
- нагрузку на процессор;
- количество процессов PHP-FPM;
- состояние базы данных;
- число соединений;
- логи веб-сервера и приложения.
Полностью заполненный диск тоже способен приводить к неожиданным последствиям. Сервисам некуда записывать временные данные и журналы, база может перестать нормально работать, а отдельные процессы начинают завершаться с ошибками.
На виртуальном хостинге пользователь обычно не имеет доступа ко всей серверной инфраструктуре. Там 502 может возникнуть из-за общей проблемы узла, перезапуска служб или ограничения ресурсов конкретного аккаунта.
Если ошибка появилась одновременно на нескольких ваших сайтах, размещенных в одном аккаунте, это особенно важный сигнал.
Но делать вывод хостинг сломался только по одному коду 502 тоже рано.
Ошибка может быть связана с конкретным сайтом.
Предположим, после установки плагина резко выросло потребление памяти или приложение начало запускать тяжелый запрос. Другие сайты аккаунта работают нормально, а один периодически получает 502.
Тогда искать причину нужно прежде всего внутри проблемного проекта.
Отдельный случай возникает при использовании CDN или внешнего reverse proxy.
Посетитель обращается не напрямую к исходному серверу. Запрос сначала приходит на промежуточную инфраструктуру, которая уже соединяется с вашим хостингом.
Если исходный сервер недоступен для этого промежуточного звена или отвечает некорректно, пользователь тоже может увидеть 502.
Поэтому важно понимать, кто именно сформировал страницу с ошибкой.
Фирменное оформление CDN, название веб-сервера или сведения в HTTP-заголовках иногда помогают определить, на каком уровне появилась проблема.
Не стоит забывать и о сетевых настройках. Ошибка в адресе upstream, неправильный порт, закрытое соединение между компонентами или некорректная конфигурация контейнеров способны привести к тому же результату.
Именно поэтому универсального решения вида измените одну строку и 502 исчезнет не существует.
Как найти причину ошибки 502
Начинать диагностику лучше не с изменения настроек, а с определения масштаба проблемы.
Откройте несколько страниц сайта.
Если 502 возникает абсолютно везде, вероятнее проблема затрагивает общий компонент инфраструктуры.
Если главная работает, а ошибка появляется только на определенной странице, нужно искать то, чем эта страница отличается от остальных. Возможно, она выполняет тяжелый PHP-код, обращается к внешнему API или запускает сложный запрос к базе.
Затем проверьте сайт с другого подключения. Можно воспользоваться мобильной сетью вместо домашнего интернета.
Если ресурс не открывается нигде, проблема действительно находится ближе к серверной стороне.
После этого вспомните последние изменения.
Это один из самых полезных вопросов при диагностике практически любой серверной ошибки.
- Обновлялась ли версия PHP?
- Менялась ли конфигурация Nginx или Apache?
- Устанавливался ли новый плагин?
- Обновлялась ли CMS?
- Переносился ли сайт?
- Менялись ли контейнеры?
- Подключался ли CDN?
- Происходило ли изменение DNS?
- Настраивался ли новый прокси?
Если 502 появилась через минуту после конкретного действия, начинать проверку с совершенно другой части инфраструктуры обычно бессмысленно.
Следующий источник информации — логи.
На VPS журналы веб-сервера часто дают намного больше информации, чем сама страница Bad Gateway.
Например, в журнале Nginx может быть видно, что соединение с upstream не устанавливается, сбрасывается или возвращает некорректный ответ.
Затем проверяются логи PHP-FPM, приложения и системные журналы.
Если перед ошибкой система завершила процесс из-за нехватки памяти, это принципиально меняет направление поиска. Простым перезапуском PHP-FPM можно временно вернуть сайт к жизни, но проблема повторится, когда память снова закончится.
Поэтому перезапуск сервиса и исправление причины — разные вещи.
На виртуальном хостинге часть журналов может быть доступна через панель управления. Если нужной информации нет, имеет смысл обратиться в поддержку.
Сообщение сайт не работает дает специалисту очень мало информации.
Лучше написать конкретно:
- какой домен показывает 502;
- когда проблема началась;
- ошибка постоянная или периодическая;
- возникает на всем сайте или на отдельных URL;
- какие изменения выполнялись перед появлением проблемы;
- работают ли другие сайты в том же аккаунте.
Если ошибка появляется периодически, укажите примерное время нескольких случаев. По нему поддержке проще найти соответствующие записи в серверных журналах.
Для VPS дополнительно полезно проверить состояние веб-сервера, PHP-FPM, базы данных и других компонентов, через которые проходит запрос.
Не нужно сразу перезагружать весь сервер.
Полная перезагрузка иногда действительно восстанавливает работу, но одновременно уничтожает часть полезной информации о текущем состоянии системы. Если есть возможность сначала посмотреть процессы, ресурсы и логи, лучше сделать это до перезагрузки.
Особое внимание требуется, если 502 появляется только во время нагрузки.
Допустим, ночью сайт работает идеально. Утром запускается импорт товаров, одновременно приходят посетители, нагрузка растет и начинается серия 502. После завершения импорта все снова приходит в норму.
В такой ситуации проблема может быть не в неправильной конфигурации как таковой, а в том, что ресурсов или числа рабочих процессов не хватает для пикового сценария.
Простое увеличение таймаутов здесь не обязательно поможет.
Если приложение реально перегружает сервер, увеличение времени ожидания способно лишь заставить посетителей дольше ждать того же неудачного результата.
Нужно искать узкое место: PHP, базу, память, внешний API, медленный код или недостаточные ресурсы.
Что делать при 502 на виртуальном хостинге и VPS
Порядок действий зависит от того, каким сервером вы управляете.
На обычном виртуальном хостинге серверное окружение обслуживает провайдер. Пользователь не должен пытаться самостоятельно перезапускать системный Nginx или PHP-FPM, если у него даже нет соответствующего доступа.
Сначала проверьте, не вносились ли изменения в сайт непосредственно перед ошибкой.
Если устанавливался плагин, менялась версия PHP или загружался новый код, попробуйте безопасно отменить последнее изменение.
Посмотрите доступные журналы ошибок и показатели использования ресурсов в панели.
Если 502 сохраняется, обращайтесь в поддержку хостинга.
При массовой серверной аварии именно провайдер сможет восстановить инфраструктуру. Если проблема находится в вашем приложении, поддержка по крайней мере может подсказать, что видно со стороны сервера.
На VPS зона ответственности владельца значительно шире.
Здесь нужно проверить всю цепочку запроса.
Работает ли Nginx? Запущен ли PHP-FPM? Совпадает ли адрес upstream с реальным адресом сервиса? Есть ли свободная память? Не заполнен ли диск? Не завершает ли Linux процессы? Работает ли база данных?
Если используется Docker, добавляется еще один слой диагностики. Контейнер приложения может остановиться, перезапускаться или оказаться недоступным из сети, через которую к нему обращается reverse proxy.
Если перед сайтом находится CDN, полезно определить, доступен ли исходный сервер напрямую. Делать это нужно аккуратно и с учетом архитектуры защиты, а не отключать CDN на рабочем проекте без необходимости.
Главная ошибка при исправлении 502 заключается в хаотичном изменении всего подряд.
Пользователь увеличивает таймауты, меняет DNS, отключает плагины, редактирует Nginx и перезапускает сервер. Через некоторое время сайт начинает работать, но что именно помогло, остается неизвестным.
При следующем сбое все повторяется.
Гораздо надежнее двигаться последовательно:
- определить масштаб проблемы;
- проверить последние изменения;
- посмотреть логи;
- проверить состояние сервисов;
- оценить использование ресурсов;
- найти неработающее звено;
- исправить именно его;
- после восстановления сайта убедиться, что ошибка не повторяется.
Если 502 была разовой и исчезла через несколько секунд, паниковать не нужно. Кратковременный перезапуск сервиса или техническое событие действительно может вызвать единичную ошибку.
Но регулярные 502 нельзя считать нормальной особенностью хостинга.
Если сайт несколько раз в неделю становится недоступным, стоит подключить внешний мониторинг и фиксировать время каждого инцидента. Так можно увидеть закономерность и предоставить поддержке конкретные данные.
При выборе хостинга полезно учитывать не только объем диска и число сайтов в тарифе. Для рабочего проекта важны стабильность инфраструктуры, доступность поддержки и возможность получить помощь при серверных ошибках.
А если сайт вырос настолько, что постоянно упирается в ограничения виртуального хостинга, бесконечно лечить последствия уже невыгодно. Иногда правильным решением становится переход на более производительный тариф или VPS.
Ошибка 502 в таком случае оказывается не самостоятельной проблемой, а сигналом о том, что текущая инфраструктура перестала справляться с проектом.
