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

Ошибка 504 Gateway Timeout — одна из самых неприятных серверных ошибок. Пользователь нажимает на кнопку, полминуты смотрит на крутящийся индикатор загрузки и в итоге видит белую страницу с надписью «504 Gateway Time-out». Заказ не оформлен, отчёт не построен, а владелец сайта часто узнаёт о проблеме последним.

Коротко: ошибка 504 означает, что сервер-посредник (nginx, балансировщик или CDN) не дождался ответа от сервера приложения за отведённое время. Сам сайт при этом может работать — он просто отвечает слишком долго. Ниже разберём, откуда берётся 504, почему её отдаёт часто «не тот» сервер, как найти причину в логах и как узнавать о таких сбоях раньше пользователей.

Что означает ошибка 504 Gateway Timeout

Код 504 относится к группе 5xx — ошибок на стороне сервера. Спецификация HTTP описывает его так: сервер, работающий как шлюз или прокси, не получил вовремя ответ от вышестоящего сервера, к которому обратился, чтобы выполнить запрос.

В современной инфраструктуре запрос почти никогда не попадает в приложение напрямую. По пути он проходит через несколько посредников: CDN, балансировщик нагрузки, nginx и только потом попадает к PHP-FPM, Python или Node.js. Каждый посредник ждёт ответа не бесконечно, а в пределах своего таймаута. Если ответа нет — посредник прекращает ждать и возвращает пользователю 504.

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

Текст зависит от того, какой сервер вернул ошибку:

• 504 Gateway Time-out — стандартная страница nginx (именно так, через дефис);
• 504 Gateway Timeout — балансировщики, Apache, облачные платформы;
• HTTP Error 504, Gateway Timeout Error — варианты в браузерах и CMS;
• Error 524: A timeout occurred — так выглядит «504 от Cloudflare»;
• в мобильных приложениях и API — просто код 504 и, возможно, пустое тело ответа.

Подсказка: по виду страницы ошибки и заголовку Server в ответе можно понять, какой именно слой не дождался ответа. Это первый шаг диагностики — к нему мы вернёмся ниже.

Чем 504 отличается от 502, 503 и других ошибок

Ошибки 5xx часто путают, хотя они указывают на совершенно разные проблемы.

Главное отличие 502 от 504 — во времени и в характере ответа. При 502 бэкенд ответил «плохо» или отказал в соединении, при 504 — не ответил вовсе. Ошибку 502 мы подробно разбирали в статье «Ошибка 502 Bad Gateway: что означает и как исправить».

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

Цепочка таймаутов: почему 504 отдаёт не тот сервер, который тормозит

Это самая важная часть статьи. Посмотрим, как путешествует запрос в типичном проекте:

Браузер → CDN → балансировщик → nginx → PHP-FPM / Gunicorn / Node.js → база данных

У каждого посредника свой таймаут ожидания ответа, и обычно их никто не согласовывает:

• Cloudflare ждёт 100 секунд и возвращает 524;
• Yandex Application Load Balancer и AWS ALB по умолчанию ждут 60 секунд;
• nginx (proxy_read_timeout, fastcgi_read_timeout) — тоже 60 секунд;
• Gunicorn убивает зависший воркер через 30 секунд, а у PHP-FPM ограничения по умолчанию нет вовсе.

Отсюда правило: ошибку 504 возвращает тот слой, у которого самый короткий таймаут, а не тот, который тормозит. Тормозит обычно база данных или внешний API, но ни база, ни приложение об ошибке ничего не знают. Более того, после того как пользователь увидел 504, бэкенд продолжает обрабатывать запрос — а пользователь нажимает «Обновить» и запускает ту же тяжёлую операцию второй раз.

Есть и обратный эффект. Если первым сдаётся сервер приложения (например, Gunicorn с --timeout 30), он убивает воркер, nginx видит оборванное соединение и возвращает 502, а не 504. Поэтому «долгая» 502 — это та же проблема медленного запроса.

Хорошая конфигурация выглядит как лесенка: чем ближе слой к пользователю, тем дольше он готов ждать. Например: PHP-FPM — 60 секунд, nginx — 65, балансировщик — 70, Cloudflare — 100. Тогда первым сдаётся приложение — единственное, кто знает, что именно пошло не так, и может вернуть понятную ошибку вместо безликой 504.

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

Медленные запросы к базе данных

Самая частая причина. Запрос без индекса, полный перебор большой таблицы, блокировка строки, которую держит другая транзакция, — и обработка страницы занимает минуту вместо 200 миллисекунд. Особенно коварны запросы, которые работали быстро, пока в таблице было мало данных.

Долгие операции прямо в запросе

Генерация отчёта, выгрузка в Excel, импорт файла, массовая рассылка, пересчёт цен — всё это нельзя выполнять синхронно, пока пользователь ждёт ответа. На небольших объёмах укладывается в таймаут, а по мере роста данных начинает регулярно выдавать 504.

Медленные внешние сервисы

