WordPress: ошибка 502 Bad Gateway — причины и решение

MAATRIX

Сайт отдаёт короткое 502 Bad Gateway, админка недоступна, а Nginx жив и спокойно перезапускается. В связке WordPress + Nginx + PHP-FPM это значит одно: внятного ответа от PHP-FPM не пришло — сокета нет, воркер умер или соединение оборвал сам FPM. Разбираем по строкам из error.log.

502 в WordPress — это про PHP-FPM: начните с одной строки лога

Nginx отдаёт статику сам, а всё на .php передаёт в PHP-FPM через fastcgi_pass; 502 значит, что обмен сорвался. Причина пишется дословно:

tail -n 50 /var/log/nginx/error.log | grep -F 'fastcgi://unix'

Заодно проверьте, чей это 502: страница Nginx голая, с подписью <center>nginx/1.24.0</center>, страница Cloudflare — с Ray ID.

curl -sI https://site.ru/ | grep -iE '^(server|cf-ray)'
curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: site.ru' http://127.0.0.1/

Локально 200, а снаружи 502 — ломается CDN, WordPress ни при чём. И не путайте с соседом: 504 — Nginx ждал fastcgi_read_timeout и не дождался, 502 — соединение не установилось или было разорвано (разбор 504).

Сокет PHP-FPM: не тот путь, нет прав, процесс не поднялся

Чаще всего Nginx стучится по адресу, где никто не слушает. Смотрите, что есть и что слушает пул:

