Начните с error log
Найдите запись по времени запроса и сопоставьте её с логами приложения. Формулировки while connecting to upstream и while reading response header from upstream указывают на разные этапы. Убедитесь, что между клиентом и приложением нет другого прокси со своим ограничением времени.
Для диагностики полезны статус ответа, идентификатор запроса, $request_time, $upstream_connect_time, $upstream_header_time и $upstream_response_time.
Три разных ограничения
| Директива | Что ограничивает |
|---|---|
proxy_connect_timeout | Установление соединения с upstream. |
proxy_send_timeout | Интервал между последовательными операциями записи запроса в upstream. |
proxy_read_timeout | Интервал между последовательными операциями чтения ответа upstream. |
Тайм-аут чтения не ограничивает полную длительность ответа. Если upstream регулярно передаёт данные, ответ может продолжаться дольше указанного значения.
Настраивайте конкретный маршрут
Пример для отдельного сервиса отчётов. Имя reports обозначает upstream, который должен быть определён в вашей конфигурации. Значения иллюстративные: выбирайте их из требований к запросу.
location /reports/ {
proxy_pass http://reports;
proxy_connect_timeout 5s;
proxy_send_timeout 30s;
proxy_read_timeout 180s;
proxy_buffering on;
}Перед применением проверьте синтаксис через nginx -t. После reload повторите запрос и проверьте журнал ошибок.
Если отчёт действительно считается долго
Измерьте время запроса к upstream напрямую из той же сети. Проверьте очередь обработчиков, обращения к базе, внешние API и ограничения ресурсов. Увеличение ожидания не добавляет пропускной способности.
Часто удобнее создать фоновую задачу, вернуть её идентификатор и дать клиенту получать статус. Тогда длительность расчёта не определяет срок жизни HTTP-соединения.
Документация и источники
Примеры иллюстративные. Имена сервисов и баз условные; команды и параметры нужно адаптировать к своему окружению.