Краткий ответ: 502 означает, что веб-сервер (nginx/Apache как прокси) не смог получить корректный ответ от бэкенда — обычно PHP-FPM или ваше приложение мертво, перезапускается или слушает другой сокет/порт, чем ожидает прокси. systemctl status php8.3-fpm и лог ошибок nginx определят, что именно, меньше чем за минуту.
Обзор
Думайте о 502 как «ресепшен работает, офис позади пуст». nginx жив и отвечает; upstream, куда он пересылает, — нет. Фикс почти всегда на стороне upstream: запустить, расширить или направить прокси на правильный адрес.
Что нужно иметь
- Доступ по SSH; знать свой upstream (PHP-FPM, node-приложение, gunicorn...).
Пошаговая инструкция
- Прочитайте точную причину:
sudo tail -n 30 /var/log/nginx/error.logconnect() failed (111)= upstream лежит;no such fileна .sock-пути = рассинхрон сокета;upstream timed out= см. гайд по 504. - Проверьте и запустите upstream:
sudo systemctl status php8.3-fpm sudo systemctl restart php8.3-fpm - Сверьте сокет/порт с обеих сторон:
После обновлений PHP имя сокета меняется (php8.1-fpm.sock → php8.3-fpm.sock) — классика 502.grep -r fastcgi_pass /etc/nginx/sites-enabled/ ls -l /run/php/ - Выясните, почему upstream умер: OOM-килл (
sudo dmesg -T | grep -i oom), полный диск, цикл падений вjournalctl -u php8.3-fpm. - Под нагрузкой осторожно поднимите ёмкость PHP-FPM (
pm.max_children) в пределах доступной RAM.
Типичные проблемы
- 502 сразу после обновления PHP: nginx всё ещё указывает на старый сокет.
- Периодические 502 на пиках трафика: пул FPM исчерпан — запросы стоят в очереди и отбрасываются.
- OOM-киллер бьёт по бэкенду: самый большой процесс проигрывает; добавьте RAM или swap.
Когда обращаться в поддержку
Если upstream-ы здоровы, сокеты совпадают, а 502 продолжаются и логи ничего не показывают, — откройте тикет с выдержкой из error-лога nginx и временными метками.
Частые вопросы
Что на самом деле говорит мне 502?
Прокси впереди (nginx или Apache) здоров, но не получил корректного ответа от бэкенда, такого как PHP-FPM. Бэкенд лежит, перезапускается, упал или слушает другой сокет или порт.
Почему 502 начались сразу после обновления PHP?
Путь сокета PHP-FPM содержит версию, поэтому конфиги nginx, указывающие на старый сокет, ломаются. Обновите fastcgi_pass на новое имя сокета и перезагрузите nginx.
Похожие статьи
- Сайт выдаёт ошибку 500
- Сайт выдаёт 504 Gateway Timeout
- Высокое использование RAM: быстрая диагностика
- Ошибка Connection refused
Нужна помощь? Связаться с поддержкой Cloud2Y →
