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

Что такое 504 Gateway Timeout?

504 Gateway Timeout — это код состояния HTTP, который означает, что сервер, выступающий в роли шлюза или прокси, не получил своевременный ответ от upstream-сервера. Прокси ждал ответа от upstream, но тот отвечал слишком долго, поэтому прокси прекратил ожидание и вернул ошибку 504 в ваш браузер.

RFC 9110 определяет его так: «Код состояния 504 (Gateway Timeout) означает, что сервер, действуя как шлюз или прокси, не получил своевременного ответа от вышестоящего (upstream) сервера, к которому ему нужно было обратиться, чтобы выполнить запрос» (RFC 9110 §15.6.5).

Ключевое слово — шлюз. Ошибка 504 всегда подразумевает как минимум два сервера: тот, к которому вы подключились (прокси/шлюз), и тот, что стоит за ним (upstream/origin), который не ответил вовремя. Типичные прокси: Nginx reverse proxy, Cloudflare, AWS Application Load Balancer (ALB) и CloudFront.

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

Текст зависит от того, какой уровень сдался:

• 504 Gateway Time-out с «nginx» ниже: nginx (пишет через дефис)
• 504 Gateway Time-out · The server didn't respond in time.: страница HAProxy по умолчанию
• Gateway Timeout · The gateway did not receive a timely response from the upstream server or application.: Apache перед PHP-FPM (mod_proxy_fcgi). Если Apache проксирует HTTP-бэкенд, он показывает Proxy Error · Error reading from remote server (это 502).
• ERROR · The request could not be satisfied · 504 ERROR: Amazon CloudFront
• Error 524: A timeout occurred: вариант Cloudflare; он дошёл до вашего сервера, но ответ не пришёл вовремя
• Страница недоступна · Превышено время ожидания ответа от сайта example.com. · Ошибка HTTP 504: Chrome, когда у 504 нет собственной страницы

Как бы ни была сформулирована ошибка, причина одна: прокси ждал сервер за собой, а ответ не пришёл вовремя. (Chrome использует ту же фразу «Превышено время ожидания ответа от сайта», когда браузер вообще не смог подключиться, но тогда заголовок «Не удается получить доступ к сайту», а код ERR_CONNECTION_TIMED_OUT, а не Ошибка HTTP 504: см. ERR_CONNECTION_TIMED_OUT.)

Как возникает ошибка 504 Gateway Timeout

Чтобы понять ошибку 504, нужно разобраться в цепочке таймаутов между браузером и origin-сервером. Типичный веб-запрос проходит через несколько уровней, и у каждого уровня есть свои настройки таймаута.

Типичная цепочка запроса: Браузер → CDN (Cloudflare) → Балансировщик нагрузки → Nginx → PHP-FPM → База данных. Если запрос к базе длится 90 секунд, а fastcgi_read_timeout в nginx равен 60 секундам, nginx перестаёт ждать и возвращает 504 балансировщику, а тот передаёт его через CDN в ваш браузер.

Сервер, который возвращает 504, обычно является прокси посередине, а не самим приложением. Приложение при этом может ещё обрабатывать запрос или зависнуть.

Источники: Cloudflare 524, настройки origin в CloudFront, Google Cloud и документация каждого сервера. Собственный max_execution_time в PHP (30 секунд) 504 не вызывает: скрипт, достигший лимита, останавливается с фатальной ошибкой, которая выглядит как 500. А в Linux он не учитывает время ожидания базы данных и другого ввода-вывода, поэтому скрипт, застрявший на медленном запросе, может работать гораздо дольше.

Распространённые причины ошибки 504 Gateway Timeout

Обычные причины, по которым прокси перестаёт ждать:

