调整 proxy_read_timeout 的核心是精准匹配后端响应节奏：仅控制收到响应头后等待响应体的空闲时间，须按路径实测P99耗时设值（如API设12秒、导出设300秒），并在location块中配置，同步调优proxy_send_timeout、send_timeout及upstream keepalive，且后端超时须小3–5秒。
调整 proxy_read_timeout 的核心不是“拉长等待”，而是让超时时间精准匹配后端真实响应节奏——它只管“收到响应头后，等响应体数据的空闲时间”，设短了误杀正常请求，设长了堆积僵死连接。
按路径实测 P99 耗时再设值
别凭经验填 60、300 或 0。打开 access log，加 $upstream_response_time 字段，统计目标接口真实耗时分布：
-
/api/user：P99 ≈ 8 秒 → 设
proxy_read_timeout 12 -
/api/export：P99 ≈ 240 秒 → 设
proxy_read_timeout 300 -
/api/heartbeat（每 45 秒上报）→ 设
proxy_read_timeout 90，留出网络抖动余量
全局统一设值会拖累快接口；设为 0 则彻底失去连接回收能力，风险极高。
必须在 location 块内精准配置
该参数作用域优先级为 location > server > http，改了 http 块却没在真正处理请求的 location 里覆盖，等于白改：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 普通 API 路径保持短超时：
location /api/ { proxy_read_timeout 20; } - 导出类慢路径单独隔离：
location /api/export/ { proxy_read_timeout 360; proxy_pass http://backend; } - 若用 PHP-FPM，
proxy_read_timeout完全不生效，要改fastcgi_read_timeout并同步调 PHP 层max_execution_time和request_terminate_timeout
同步调齐三项关联参数
单改 proxy_read_timeout 几乎无效，容易出现“断不对”或“根本断不了”：
- proxy_send_timeout ≥ 它：防止大 Body 请求（如带附件 POST）还没发完就被切断
- send_timeout ≥ 它：确保弱网用户下载大文件时，Nginx 不提前关闭客户端连接
-
upstream 启用 keepalive：例如
keepalive 32;，并配proxy_http_version 1.1;和proxy_set_header Connection '';，否则每次重连多耗数秒，实际可用时间大幅缩水
后端超时必须比它小 3–5 秒
Nginx 断连要有依据，不能自己猜：
- Tomcat：设
connectionTimeout="295000"（单位毫秒），若 Nginx 设 300 秒 - Spring Boot：设
server.tomcat.connection-timeout=295000 - 这样后端会先主动 FIN，Nginx 收到后自然释放连接，避免
upstream timed out (110)这类僵持错误
调完务必执行 nginx -t && nginx -s reload，热重载不生效。开启 error_log ... debug 可临时捕获超时上下文，重点看报错中是否含 while reading response header from upstream 或 while reading upstream。
