Сайт выдаёт 502: что проверить на хостинге и VPS?

Сначала сохраните адрес страницы и время ошибки, затем проверьте сайт через другую сеть. Ошибка 502 Bad Gateway означает, что сервер-посредник не получил корректный ответ от следующего сервера или приложения. Например, Nginx принял запрос, но PHP-FPM не смог его обработать. Владельцу бизнеса полезно отделить локальный сбой от серверного, собрать сведения для поддержки и проверить результат исправления. Ниже — порядок действий для обычного хостинга и VPS без перезапуска всего сервера наугад.

Как понять, где возникает ошибка 502?

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

Если главная открывается, это ещё не подтверждает исправность приложения: её мог сохранить кэш. Для интернет-магазина проверяйте путь покупателя до оформления заказа, но не повторяйте оплату, пока не выясните статус предыдущей попытки.

Надпись nginx на странице ошибки показывает, какой компонент сформировал ответ. Она сама по себе не доказывает, что сломан Nginx: проблема бывает в PHP-FPM, Apache или приложении за ним. PHP-FPM обрабатывает PHP-код сайта, а Nginx передаёт ему запросы и возвращает результат посетителю.

Уточните время начала сбоя. Если перед ним обновили сайт, сменили версию PHP или перенесли проект, передайте эту связь администратору. Когда ошибка повторяется по расписанию, проверьте совпадение с резервным копированием и заданиями cron — задачами, которые сервер запускает автоматически (источник: «Хостинг в деталях»).

Что проверить на обычном хостинге и VPS?

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

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

1. Проверить журнал ошибок Nginx. Нужна запись по проблемному запросу: отказ в соединении, недоступный сокет или обрыв ответа следующего сервиса. Сохранить её до перезапуска.
2. Проверить состояние PHP-FPM или Apache. Если процесс остановился, найти причину завершения в журнале службы. При работающем процессе проверить, принимает ли он новые запросы.
3. Сверить настройки связи между службами. Адрес, порт или путь к сокету в Nginx должны соответствовать настройкам обработчика. После смены версии PHP особенно полезно проверить путь к сокету и права доступа к нему.
4. Посмотреть ресурсы в момент сбоя. Проверить доступную память, загрузку процессора, свободное место и ожидание дисковых операций. Перегрузка PHP-FPM и нехватка ресурсов входят в возможные причины 502 (источник: VPS Test).
5. Сопоставить ошибку с запросом приложения. Если сбой вызывает конкретная страница, проверить журнал приложения и обращения к базе данных именно для этого действия.

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

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

Что передать поддержке хостинга?

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

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

Пример текста обращения: «На сайте появляется 502 Bad Gateway при отправке формы заказа. Главная страница открывается. Ошибка повторяется через другую сеть. Перед сбоем обновили модуль оформления заказа. Время и адрес проблемной страницы прилагаю. Проверьте, пожалуйста, записи Nginx и состояние обработчика PHP в этот момент».

Попросите указать причину и действие, которое выполнила поддержка. Ответ «перезапустили, теперь работает» подтверждает восстановление доступа, но не объясняет повторяющийся сбой. Для следующего решения нужны сведения: какая служба остановилась, что показал журнал и какой ресурс закончился.

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

Как проверить исправление и избежать повторного сбоя?

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

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

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

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

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

Типичные ошибки при устранении 502

• Перезапускать весь VPS до просмотра журналов. Доступ иногда восстанавливается, но текущее состояние процессов теряется. Сначала сохраните записи и показатели нагрузки.
• Менять сразу несколько настроек. После этого трудно понять, какое действие помогло. Проверяйте одну гипотезу за раз и фиксируйте результат.
• Повышать тайм-ауты без разбора причины. Это не устранит отказ соединения или остановку PHP-FPM. Сначала прочитайте сообщение в журнале Nginx.
• Отключать защиту или открывать доступ к служебным портам наугад. Попросите администратора проверить конкретное соединение между Nginx и обработчиком приложения.
• Считать любой 502 основанием для смены хостинга. Сначала отделите ограничения площадки от ошибки приложения и конфигурации сервера.

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