Gateway Timeout 504 — HTTP-статус, который возвращает промежуточный сервер (обычно Nginx или балансировщик нагрузки), когда он не получил своевременного ответа от upstream-сервера. Это означает, что Nginx дождался запроса от браузера, передал его бэкенду (PHP-FPM, Node.js, Python-сервис), но бэкенд не ответил в отведённое время.
Как работает
Когда Nginx работает как reverse proxy, он ограничивает время ожидания ответа от upstream несколькими параметрами:
proxy_connect_timeout— время на установку соединения с upstream (по умолчанию 60s)proxy_send_timeout— время на отправку запроса upstreamproxy_read_timeout— время ожидания ответа (чаще всего причина 504)
Если proxy_read_timeout истёк — Nginx возвращает клиенту 504. Аналогично работает Apache с ProxyTimeout и AWS ALB с таймаутом 60 секунд по умолчанию.
Причины 504: перегруженный бэкенд (медленные запросы к базе данных), зависший PHP-FPM воркер, медленный внешний API в синхронном запросе, нехватка ресурсов сервера.
История
Коды HTTP-статусов стандартизированы в RFC 7231 (2014), но 504 появился ещё в HTTP/1.1 (RFC 2616, 1999). С распространением микросервисной архитектуры 504 стал более частым: цепочка из нескольких сервисов увеличивает вероятность превышения таймаута на любом из звеньев.
Диагностика и исправление
Первый шаг — определить, на каком уровне таймаут. Логи Nginx (/var/log/nginx/error.log) покажут: «upstream timed out (110: Connection timed out)». Логи приложения покажут, что именно выполнялось в момент таймаута.
Часто причина — медленный SQL-запрос. Включите slow query log в MySQL: slow_query_log = 1, long_query_time = 1. Запросы дольше 1 секунды — кандидаты на оптимизацию через индексы.
Временное решение — увеличить таймауты в Nginx: proxy_read_timeout 300;. Постоянное решение — оптимизировать бэкенд или перенести тяжёлые операции в очередь задач. Мониторинг 504 через Grafana: метрика nginx_http_requests_total{status="504"} позволяет отслеживать частоту ошибок и настроить алерты.
504 при долгих операциях
Иногда 504 — не ошибка, а архитектурное ограничение. Операции дольше 60 секунд (генерация отчётов, обработка видео, массовый импорт) не должны выполняться синхронно через HTTP. Правильный паттерн: принять задачу, вернуть 202 Accepted с ID задачи, выполнить в очереди задач, предоставить endpoint для проверки статуса.
Диагностический чеклист при 504:
- Проверить
/var/log/nginx/error.log— есть ли «upstream timed out» - Проверить
systemctl status php8.2-fpm— статус и активные воркеры - Выполнить запрос вручную с
curl -w "%{time_total}" ...— сколько реально занимает - Включить slow query log в MySQL и проверить медленные запросы
- Проверить
top/htop— не перегружен ли сервер
Для PHP-приложений иногда причина 504 — max_execution_time в PHP.ini (по умолчанию 30 секунд). При работе через Nginx нужно согласовать таймауты: fastcgi_read_timeout в Nginx должен быть больше max_execution_time в PHP. Мониторинг частоты 504 по URL помогает найти конкретные эндпоинты-узкие места.