Ошибка 504: что это, почему возникает и как ее исправить

Ошибка 504 Gateway Timeout (от англ. «тайм-аут шлюза») — код состояния HTTP, указывающий на отсутствие своевременного ответа от вышестоящего сервера при попытке загрузить страницу. Технически это означает сбой на сервере, когда машина выступает шлюзом или прокси-сервером.

Как выглядит ошибка 504

В зависимости от конфигурации серверного ПО ошибка 504 имеет различные формы вывода на экран:

• 504 Error.
• «Время ответа сервера истекло».
• HTTP Error 504.
• «Ошибка таймаута шлюза».
• Gateway timeout.
• The server didn't respond in time.

Точный текст зависит от используемого программного обеспечения в качестве фронтенда и бэкенда. Наиболее распространенные сценарии в production-среде — связки Nginx и Apache.

А на вашем сайте техничка в порядке?

• Подарим чек-лист по внутренней оптимизации
• Проконсультируем по SEO-вопросам

Получить чек-лист

Читайте также:

Ошибка сервера 500 на сайте: что означает и как устранить

Почему возникает ошибка 504

Основная причина — перегрузка сервера или исчерпание лимитов времени на выполнение операций. Источник сбоя часто кроется во внутренних процессах сайта, неоптимизированном коде или проблемах сетевой инфраструктуры.

Ошибки от плагинов и скриптов

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

Аномальное увеличение посещаемости

Резкий рост трафика замедляет работу сервера. Увеличение количества запросов приводит к накоплению очереди. Со временем число необработанных соединений превышает допустимые лимиты, взаимодействие с бэкендом прерывается, и веб-сервер возвращает код 504 Bad Gateway.

Израсходование лимитов тарифного плана хостинга

Начальные тарифы виртуального хостинга не рассчитаны на высоконагруженные проекты. Необходимо регулярно проверять панель управления на предмет превышения статической нагрузки, лимитов оперативной памяти (RAM), процессорного времени (CPU) и дисковой квоты.

Тяжелые операции в административной панели

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

5 классных SEO-кейсов

Круче, чем Гудини: как мы вырастили трафик в 2,2 раза

Все вы прекрасно знаете Гарри Гудини: этот фокусник мог выбраться из закрытой бочки, брошенной в воду. Примерно в таких же рамках оказались и мы, начиная работу с сайтом Eurorepar. Узкий функционал, жесткие требования. Но мы справились без магии, увеличив трафик х2!

Читать кейс

Читать кейс

Как выжать максимум из двадцатилетнего сайта

Можно ли выжать максимум из 20-летнего сайта и докрутить его до современных стандартов? А если есть отягчающие обстоятельства — накрутка поведенческих факторов, антиботы, да еще и админка капризничает и сама удаляет категории?

Читать кейс

Читать кейс

Долгая дорога в SEO и мощный прорыв

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

Читать кейс

Читать кейс

Qugo: вырастили трафик из блога платформы b2b в 9,7 раз!

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

Читать кейс

Читать кейс

Эффективное ссылочное продвижение для федеральной аптечной сети

Федеральная аптечная сеть пришла в Kokoc Performance (входит в Kokoc Group) за ссылочным продвижением. Интересно, что в компании есть своя in-house команда по SEO, которая подготовила ссылочную стратегию, а за ее реализацией обратилась к нам.

Читать кейс

Читать кейс

1/5

Хакерские атаки и вредоносный код

Распределенные атаки типа «отказ в обслуживании» (DDoS) целенаправленно исчерпывают ресурсы сервера, вызывая массовые ошибки 5xx. Наличие уязвимостей, шеллов или бэкдоров приводит к заражению файлов. Вредоносный код генерирует скрытые запросы, перегружая систему и провоцируя непредсказуемое поведение ресурса.

Читайте также:

Что такое robots.txt как его создать и правильно настроить

Перегрузка или блокировки в базе данных

Медленные SQL-запросы и транзакционные блокировки таблиц — критичная серверная причина 504 ошибки. Пока СУБД (MySQL, PostgreSQL) обрабатывает тяжелый запрос или ожидает снятия блокировки, веб-сервер держит соединение открытым. При превышении установленного лимита времени возвращается статус 504.

Долгие ответы внешних API и веб-хуков