ls -l /run/php/
grep -rn '^listen' /etc/php/*/fpm/pool.d/
grep -rn 'fastcgi_pass' /etc/nginx/sites-enabled/
systemctl status php8.3-fpm --no-pager

Классика на Ubuntu — обновление PHP. Поставили 8.4 из PPA ondrej/php, apt остановил старый сервис: в /run/php/ теперь только php8.4-fpm.sock, а в конфиге сайта прежний fastcgi_pass unix:/run/php/php8.3-fpm.sock;. Сайт лежит целиком, вместе с wp-login.php; лечится правкой одной строки и nginx -t && systemctl reload nginx.

Вторая ситуация — 13: Permission denied. Сокет создаёт владелец пула, а ходит в него Nginx от www-data, и в /etc/php/8.3/fpm/pool.d/www.conf это должно быть согласовано:

listen = /run/php/php8.3-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Завели пул от пользователя site1 — всё равно оставьте listen.group = www-data. Третья ситуация — FPM не стартовал вовсе, systemctl status показывает Active: failed: причину пишет journalctl -u php8.3-fpm -n 30 --no-pager, синтаксис проверяет php-fpm8.3 -t.

Чтобы отделить проблему Nginx от проблемы PHP, постучитесь в сокет мимо веб-сервера — добавьте в пул ping.path = /ping:

apt install -y libfcgi-bin
SCRIPT_NAME=/ping SCRIPT_FILENAME=/ping REQUEST_METHOD=GET \
  cgi-fcgi -bind -connect /run/php/php8.3-fpm.sock

Ответ pong — FPM жив, значит виноват конфиг Nginx или права на сокет; молчание или Connection refused — проблема на стороне PHP.

Воркер умирает на запросе: OOM-киллер и сегфолт

recv() failed (104: Connection reset by peer) — не сетевая ошибка, а погибший воркер: процесс исчез раньше, чем отдал заголовки. Причин две.

OOM-киллер. Память кончилась, ядро сняло самый крупный процесс — dmesg -T | grep -iE 'killed process|out of memory':

Out of memory: Killed process 21847 (php-fpm8.3) total-vm:1284560kB, anon-rss:412300kB

Тонкость, экономящая часы: убит php-fpm — это 502, убит mariadbd — «Error establishing a database connection». А исчерпание memory_limit внутри PHP 502 не даёт вовсе: скрипт умирает штатно с PHP Fatal error: Allowed memory size of 268435456 bytes exhausted и отдаёт 500 или белый экран.

Сегфолт. В /var/log/php8.3-fpm.log появляется сигнал 11, а виновную библиотеку показывает dmesg -T | grep -i segfault:

WARNING: [pool www] child 21847 exited on signal 11 (SIGSEGV) after 412.339 seconds from start
php-fpm8.3[21847]: segfault at 0 ip 00007f2a1c3d4e21 sp 00007ffd8e9a2b30 error 4 in imagick.so

На WordPress лидируют трое: imagick.so на превью из тяжёлых PNG и PDF, opcache.so после обновления PHP без очистки кэша и auto_prepend_file от Wordfence (wordfence-waf.php). Проверка грубая, но честная: phpdismod -v 8.3 -s fpm imagick && systemctl restart php8.3-fpm. Ушли 502 — переключайте плагин на GD или обновляйте библиотеку; не ушли — возвращайте phpenmod и ищите дальше.

502 вместо 504: PHP-FPM обрывает долгий запрос сам

upstream prematurely closed connection while reading response header from upstream — соединение закрыл PHP-FPM, а не Nginx. По коду это 502, по смыслу таймаут; поэтому и крутят fastcgi_read_timeout. Механика в двух параметрах: fastcgi_read_timeout — сколько ждёт Nginx, request_terminate_timeout в пуле (и max_execution_time в PHP) — сколько живёт скрипт.

В логе FPM момент виден дословно:

WARNING: [pool www] child 3312, script '/var/www/site.ru/index.php' (request: "POST /wp-admin/admin-ajax.php") execution timed out (35.221281 sec), terminating

Правило: request_terminate_timeout держите заведомо больше fastcgi_read_timeout, иначе ошибки мимикрируют друг под друга. Рабочая пара — 180 секунд в пуле против 120 в Nginx:

request_terminate_timeout = 180s
php_admin_value[max_execution_time] = 120
slowlog = /var/log/php8.3-fpm-slow.log
request_slowlog_timeout = 10s

slowlog — самая полезная из четырёх: FPM снимает стек PHP у запросов дольше десяти секунд, и вы видите не «сайт тормозит», а конкретную функцию.

[0x00007f2a] curl_exec()     /var/www/site.ru/wp-includes/class-wp-http-curl.php:158
[0x00007f2a] wp_remote_get() /var/www/site.ru/wp-content/plugins/some-feed/cron.php:44

Трейс закрывает вопрос за минуту: плагин ходит во внешний API без таймаута, воркер стоит и снимается. Лечение — 'timeout' => 5 в wp_remote_get() или удаление плагина, а не рост таймаутов: посетитель всё равно ждёт две минуты, просто вместо 502 увидит 504.

Пул кончился: очередь на сокете, wp-cron и admin-ajax

connect() to unix:/run/php/php8.3-fpm.sock failed (11: Resource temporarily unavailable) означает, что свободных воркеров нет, а очередь на сокете переполнена. Это 502 «по нагрузке»: приходит волнами в часы трафика. Сначала измерьте — включите статус, доступный только с локалхоста:

pm.status_path = /fpm-status
listen.backlog = 511

location = /fpm-status {
    allow 127.0.0.1;
    deny all;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

$ curl -s -H 'Host: site.ru' http://127.0.0.1/fpm-status
process manager:      ondemand
active processes:     12
max children reached: 17
listen queue:         128
slow requests:        43

Ненулевой max children reached — прямая улика: пул упирался в потолок 17 раз. То же видно без статуса — ss -lnx | grep fpm: первое число Recv-Q, необслуженные соединения, второе Send-Q, текущий listen.backlog.

Не поднимайте pm.max_children вслепую: умножьте новое значение на средний вес воркера и сверьте со свободной памятью.

ps --no-headers -o rss -C php-fpm8.3 | awk '{s+=
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть WordPress
Воркер умирает на запросе: OOM-киллер и сегфолт
recv() failed (104: Connection reset by peer) — не сетевая ошибка, а погибший воркер: процесс исчез раньше, чем отдал заголовки. Причин две.
OOM-киллер. Память кончилась, ядро сняло самый крупный процесс — dmesg -T | grep -iE 'killed process|out of memory':
Out of memory: Killed process 21847 (php-fpm8.3) total-vm:1284560kB, anon-rss:412300kB
Тонкость, экономящая часы: убит php-fpm — это 502, убит mariadbd — «Error establishing a database connection». А исчерпание memory_limit внутри PHP 502 не даёт вовсе: скрипт умирает штатно с PHP Fatal error: Allowed memory size of 268435456 bytes exhausted и отдаёт 500 или белый экран.
Сегфолт. В /var/log/php8.3-fpm.log появляется сигнал 11, а виновную библиотеку показывает dmesg -T | grep -i segfault:
WARNING: [pool www] child 21847 exited on signal 11 (SIGSEGV) after 412.339 seconds from start
php-fpm8.3[21847]: segfault at 0 ip 00007f2a1c3d4e21 sp 00007ffd8e9a2b30 error 4 in imagick.so
На WordPress лидируют трое: imagick.so на превью из тяжёлых PNG и PDF, opcache.so после обновления PHP без очистки кэша и auto_prepend_file от Wordfence (wordfence-waf.php). Проверка грубая, но честная: phpdismod -v 8.3 -s fpm imagick && systemctl restart php8.3-fpm. Ушли 502 — переключайте плагин на GD или обновляйте библиотеку; не ушли — возвращайте phpenmod и ищите дальше.
502 вместо 504: PHP-FPM обрывает долгий запрос сам
upstream prematurely closed connection while reading response header from upstream — соединение закрыл PHP-FPM, а не Nginx. По коду это 502, по смыслу таймаут; поэтому и крутят fastcgi_read_timeout. Механика в двух параметрах: fastcgi_read_timeout — сколько ждёт Nginx, request_terminate_timeout в пуле (и max_execution_time в PHP) — сколько живёт скрипт.
Что срабатывает первым
Что видит посетитель
fastcgi_read_timeout — Nginx устал ждать
504 Gateway Time-Out
request_terminate_timeout — FPM убил скрипт
502 Bad Gateway
В логе FPM момент виден дословно:
WARNING: [pool www] child 3312, script '/var/www/site.ru/index.php' (request: "POST /wp-admin/admin-ajax.php") execution timed out (35.221281 sec), terminating
Правило: request_terminate_timeout держите заведомо больше fastcgi_read_timeout, иначе ошибки мимикрируют друг под друга. Рабочая пара — 180 секунд в пуле против 120 в Nginx:
request_terminate_timeout = 180s
php_admin_value[max_execution_time] = 120
slowlog = /var/log/php8.3-fpm-slow.log
request_slowlog_timeout = 10s
slowlog — самая полезная из четырёх: FPM снимает стек PHP у запросов дольше десяти секунд, и вы видите не «сайт тормозит», а конкретную функцию.
[0x00007f2a] curl_exec()     /var/www/site.ru/wp-includes/class-wp-http-curl.php:158
[0x00007f2a] wp_remote_get() /var/www/site.ru/wp-content/plugins/some-feed/cron.php:44
Трейс закрывает вопрос за минуту: плагин ходит во внешний API без таймаута, воркер стоит и снимается. Лечение — 'timeout' => 5 в wp_remote_get() или удаление плагина, а не рост таймаутов: посетитель всё равно ждёт две минуты, просто вместо 502 увидит 504.
Пул кончился: очередь на сокете, wp-cron и admin-ajax
connect() to unix:/run/php/php8.3-fpm.sock failed (11: Resource temporarily unavailable) означает, что свободных воркеров нет, а очередь на сокете переполнена. Это 502 «по нагрузке»: приходит волнами в часы трафика. Сначала измерьте — включите статус, доступный только с локалхоста:
pm.status_path = /fpm-status
listen.backlog = 511
location = /fpm-status {
    allow 127.0.0.1;
    deny all;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
$ curl -s -H 'Host: site.ru' http://127.0.0.1/fpm-status
process manager:      ondemand
active processes:     12
max children reached: 17
listen queue:         128
slow requests:        43
Ненулевой max children reached — прямая улика: пул упирался в потолок 17 раз. То же видно без статуса — ss -lnx | grep fpm: первое число Recv-Q, необслуженные соединения, второе Send-Q, текущий listen.backlog.
Не поднимайте pm.max_children вслепую: умножьте новое значение на средний вес воркера и сверьте со свободной памятью.
ps --no-headers -o rss -C php-fpm8.3 | awk '{s+=$1;n++} END {print s/n/1024" MB, "n" proc"}'
Обычный WordPress даёт 45–70 МБ на процесс, сайт на Elementor — 120–160 МБ. Пул на 40 воркеров при 4 ГБ RAM просто меняет 502 по очереди на 502 по OOM-киллеру. Полезнее убрать источник запросов:
wp-cron на каждом хите. WordPress дёргает wp-cron.php петлёй на себя при посещениях, на ботовом трафике расход воркеров удваивается. Ставьте define('DISABLE_WP_CRON', true); в wp-config.php и крон */5 * * * * cd /var/www/site.ru && wp cron event run --due-now --quiet.
admin-ajax.php и Heartbeat. В открытом редакторе WordPress стучится каждые 15 секунд, десяток забытых вкладок выедает пул целиком. Частоту правит плагин Heartbeat Control или фильтр heartbeat_settings.
Боты на /?s= и xmlrpc.php. Поиск не кэшируется и бьёт в базу: location = /xmlrpc.php { deny all; } плюс limit_req.
Радикально снимает вопрос микрокэш Nginx: анонимные страницы отдаются без обращения к PHP (настройка).
502 только на отдельных страницах: заголовки, буферы и диск
Бывает, что сайт работает, а падают отдельные адреса: /checkout/, вход в админку, сохранение большой страницы в конструкторе. В логе тогда стоит:
[error] 918#918: *5123 upstream sent too big header while reading response header from upstream, request: "GET /checkout/ HTTP/1.1"
По умолчанию Nginx выделяет под заголовки ответа один буфер в страницу памяти — 4 КБ. WooCommerce с набором Set-Cookie, длинные Location от SEO-плагинов и заголовки безопасности перебивают лимит, и ответ отбрасывается. Лечится в серверном блоке:
fastcgi_buffer_size 32k;
fastcgi_buffers 16 16k;
fastcgi_busy_buffers_size 64k;
fastcgi_buffer_size — тот самый первый буфер под заголовки, остальные два отвечают за тело. Дальше nginx -t && systemctl reload nginx.
Вторая причина точечных 502 — кончилось место или иноды: на полном диске FPM не создаёт сокет после рестарта. Смотрите обе строки, df -h / и df -i /: на WooCommerce сессии в /var/lib/php/sessions выедают иноды задолго до мегабайтов, чистит их phpsessionclean.timer.
Третья: короткий 502 сразу после systemctl restart php8.3-fpm — Nginx успевает принять запрос, пока сокет пересоздаётся. Для изменений в пуле используйте systemctl reload php8.3-fpm: мягкая перезагрузка сокет не разрывает.
Какой сервер под WordPress брать в MAATRIX
502 у WordPress почти всегда упирается в память: воркеров ставят столько, сколько её нет, и сайт живёт между OOM-киллером и очередью.
Минимум: 2 vCPU, 2 ГБ RAM, 40 ГБ NVMe. Nginx (~40 МБ), MariaDB (~400 МБ) и 8–12 воркеров FPM в ondemand по 60–70 МБ — хватает блогу или корпоративному сайту до пары тысяч визитов в сутки. Честное ограничение: на 1 ГБ WordPress ставится и открывается, но первое же сохранение страницы в Elementor рядом с MariaDB уводит машину в своп, и 502 становится фоновым шумом.
Комфортный вариант: 2–4 vCPU, 4–8 ГБ RAM, 80 ГБ NVMe. Помещаются 20–25 воркеров, Redis под объектный кэш, innodb_buffer_pool_size в 1–2 ГБ и микрокэш Nginx. Для WooCommerce это нижняя разумная планка: воркер магазина весит 90–140 МБ, а корзина и оформление заказа не кэшируются в принципе.
Локация — UK, Лондон. Для двуязычного сайта удачный компромисс: RTT до Москвы 45–60 мс, до Европы единицы миллисекунд, плюс европейская юрисдикция и GDPR — существенно, если через сайт идут формы и платежи клиентов из ЕС. Вся аудитория в России и есть персданные по 152-ФЗ — берите RU-площадку: пинг 5–15 мс.
WordPress из каталога apps.maatrix.io ставится автоматически при заказе — команды вставлять не нужно, автоустановка работает на Ubuntu и Debian, доступы появляются в личном кабинете, в разделе «Доступ». Вы получаете согласованную связку Nginx + PHP-FPM + MariaDB, где путь к сокету, права и параметры пула не разъезжаются, — то есть половину причин 502 из этой статьи. Выбрать конфигурацию можно сразу под нагрузку; оплата — картой российского банка, по СБП, криптой или токеном MAAT.
Дальше по теме: установка WordPress на LEMP и частые ошибки WordPress на сервере.
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть WordPress
;n++} END {print s/n/1024" MB, "n" proc"}'