• Медленный запрос: тяжёлый запрос к базе, отчёт или вызов медленного стороннего API занимает больше времени, чем таймаут прокси.
• Перегруженный сервер: CPU на 100 %, нехватка памяти или все воркеры PHP-FPM заняты, и новые запросы стоят в очереди, пока прокси не сдастся.
• Узкие места в базе данных: медленные запросы, отсутствующие индексы, заблокированные таблицы или исчерпанный пул соединений.
• Слишком низкие таймауты: 60 секунд nginx мало для бэкенда, которому действительно нужно больше времени (экспорт, импорт, большая загрузка).
• Проблемы сети между прокси и origin: потеря пакетов или файрвол, который молча отбрасывает пакеты прокси (файрвол, который их отклоняет, даёт 502).
• Жёсткий лимит CDN: Cloudflare ждёт 125 секунд на Free, Pro и Business, что бы ни разрешал ваш nginx, а затем показывает Error 524.
• Наплыв трафика: всплеск или атака занимает все воркеры, и обычные запросы не успевают получить ответ. (Сервер, который знает о своей перегрузке, может ответить 503.)

Решение для посетителей: что можно сделать

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

• Подождите минуту и обновите страницу: многие 504 длятся лишь столько, сколько занят сервер.
• Проверьте, недоступен ли сайт для всех: Website Down Checker открывает страницу из 11 мест. Если там тоже 504, проблема на стороне сайта.
• Попробуйте другую сеть: мобильный интернет вместо Wi-Fi или без VPN, на случай если таймаут даёт ваш собственный прокси или VPN.
• Загляните на страницу статуса сайта или в его соцсети: нагруженные сайты часто сообщают о сбоях.

Решение 1: увеличить настройки таймаутов (Nginx и Apache)

Самое распространённое решение для ошибок 504 — увеличение значений таймаута на вашем reverse proxy. Если вашему бэкенду действительно нужно больше 60 секунд (значение по умолчанию), прокси должен знать, что нужно ждать дольше.

# nginx — reverse proxy to a backend (Node.js, Python, etc.)
location / {
    proxy_pass http://backend;
    proxy_read_timeout 300;
    proxy_send_timeout 300;
}

# nginx — FastCGI (PHP-FPM)
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_read_timeout 300;
    fastcgi_send_timeout 300;
    include fastcgi_params;
}

# Leave proxy_connect_timeout / fastcgi_connect_timeout at their defaults:
# nginx caps them at about 75 seconds, and a dead backend should fail fast.

Для Apache добавьте ProxyTimeout 300 в VirtualHost или используйте ProxyPass / http://backend:8080/ timeout=300 для одного бэкенда.

Важно: таймауты чтения и отправки измеряют паузу между двумя последовательными операциями чтения или записи, а не общее время передачи. Поэтому proxy_read_timeout 300 означает «если данные не приходят 300 секунд», а не «весь ответ должен завершиться за 300 секунд». После изменения перезагрузите конфигурацию: sudo nginx -t && sudo systemctl reload nginx.

За CDN действует и его собственный лимит: Cloudflare обрывает запрос на 125 секундах (от Free до Business), CloudFront по умолчанию на 30, поэтому увеличение таймаутов nginx выше этих значений ничего не меняет для посетителей, которые приходят через CDN.

Решение 2: оптимизировать медленные скрипты и запросы к базе данных

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

• Найдите медленные запросы — Включите журнал медленных запросов MySQL (slow_query_log = 1, long_query_time = 1) или используйте EXPLAIN ANALYZE для подозрительных запросов. Добавьте недостающие индексы, избегайте SELECT * и используйте пагинацию для больших наборов результатов.
• Добавьте кэширование — Используйте Redis или Memcached для кэширования результатов тяжёлых запросов. Запрос, который выполняется 5 секунд при каждой загрузке страницы, должен быть закэширован.
• Перенесите тяжёлые задачи в фоновые процессы — Генерация отчётов, отправка писем, обработка изображений и импорт данных должны выполняться в очереди задач (Celery, Sidekiq, Bull), а не в цикле HTTP-запроса.
• Оптимизируйте вызовы API — Если ваш бэкенд обращается к медленным сторонним API, добавьте таймауты для этих вызовов и реализуйте circuit breaker, чтобы один медленный API не блокировал все запросы.
• Устраните проблему N+1 запросов — Запросы, генерируемые ORM, часто делают сотни отдельных обращений к базе данных. Используйте eager loading или пакетные запросы для сокращения количества обращений.

