504 Gateway Timeout на WordPress — как исправить

В отличие от 502 Bad Gateway (PHP-FPM упал), 504 означает что PHP работает, но не успевает ответить за отведённое время. На WordPress это случается при тяжёлых плагинах (WP All Import, WooCommerce с 10 000 товаров), медленных API-запросах или нехватке воркеров PHP-FPM. Дальше — от быстрой проверки к глубокой диагностике.

4 причины 504 Gateway Timeout

1. Низкий таймаут прокси в Nginx — стандартный proxy_read_timeout (60 секунд) слишком мал для импорта, генерации отчётов или массовой обработки записей. Самая частая и легко исправляемая причина.
2. Перегрузка PHP-FPM — все воркеры заняты долгими запросами, новые запросы встают в очередь и не дожидаются ответа. Типично для дешёвых VPS с 1-2 ядрами и низким pm.max_children.
3. Медленный PHP-скрипт или внешний API — плагин делает десятки HTTP-запросов (например, проверка обновлений, синхронизация с CRM, загрузка изображений) и каждый висит по 10-30 секунд.
4. Проблемы с базой данных — длинные MySQL-запросы (без индексов, большие JOIN) блокируют выполнение PHP. WordPress ждёт ответа от БД, Nginx ждёт ответа от PHP — истекает таймаут.

Как исправить: пошагово

Шаг 1. Быстрая проверка (1 минута)

Проверьте, возникает ли 504 на всех страницах или только на одной.

• 504 везде — проблема с PHP-FPM или Nginx. Идите к шагу 2.
• 504 на одной странице/действии — проблема в конкретном плагине или скрипте. Идите к шагу 4.
• 504 время от времени — перегрузка PHP-FPM под пиковой нагрузкой. Идите к шагу 3.

Заодно проверьте /var/log/nginx/error.log и /var/log/php8.x-fpm.log — ошибки там точнее чем на экране.

Шаг 2. Увеличьте таймаут в Nginx

Если у вас VPS и вы управляете Nginx сами, отредактируйте конфиг сайта (обычно /etc/nginx/sites-enabled/your-site):

http {
    proxy_read_timeout 300;
    proxy_connect_timeout 75;
    fastcgi_read_timeout 300;
    # или в location ~ \.php$ блоке:
    location ~ \.php$ {
        fastcgi_read_timeout 300;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
}

После правки проверьте и перезагрузите:

sudo nginx -t && sudo systemctl reload nginx

На Beget (shared-хостинг) вы не можете править Nginx — обратитесь в поддержку или переходите на VPS. На Timeweb на тарифах «Виртуальный сервер» доступ к Nginx есть.

Шаг 3. Оптимизируйте PHP-FPM пул

Если воркеров не хватает, очередь растёт и новые запросы падают с 504.

Отредактируйте пул /etc/php/8.2/fpm/pool.d/www.conf:

pm = dynamic
pm.max_children = 10
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

Формула расчёта: max_children = RAM (MB) / memory_limit (MB). Например, на VPS 2GB RAM при memory_limit=128M: 2048 / 128 = 16. Ставьте 10-12 с запасом.

Проверьте текущую загрузку воркеров:

ps aux | grep 'php-fpm' | grep -v grep | wc -l
# или через статусный сокет:
sudo tail -f /var/log/php8.2-fpm.log | grep 'WARNING'
# Если видите: WARNING: [pool www] seems busy (you may need to increase pm.start_servers)
# — значит идёте верным путём

Перезагрузите PHP-FPM после правок:

sudo systemctl reload php8.2-fpm

Шаг 4. Найдите проблемный плагин

Если 504 только при конкретном действии — виноват плагин или функция темы.

1. Импорт/экспорт — WP All Import, WooCommerce CSV Import. Настройте пакетную обработку: 50 записей за проход вместо 500. Увеличьте таймаут в PHP: в wp-config.php добавьте set_time_limit(300); перед импортом.
2. SEO-плагины — Rank Math и Yoast создают тяжёлые запросы при перегенерации sitemap или редиректов. Отключите авто-генерацию sitemap в настройках.
3. Обновления — WordPress проверяет обновления плагинов через API. Если API Яндекса или wordpress.org недоступен, запрос висит до таймаута. Отключите проверку: добавьте в wp-config.php define('WP_AUTO_UPDATE_CORE', false);.
4. Внешние API — плагины кэширования валют, доставки СДЭК, погоды делают HTTP-запросы к внешним серверам. Если API не отвечает 30+ секунд — 504.

Отключайте плагины по одному через FTP (переименуйте папку в /wp-content/plugins/) и проверяйте, уходит ли 504.

Как проверить результат

1. После каждого шага перезагрузите страницу, на которой была 504. Должна открыться за 1-3 секунды.
2. Проверьте sudo tail -100 /var/log/nginx/error.log | grep 504 — новых ошибок быть не должно.
3. Откройте страницу, которая раньше падала, в инструментах разработчика (F12 → Network). Время ответа сервера (TTFB) должно быть < 2000 мс.
4. Если проблема была в импорте — запустите импорт повторно. Он должен выполниться без 504.
5. Проверьте curl -I https://вашсайт.ру — ответ 200 OK, без редиректов и таймаутов.

Когда этот способ не сработает

• 504 на домашней странице при нулевом трафике — завис не WordPress, а PHP-FPM процесс. Проверьте: sudo systemctl status php8.2-fpm. Если статус failed — рестарт: sudo systemctl restart php8.2-fpm. На Beget shared — обратитесь в поддержку.
• 504 после установки нового плагина — деактивируйте его через FTP (переименуйте папку плагина) и удалите. Не пытайтесь «настроить» плагин — если он даёт 504 из коробки, он несовместим с вашим стеком.
• 504 на всех страницах после обновления PHP — новый PHP (8.3, 8.4) может быть несовместим с частью плагинов. Откатите версию PHP через панель хостинга. На Beget — в разделе «Управление PHP», на Timeweb — в «Настройки PHP».
• 504 только в админке WordPress — проблема не в Nginx, а в wp-admin. Проверьте: php -d memory_limit=256M wp-admin/admin-ajax.php. Если падает — увеличьте лимит памяти через wp-config.php: define('WP_MEMORY_LIMIT', '256M');.
• 504 в WooCommerce при оформлении заказа — проблема с плагином оплаты (ЮKassa, CloudPayments) или доставки (СДЭК). Временно переключите способ оплаты на «Наложенный платёж» и проверьте. Если работает — пишите в поддержку платёжного шлюза.

Диагностика через логи (для VPS)

Если ни один шаг не помог — смотрите логи в реальном времени:

# Nginx upstream логи (покажут какой бэкенд не отвечает)
sudo tail -f /var/log/nginx/error.log | grep upstream

# PHP-FPM slow log (покажет какие скрипты тормозят)
sudo tail -f /var/log/php8.2-fpm.log.slow

# MySQL slow queries
sudo tail -f /var/log/mysql/mysql-slow.log

Чтобы slow log работал, включите в pool.d/www.conf:

slowlog = /var/log/php8.2-fpm.log.slow
request_slowlog_timeout = 10s

После правки рестарт PHP-FPM. Через 10-15 минут в slowlog будут видны все скрипты, которые работают дольше 10 секунд — это и есть причины 504.

Переезд сайта

Настрою сервер, SSL, бэкапы.

7.200

Подробнее

Техническая оптимизация

Серверный кэш, PHP-FPM, Nginx.

7.200

Подробнее