504 Gateway Timeout

4 мин чтения
Обновлено 28 апреля 2026

Код 504 Gateway Timeout означает, что шлюз — nginx, Apache или CDN, стоящий перед вашим приложением, — не дождался ответа от сервера, которому передал запрос. Сам шлюз работает исправно: он принял запрос, передал его дальше и отсчитал таймаут впустую. Для владельца сайта это почти всегда сигнал о медленном коде или базе данных, а не о полном отказе сервера.

Что означает код 504

504 — серверная ошибка из группы 5xx, описанная в стандарте RFC 9110. Возвращает её не само приложение, а промежуточный узел: обратный прокси, балансировщик нагрузки или CDN. Поэтому страница с ошибкой 504 обычно выглядит как стандартная заглушка nginx или CDN, а не как страница вашего сайта.

Главное отличие от смежного кода 502 Bad Gateway: при 502 шлюз не смог соединиться с приложением или получил от него некорректный ответ. При 504 соединение установлено, но ответ не пришёл в отведённое время. От 503 Service Unavailable код отличается источником: 503 сервер отдаёт сам, когда перегружен или закрыт на обслуживание, а 504 всегда сообщает посредник. Cloudflare в той же ситуации использует собственный код 524 — таймаут ожидания origin. Место 504 среди остальных кодов — в полном списке кодов ответа HTTP.

Считает ли Tracker.ru 504 падением

Да. Успешной Tracker.ru считает только проверку с кодом 2xx. Ответ 504 помечает сайт недоступным, тип ошибки — «HTTP-ошибка», и вы получаете уведомление на email, в Telegram или по webhook. Важно не путать 504 с ошибкой таймаута в мониторинге: таймаут означает, что сервер вообще не ответил за отведённое время, а 504 — это полноценный HTTP-ответ от живого шлюза. Проверки идут из нескольких регионов, поэтому случайный всплеск нагрузки легко отличить от стабильной проблемы. Периоды недоступности отражаются в статистике аптайма.

Типичные причины

  • Долгие SQL-запросы. Тяжёлый отчёт или запрос без индекса выполняется дольше, чем таймаут прокси — например, значение proxy_read_timeout в nginx по умолчанию составляет 60 секунд.
  • Медленный внешний сервис. Приложение синхронно ждёт ответа платёжного шлюза, CRM или стороннего API и само не успевает ответить прокси.
  • Слишком короткие таймауты на прокси. proxy_read_timeout в nginx или ProxyTimeout в Apache выставлены меньше реального времени генерации страницы.
  • Перегруженный backend. Все обработчики приложения заняты, новый запрос стоит в очереди дольше таймаута — типичная картина при наплыве трафика.
  • Тяжёлые фоновые задачи. Бэкап, переиндексация или деплой в час пик съедают ресурсы сервера, и обычные страницы начинают отвечать медленно.
  • Сеть между прокси и приложением. Если шлюз и backend стоят на разных серверах, потери пакетов или файрвол между ними дают тот же эффект.

Что проверить владельцу сайта

  1. Откройте онлайн-проверку кода ответа своего сайта — она покажет актуальный ответ сервера без кэша браузера и без регистрации.
  2. Загляните в лог ошибок прокси: в nginx ошибка 504 сопровождается записью «upstream timed out» с адресом backend и конкретным URL.
  3. Проверьте журнал медленных запросов базы данных за время ошибки — долгий запрос чаще всего и есть виновник.
  4. Просмотрите внешние интеграции: вызовы сторонних API стоит выполнять в фоне или ограничивать собственным коротким таймаутом.
  5. Сверьте цепочку таймаутов: лимит на прокси, лимит выполнения скрипта в приложении и таймаут CDN не должны противоречить друг другу.
  6. Посмотрите графики нагрузки у хостинга: если 504 совпадает с пиками CPU или диска, серверу не хватает ресурсов.

Как часто встречается 504 на практике

Код 504 встретился в проверках Tracker.ru 71 раз на десять с лишним миллионов — чаще большинства редких кодов, но несравнимо реже, чем 502 или 503 (по данным на июль 2026). Причина в том, что для 504 перед приложением должен работать исправный прокси. Когда сервер тормозит целиком, проверка чаще фиксирует ошибку таймаута без HTTP-кода вовсе.

Частые вопросы

Чем 504 отличается от 502 Bad Gateway?

При ошибке 502 Bad Gateway шлюз не смог связаться с приложением: процесс упал, порт закрыт, ответ некорректен. При 504 связь есть, но приложение не ответило в отведённое время. Упрощённо: 502 — «backend сломан», 504 — «backend слишком медленный».

Поможет ли просто увеличить таймауты?

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

Почему мониторинг показывает 504, а у меня сайт открывается?

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

См. также