proxy_read_timeout仅控制后端返回响应头后等待响应体的空闲时长，超时即504；需按业务路径（如普通API设20秒、导出接口据P99×1.2～1.5设值）用location隔离配置，并同步调优proxy_send_timeout、send_timeout、upstream keepalive及后端超时（建议设为Nginx值的0.8倍），流式接口还需关闭proxy_buffering。

proxy_read_timeout 不是“忍受整个请求的时间”，它只管一件事：后端已返回响应头之后，Nginx 等待后续响应体数据到达的空闲时长上限。超了就断连、报 504。要真正优化复杂业务（如报表导出、AI 推理、批量同步）的等待体验，得精准配置 + 协同调优。

按业务路径单独设值，别全局一刀切

后端跑着登录接口和导出任务？不能全用一个 timeout。必须用 location 隔离：

• 普通 API（如 /api/user）：设 proxy_read_timeout 20; —— P99 耗时通常 1–3 秒，留 5 倍余量够用
• 长耗时路径（如 /api/export/、/api/submit-xml）：单独写 location 块
• 参考真实 P99 × 1.2～1.5：比如监控显示导出接口 P99 是 285 秒，就设 360；若波动大（30 秒～10 分钟），宁可略高，但避免盲目填 86400

必须同步调这三项，否则单改无效

只动 proxy_read_timeout 就像加固门却忘了关窗：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• proxy_send_timeout ≥ 你设的 proxy_read_timeout：防止请求体（比如大 JSON 或文件）还没发完就被切断
• send_timeout ≥ proxy_read_timeout：确保弱网用户下载导出文件时，Nginx 不会中途断开客户端连接
• upstream 块启用 keepalive 32，并配 proxy_http_version 1.1 和 proxy_set_header Connection ''：否则每次请求都重建 TCP 连接，再长的 timeout 也没意义

后端超时必须比 Nginx 小，留出缓冲

Nginx 和后端超时要错开，避免互相“等死”：

• 若 proxy_read_timeout 设为 300 秒，Tomcat 的 connectionTimeout 或 Spring Boot 的 server.tomcat.connection-timeout 应设为 240 秒左右（0.8 倍）
• 太接近（如后端设 295 秒）→ Nginx 还没超时，后端先断，结果报 502 或 504
• 太宽松（如后端设 600 秒）→ Nginx 先超时，后端还在跑，浪费资源且无预警

配合流式响应的关键开关

对导出 Excel、SSE、实时日志等流式接口：

• 加 proxy_buffering off;：避免 Nginx 缓存整块响应再吐给客户端，导致“卡住假超时”
• 可加 chunked_transfer_encoding on;：支持分块传输，提升大响应兼容性
• 若用 WebSocket 或 SSE，注意 proxy_read_timeout 实际控制的是两次数据帧之间的最大静默间隔，不是会话总时长

不复杂但容易忽略