504 Gateway Timeout: Что Это Значит и Как Исправить

Что такое 504 Gateway Timeout?

504 Gateway Timeout — это код состояния HTTP, который означает, что сервер, выступающий в роли шлюза или прокси, не получил своевременный ответ от upstream-сервера. Прокси ждал ответа от upstream, но тот отвечал слишком долго, поэтому прокси прекратил ожидание и вернул ошибку 504 в ваш браузер.

Официальное определение содержится в RFC 9110 (HTTP Semantics), раздел 15.6.5: «Код состояния 504 (Gateway Timeout) указывает, что сервер, выступая в роли шлюза или прокси, не получил своевременного ответа от upstream-сервера, к которому ему необходимо было обратиться для выполнения запроса.»

Ключевое слово — шлюз. Ошибка 504 всегда подразумевает как минимум два сервера: тот, к которому вы подключились (прокси/шлюз), и тот, что стоит за ним (upstream/origin), который не ответил вовремя. Типичные прокси: Nginx reverse proxy, Cloudflare, AWS Application Load Balancer (ALB) и CloudFront.

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

Независимо от формулировки, основная причина всегда одна и та же: прокси-сервер ждал ответа от upstream-сервера, а upstream-сервер не ответил в пределах настроенного окна таймаута.

• 504 Gateway Timeout

• 504 Gateway Time-out (по умолчанию в Nginx — через дефис)

• HTTP Error 504 — Gateway Timeout

• This page isn't working — [domain] took too long to respond (Chrome / Edge)

• Gateway Timeout (Firefox)

• Error 504

• 504 Gateway Time-out — The server didn't respond in time (Apache с mod_proxy)

• Error 524: A timeout occurred (только Cloudflare — технически не 504, но та же причина)

• ERROR — The request could not be satisfied — 504 ERROR (AWS CloudFront)

Как возникает ошибка 504 Gateway Timeout

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

Вот типичная цепочка запроса: Браузер → CDN (Cloudflare) → Балансировщик нагрузки → Nginx → PHP-FPM → База данных. Если запрос к базе данных занимает 90 секунд, а proxy_read_timeout в Nginx установлен на 60 секунд, Nginx прекращает ожидание и возвращает 504 балансировщику нагрузки, который передаёт его обратно в ваш браузер.

Сервер, который возвращает 504, всегда является посредником (прокси или шлюзом), а не самим origin-сервером. Origin-сервер просто не ответил вовремя — возможно, он всё ещё обрабатывает запрос, а возможно, полностью завис.

Распространённые причины ошибки 504 Gateway Timeout

Понимание первопричины — кратчайший путь к решению. Вот наиболее частые причины, по которым сервер возвращает 504, в порядке убывания частоты.

• Медленный origin-сервер — PHP-скрипты, выполняющие сложные запросы к базе данных, генерирующие отчёты или обращающиеся к медленным сторонним API, могут превысить таймаут прокси. Это причина №1 ошибок 504.

• Перегрузка сервера — CPU загружен на 100%, нехватка оперативной памяти (OOM kills) или все воркеры PHP-FPM заняты. Origin-сервер работает, но слишком перегружен, чтобы ответить вовремя.

• Узкое место в базе данных — Медленные SQL-запросы, отсутствующие индексы, блокировки таблиц или исчерпанный пул соединений. Приложение зависает в ожидании базы данных, и прокси получает таймаут.

• Неправильная настройка таймаутов — proxy_read_timeout в Nginx установлен слишком низко для бэкенда, которому действительно нужно больше времени (например, генератор отчётов или обработчик загрузки файлов).

• Сетевые проблемы между прокси и origin — Потеря пакетов, высокая задержка или проблемы маршрутизации между дата-центрами. Часто встречается в мультирегиональных или гибридных облачных архитектурах.

• Файрвол или группа безопасности блокирует трафик — Группы безопасности AWS не пропускают трафик на эфемерных портах, правила iptables блокируют внутренние соединения, или WAF блокирует легитимные upstream-запросы.

