proxy_read_timeout仅控制Nginx接收响应体的空闲超时，需按路径隔离配置、同步调大proxy_send_timeout和send_timeout、启用upstream keepalive，并确保后端超时设为Nginx值的0.8倍。

直接调大 proxy_read_timeout 不能解决问题，必须明确它只管“等响应体数据”这一段，并同步调整关联参数、按路径隔离、对齐后端超时策略。

先搞清 proxy_read_timeout 管什么、不管什么

它仅控制 Nginx 从上游收到响应头后，等待接收完整响应体（比如导出的 Excel 流、AI 推理结果流）的空闲时间上限。两次数据包之间若超过该值没新数据，Nginx 就断连并返回 504。

它不负责：

• 建立 TCP 连接（那是 proxy_connect_timeout 的事）
• 把请求发给后端（那是 proxy_send_timeout 的事）
• 把响应传给客户端（那是 send_timeout 的事）

按业务路径单独配置，别全局一刀切

后端同时跑登录接口和报表导出？不能所有 location 都用一个 timeout。必须用 location 做隔离：

FastAPI Flask Proxy

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

下载

• 普通 API 路径（如 /api/user）：保持 proxy_read_timeout 20;
• 长耗时路径（如 /api/export/ 或 /api/submit-xml）：单独写 location 块，设更高值
• 参考真实 P99 耗时 × 1.2～1.5，例如监控显示导出接口 P99 是 220 秒，就设为 300

必须配套改的三个参数

只改 proxy_read_timeout 是白忙——后端还没开始回数据，Nginx 可能已在发请求时就被切断了：

• proxy_send_timeout ≥ proxy_read_timeout（防止请求体没发完就被中断）
• send_timeout ≥ proxy_read_timeout（防止弱网用户下载慢，Nginx 提前断连）
• upstream 块启用 keepalive 32，并配 proxy_http_version 1.1 和 proxy_set_header Connection ''（否则连接无法复用，每次重连都浪费资源）

后端超时必须比 Nginx 小

如果 Tomcat 的 connectionTimeout 或 Spring Boot 的 server.tomcat.connection-timeout 设成 360 秒，而 Nginx 的 proxy_read_timeout 是 300 秒，那后端根本不会提前断，但 Nginx 会先报 504；反过来，如果后端设成 200 秒，Nginx 却设 300 秒，就会出现后端已关连接、Nginx 还在等，最终报 502 或 504。

稳妥做法：后端超时 = Nginx proxy_read_timeout × 0.8 左右，留出缓冲余地。