Nginx upstream timed out: не увеличивайте timeout вслепую
Сообщение upstream timed out означает, что Nginx не получил нужную часть ответа upstream за заданное время. Это симптом: причиной может быть медленный запрос, очередь workers, внешняя зависимость или перегрузка.
Диагностическое дерево HTTP 5xx
Выберите симптом, чтобы увидеть вероятную зону проверки.
Начните с логов backend, последних деплоев, переменных окружения и ошибок базы данных.
Как диагностировать upstream timed out в Nginx: время ошибки, upstream, proxy timeout, PHP-FPM, база, внешние API, очередь и нагрузка сервера.
Прочитайте точную строку журнала ошибок
Зафиксируйте client, request, upstream, host и фазу timeout: connecting, reading response header или sending request. Они показывают, где именно ожидание превысило лимит.
Сопоставьте timestamp с access log и request id. Без конкретного URL и времени анализ CPU или базы превращается в догадку.
Проверьте upstream напрямую
Безопасный локальный запрос к health endpoint помогает отделить Nginx от приложения, но не запускайте тяжёлую пользовательскую операцию повторно на production. Проверьте, слушает ли процесс правильный socket/port и нет ли очереди.
Для PHP-FPM смотрите max children reached, active/idle processes и slowlog. Для Node/Java — event loop, worker pool, GC и внутренние таймауты.
Мониторинг покажет, когда состояние изменится
Добавьте сайт или сервер один раз — perfMon будет проверять его автоматически, сохранит историю и сообщит о сбое и восстановлении.
7 дней без оплаты и банковской карты с момента создания сервера. Затем 2 000 ₽ за сервер за 30 дней, до 50 сайтов на сервер. Продление вручную. Условия тарифа
Найдите медленную зависимость
Частые причины — запрос к базе без индекса, блокировка, внешний API без короткого timeout, сетевое хранилище или синхронная тяжёлая задача. Используйте tracing, slow query log и application logs около одного запроса.
Если все запросы замедлились одновременно, сопоставьте CPU, RAM, load, disk I/O и сеть. Высокая метрика — корреляция, а не доказательство, пока логи не показывают конкретное ожидание.
Когда менять таймаут прокси
Увеличение proxy_read_timeout оправдано, если операция по контракту действительно длительная и пользователь должен ждать синхронный ответ. Но для фоновой задачи лучше очередь и отдельный статус выполнения.
После исправления повторите контролируемый запрос, проверьте TTFB и оставьте мониторинг критичного endpoint. Порог должен учитывать нормальный p95, а не единичный лучший ответ.
Автоматизируйте проверку, описанную в статье
Разовая диагностика помогает сейчас. Регулярный мониторинг нужен, чтобы не пропустить повторение проблемы.
7 дней без оплаты и банковской карты с момента создания сервера. Затем 2 000 ₽ за сервер за 30 дней, до 50 сайтов на сервер. Продление вручную. Условия тарифа
Попробовать 7 днейПрименить на практике
Частые вопросы
Короткие ответы на вопросы, которые обычно возникают при диагностике.
upstream timed out — это всегда 504?
Часто клиент получает 504, но точный результат зависит от фазы, конфигурации и того, успел ли Nginx отправить часть ответа.
Поможет ли proxy_read_timeout 300?
Он может скрыть симптом и занять worker/connection дольше. Сначала подтвердите, почему upstream медленный и соответствует ли длительность контракту.
Чем 502 отличается от 504?
502 обычно означает некорректный или отсутствующий ответ upstream, 504 — превышение времени ожидания ответа.
Не ждите следующего сообщения «сайт не работает»
Добавьте первый сайт или сервер: perfMon будет проверять состояние автоматически, сохранит историю и уведомит ответственных.
7 дней без оплаты и банковской карты с момента создания сервера. Затем 2 000 ₽ за сервер за 30 дней, до 50 сайтов на сервер. Продление вручную. Условия тарифа