• Сбой DNS-разрешения на прокси — Прокси не может разрешить имя хоста upstream. В Nginx это происходит при использовании переменных в proxy_pass без директивы resolver.

• Таймаут CDN — Cloudflare имеет жёсткий лимит в 100 секунд на тарифах Free/Pro/Business. Если вашему origin нужно больше 100 секунд, Cloudflare вернёт Error 524 независимо от настроек Nginx.

• DDoS-атака — Поток запросов исчерпывает ресурсы сервера, делая origin слишком медленным для ответа на легитимный трафик в пределах таймаута прокси.

Решение для посетителей: что можно сделать

Если вы видите ошибку 504 на чужом сайте, проблема на их сервере, а не на вашем устройстве. Тем не менее, есть несколько вещей, которые стоит попробовать.

• Подождите и обновите страницу — Большинство ошибок 504 временные. Подождите 30–60 секунд, затем принудительно обновите страницу: Ctrl+Shift+R (Windows/Linux) или Cmd+Shift+R (Mac).

• Проверьте, недоступен ли сайт для всех — Используйте инструмент HTTP Headers DNS Robot, чтобы проверить код ответа сервера с внешнего расположения. Если 504 возвращается для всех, проблема на стороне сервера.

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

• Попробуйте другую сеть — Переключитесь с Wi-Fi на мобильные данные или отключите VPN. Проблемы маршрутизации между вашим провайдером и сервером иногда могут вызывать 504.

• Очистите DNS-кэш — Устаревшие DNS-записи могут направлять запросы на неправильный сервер. В Windows: ipconfig /flushdns. В Mac: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder.

• Проверьте страницу статуса или социальные сети сайта — Возможно, на сайте опубликовано объявление об известном сбое или плановом обслуживании.

Решение 1: Увеличить настройки таймаутов (Nginx и Apache)

Самое распространённое решение для ошибок 504 — увеличение значений таймаута на вашем reverse proxy. Если вашему бэкенду действительно нужно больше 60 секунд (значение по умолчанию), прокси должен знать, что нужно ждать дольше.

# Nginx — reverse proxy to a backend (Node.js, Python, etc.)
location / {
    proxy_pass http://backend;
    proxy_connect_timeout 300;
    proxy_send_timeout    300;
    proxy_read_timeout    300;
    send_timeout          300;
}

# Nginx — FastCGI (PHP-FPM)
location ~ \.php$ {
    fastcgi_pass unix:/var/run/php-fpm.sock;
    fastcgi_read_timeout    300;
    fastcgi_send_timeout    300;
    fastcgi_connect_timeout 300;
    include fastcgi_params;
}

Для Apache с mod_proxy добавьте ProxyTimeout 300 в ваш VirtualHost или используйте ProxyPass / http://backend:8080/ timeout=300 для настройки конкретного бэкенда.

Важно: Эти таймауты измеряют время между двумя последовательными операциями чтения/записи, а не общее время передачи. Так что proxy_read_timeout 300 означает «если данные не поступают в течение 300 секунд», а не «весь ответ должен быть получен за 300 секунд». После изменения значений таймаутов перезагрузите конфигурацию: sudo nginx -t && sudo systemctl reload nginx.

Решение 2: Оптимизировать медленные скрипты и запросы к базе данных

Если ваш бэкенд постоянно превышает таймаут, увеличение значения таймаута лишь маскирует проблему. Настоящее решение — сделать так, чтобы бэкенд отвечал быстрее.

• Найдите медленные запросы — Включите журнал медленных запросов MySQL (slow_query_log = 1, long_query_time = 1) или используйте EXPLAIN ANALYZE для подозрительных запросов. Добавьте недостающие индексы, избегайте SELECT * и используйте пагинацию для больших наборов результатов.

• Добавьте кэширование — Используйте Redis или Memcached для кэширования результатов тяжёлых запросов. Запрос, который выполняется 5 секунд при каждой загрузке страницы, должен быть закэширован.