Обычный WordPress даёт 45–70 МБ на процесс, сайт на Elementor — 120–160 МБ. Пул на 40 воркеров при 4 ГБ RAM просто меняет 502 по очереди на 502 по OOM-киллеру. Полезнее убрать источник запросов:

• wp-cron на каждом хите. WordPress дёргает wp-cron.php петлёй на себя при посещениях, на ботовом трафике расход воркеров удваивается. Ставьте define('DISABLE_WP_CRON', true); в wp-config.php и крон */5 * * * * cd /var/www/site.ru && wp cron event run --due-now --quiet.
• admin-ajax.php и Heartbeat. В открытом редакторе WordPress стучится каждые 15 секунд, десяток забытых вкладок выедает пул целиком. Частоту правит плагин Heartbeat Control или фильтр heartbeat_settings.
• Боты на /?s= и xmlrpc.php. Поиск не кэшируется и бьёт в базу: location = /xmlrpc.php { deny all; } плюс limit_req.

Радикально снимает вопрос микрокэш Nginx: анонимные страницы отдаются без обращения к PHP (настройка).

502 только на отдельных страницах: заголовки, буферы и диск

Бывает, что сайт работает, а падают отдельные адреса: /checkout/, вход в админку, сохранение большой страницы в конструкторе. В логе тогда стоит:

