proxy_read_timeout的核心目标是精准匹配后端响应节奏：仅控制响应头接收后到响应体收完间的空闲等待，需按路径P99耗时设值（如API设12秒、导出设300秒），并同步调整proxy_send_timeout、send_timeout及upstream keepalive，且后端超时须比其小3–5秒。
优化 proxy_read_timeout 的核心目标不是“避免超时”，而是让超时在该发生时才发生——即后端真卡住时快速断连，而非在它正常工作时误杀连接。过早超时（如设为 30 秒却用于导出接口）会导致大量 504，掩盖真实问题；过晚超时（如全局设 600 秒）则堆积僵死连接，耗尽文件描述符和内存。关键在“精准匹配后端响应节奏”。
先确认它到底管哪一段
proxy_read_timeout 只监控一个窗口：从后端返回响应头（例如 HTTP/1.1 200 OK）开始，到完整收完响应体之间的空闲等待时间。 它不关心：
- 后端 SQL 是否还在执行（那是应用或数据库层问题）
- TCP 连接是否已建立（归
proxy_connect_timeout管） - Nginx 是否把请求体发完了（归
proxy_send_timeout管） - 客户端下载慢不慢（归
send_timeout管）
按路径实测 P99 耗时再设值
不要凭经验填 60、300 或 0。打开 Nginx access log，加入 $upstream_response_time 字段，统计目标接口的真实耗时分布：
Bailian Usage Proxy
下载
阿里百炼大模型平台多人共享账号用量统计代理服务。解决公司共用账号时无法区分个人用量的问题。适用场景：1)部署用量统计代理；2)统计多人Token用量和调用次数；3)管理大模型API调用配额。
- 普通 API（如
/api/user）：P99 ≈ 8 秒 → 设proxy_read_timeout 12 - 报表导出（如
/api/export）：P99 ≈ 240 秒 → 设proxy_read_timeout 300 - 工控心跳（每 45 秒上报一次）：设
proxy_read_timeout 90，留出网络抖动余量 - 绝对避免设为 0（禁用超时）——失去连接回收能力；也避免设为 3600+ —— 单个慢请求可能挂住连接数分钟
必须同步调的三个关联参数
单改 proxy_read_timeout 几乎无效，容易出现“断得不对”或“根本断不了”：
-
proxy_send_timeout≥ 它：防止大 Body 请求（如带附件的 POST）还没发完就被切断 -
send_timeout≥ 它：确保用户弱网下载大文件时，Nginx 不提前关闭 client 连接 - upstream 块启用
keepalive 32，并配proxy_http_version 1.1和proxy_set_header Connection ''：否则每次请求都重握手，实际可用时间大幅缩水
配合后端超时形成闭环
Nginx 断连要“有依据”，不能自己猜：
- 后端 connectionTimeout（如 Tomcat 的
connectionTimeout或 Spring Boot 的server.tomcat.connection-timeout）必须比proxy_read_timeout小至少 3–5 秒 - 例如 Nginx 设 300 秒，则后端设 295 秒；这样后端会先主动 FIN，Nginx 收到后自然释放连接，避免
upstream timed out (110)这类僵持错误 - 开启
error_log ... debug临时捕获超时日志，重点看报错中是否含while reading response header（说明压根没到 proxy_read_timeout 生效阶段）