• Перенесите тяжёлые задачи в фоновые процессы — Генерация отчётов, отправка писем, обработка изображений и импорт данных должны выполняться в очереди задач (Celery, Sidekiq, Bull), а не в цикле HTTP-запроса.

• Оптимизируйте вызовы API — Если ваш бэкенд обращается к медленным сторонним API, добавьте таймауты для этих вызовов и реализуйте circuit breaker, чтобы один медленный API не блокировал все запросы.

• Устраните проблему N+1 запросов — Запросы, генерируемые ORM, часто делают сотни отдельных обращений к базе данных. Используйте eager loading или пакетные запросы для сокращения количества обращений.

Решение 3: Проверить ресурсы сервера (CPU, RAM, диск)

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

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space (full disk = silent failures)
df -h

# Check memory details
free -m

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Check active network connections
ss -s

Если CPU или RAM загружены на 90%+, необходимо либо оптимизировать приложение, остановить «убежавшие» процессы, либо обновить сервер. Если диск заполнен, удалите старые лог-файлы, резервные копии или временные файлы — заполненный диск может привести к тихому падению базы данных и каскадным ошибкам 504.

Решение 4: Проверить журналы ошибок

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

# Nginx error log (look for "upstream timed out")
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log       # Debian/Ubuntu
tail -50 /var/log/httpd/error_log          # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.2-fpm.log

# System log (OOM kills, crashes)
tail -50 /var/log/syslog

Типичные сообщения в логах, вызывающие 504:

"upstream timed out (110: Connection timed out)" (Nginx) — Upstream-сервер не ответил в пределах proxy_read_timeout. Увеличьте таймаут или исправьте медленный upstream.

"server reached pm.max_children" (PHP-FPM) — Все рабочие процессы PHP заняты. Увеличьте pm.max_children в конфигурации пула PHP-FPM.

"connect() failed (111: Connection refused)" (Nginx) — Upstream-сервер не запущен или не слушает на ожидаемом порту. Перезапустите бэкенд.

"Too many connections" (MySQL) — Лимит подключений к базе данных исчерпан. Увеличьте max_connections в конфигурации MySQL или оптимизируйте пул соединений.

Решение 5: Настроить параметры PHP-FPM

После изменения настроек PHP-FPM перезапустите сервис: sudo systemctl restart php8.2-fpm. Убедитесь, что fastcgi_read_timeout в Nginx всегда больше или равен max_execution_time в PHP. В противном случае Nginx прекратит ожидание раньше, чем PHP завершит работу, что приведёт к ошибке 504.

Решение 6: Проверить конфигурацию CDN и прокси

Пользователям Cloudflare: Если вы на тарифе Free, Pro или Business и вашему origin нужно больше 100 секунд, вы всегда будете получать Error 524. Единственные варианты: оптимизировать бэкенд, чтобы он отвечал в пределах 100 секунд, перенести долгие задачи в фоновые процессы или перейти на тариф Enterprise.

Пользователям AWS CloudFront: Увеличьте таймаут ответа origin в настройках origin вашей дистрибуции. 30 секунд по умолчанию часто недостаточно для динамического контента.

Используйте инструмент HTTP Headers DNS Robot для проверки заголовков ответа и определения, какой уровень возвращает 504. Ищите заголовки server: cloudflare, server: awselb/2.0 или server: nginx, чтобы определить прокси.

Решение 7: Решения для WordPress

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

• Определите медленные плагины — Деактивируйте все плагины, затем активируйте по одному. Если вы не можете зайти в wp-admin, переименуйте папку plugins через SSH: mv wp-content/plugins wp-content/plugins_disabled. Используйте плагин Query Monitor для выявления медленных запросов к базе данных.

• Увеличьте память PHP — Добавьте define('WP_MEMORY_LIMIT', '512M'); в wp-config.php. Многим плагинам нужно больше, чем стандартные 128 МБ.

• Установите плагин кэширования — WP Super Cache, W3 Total Cache или WP Rocket уменьшают серверную нагрузку, отдавая статический HTML вместо выполнения PHP при каждом запросе.