[error] 918#918: *5123 upstream sent too big header while reading response header from upstream, request: "GET /checkout/ HTTP/1.1"

По умолчанию Nginx выделяет под заголовки ответа один буфер в страницу памяти — 4 КБ. WooCommerce с набором Set-Cookie, длинные Location от SEO-плагинов и заголовки безопасности перебивают лимит, и ответ отбрасывается. Лечится в серверном блоке:

fastcgi_buffer_size 32k;
fastcgi_buffers 16 16k;
fastcgi_busy_buffers_size 64k;

fastcgi_buffer_size — тот самый первый буфер под заголовки, остальные два отвечают за тело. Дальше nginx -t && systemctl reload nginx.

Вторая причина точечных 502 — кончилось место или иноды: на полном диске FPM не создаёт сокет после рестарта. Смотрите обе строки, df -h / и df -i /: на WooCommerce сессии в /var/lib/php/sessions выедают иноды задолго до мегабайтов, чистит их phpsessionclean.timer.

Третья: короткий 502 сразу после systemctl restart php8.3-fpm — Nginx успевает принять запрос, пока сокет пересоздаётся. Для изменений в пуле используйте systemctl reload php8.3-fpm: мягкая перезагрузка сокет не разрывает.

Какой сервер под WordPress брать в MAATRIX

