定时任务类接口需在匹配的location块中精准配置proxy_connect_timeout（10–30s）、proxy_send_timeout（300s）、proxy_read_timeout（按p95×1.2向上取整），禁用proxy_buffering，启用http/1.1复用，并对齐后端及系统级超时。
定时任务类接口（如报表生成、数据同步、AI批量推理）常需数分钟甚至更久才返回结果，Nginx 默认 60 秒超时极易中断请求，造成“挂起假象”——实际是 Nginx 主动断连，而非后端卡死。关键不是无差别拉长所有超时，而是精准定位路径、分层设参、配套兜底。
只在匹配该定时接口的 location 中单独配置
不能在 http 或 server 级全局改 proxy_read_timeout，否则会拖慢所有普通接口、堆积无效连接。必须找到真实生效的 location 块，例如：
-
路径精确匹配：
location /api/v1/task/export/ { ... } -
正则匹配：
location ~ ^/jobs/[a-z]+/status$ { ... } - 用
nginx -T | grep -A10 "export"验证配置是否落在此块内，避免写错作用域
三项 proxy 超时参数按业务节奏设值
这三项独立计时，缺一不可：
- proxy_connect_timeout：设为 10–30s。若后端是冷启动的 Java 应用（首次加载耗时 90s），需 ≥120s，否则连不上就直接报 502
- proxy_send_timeout：设为 300s（5 分钟）。适用于大参数 POST 或含文件上传的触发请求
- proxy_read_timeout：最关键。按该接口 P95 耗时 ×1.2 向上取整，例如实测导出平均 420s、P95 是 540s，建议设为 600s 或 10m；超时后 Nginx 返回 504
必须同步关闭缓冲并启用 HTTP/1.1 复用
仅调超时不解决流式响应挂起问题：
- proxy_buffering off;：防止 Nginx 缓存未完成的响应体（如边生成边输出的 CSV 或日志流），导致客户端一直等不到数据
- proxy_http_version 1.1; + proxy_set_header Connection '';：启用连接复用，避免每个 chunk 都建新连接
- 若用了 upstream，加 keepalive 32; 并配 least_conn 调度，防某台后端被长任务占满
对齐后端与系统级超时，避免提前掐断
Nginx 超时再宽，若后端或内核先断，照样挂：
- Tomcat 的
connectionTimeout、Spring Boot 的server.tomcat.connection-timeout必须 ≥ Nginx 的proxy_read_timeout - Linux 内核 TCP keepalive 时间（
net.ipv4.tcp_keepalive_time）建议设为 600s，让系统层能更快探测僵死连接 - 禁用 IPv6 时，确保 resolver 配置的 DNS 支持 A 记录查询，避免因只回 AAAA 导致隐式阻塞
