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

Если вы посетитель: дело не в вашем компьютере, не в браузере и не в соединении. Любой код ошибки, начинающийся с 5, - это сама площадка сообщает о своей проблеме. Очистка кэша не поможет, и другой браузер тоже.

Картина из двух серверов

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

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

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

504 против 502, которые постоянно путают

Они приходят из одного места и означают разное, и понимание того, какой из них у вас, заметно сужает круг причин.

502 Bad Gateway
Сервер выше по цепочке ответил, и ответ оказался непригодным - отказ в соединении, упавший процесс, мусор в канале. Обычно быстро
504 Gateway Timeout
Сервер выше по цепочке не ответил вовсе за отведённое время. Обычно долго, и сама задержка перед ошибкой - уже подсказка

Грубо говоря: 502 - это «он сказал что-то не то», 504 - это «он пока ничего не сказал». 502 указывает на то, что что-то сломано или выключено; 504 - на то, что что-то работает медленно, застряло или перегружено.

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

Если вы посетитель

Сделать можно очень немного, и это честный ответ, а не просто короткий.

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

Единственное по-настоящему полезное, что вы можете сделать, - сообщить им, с деталями, достаточными, чтобы они нашли этот случай. Какая страница, в какое время и что вы делали. 504 при оформлении заказа в 14:32 - это то, что инженер может найти в логе; «у вас сайт не работает» - нет.

Если это ваш сайт

Четыре причины покрывают большинство случаев, примерно в таком порядке.

  • Что-то одно медленное. Запрос к базе без индекса, внешний API, который вы вызываете, пока пользователь ждёт, отчёт, разросшийся сверх того размера, на который его рассчитывали. Запрос не завис, он просто медленнее, чем терпение прокси.
  • Таймаут, выставленный ниже реальности. У nginx по умолчанию шестьдесят секунд на чтение от проксируемого сервера. Если ваш самый медленный законный запрос занимает девяносто, вы будете отдавать 504 тем, кто пользуется самой важной функцией.
  • Исчерпанные воркеры. Все процессы приложения заняты, поэтому новые запросы выстраиваются в очередь за ними и до кода вообще не доходят. Это приходит всплесками и выглядит как полный отказ сайта, потому что по сути им и является.
  • Сетевой путь. Группа безопасности, изменение DNS, переехавший сервис. Встречается реже и обычно проявляется целиком, а не время от времени.

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

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

Session Replay

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

Установить расширение

Почему потом их так трудно догнать

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

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

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

Одним абзацем

504 означает, что сервер впереди спросил сервер позади и потерял терпение. Это проблема сайта, а не ваша, обычно она означает «медленно», а не «сломано», и от 502 её отличает пауза перед ней. Если это ваш сайт, выясните, какой слой упёрся в таймаут, прежде чем трогать любую настройку таймаута, потому что журнал, не записавший ничего, и журнал, записавший девяносто секунд, рассказывают вам две разные истории.