proxy_read_timeout精准控制Nginx在收到响应头后等待后端传输响应体的空闲时长，仅作用于响应体流式传输阶段，需按路径分级配置并同步调整proxy_send_timeout和send_timeout。
proxy_read_timeout 不是用来“兼容”慢速后端的万能开关，而是精准控制 Nginx 等待后端返回响应体数据的空闲上限。它只在响应头已收到、但响应体尚未传完的阶段起作用——比如后端正把一个大文件从对象存储（如 S3、MinIO）流式读出并转发给 Nginx 时，Nginx 就靠这个参数决定“等多久没新数据就断开”。设小了会误杀合法长响应；设大了又易堆积僵死连接。
明确它管什么、不管什么
它仅约束这一段行为：
→ 后端已返回 HTTP/1.1 200 OK 及响应头
→ Nginx 开始接收响应体（例如 PDF、ZIP、视频分片）
→ 中间若连续空闲超时，即断连
它和以下环节完全无关：
• proxy_connect_timeout：TCP 连接建立阶段
• proxy_send_timeout：Nginx 往后端发请求（如带签名的预签 URL 请求）的时间
• send_timeout：Nginx 往客户端传响应的慢速下载超时
• 客户端侧的 client_header_timeout 或网络抖动
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
按静态响应路径分级配置
不要全局统一设值。后端若同时提供普通 API 和静态资源服务（如 /static/、/downloads/、/assets/），必须用 location 隔离：
- 对普通接口（如
/api/health）：保持默认或设为30s - 对明确走对象存储的路径（如
/downloads/.*\.(zip|pdf|mp4)$）：
– 查看该路径近 7 天 P95 响应耗时（含后端从存储拉取+组装头的时间）
– 设为P95 × 1.3～1.5，例如 P95 是 82 秒 → 设120s
– 若后端使用预签名 URL 直链跳转，则此参数不生效（Nginx 不参与传输）
必须同步调整的三项关联参数
单改 proxy_read_timeout 几乎无效，需形成闭环：
-
proxy_send_timeout≥proxy_read_timeout：确保 Nginx 有足够时间把请求（如含 token 的 HEAD 请求）完整发给后端存储网关 -
send_timeout≥proxy_read_timeout：防止客户端网络差时，Nginx 在转发完响应体后、还没推完给用户时就断连 - 启用连接复用：
–proxy_http_version 1.1
–proxy_set_header Connection ""
– upstream 块中配keepalive 32，否则每次都要重连对象存储网关，增加延迟
验证是否真正生效
改完不能只信配置语法正确：
- 开启 Nginx 错误日志
error_log /var/log/nginx/error.log notice，搜索upstream timed out或readv() failed - 用
curl -v http://your-domain/downloads/bigfile.zip观察实际耗时与返回状态码 - 检查后端对象网关日志：确认是它主动断连（如返回
408），还是 Nginx 先发了FIN - 对比监控指标：Nginx 的
upstream_response_time分位值是否与设置值匹配，而非始终卡在超时边界