При отправке запроса к стороннему сервису (платежный шлюз, CRM, служба доставки) основной сервер ожидает ответа в синхронном режиме. Каждый долгий запрос занимает слот обработки. При недоступности внешнего API накапливаются заблокированные потоки, новые запросы встают в очередь и массово отваливаются по таймауту.

Сбои на стороне CDN или WAF

Сети доставки контента (CDN) и межсетевые экраны (WAF) функционируют как промежуточный слой. Если защитный экран временно ограничивает пропускную способность или блокирует подозрительные пакеты, origin-сервер получает запросы с критической задержкой, что приводит к обрыву связи.

Как исправить ошибку 504 вебмастеру

Устранение проблемы на стороне сервера требует последовательного анализа логов и корректировки конфигурационных файлов.

Шаг 1. Быстрая диагностика по логам и окружению (5–7 минут)

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

• Проверьте логи веб-сервера на тайм-ауты апстрима.

  NGINX:   /var/log/nginx/error.log   (ищите upstream timed out)
  APACHE:  /var/log/apache2/error.log (ищите upstream timed out / AHxxx)

• Если используется PHP-FPM, включите slowlog (параметр request_slowlog_timeout) для выявления зависающих скриптов.
• Проверьте «медленные» SQL-запросы (Slow Query Log) и наличие deadlocks в базе данных.
• Исключите влияние внешних API: временно отключите проблемный вызов. Для тестирования таймаутов используйте консольную утилиту curl с параметрами --connect-timeout (ограничение на установку соединения) и --max-time (максимальное время выполнения всей операции).
• Проверьте CDN/Firewall: временно выключите проксирование (переведите в Development Mode), очистите кэш и протестируйте прямой доступ к origin-серверу.
• Зафиксируйте точное время и URL ошибки — сверяйте данные по логам для подтверждения причины.

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

Управление конфигурацией VPS с Nginx / Apache

На выделенных серверах (VPS/VDS) корректировка лимитов выполняется через конфигурационные файлы.

1. В дистрибутиве Apache найдите файл httpd.conf. Установите значение тайм-аута на разумную величину (120–300 секунд). Примените изменения командой systemctl reload apache2 (или service apache2 reload).
2. В конфигурации PHP найдите файл php.ini. Измените параметр max_execution_time на 300 секунд. При использовании PHP-FPM выполните перезагрузку командой systemctl reload php8.2-fpm (указав актуальную версию сервиса).

Ключевое отличие команды reload от restart заключается в безопасном применении настроек: конфигурация обновляется без остановки процесса и принудительного разрыва активных пользовательских соединений.

Читайте также:

Ошибка Forbidden 403: что это значит и как устранить

Изменение портов в панели управления хостингом

Смена порта не влияет на скорость выполнения скриптов; используйте эту меру только при конфликте, сетевой блокировке или специфических требованиях панели управления.

Данный метод применяется, когда выполнение тяжелого скрипта занимает более 30 секунд, и стандартные лимиты обойти невозможно. Смена порта (например, на 8080 в Plesk или 8081 в ISPManager) позволяет направить запрос в обход жестких ограничений фронтенд-прокси, но не решает проблему производительности самого кода.

Отключение CDN для диагностики

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

Эффективное SEO

• Гарантия результатов
• Комплексное развитие
• При любом тарифе отслеживаем динамику заявок и звонков с сайтов
• Регулярный пересмотр семантического ядра

Узнать больше

Включение журналирования ошибок в CMS

Детальные логи позволяют точно определить строку кода или SQL-запрос, вызывающий сбой. В CMS WordPress необходимо отредактировать конфигурационный файл wp-config.php, добавив константы в верхнем регистре:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Логи пишутся в файл wp-content/debug.log; сверяйте метку времени с моментом появления 504 ошибки для точной идентификации проблемного процесса. Параметр WP_DEBUG_DISPLAY отключает вывод системных уведомлений на фронтенде, сохраняя безопасность данных.

Настройка директив веб-сервера Nginx

В конфигурационном файле Nginx (обычно nginx.conf или конфиг конкретного виртуального хоста) корректируются следующие параметры:

# Для проксирования к приложению/бекенду
proxy_connect_timeout 60s;
proxy_send_timeout    60s;
proxy_read_timeout    120s;
send_timeout          60s;

