proxy_read_timeout仅控制响应头返回后两次响应体数据到达的空闲间隔上限，非总请求超时；需基于p99数据块间隔加缓冲设定，并同步调整proxy_send_timeout、send_timeout及upstream keepalive参数。
proxy_read_timeout 不是“延长整个请求时间”的万能开关，它只管一件事：Nginx 收到后端返回的响应头（比如 200 OK 和 Content-Type）之后，等待后端发送响应体数据的**空闲间隔上限**。大数据流场景（如报表导出、SSE 推送、日志流下载）中，后端常边计算边写入，中间有停顿——这个停顿一旦超时，Nginx 就断连，前端看到 504 或连接重置。
明确它真正生效的时机
它只在以下链条中起作用：
- 后端已返回完整响应头（此时计时器启动）；
- 后端开始写入响应体（例如用
flush()输出第一个换行符或 JSON 片段）； - 但后续数据迟迟没来（比如查下一页库、等消息队列、生成中间文件）；
- 两次数据到达之间的空闲时间超过
proxy_read_timeout→ Nginx 主动关闭连接。
它不管后端花 40 秒才返回 header（那是 proxy_connect_timeout 或后端自身问题），也不管客户端下载慢（那是 send_timeout）。
按流式节奏设值，别拍脑袋
不能统一填 3600。应基于真实监控中的 P99 数据块间隔来设：
- 查后端该接口的 P99 “两次 flush 间隔”（不是总耗时），例如监控显示平均 28 秒、P99 是 42 秒；
- 加 5–10 秒缓冲（应对 GC 暂停、DB 临时抖动、网络延迟）；
- 推荐值 = 42 + 8 = 50 秒；
- 若后端固定每 30 秒推一次事件，直接设为 45 秒 更精准。
必须同步调的三个参数
单改 proxy_read_timeout 基本无效，以下三项必须同频调整：
-
proxy_send_timeout ≥ proxy_read_timeout：防止 Nginx 向后端转发带大筛选条件的请求体时中途断开（尤其导出请求常含长 JSON）； -
send_timeout ≥ proxy_read_timeout：确保弱网用户下载大流时，Nginx 不会因客户端接收慢而提前断连； -
upstream 开启
keepalive 32，并配proxy_http_version 1.1和proxy_set_header Connection ''：避免每次流式请求都重建 TCP 连接，否则 TIME_WAIT 爆满、握手延迟破坏流连续性。
路径级配置，拒绝全局一刀切
普通查询接口（/api/user）和大数据流接口（/api/export、/events）必须隔离配置：
- 在
location ^~ /api/export/块内显式设置超时，不依赖 server 或 http 块； - 同时关闭缓冲：
proxy_buffering off，避免 Nginx 缓存未发出的数据块，造成“已发但未达”的假象； - 检查
client_max_body_size和client_body_timeout，确保上传阶段不因参数过大被拦截（如导出请求带 Base64 条件）。
