Ошибка 504 Gateway Timeout: что означает и как исправить Печать

Ошибка 504 Gateway Timeout означает, что сервер, который обрабатывает запрос пользователя как шлюз или прокси, не дождался ответа от другого сервера в установленный промежуток времени.

Проще говоря, один сервер отправил запрос другому, но не получил от него ответ вовремя.

Такая ситуация часто возникает при работе связки Nginx → PHP-FPM, Nginx → Apache, Cloudflare → origin-сервер, а также при использовании reverse proxy, API и других backend-сервисов.

В отличие от ошибки 503, при которой сервис обычно недоступен или не может принять запрос, ошибка 504 чаще говорит о том, что backend доступен, но отвечает слишком долго.

Как выглядит ошибка 504

В зависимости от сервера и используемого прокси пользователь может увидеть:

504 Gateway Timeout

или:

HTTP 504 Gateway Timeout

Если сайт работает через Cloudflare, внешний вид страницы ошибки будет зависеть от Cloudflare и конфигурации origin-сервера.

Сам код 504 означает, что промежуточный сервер не дождался ответа от upstream-сервера.

Как работает запрос при возникновении 504

Типичная схема может выглядеть так:

Браузер
   ↓
Cloudflare
   ↓
Nginx
   ↓
PHP-FPM / Apache
   ↓
MySQL / MariaDB

Например, пользователь открывает страницу WordPress.

Nginx передает запрос PHP-FPM. PHP начинает обрабатывать страницу, обращается к базе данных, выполняет код плагинов и формирует ответ.

Если обработка занимает слишком много времени и установленный timeout истекает, Nginx или другой промежуточный сервер возвращает пользователю 504 Gateway Timeout.

Поэтому сама ошибка 504 не обязательно означает, что веб-сервер полностью не работает.

Основные причины ошибки 504

На практике 504 чаще всего возникает из-за следующих причин:

• слишком долгой обработки PHP-запроса;

• медленного SQL-запроса;

• высокой нагрузки на CPU;

• нехватки оперативной памяти;

• перегруженной базы данных;

• зависшего PHP-процесса;

• проблем с PHP-FPM;

• слишком маленького значения timeout;

• медленного backend-приложения;

• проблем reverse proxy;

• внешнего API, которое долго отвечает;

• сетевых проблем между серверами;

• перегрузки origin-сервера;

• неправильной конфигурации Nginx или Apache;

• ограничений Cloudflare или другого CDN.

Начинать диагностику лучше не с увеличения timeout, а с определения того, какой именно компонент не успевает ответить.

Проверьте нагрузку на VPS

Первым делом проверьте состояние сервера:

top

или:

htop

Если htop не установлен, можно использовать стандартный top.

Обратите внимание на:

• загрузку CPU;

• использование RAM;

• swap;

• количество работающих процессов;

• процессы PHP-FPM;

• MySQL или MariaDB.

Если процессор постоянно загружен на 100%, приложение может просто не успевать обрабатывать входящие запросы.

Проверьте память:

free -h

Если оперативная память закончилась и сервер активно использует swap, обработка запросов может значительно замедлиться.

Найдите процессы, которые создают нагрузку

Для просмотра процессов с максимальным потреблением CPU:

ps aux --sort=-%cpu | head

Для поиска процессов, которые используют больше всего памяти:

ps aux --sort=-%mem | head

Если в верхней части списка постоянно находится PHP, MySQL или конкретное приложение, это может быть причиной задержек.

Проверьте PHP-FPM

Для сайтов на PHP особое внимание стоит уделить PHP-FPM.

Например, для PHP 8.2:

systemctl status php8.2-fpm

Если используется другая версия PHP, укажите соответствующую версию.

Посмотреть последние сообщения сервиса:

journalctl -u php8.2-fpm -n 100 --no-pager

Если PHP-FPM работает, это еще не означает, что он справляется с нагрузкой.

Проверьте журнал на наличие сообщений о:

• слишком долгом выполнении процессов;

• достижении pm.max_children;

• завершении worker-процессов;

• нехватке памяти;

• ошибках PHP;

• сбоях дочерних процессов.