Решение 3: проверить ресурсы сервера (CPU, RAM, диск)

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

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space (full disk = silent failures)
df -h

# Check memory details
free -m

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Check active network connections
ss -s

Если CPU или RAM загружены на 90%+, необходимо либо оптимизировать приложение, остановить «убежавшие» процессы, либо обновить сервер. Если диск заполнен, удалите старые лог-файлы, резервные копии или временные файлы — заполненный диск может привести к тихому падению базы данных и каскадным ошибкам 504.

Решение 4: проверить журналы ошибок

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

# Nginx error log (look for "upstream timed out")
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log       # Debian/Ubuntu
tail -50 /var/log/httpd/error_log          # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.3-fpm.log

# System log (OOM kills, crashes)
tail -50 /var/log/syslog

Типичные сообщения в логах при 504:

«upstream timed out (110: Connection timed out) while reading response header from upstream» (nginx): бэкенд отвечал дольше proxy_read_timeout (или fastcgi_read_timeout). Ускорьте его или увеличьте таймаут, если ожидание оправдано.

«upstream timed out (110: Connection timed out) while connecting to upstream» (nginx): nginx не смог даже подключиться вовремя: файрвол отбрасывает пакеты или бэкенд слишком занят, чтобы принимать соединения.

«server reached pm.max_children setting» (PHP-FPM): все воркеры заняты, поэтому запросы ждут в очереди. Увеличивайте pm.max_children только если хватает RAM; иначе найдите медленные запросы, которые удерживают воркеры.

«Too many connections» (MySQL): лимит соединений исчерпан. Новые соединения отклоняются сразу (это 500, как «Error establishing a database connection» в WordPress), а запросы, которые их удерживают, часто и есть медленные причины ваших 504.

Решение 5: настроить параметры PHP-FPM

Для PHP-приложений (WordPress, Laravel, Magento) держите таймауты цепочкой, где каждый уровень немного длиннее следующего: fastcgi_read_timeout в nginx ≥ request_terminate_timeout в PHP-FPM ≥ max_execution_time в PHP.

После изменения настроек PHP-FPM перезапустите его (sudo systemctl restart php8.3-fpm, подставьте свою версию). Если fastcgi_read_timeout в nginx короче лимитов PHP, nginx сдаётся первым, и посетители видят 504, пока PHP ещё работает.

Решение 6: проверить конфигурацию CDN и прокси

Если сайт стоит за CDN, например Cloudflare или AWS CloudFront, у CDN есть собственные настройки таймаутов, которые могут перекрывать конфигурацию вашего сервера.

Cloudflare: на Free, Pro и Business, если ваш origin не начал отвечать за 125 секунд, Cloudflare сдаётся и показывает Error 524 (Cloudflare). Совет самого Cloudflare: ускорьте запрос, вынесите долгие задачи в фон или отдавайте их с поддомена только с DNS (серое облако); на тарифе Enterprise лимит можно увеличить.

CloudFront: увеличьте response timeout origin в настройках origin дистрибутива (AWS). AWS советует сначала починить медленный origin. Для GET и HEAD CloudFront повторяет запрос к origin (по умолчанию 3 попытки подключения), так что origin может увидеть один и тот же запрос несколько раз, прежде чем посетитель получит 504.

Чтобы понять, какой уровень отправил 504, посмотрите заголовки ответа в HTTP Header Checker: server: awselb/2.0 — балансировщик AWS, x-cache: Error from cloudfront — CloudFront, server: nginx — nginx. За Cloudflare каждый ответ содержит server: cloudflare, поэтому там подсказка — сам код (524 или 504).

Решение 7: решения для WordPress

Сайты на WordPress особенно подвержены ошибкам 504 из-за тяжёлых плагинов, раздутой базы данных и ограничений виртуального хостинга. Вот целевые решения.

