Nginx upstream timed out: не увеличивайте timeout вслепую

Зафиксируйте client, request, upstream, host и фазу timeout: connecting, reading response header или sending request. Они показывают, где именно ожидание превысило лимит.

Сопоставьте timestamp с access log и request id. Без конкретного URL и времени анализ CPU или базы превращается в догадку.

Безопасный локальный запрос к health endpoint помогает отделить Nginx от приложения, но не запускайте тяжёлую пользовательскую операцию повторно на production. Проверьте, слушает ли процесс правильный socket/port и нет ли очереди.

Для PHP-FPM смотрите max children reached, active/idle processes и slowlog. Для Node/Java — event loop, worker pool, GC и внутренние таймауты.

Частые причины — запрос к базе без индекса, блокировка, внешний API без короткого timeout, сетевое хранилище или синхронная тяжёлая задача. Используйте tracing, slow query log и application logs около одного запроса.

Если все запросы замедлились одновременно, сопоставьте CPU, RAM, load, disk I/O и сеть. Высокая метрика — корреляция, а не доказательство, пока логи не показывают конкретное ожидание.

Увеличение proxy_read_timeout оправдано, если операция по контракту действительно длительная и пользователь должен ждать синхронный ответ. Но для фоновой задачи лучше очередь и отдельный статус выполнения.

После исправления повторите контролируемый запрос, проверьте TTFB и оставьте мониторинг критичного endpoint. Порог должен учитывать нормальный p95, а не единичный лучший ответ.