502 у WordPress почти всегда упирается в память: воркеров ставят столько, сколько её нет, и сайт живёт между OOM-киллером и очередью.

Минимум: 2 vCPU, 2 ГБ RAM, 40 ГБ NVMe. Nginx (~40 МБ), MariaDB (~400 МБ) и 8–12 воркеров FPM в ondemand по 60–70 МБ — хватает блогу или корпоративному сайту до пары тысяч визитов в сутки. Честное ограничение: на 1 ГБ WordPress ставится и открывается, но первое же сохранение страницы в Elementor рядом с MariaDB уводит машину в своп, и 502 становится фоновым шумом.

Комфортный вариант: 2–4 vCPU, 4–8 ГБ RAM, 80 ГБ NVMe. Помещаются 20–25 воркеров, Redis под объектный кэш, innodb_buffer_pool_size в 1–2 ГБ и микрокэш Nginx. Для WooCommerce это нижняя разумная планка: воркер магазина весит 90–140 МБ, а корзина и оформление заказа не кэшируются в принципе.

Локация — UK, Лондон. Для двуязычного сайта удачный компромисс: RTT до Москвы 45–60 мс, до Европы единицы миллисекунд, плюс европейская юрисдикция и GDPR — существенно, если через сайт идут формы и платежи клиентов из ЕС. Вся аудитория в России и есть персданные по 152-ФЗ — берите RU-площадку: пинг 5–15 мс.

WordPress из каталога apps.maatrix.io ставится автоматически при заказе — команды вставлять не нужно, автоустановка работает на Ubuntu и Debian, доступы появляются в личном кабинете, в разделе «Доступ». Вы получаете согласованную связку Nginx + PHP-FPM + MariaDB, где путь к сокету, права и параметры пула не разъезжаются, — то есть половину причин 502 из этой статьи. Выбрать конфигурацию можно сразу под нагрузку; оплата — картой российского банка, по СБП, криптой или токеном MAAT.

Дальше по теме: установка WordPress на LEMP и частые ошибки WordPress на сервере.

Частые вопросы