Сбои и доступность
504 Gateway Timeout: что делать с зависшим запросом
Сайт долго ждёт, затем показывает 504 Gateway Timeout. Разберём, где заканчивается ожидание и почему повторять операцию сразу бывает неправильно.
Что происходит и с чего начать
504 означает, что один узел цепочки не дождался ответа другого вовремя. Это может произойти при работе приложения, базы или внешнего сервиса. Истечение ожидания не обязательно остановило саму операцию: на сервере она иногда продолжает выполняться. Поэтому при ошибке после оформления или оплаты сначала проверяют результат, а не предлагают человеку нажать ещё раз. Для диагностики нужно знать точный запрос, время ожидания и то, какой промежуточный узел вернул ошибку посетителю.
Что можно проверить самостоятельно
- Запишите действие и приблизительное время до ошибки. Сравните, возникает ли она на обычной странице, при большом отчёте или только на оформлении определённого заказа.
- Проверьте, появился ли результат после ошибки: заказ, платёж, запись или файл. Не запускайте повторные изменения, пока не выяснено состояние первой попытки.
- Уточните, совпадает ли отказ с нагрузкой, обменом или недоступностью партнёрского сервиса. Сохраните несколько временных отметок, если проблема возникает периодически, а не постоянно.
Как понять результаты проверки
Увеличение времени ожидания допустимо только после понимания стоимости операции и ограничений всей цепочки. Долгую подготовку отчёта часто разумнее выполнять в фоне, сообщая пользователю состояние. Для обычной покупки ищут причину задержки и задают понятное поведение при отказе зависимости. Разработчик должен различать «операция не выполнена» и «ответ не получен». Без этого интерфейс может повторить уже совершённое действие и создать дубли, хотя первоначальная проблема была лишь в недоставленном ответе.
Что проверяет разработчик
Для этой части понадобятся доступ к настройкам, журналам ошибок или коду. Её можно передать специалисту вместе с результатами предыдущих шагов.
- Найдите тайм-аут в журнале прокси и сопоставьте с журналом приложения. Определите, ожидалось подключение или уже начатый ответ.
- Проверьте заказ по идентификатору и времени. Обработка могла продолжиться после того, как браузер увидел ошибку.
- Измерьте длительность SQL, блокировок и внешних API-вызовов внутри запроса. Особенно важны последовательные запросы доставки и оплаты.
На что обратить внимание
Увеличенный тайм-аут может скрыть медленную зависимость, но процессы продолжат занимать ресурсы. Повторный клик пользователя при неопределённом результате способен создать дубль.
Как исправляют причину
Сократите синхронную работу, ограничьте ожидание внешних сервисов и обеспечьте безопасный повтор операции. Долгие задачи переносите в фон только с понятным статусом и надёжным сохранением запроса.
Как убедиться, что проблема решена
Смоделируйте задержку зависимости на тестовом окружении. Пользователь должен получить определённый результат или возможность проверить состояние, а заказ — сохраниться не более одного раза.
Проверьте быстрый обычный сценарий и тот объём данных, на котором возникал отказ. Если работа перенесена в фон, должен быть понятен прогресс и доступен результат после завершения. Для операций записи проверьте повтор и восстановление после разрыва соединения. Принимать стоит предсказуемое выполнение без дублей, а не просто исчезновение 504 за счёт очень долгого ожидания посетителя.