502 Bad Gateway: что это и как починить
Вы открываете сайт — а там серая страница «502 Bad Gateway». Для владельца магазина или лендинга это не техническая абстракция, а горящие деньги. Разбираем, что сломалось, что делать в первые 10 минут и как не потерять ни одного клиента, пока идёт ремонт.
Что произошло на самом деле
Между посетителем и вашим сайтом стоят две машины: фронт-сервер (обычно nginx), принимающий запрос, и бэкенд — PHP-FPM, Node, Python-приложение или база, — который этот запрос исполняет. 502 означает: фронт жив, а бэкенд молчит. Причины в порядке частоты: упал PHP-FPM после обновления плагина; кончилась память или диск; хостер перезагрузил ноду; ваш плагин нагнал нагрузку и бэкенд убит по лимиту.
Первая помощь за 10 минут
Если у вас VPS и есть SSH: systemctl status php8.3-fpm (или вашего стека), free -h и df -h для памяти и диска, tail логов nginx — и перезапуск бэкенда. На шаред-хостинге SSH нет: пишите в поддержку хостера и параллельно проверьте, не совпал ли 502 с вашим последним действием (обновление плагина, новая тема, импорт товаров). Откат последнего изменения решает половину случаев.
Пока чините — клиенты видят ошибку
Каждая минута 502 — это посетители из поиска и рекламы, которые видят мёртвую страницу и уходят к конкуренту. Поисковик тоже замечает: редкий час простоя простит, регулярные — нет. Поэтому второй слой защиты: зеркало сайта, которое включается автоматически. baser снимает копию сайта каждую ночь, следит за доступностью каждые 60 секунд, а при 502 переключает домен на зеркало за 1–3 минуты. Посетители видят живой сайт, заявки с форм приходят вам в Telegram.
Профилактика
Обновления плагинов — сначала на копии. Лимиты памяти и диска — с запасом 30%. Мониторинг доступности — обязательно: узнавать о падении от клиента — худший способ. И резерв, который включается сам, а не после будильника админа.