Проверьте лимит PHP-FPM

Одна из причин медленной обработки запросов — неправильная настройка PHP-FPM.

В конфигурации пула обычно используются:

pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers

Например:

pm.max_children = 20

pm.max_children определяет максимальное количество одновременно работающих PHP-процессов.

Если все доступные процессы заняты, новые запросы могут ждать своей очереди.

Если ожидание становится слишком большим, промежуточный сервер может вернуть 504.

Однако простое увеличение pm.max_children не всегда является правильным решением.

Каждый PHP-процесс потребляет RAM. Если установить слишком большое значение на небольшом VPS, можно получить еще большую нагрузку и даже исчерпание памяти.

Проверьте Nginx

Если используется Nginx, проверьте его состояние:

systemctl status nginx

Затем проверьте конфигурацию:

nginx -t

Если конфигурация корректна, вы увидите:

syntax is ok
test is successful

Если Nginx работает, но возвращает 504, обязательно проверьте его журнал ошибок:

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

Для просмотра новых сообщений в реальном времени:

tail -f /var/log/nginx/error.log

Особенно полезны сообщения, содержащие:

upstream timed out

Например:

upstream timed out (110: Connection timed out)

Это важный признак того, что Nginx не дождался ответа от upstream.

Проверьте настройки timeout в Nginx

В конфигурации Nginx могут использоваться следующие параметры:

proxy_connect_timeout
proxy_send_timeout
proxy_read_timeout
fastcgi_connect_timeout
fastcgi_send_timeout
fastcgi_read_timeout

Например:

fastcgi_read_timeout 60;

Это означает, что Nginx будет ждать ответ от FastCGI в течение указанного времени.

Для reverse proxy может использоваться:

proxy_read_timeout 60;

Если приложение действительно выполняет тяжелую операцию, timeout может оказаться слишком маленьким.

В таком случае его можно увеличить, например:

proxy_read_timeout 120;

После изменения конфигурации обязательно проверьте ее:

nginx -t

И только после успешной проверки перезагрузите Nginx:

systemctl reload nginx

Но увеличивать timeout только для того, чтобы скрыть проблему, не стоит. Если запрос должен выполняться несколько минут, лучше сначала разобраться, почему он настолько медленный.

Проверьте Apache

Если Nginx работает перед Apache, необходимо проверить оба сервиса.

Статус Apache:

systemctl status apache2

На некоторых системах:

systemctl status httpd

Проверьте журнал:

/var/log/apache2/error.log

или:

/var/log/httpd/error_log

Если Apache обрабатывает запрос слишком долго или не может обратиться к PHP, это может привести к 504 на уровне Nginx.

Проверьте backend-приложение

Если используется reverse proxy, убедитесь, что само приложение отвечает.

Например, если Nginx настроен так:

proxy_pass http://127.0.0.1:8080;

проверьте приложение напрямую:

curl -I http://127.0.0.1:8080

Если приложение не отвечает или отвечает с большой задержкой, проблема находится не в Nginx, а на стороне backend.

Можно также проверить время ответа:

time curl -I http://127.0.0.1:8080

Это помогает понять, сколько времени занимает получение ответа.

Проверьте базу данных

Очень часто причина 504 находится не в веб-сервере, а в базе данных.

Проверьте MySQL:

systemctl status mysql

или MariaDB:

systemctl status mariadb

Если база работает, проверьте текущие запросы:

mysqladmin processlist

Ищите запросы, которые выполняются необычно долго.

Особенно часто проблемы возникают при:

• больших SQL-запросах;

• отсутствии индексов;

• обработке большого количества записей;

• импорте данных;

• резервном копировании;

• высокой нагрузке;

• работе неоптимизированных плагинов.

Найдите долгие SQL-запросы

Если 504 появляется при загрузке конкретной страницы, возможно, именно эта страница запускает тяжелый SQL-запрос.

Для MySQL можно проверить активные процессы:

SHOW FULL PROCESSLIST;

Обратите внимание на запросы, которые долго находятся в состоянии:

Query
Locked
Sending data
Waiting

Не каждый долгий запрос является ошибкой, поэтому не следует завершать процессы без понимания того, что они делают.

