Ошибка 502 Bad Gateway в Nginx и PHP-FPM на VDS: пошаговое решение

Answer Capsule: Ошибка 502 Bad Gateway в связке Nginx и PHP-FPM возникает из-за аварийного завершения процесса PHP-FPM, переполнения очереди UNIX-сокета или превышения лимитов времени ожидания ответа бэкенда. Для оперативного исправления необходимо проанализировать логи /var/log/nginx/error.log, увеличить лимиты pm.max_children в конфиге пула www.conf, корректно настроить параметры fastcgi_read_timeout и перезапустить управляющие сервисы.

Причины возникновения 502 Bad Gateway в архитектуре Nginx и PHP-FPM

При обработке динамических запросов Nginx выступает в роли фронтенд-прокси (reverse proxy), который транслирует входящие HTTP-запросы к FastCGI-серверу PHP-FPM через сетевой сокет (TCP) или локальный доменный сокет UNIX. Ошибка 502 (Bad Gateway) указывает на то, что Nginx попытался передать запрос или получить ответ от бэкенда, но сокет вернул некорректный ответ либо закрыл соединение до завершения передачи данных.

Разберём ключевые причины возникновения данного сбоя в продакшн-окружении:

1. Аварийное завершение воркера PHP-FPM (Out of Memory / OOM Killer): При выполнении тяжелых сценариев или обработке неоптимизированных SQL-выборок процесс превышает лимит памяти memory_limit. В результате операционная система Linux принудительно завершает рабочий процесс через OOM Killer, и Nginx получает разрыв сокета.

1. Исчерпание свободных воркеров (Max Children Reached): Если количество одновременных посетителей превышает значение pm.max_children, входящие запросы встают в очередь listen.backlog. При заполнении очереди новые соединения сбрасываются со стороны PHP-FPM.

1. Права доступа к файлу UNIX-сокета: Если PHP-FPM запущен от пользователя www-data или php-fpm, а Nginx не имеет прав на чтение и запись в сокет /run/php/php8.2-fpm.sock, Nginx возвращает ошибку 13: Permission denied в логах.

1. Таймаут FastCGI соединения: Если скрипт выполняет длительную фоновую обработку (экспорт данных, генерация отчетов, обращение к внешним API), время ожидания превышает параметр fastcgi_read_timeout в Nginx.

Первичная диагностика сервера через CLI и системные логи

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

```bash

systemctl status php8.2-fpm # Или php-fpm в зависимости от дистрибутива

tail -n 50 /var/log/nginx/error.log

dmesg -T | grep -i oom

ls -l /run/php/php*-fpm.sock

```

Типичный текст ошибки в /var/log/nginx/error.log при исчерпании воркеров выглядит следующим образом:

[error] 1234#0: *5678 connect() to unix:/run/php/php-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream

Пошаговая пошаговая настройка конфигурации Nginx и PHP-FPM

Шаг 1. Оптимизация пула воркеров в /etc/php-fpm.d/www.conf

Откройте конфигурационный файл пула PHP-FPM в текстовом редакторе:

```ini

; Путь к файлу: /etc/php-fpm.d/www.conf (для CentOS/AlmaLinux) или /etc/php/8.2/fpm/pool.d/www.conf (Debian/Ubuntu)

pm = dynamic

pm.max_children = 50

pm.start_servers = 10

pm.min_spare_servers = 5

pm.max_spare_servers = 20

pm.max_requests = 500

process.priority = -10

```

Формула расчета pm.max_children: выделите 70% доступной RAM сервера под PHP и разделите на средний объем памяти одного процесса (обычно 35–50 МБ). На VDS с 4 ГБ RAM оптимальным значением будет 50–60 воркеров.

Шаг 2. Настройка таймаутов и буферов FastCGI в Nginx

В конфигурации вашего виртуального хоста Nginx (/etc/nginx/conf.d/site.conf) добавьте следующие параметры в блок location ~ \.php$:

```nginx

location ~ \.php$ {

include fastcgi_params;

fastcgi_pass unix:/run/php/php8.2-fpm.sock;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

fastcgi_read_timeout 300;

fastcgi_send_timeout 300;

fastcgi_connect_timeout 60;

fastcgi_buffer_size 64k;

fastcgi_buffers 16 32k;

fastcgi_busy_buffers_size 128k;

}

```

Шаг 3. Корректировка лимитов в php.ini

Увеличьте максимальное время выполнения скрипта и объем выделяемой памяти в /etc/php.ini:

```ini

memory_limit = 256M

max_execution_time = 300

max_input_time = 300

upload_max_filesize = 64M

post_max_size = 64M

```

Часто задаваемые вопросы (FAQ)

В чем разница между ошибками 502 Bad Gateway и 504 Gateway Time-out в Nginx?

Ошибка 502 означает немедленный сброс или отказ соединения (PHP-FPM упал или сокет недоступен), а ошибка 504 означает, что бэкенд жив, но не успел вернуть ответ за отведенное время таймаута (например, 60 секунд fastcgi_read_timeout) из-за зависшего запроса или тяжелой выборки.

Какие параметры Nginx и PHP-FPM отвечают за устранение 504 Gateway Time-out?

В блоке location конфига Nginx увеличивают fastcgi_read_timeout и proxy_read_timeout (например, до 180s или 300s), а в php.ini синхронно поднимают max_execution_time и max_input_time.

Как быстро восстановить работу сервера при 502 ошибке?

Проверьте статус службы командой 'systemctl status php*-fpm', изучите последние строки лога ошибок '/var/log/nginx/error.log' и скорректируйте лимиты pm.max_children и memory_limit в www.conf.

Итоговое резюме по устранению сбоя

После внесения изменений выполните синтаксическую проверку конфига nginx -t и перезагрузите сервисы systemctl reload nginx php-fpm. Мониторинг логов позволит вовремя заметить утечки памяти или некорректно оптимизированные SQL-запросы.

Если после выполнения базовых шагов ошибка сохраняется, рекомендуется провести полный аудит взаимодействия дисковой подсистемы IOPS и сетевых портов сервера. Системные администраторы советуют логировать медленные FastCGI запросы через request_slowlog_timeout и контролировать пиковые значения нагрузки для своевременного масштабирования вычислительных ресурсов.