Коротка відповідь: 502 означає, що вебсервер (nginx/Apache як проксі) не зміг отримати коректну відповідь від бекенда — зазвичай PHP-FPM чи ваш застосунок мертвий, перезапускається або слухає інший сокет/порт, ніж очікує проксі. systemctl status php8.3-fpm і лог помилок nginx визначать, що саме, менш ніж за хвилину.

Огляд

Думайте про 502 як «рецепція працює, офіс позаду порожній». nginx живий і відповідає; upstream, куди він пересилає, — ні. Фікс майже завжди на боці upstream: запустити, розширити або направити проксі на правильну адресу.

Що потрібно мати

  • Доступ по SSH; знати свій upstream (PHP-FPM, node-застосунок, gunicorn...).

Покрокова інструкція

  1. Прочитайте точну причину:
    sudo tail -n 30 /var/log/nginx/error.log
    connect() failed (111) = upstream лежить; no such file на .sock-шляху = розсинхрон сокета; upstream timed out = див. гайд по 504.
  2. Перевірте й запустіть upstream:
    sudo systemctl status php8.3-fpm
    sudo systemctl restart php8.3-fpm
  3. Звірте сокет/порт з обох боків:
    grep -r fastcgi_pass /etc/nginx/sites-enabled/
    ls -l /run/php/
    Після оновлень PHP назва сокета змінюється (php8.1-fpm.sock → php8.3-fpm.sock) — класика 502.
  4. Зʼясуйте, чому upstream помер: OOM-кіл (sudo dmesg -T | grep -i oom), повний диск, цикл падінь у journalctl -u php8.3-fpm.
  5. Під навантаженням обережно підніміть ємність 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.

Схожі статті

Потрібна допомога? Звернутися в підтримку Cloud2Y →

Ця відповідь Вам допомогла? 0 Користувачі, які знайшли це корисним (0 Голосів)