Если проблема повторяется, лучше найти сам SQL-запрос и оптимизировать его.

Проверьте внешние API

Иногда сайт работает нормально, но отдельная страница возвращает 504 из-за внешнего сервиса.

Например:

Ваш сервер
   ↓
Внешний API
   ↓
Ответ

Если API отвечает 30–60 секунд или вообще не отвечает, ваш сервер может не дождаться результата.

Это особенно часто встречается в:

• платежных системах;

• CRM;

• API доставки;

• внешних базах данных;

• системах аналитики;

• сервисах авторизации;

• сторонних интеграциях.

Проверьте логи приложения и определите, какой внешний запрос выполняется перед появлением 504.

Проверьте сетевое соединение

Если backend находится на другом сервере, проверьте сетевое соединение.

Например:

ping 192.0.2.10

Для проверки TCP-порта:

nc -zv 192.0.2.10 8080

Если порт недоступен, проверьте:

• firewall;

• security groups;

• маршрутизацию;

• настройки backend;

• доступность самого сервера.

При этом отсутствие ответа на ping не всегда означает проблему: ICMP может быть отключен на сервере или firewall.

Проверьте firewall

Если запрос проходит между несколькими серверами, firewall может задерживать или полностью блокировать соединение.

Для UFW:

sudo ufw status

Для firewalld:

sudo firewall-cmd --list-all

Проверьте, разрешен ли необходимый трафик между серверами.

Не стоит открывать backend-порты для всего интернета, если они нужны только для внутреннего взаимодействия.

Проверьте Cloudflare

Если сайт работает через Cloudflare, схема выглядит примерно так:

Пользователь
   ↓
Cloudflare
   ↓
Origin server
   ↓
Nginx
   ↓
PHP-FPM / Apache
   ↓
Database

При возникновении 504 важно определить, на каком участке происходит задержка.

Если origin-сервер сам отвечает слишком долго, Cloudflare не сможет исправить проблему.

Проверьте сайт непосредственно на origin-сервере, если такая возможность есть.

Если origin отвечает быстро, а через Cloudflare появляется ошибка, проверьте:

• настройки DNS;

• proxy status;

• Cloudflare Rules;

• firewall;

• timeout;

• последние изменения конфигурации.

Важный момент при использовании Cloudflare

Cloudflare имеет собственные ограничения на время ожидания ответа от origin-сервера.

Поэтому увеличение proxy_read_timeout в Nginx не всегда решит проблему.

Например, если приложение обрабатывает запрос несколько минут, Cloudflare может завершить соединение раньше, чем Nginx получит окончательный результат.

В таком случае лучше изменить саму логику приложения.

Вместо одного длительного запроса можно:

1. запустить операцию в фоновом режиме;

2. вернуть пользователю подтверждение запуска;

3. выполнять обработку через очередь;

4. получить результат отдельным запросом.

Такой подход намного надежнее для тяжелых операций.

Если 504 появляется только на одной странице

Если весь сайт работает нормально, а ошибка возникает только при открытии одной страницы, проблема чаще всего связана с конкретной операцией.

Например:

• тяжелый SQL-запрос;

• большой импорт;

• генерация отчета;

• обработка большого файла;

• запрос к внешнему API;

• неоптимизированный PHP-код;

• плагин WordPress.

В этом случае не стоит увеличивать timeout для всего сайта.

Лучше найти операцию, которая выполняется слишком долго.

Если 504 появляется во время импорта

Импорт большого количества данных часто занимает больше времени, чем разрешено обычным HTTP-запросом.

Например:

Браузер → Nginx → PHP → обработка 500 000 записей

Если операция занимает несколько минут, браузер или reverse proxy может получить 504 еще до того, как PHP закончит работу.

Для больших задач лучше использовать:

• CLI;

• cron;

• очереди;

• фоновые задачи.

Например, вместо запуска импорта через браузер можно выполнить его из консоли:

php import.php

Такой подход не зависит от HTTP timeout.

Если 504 появляется после обновления WordPress

Если ошибка появилась после обновления WordPress, темы или плагина, сначала проверьте PHP и логи.