Платёжный шлюз, служба доставки, CRM, сервис проверки адресов. Если приложение ходит во внешний API без собственного таймаута, любая проблема на стороне партнёра превращается в 504 на вашем сайте.

Нехватка воркеров и соединений

У PHP-FPM есть ограничение pm.max_children, у Gunicorn — число воркеров, у приложения — пул соединений с базой. Когда все воркеры заняты, новые запросы встают в очередь и ждут. Если очередь двигается медленнее таймаута nginx, пользователи получают 504, хотя каждый отдельный запрос обрабатывается быстро. Типичный признак — ошибки только в часы пик.

Несогласованные таймауты

Разобранная выше ситуация: балансировщик ждёт меньше, чем nginx, nginx — меньше, чем приложение. В итоге увеличение таймаута в одном месте ничего не меняет, потому что раньше сдаётся другой слой.

Сетевые проблемы между прокси и бэкендом

Если файрвол молча отбрасывает пакеты (правило DROP), прокси не получает ни ответа, ни отказа и ждёт до истечения таймаута подключения — получается 504. Если соединение явно отклоняется (REJECT, закрытый порт), будет уже 502. Сюда же относятся устаревший IP в upstream после переезда сервера и проблемы с DNS внутри инфраструктуры.

Kubernetes: под не готов или перегружен

В кластере 504 часто возвращает Ingress-контроллер: поды сервиса перезапускаются, не проходят readiness-пробу или упираются в лимиты CPU и начинают отвечать медленно. Учтите, что в ingress-nginx по умолчанию proxy-connect-timeout равен всего 5 секундам, а proxy-read-timeout — 60. Если вы ещё используете ingress-nginx, помните, что проект больше не развивается, — переход на Gateway API хороший повод заодно пересмотреть таймауты.

CDN и Cloudflare: 504 или 524

Если сайт работает через Cloudflare, после 100 секунд ожидания пользователь увидит не 504, а ошибку 524. На тарифах Free, Pro и Business этот лимит не меняется — поднять его можно только на Enterprise. Если же Cloudflare показывает 504, скорее всего, её вернул ваш собственный nginx или балансировщик, а Cloudflare лишь передал ответ дальше. У других CDN и сервисов защиты от DDoS свои таймауты — их значения стоит уточнить в документации провайдера.

Что делать пользователю, если появилась ошибка 504

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

1. Подождите минуту и обновите страницу. Часто 504 — следствие кратковременного всплеска нагрузки.
2. Не отправляйте форму оплаты повторно. Запрос мог выполниться, несмотря на ошибку: сначала проверьте почту или личный кабинет, иначе рискуете оплатить дважды.
3. Проверьте сайт с другого устройства или через мобильный интернет. Если ошибка только у вас, виноват может быть корпоративный прокси или VPN.
4. Сообщите владельцу сайта. Укажите время, адрес страницы и что вы делали — это сильно ускорит поиск причины.

Как исправить ошибку 504 владельцу сайта

Шаг 1. Найдите слой, который вернул 504

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

Если время до ошибки совпадает с таймаутом одного из слоёв (30, 60, 100 секунд), вы нашли, кто сдался. Заголовок Server, наличие cf-ray и вид страницы ошибки подскажут, кто именно.

Шаг 2. Найдите медленный запрос

Добавьте в формат access-лога nginx переменную $upstream_response_time — она показывает, сколько отвечал бэкенд на каждый запрос:

log_format timing '$remote_addr [$time_local] "$request" $status '
                  'rt=$request_time urt=$upstream_response_time';
access_log /var/log/nginx/access.log timing;

Отсортировав лог по urt, вы увидите, какие адреса отвечают дольше всего. Дальше — профилирование: slowlog PHP-FPM, лог медленных запросов базы данных, EXPLAIN ANALYZE для подозрительных SQL-запросов, APM-инструменты.

Шаг 3. Проверьте воркеры и базу данных

• Сообщение server reached pm.max_children setting в логе PHP-FPM означает, что воркеров не хватает. Увеличивайте их число, только если хватает памяти, — иначе сервер начнёт уходить в swap и станет ещё медленнее.
• Посмотрите активные запросы и блокировки в базе: в PostgreSQL — pg_stat_activity, в MySQL — SHOW PROCESSLIST.
• Проверьте, что пул соединений приложения не меньше числа воркеров.

Шаг 4. Согласуйте таймауты

Выстройте таймауты лесенкой: приложение → nginx → балансировщик → CDN, каждый следующий на 5–10 секунд больше предыдущего. Пример для связки nginx и PHP-FPM:

location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_read_timeout 65s;
}

; /etc/php/8.3/fpm/pool.d/www.conf
request_terminate_timeout = 60s

Обратите внимание: max_execution_time в PHP на Linux учитывает только время выполнения самого скрипта, а ожидание базы данных и внешних API в него не входит. От зависшего запроса к базе защищает именно request_terminate_timeout.

Шаг 5. Уберите долгие операции из запроса

Поднять таймауты до пяти минут — самое простое и самое плохое решение: воркеры будут заняты дольше, и под нагрузкой 504 станет только больше. Правильный путь для операций дольше 30 секунд:

1. Приложение принимает запрос, ставит задачу в очередь (RabbitMQ, Redis, Celery, Sidekiq, Laravel Queue) и сразу отвечает «Отчёт готовится».
2. Фоновый воркер выполняет задачу без ограничений по таймауту HTTP.
3. Пользователь получает результат по ссылке, уведомлению или через периодический опрос статуса.

Внешним API задайте собственные таймауты — 5–10 секунд вместо бесконечного ожидания — и предусмотрите понятную ошибку, если партнёр не ответил.

Как Pingera помогает ловить ошибку 504 до пользователей

Ошибка 504 опасна тем, что часто появляется не на главной странице, а в личном кабинете, на оформлении заказа или в API. Пользователь уходит молча, а в логах она теряется среди тысяч успешных запросов. Поэтому о 504 важно узнавать от системы мониторинга, а не из жалоб клиентов.

Проверки доступности сайта и API

Мониторинг Pingera регулярно отправляет запросы к вашим страницам и API — раз в 3 минуты на бесплатном тарифе и от 30 секунд на платных. Проверка считается проваленной и при ответе с кодом 5xx, и если сервер не ответил за заданный таймаут: такой результат получает отдельный статус timeout. Для каждой проверки сохраняются время ответа, заголовки и начало тела ответа — по ним видно, какой именно слой вернул 504.

Так выглядит проваленная проверка в Pingera: статус «Сбой», код ответа 504 и заголовки ответа. Обратите внимание на время — 39 миллисекунд — и заголовок X-Powered-By: Express: ошибку быстро вернуло само Node.js-приложение, а не nginx или CDN, которые не дождались ответа. Значит, искать причину нужно в коде приложения или в сервисе, к которому оно обращается.

График времени ответа

Ошибке 504 почти всегда предшествует рост времени ответа: страница, которая открывалась за 300 миллисекунд, начинает отвечать за 5, потом за 20 секунд. На графике времени ответа в Pingera этот тренд виден заранее — до того, как запрос упрётся в таймаут.

Проверки из нескольких регионов

Pingera проверяет сайт из нескольких регионов одновременно. Это помогает отличить настоящий сбой от сетевой проблемы в одной локации. А автоматический повтор проверки отсекает ложные срабатывания от разовых всплесков.

Пошаговые и синтетические проверки

504 часто возникает не на открытии страницы, а на конкретном действии: поиске, оформлении заказа, построении отчёта. Пошаговые API-проверки повторяют цепочку запросов к API, а синтетические проверки на Playwright проходят сценарий в настоящем браузере — как пользователь.

Мониторинг фоновых задач

Если вы последовали совету и вынесли долгие операции в очередь, их тоже нужно контролировать: фоновая задача может зависнуть так же тихо, как HTTP-запрос. Пульсары Pingera сообщат, если задача не отчиталась вовремя.

Алерты и Статус Страница

Правила алертов позволяют реагировать на падение по таймауту, на несколько неудачных проверок подряд или на снижение аптайма. Уведомления приходят в Telegram, MAX, на почту, по SMS или в вебхук, а Статус Страница может обновиться автоматически — клиенты увидят, что вы уже знаете о проблеме и работаете над ней.

Проверить, как ваши алерты реагируют на 504, можно без поломки продакшна: Pingera держит публичные HTTP-инструменты для тестирования мониторинга. Адрес https://app.pingera.ru/tools/code/504 всегда отвечает кодом 504, а https://app.pingera.ru/tools/delay/40000 держит соединение 40 секунд — этого достаточно, чтобы проверка с таймаутом 30 секунд упала по таймауту.

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

• Согласуйте таймауты во всей цепочке — лесенкой от приложения к пользователю.
• Ограничьте время запроса в приложении и задайте таймауты всем обращениям к внешним API и базе данных.
• Выносите в фон всё, что может длиться дольше 30 секунд.
• Следите за медленными запросами: slowlog PHP-FPM, лог медленных запросов базы данных, $upstream_response_time в логах nginx.
• Планируйте ресурсы — число воркеров, размер пула соединений, лимиты подов — с запасом на пиковую нагрузку.
• Разнесите по времени тяжёлые фоновые задачи: бэкапы, импорты и пересчёты не должны совпадать с часами пик.
• Отдавайте 503 с заголовком Retry-After на время плановых работ, а не 504.
• Мониторьте ключевые страницы и API снаружи и настройте алерты до того, как случится следующий сбой.

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

Итог

Ошибка 504 Gateway Timeout означает, что один из посредников между пользователем и приложением не дождался ответа. Почти всегда за ней стоит медленный запрос, нехватка воркеров или несогласованные таймауты, а не «упавший» сервер. Найдите, какой слой сдался первым, отыщите медленный запрос по логам и выстройте таймауты лесенкой, а долгие операции перенесите в фон.

И главное — узнавайте о 504 раньше пользователей. Pingera проверит ваши страницы и API из нескольких регионов, покажет рост времени ответа до того, как он превратится в ошибку, и пришлёт алерт в первые минуты сбоя.