• Используйте объектное кэширование — Установите Redis или Memcached и плагин объектного кэша для WordPress. Это кэширует результаты запросов к базе данных в памяти, снижая нагрузку на MySQL.

• Очистите базу данных — Удалите старые ревизии записей, transient-данные, спам-комментарии и осиротевшие метаданные. Используйте WP-Optimize или WP-Sweep. Добавьте define('WP_POST_REVISIONS', 5); для ограничения будущих ревизий.

• Отключите wp-cron — Виртуальный cron WordPress запускается при каждой загрузке страницы и может накапливать задачи. Добавьте define('DISABLE_WP_CRON', true); в wp-config.php и настройте серверный cron: */5 * * * * curl -s https://yoursite.com/wp-cron.php > /dev/null 2>&1.

504 vs 502 vs 503 vs 408: в чём разница?

Ключевое различие: 502 означает, что прокси получил некорректный ответ, а 504 означает, что прокси не получил ответ вовсе. Ошибка 503 не требует прокси — её может вернуть любой сервер при перегрузке. Ошибка 408 — это таймаут на стороне клиента (класс 4xx), когда сервер прекратил ожидать запрос от клиента.

Если вы видите одновременно 502 и 504, upstream-сервер, скорее всего, падает. Ошибка 502 возникает, когда прокси получает частичный или повреждённый ответ от умирающего процесса, а 504 — когда процесс полностью не отвечает.

Влияет ли ошибка 504 на SEO?

Короткий ответ: кратковременная ошибка 504 не влияет на SEO. Длительная ошибка 504 может привести к деиндексации.

Минуты — часы: Никакого влияния. Google понимает временные серверные ошибки и не наказывает немедленно. Если Googlebot не заходил на сайт во время сбоя, он даже не заметит.

Часы — дни: Google снижает частоту сканирования для сайтов, возвращающих ошибки 5xx, чтобы не создавать дополнительную нагрузку на проблемный сервер. Страницы могут отображаться как «Server error (5xx)» в отчёте Page Indexing Google Search Console.

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

Восстановление: Когда сервер снова работает стабильно, Google повторно сканирует и индексирует страницы автоматически. Используйте инструмент URL Inspection в Google Search Console для запроса повторной индексации важных страниц. Время восстановления зависит от размера сайта и длительности ошибок.

Как предотвратить ошибки 504 Gateway Timeout

Профилактика лучше аварийного реагирования. Эти практики помогут вашему серверу отвечать в пределах таймаутов.

• Настройте мониторинг — Используйте мониторинг доступности (UptimeRobot, Pingdom или инструмент Ping DNS Robot) для обнаружения ошибок 504 до того, как их заметят пользователи.

• Согласуйте цепочку таймаутов — Убедитесь, что таймаут CDN ≥ таймаут прокси ≥ таймаут приложения. Несогласованные значения вызывают непредсказуемые ошибки 504.

• Реализуйте проверки здоровья — Балансировщики нагрузки и прокси должны проверять состояние upstream-серверов и перенаправлять трафик от неотвечающих экземпляров.

• Активно используйте кэширование — Кэшируйте статические ресурсы, ответы API и результаты запросов к базе данных. Закэшированный ответ никогда не будет настолько медленным, чтобы вызвать 504.

• Автомасштабирование — Используйте горизонтальное масштабирование (больше экземпляров), чтобы всплески трафика не перегружали один сервер.

• Выносите тяжёлые задачи — Переместите обработку файлов, генерацию отчётов, отправку писем и массовый импорт в очереди фоновых задач. Никогда не выполняйте ресурсоёмкие операции внутри HTTP-запроса.

• Мониторьте медленные запросы — Включите журнал медленных запросов в MySQL/PostgreSQL. Настройте оповещения для запросов, превышающих 1 секунду.

• Следите за состоянием зависимостей — Мониторьте сторонние API, от которых зависит ваш бэкенд. Добавьте таймауты и circuit breaker, чтобы один медленный API не вызывал каскад ошибок 504 для всех пользователей.