Коротка відповідь: 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 →
