Ошибка 504 Gateway Timeout: вышестоящий сервер не ответил вовремя

Как и в случае 502, этот код выдаёт посредник: промежуточный сервер, балансировщик или сервис ускорения. Он передал запрос дальше, к приложению, и стал ждать. Отведённое время вышло, а ответа так и не последовало, поэтому посреднику пришлось вернуть вам 504.

Ваше соединение с посредником при этом работало нормально: вы получили ответ, пусть и об ошибке. Значит, проблема находится за первым звеном, а не в вашем интернете.

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

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

Ещё бывают слишком короткие таймауты в настройках промежуточного сервера: приложение работает штатно, но некоторые запросы занимают дольше отведённого срока.

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

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

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

Иногда помогает уменьшить объём запроса: если вы запрашиваете отчёт за очень длинный период или загружаете крупный файл, разбейте операцию на несколько частей. Меньшие запросы укладываются в отведённое время и не упираются в ограничения шлюза.

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

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

Увеличение таймаута промежуточного сервера может скрыть симптом, но не устраняет причину. Разумно поднимать лимит только для конкретных адресов с заведомо долгими операциями. Согласуйте значения по всей цепочке: таймаут CDN, балансировщика, веб-сервера и приложения должны идти по нарастающей, иначе верхнее звено сдастся раньше нижнего.

Проверьте также лимиты на стороне хостинга: некоторые провайдеры ограничивают время выполнения скриптов жёстче, чем ваш веб-сервер. Тогда ответ обрывается раньше, и пользователь видит ошибку шлюза, хотя ваши настройки допускают более долгое ожидание.

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

Если вы наблюдаете ошибку не на сайте, а в приложении или при обращении к интерфейсу другого сервиса, повторите запрос с паузой и не забывайте о возможных дублях: операция могла завершиться успешно, а вам вернули ошибку.