Если административная панель недоступна, временно отключите плагины:

mv wp-content/plugins wp-content/plugins_backup

После этого проверьте сайт.

Если проблема исчезла, верните каталог:

mv wp-content/plugins_backup wp-content/plugins

и включайте плагины по одному.

Также проверьте совместимость используемой версии PHP с текущей версией WordPress, темы и установленных плагинов.

Если 504 появляется после изменения конфигурации Nginx

Если ошибка появилась сразу после изменения Nginx, проверьте конфигурацию:

nginx -t

Если конфигурация корректна, посмотрите последние записи:

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

При необходимости можно временно вернуть предыдущую рабочую конфигурацию.

Не изменяйте сразу несколько параметров. Если менять все настройки одновременно, будет сложно понять, какое именно изменение повлияло на работу сайта.

Проверьте дисковое пространство

Нехватка места на диске также может приводить к непредсказуемому поведению сервисов.

Проверьте:

df -h

И inode:

df -i

Если диск заполнен на 100%, освободите место и снова проверьте работу сайта.

Особое внимание стоит уделить:

• /var/log;

• резервным копиям;

• временным файлам;

• кешу;

• старым архивам.

Проверьте системные журналы

Если причина не очевидна, посмотрите системные сообщения:

journalctl --since "10 minutes ago"

Если 504 появляется периодически, лучше запускать диагностику сразу после возникновения ошибки.

Это позволит сопоставить время ошибки с событиями в:

• Nginx;

• PHP-FPM;

• Apache;

• MySQL;

• системе.

Как определить источник проблемы

Удобнее всего двигаться сверху вниз:

Cloudflare
   ↓
Nginx / Apache
   ↓
PHP-FPM / backend
   ↓
Application
   ↓
Database
   ↓
External API

Проверяйте каждый уровень отдельно.

Например, если:

• Nginx работает;

• PHP-FPM работает;

• PHP отвечает быстро;

• база данных отвечает быстро;

• но внешний API отвечает 90 секунд,

то именно внешний API может быть причиной 504.

Такой подход значительно быстрее, чем изменение всех timeout-параметров подряд.

Быстрый алгоритм диагностики

Если сайт возвращает 504 Gateway Timeout, проверьте:

1. Загрузку CPU и RAM.

2. Использование swap.

3. Состояние Nginx или Apache.

4. Логи веб-сервера.

5. Состояние PHP-FPM.

6. Логи PHP-FPM.

7. Лимиты pm.max_children.

8. Время ответа backend.

9. Состояние MySQL или MariaDB.

10. Долгие SQL-запросы.

11. Внешние API и интеграции.

12. Firewall и сетевое соединение.

13. Настройки reverse proxy.

14. Cloudflare, если он используется.

15. Свободное место на диске.

Как уменьшить вероятность появления 504

Если сайт регулярно сталкивается с 504, стоит искать не временное решение, а причину.

Полезно контролировать:

• CPU;

• RAM;

• swap;

• PHP-FPM;

• MySQL;

• количество соединений;

• время ответа backend;

• медленные SQL-запросы;

• внешние API;

• ошибки веб-сервера.

Для сайтов с высокой нагрузкой помогают:

• кеширование;

• CDN;

• оптимизация базы данных;

• PHP OPcache;

• оптимизация PHP-кода;

• фоновые задачи;

• очереди;

• увеличение ресурсов VPS;

• разделение frontend и backend;

• несколько backend-серверов.

Особенно важно не использовать HTTP-запрос для операций, которые объективно выполняются несколько минут. Импорт больших объемов данных, создание резервных копий и тяжелые вычисления лучше запускать через CLI, cron или систему фоновых задач.

Чем 504 отличается от 502 и 503

Эти ошибки часто путают, хотя причина у них может быть разной.

502 Bad Gateway обычно означает, что gateway или proxy получил некорректный ответ от upstream-сервера либо не смог корректно с ним взаимодействовать.

503 Service Unavailable обычно означает, что сервис временно недоступен или не может принять запрос.

504 Gateway Timeout означает, что gateway или proxy не дождался ответа от upstream-сервера за установленное время.

Это различие помогает быстрее определить направление диагностики.