• Определите медленные плагины — Деактивируйте все плагины, затем активируйте по одному. Если вы не можете зайти в wp-admin, переименуйте папку plugins через SSH: mv wp-content/plugins wp-content/plugins_disabled. Используйте плагин Query Monitor для выявления медленных запросов к базе данных.
• Установите плагин кэширования — WP Super Cache, W3 Total Cache или WP Rocket уменьшают серверную нагрузку, отдавая статический HTML вместо выполнения PHP при каждом запросе.
• Используйте объектное кэширование — Установите Redis или Memcached и плагин объектного кэша для WordPress. Это кэширует результаты запросов к базе данных в памяти, снижая нагрузку на MySQL.
• Очистите базу данных — Удалите старые ревизии записей, transient-данные, спам-комментарии и осиротевшие метаданные. Используйте WP-Optimize или WP-Sweep. Добавьте define('WP_POST_REVISIONS', 5); для ограничения будущих ревизий.
• Перенесите wp-cron на настоящий cron — посещения страниц запускают WP-Cron, который выполняет просроченные задачи в loopback-запросе, занимающем отдельный воркер PHP. Добавьте define('DISABLE_WP_CRON', true); в wp-config.php и пусть сервер запускает wp cron event run --due-now каждые 5 минут.

504 vs 502 vs 503 vs 408: в чём разница?

Эти коды ошибок HTTP часто путают. Вот что на самом деле означает каждый из них.

Главное различие: 502 означает, что прокси получил испорченный ответ либо соединение было отклонено или закрыто; 504 означает, что таймер прокси истёк, пока upstream молчал. 503 не требует прокси: любой сервер может отправить его при перегрузке. 408 — клиентский таймаут (класс 4xx), когда сервер устал ждать клиента.

Если вы видите 502 и 504 вместе, бэкенд, скорее всего, не справляется: запросы с таймаутом дают 504, а упавшие или убитые воркеры дают 502.

Если у вас 502, а не 504, наше руководство по 502 Bad Gateway разбирает сообщения из журнала ошибок nginx, которые его объясняют, включая реальный случай с этого сайта.

Влияет ли ошибка 504 на SEO?

Документация Google описывает, что делают ошибки 5xx (документация Google о сканировании):

• Сканирование замедляется для всего сайта пропорционально числу URL, возвращающих ошибки сервера.
• Проиндексированные страницы поначалу сохраняются, но URL, которые постоянно возвращают ошибку сервера, со временем удаляются.
• Сканирование постепенно восстанавливается, когда сервер снова отвечает кодом 2xx.

Как предотвратить ошибки 504 Gateway Timeout

Профилактика лучше аварийного реагирования. Эти практики помогут вашему серверу отвечать в пределах таймаутов.

• Настройте мониторинг — монитор доступности, который каждые несколько минут загружает ключевые страницы, ловит 504 раньше, чем о них сообщат пользователи.
• Согласуйте цепочку таймаутов — Убедитесь, что таймаут CDN ≥ таймаут прокси ≥ таймаут приложения. Несогласованные значения вызывают непредсказуемые ошибки 504.
• Настройте health check — Балансировщики нагрузки и прокси должны проверять состояние upstream-серверов и перенаправлять трафик от неотвечающих экземпляров.
• Активно используйте кэширование — Кэшируйте статические ресурсы, ответы API и результаты запросов к базе данных. Закэшированный ответ никогда не будет настолько медленным, чтобы вызвать 504.
• Автомасштабирование — Используйте горизонтальное масштабирование (больше экземпляров), чтобы всплески трафика не перегружали один сервер.
• Выносите тяжёлые задачи — Переместите обработку файлов, генерацию отчётов, отправку писем и массовый импорт в очереди фоновых задач. Никогда не выполняйте ресурсоёмкие операции внутри HTTP-запроса.
• Мониторьте медленные запросы — Включите журнал медленных запросов в MySQL/PostgreSQL. Настройте оповещения для запросов, превышающих 1 секунду.
• Следите за состоянием зависимостей — Мониторьте сторонние API, от которых зависит ваш бэкенд. Добавьте таймауты и circuit breaker, чтобы один медленный API не вызывал каскад ошибок 504 для всех пользователей.