Nginx大事务接口超时需分阶段精准调优：proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout三者须同步设为业务P99耗时×1.3～1.5倍（如420秒），并匹配client_body_timeout和send_timeout；应通过location精确覆盖导出路径，禁用proxy_buffering，且需校验后端自身超时配置。
大事务接口（如报表导出、批量数据处理、AI推理等）执行时间超过 5 分钟时，Nginx 默认的 60 秒超时会直接中断连接，返回 504 Gateway Timeout。要避免被掐断，关键不是“全调大”，而是分阶段、按需、精准配置超时参数，并确保各环节协同生效。
核心三阶段超时必须同步调高
仅改 proxy_read_timeout 不够，三个 proxy 超时参数需匹配业务最大耗时（建议设为 P99 耗时 × 1.3～1.5 倍，例如 6 分钟任务可设 420 秒）：
- proxy_connect_timeout：控制 Nginx 连上后端的最长时间。内网建议 5–10s，跨机房或 HTTPS 后端建议 10–15s（SSL 握手额外耗时）
- proxy_send_timeout：Nginx 向后端发完完整请求（含 header + body）的总时限。若请求体较大（如带参数的导出请求），需 ≥ 420s
- proxy_read_timeout：从后端开始返回响应头后，读取全部响应体的最大空闲等待时间。这是防“后端卡在生成中”的主控参数，必须 ≥ 420s
客户端侧超时也要对齐，防止中间断连
Nginx 和客户端之间的链路同样不能提前断开，尤其在流式下载大文件时：
- client_body_timeout：上传请求体时两次接收间隔上限，上传类大事务建议设 300–600s
- send_timeout：Nginx 向浏览器/APP 发送响应时的单次写操作间隔，弱网或大文件传输建议 ≥ 420s
- client_header_timeout：通常影响不大，设 30s 即可，避免慢速 HTTP 攻击
用 location 精确覆盖，不污染其他接口
全局调大所有超时会拖慢健康检查、普通 API 等短路径，应只对大事务路径单独优化：
- 在
location ^~/api/export/或location /report/generate中，仅覆盖必要参数 - 例如：
proxy_read_timeout 420s;、proxy_send_timeout 420s;、client_body_timeout 600s; - 其余参数自动继承 http 块设置，保持简洁与可维护性
配套检查项不能漏
光调 Nginx 不足以保成功，还需确认：
- 后端应用自身是否有线程/连接超时（如 Tomcat 的
connectionTimeout、Spring Boot 的server.tomcat.connection-timeout） - 是否启用
proxy_buffering off（流式响应必须关缓冲，否则 Nginx 会攒满再发，触发超时） - 检查 access_log 和 error_log，确认报错是 504 还是 502，定位真实瓶颈在连接建立、发送还是读取阶段
