Артём Савельев 
504 Gateway Timeout: что означает ошибка и как её чинить
504 — ошибка нетерпения: приложение ещё работает над ответом, а прокси уже устал ждать. У неё всегда два подозреваемых — слишком медленный бэкенд или слишком строгий таймаут — и лечится она с обеих сторон. Разбираем механику, конкретные цифры таймаутов по умолчанию и главный вопрос: ускорять запрос или увеличивать ожидание.
Механика: кто и сколько ждёт
Запрос идёт по цепочке браузер → CDN/балансировщик → веб-сервер → приложение, и у каждого звена есть лимит терпения. Ошибку 504 отдаёт то звено, чей лимит истёк первым. Ориентиры по умолчанию, от которых пляшет большинство конфигураций:
| Звено | Параметр | Типичное значение по умолчанию |
|---|---|---|
| nginx как прокси | proxy_read_timeout | 60 секунд |
| nginx → PHP | fastcgi_read_timeout | 60 секунд |
| Сам PHP | max_execution_time | 30 секунд |
| Cloudflare (прокси-режим) | ожидание ответа origin | ~100 секунд, дальше своя ошибка 524 |
Из таблицы видна типовая картина: обычный сайт получает 504 на запросах длиннее минуты. Если страница отвечает за 200–500 миллисекунд (норму времени ответа мы разбирали в статье о проверке доступности), запас у вас стократный — и появление 504 означает, что какой-то запрос стал в сотни раз медленнее обычного. Это всегда симптом, а не случайность.
Если вы посетитель
Как и остальные 5xx, ошибка живёт на стороне сайта. Подождите минуту и обновите страницу — но с одной оговоркой: если 504 вылетела при оформлении заказа или оплате, не жмите «повторить» многократно. Долгий запрос мог успеть выполниться на сервере уже после того, как прокси отдал вам ошибку, — так появляются задвоенные заказы. Проверьте личный кабинет или почту, прежде чем отправлять форму заново.
Если вы владелец: найти медленный запрос
Главный вопрос диагностики — какой именно запрос не укладывается. Ответ почти всегда лежит в одном из четырёх мест. Первое — база данных: разросшаяся таблица без индекса превращает запрос, который годами занимал миллисекунды, в минутный; лечится анализом медленных запросов (slow query log) и индексами. Второе — внешние вызовы: приложение синхронно ждёт чужой API (платёжку, 1С, службу доставки), тот тормозит — и ваш сайт тормозит вместе с ним; лечится таймаутами на исходящие запросы и переводом интеграций в фон. Третье — тяжёлые операции в вебе: экспорт каталога, генерация отчёта, пересчёт цен, запущенные по HTTP-запросу; их место — в фоновых задачах, а не в запросе браузера. Четвёртое — общая деградация сервера: диск, соседи по хостингу, нехватка памяти — тогда медленным становится всё сразу.
Найти виновника помогает одна настройка, которую стоит включить заранее: добавьте в лог-формат nginx время ответа бэкенда — и лог начнёт сам называть медленные запросы поимённо:
# в log_format добавить: $request_time $upstream_response_time
# топ-10 самых медленных запросов за сегодня:
awk '{print $(NF-1), $7}' /var/log/nginx/access.log | sort -rn | head -10
Дальше правило согласованности таймаутов по всей цепочке: каждый внешний лимит должен быть больше внутреннего. Если PHP разрешено работать 30 секунд, а nginx ждёт 60 — ошибку отдаст PHP, и в логе будет внятная причина. Если наоборот (PHP 300, nginx 60) — nginx оборвёт ожидание первым, вы получите безликий 504, а запрос продолжит молотить сервер вхолостую. Выстройте лесенку: приложение — самый короткий лимит, прокси — длиннее, CDN — ещё длиннее, и каждый обрыв будет происходить на том слое, который умеет объяснить причину.
Поднять proxy_read_timeout до 300 секунд просто, и 504 исчезнет. Но пятиминутные запросы никуда не денутся: они будут занимать воркеры, копить очередь и в час пик уронят сайт уже целиком — только теперь без внятного кода ошибки. Правильный порядок: сначала понять, почему запрос долгий, и лишь для законно долгих операций (большие выгрузки по API) — точечно поднимать лимит на конкретный путь.
Законно долгие операции: как их делать без 504
Бывают запросы, которые честно не могут быть быстрыми: генерация большого отчёта, выгрузка каталога, массовая рассылка, конвертация видео. Держать их в HTTP-запросе — заведомо проигрышная стратегия: даже подняв все таймауты, вы оставляете посетителя смотреть на крутящийся индикатор и молиться, что соединение не оборвётся. Взрослый паттерн — «принял и отпустил»: запрос мгновенно ставит задачу в очередь и возвращает ответ «принято», тяжёлая работа выполняется в фоне, а результат забирается опросом статуса, приходит на почту или вебхуком. Для интеграций по API тот же принцип — пагинация вместо «отдать всё одним запросом». После такого рефакторинга долгих запросов в системе не остаётся вовсе — и любой 504 снова становится тем, чем должен быть: сигналом настоящей аномалии, а не «нормальным поведением отчёта по понедельникам».
504 — ошибка с предысторией
У 504 есть ценное свойство, которого нет у внезапных ошибок: она почти никогда не приходит первой. Сначала время ответа страницы растёт неделями — 300 мс, 800 мс, полторы секунды, три, — и только упершись в таймаут, превращается в ошибку. Кто смотрит на график времени ответа, видит проблему за недели до первого 504 и чинит её в спокойном режиме. Кто не смотрит — знакомится с ней в пятницу вечером. В этом смысле 504 — самая предотвратимая ошибка пятисотой серии: достаточно следить не только за фактом «отвечает/не отвечает», но и за трендом скорости ответа.
Пруфен в каждой HTTP-проверке измеряет время ответа из 13 точек и хранит историю — восходящий тренд виден на графике задолго до первых 504. В настройках проверки задаётся и собственный таймаут: можно считать инцидентом не только ошибку, но и ответ дольше порога, который вы сами считаете допустимым.
Частые вопросы
Чем 504 отличается от 502? При 502 бэкенд ответил некорректно или отказал сразу — он «сломан». При 504 бэкенд работает, но слишком медленно — он «тормозит». Диагностика разная: для 502 смотрят, жив ли процесс, для 504 — что именно долго выполняется.
Почему 504 возникает только на одной странице? Потому что тяжёлый запрос — именно на ней: фильтр по огромному каталогу, отчёт, поиск без индекса. Это удобно для диагностики: сравните, что эта страница делает такого, чего не делают остальные.
Может ли 504 быть виной хостинга? Да: перегруженный сосед на shared-тарифе, деградация диска, проблемы с базой на стороне провайдера. Аргументом в разговоре с поддержкой будет история времени ответа: если сайт без изменений в коде стал в разы медленнее — вопрос к площадке.
Что за ошибка 524 у Cloudflare? Тот же таймаут, только словами Cloudflare: он ждёт ответа вашего сервера около 100 секунд и, не дождавшись, отдаёт собственный код 524. Лечится так же, как 504: ищите медленный запрос на origin-сервере.