# Для PHP-FPM
fastcgi_read_timeout  120s;

Повышайте тайм-ауты постепенно и параллельно оптимизируйте код/запросы. Для специфических ресурсоемких задач (генерация тяжелых отчетов) допускается установка сбалансированных стартовых значений proxy_read_timeout до 600 секунд, но это требует обязательной синхронизации с max_execution_time в PHP.

Влияние ошибок 5xx на SEO и индексацию

Статус 504 — это не просто технический сбой, а прямая угроза коммерческим показателям проекта. Систематические ошибки 5xx оказывают разрушительное воздействие на видимость сайта в поисковых системах.

• Краткосрочные сбои. Поисковые боты оперативно реагируют на недоступность ресурса, снижая частоту краулинга (обхода страниц). Позиции не падают мгновенно, но краулинговый бюджет расходуется впустую.
• Длительные сбои (более 24 часов). Существует высокий риск деиндексации отдельных URL. Страницы выпадают из поиска, что ведет к прямой потере органического трафика.
• Поведение пользователей. Установка экстремально высоких таймаутов (более 700 секунд) маскирует проблему, но критически увеличивает показатель TTFB (Time to First Byte). Согласно аналитике DrMax, высокий TTFB генерирует сигнал badClick в алгоритме NavBoost (пользователь не дожидается загрузки и возвращается в выдачу). Каждая дополнительная секунда задержки снижает конверсию на 4,42%.

Подробнее алгоритмы обработки сбоев описаны в официальной документации Google Search Central по HTTP-статусам (5xx).

Как исправить ошибку 504 пользователю

Если проблема возникает на стороне клиента, первым шагом выполняется жесткая перезагрузка страницы с полным сбросом кэша браузера. Комбинации клавиш зависят от операционной системы:

Очистка DNS и сетевые настройки

Устаревшие записи в локальном кэше DNS препятствуют корректному разрешению доменного имени.

• На macOS откройте «Терминал» и выполните команду: sudo killall -HUP mDNSResponder.
• На Windows запустите командную строку от имени администратора и введите: ipconfig /flushdns.

Дополнительные шаги диагностики

Для исключения локальных сетевых проблем выполните следующие действия:

1. Временно отключите VPN/прокси и повторите попытку (или, наоборот, активируйте для обхода ограничений магистрального провайдера).
2. Поменяйте системные DNS-серверы на публичные (например, 8.8.8.8 от Google или 1.1.1.1 от Cloudflare).
3. Проверьте доступность ресурса через специализированные сервисы мониторинга сбоев: UptimeRobot, Pingdom, DNSChecker, MXToolbox или DownDetector. Это позволит достоверно определить, носит ли проблема глобальный характер.

Профилактика появления Gateway Timeout

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

Коротко о главном

Ошибка 504 Gateway Timeout сигнализирует о том, что сервер не дождался ответа от вышестоящего узла. Эффективное устранение сбоя требует системного подхода к диагностике и понимания архитектуры веб-приложения.

• Код 504 означает тайм-аут ответа от upstream: бэкенда, базы данных, внешнего API или CDN/WAF.
• Диагностика начинается с логов: в Nginx и Apache необходимо искать строки upstream timed out, а в PHP-FPM анализировать slowlog.
• Частые серверные причины включают медленные SQL-запросы, транзакционные блокировки в БД, зависшие скрипты и синхронные долгие ответы внешних сервисов.
• Повышение тайм-аутов (proxy_read_timeout, fastcgi_read_timeout) применяется исключительно как временная мера; необходимо сразу устранять корневую причину задержки.
• Для CMS WordPress отладка включается через константы WP_DEBUG и WP_DEBUG_LOG в файле wp-config.php, логи сохраняются в wp-content/debug.log.
• Пользователям рекомендуется выполнить принудительную перезагрузку страницы, очистить DNS-кэш, проверить настройки VPN и протестировать доступность сайта через сервисы мониторинга (UptimeRobot, Pingdom).
• Систематические ошибки 5xx критически снижают частоту краулинга, увеличивают TTFB, провоцируют badClick в NavBoost и при сбое более 24 часов грозят полной деиндексацией страниц.