必须在特定 location 中启用 proxy_ignore_client_abort on，并配套 proxy_read_timeout、proxy_buffering off 等参数，同时后端需具备中断感知与状态追踪能力，三者协同才能避免客户端断开导致的无效计算。
要避免客户端断开引发后端无效计算，不能只开 proxy_ignore_client_abort on——它只是让 Nginx 不主动中止后端请求，但若后端无感知、无防护，仍会白跑任务、空耗资源。关键在于“Nginx 不甩手 + 后端能识停 + 业务可兜底”三者协同。
只在真正需要保活的 location 中启用
该指令仅对 proxy_pass 生效，且必须按路径精准控制：
- ✅ 推荐场景：/api/v1/notify、/upload/complete、/task/export 等异步、幂等、用户无需等待响应的接口
- ❌ 禁用场景：/login、/pay/confirm、/withdraw 等敏感操作——客户端取消即应终止，否则可能重复扣款或越权提交
- ⚠️ 切勿写在
http或server块顶层，否则影响全部流量；必须嵌入具体location块内
必须配套调整超时与缓冲参数
单独开启 proxy_ignore_client_abort on 几乎无效，Nginx 会在等待过程中自行超时断连：
-
proxy_read_timeout 300：设为后端最长预期耗时（如导出报表需 240 秒，则至少设 300） -
proxy_send_timeout 300：防止 Nginx 在向后端发送请求体中途因无响应而中断 -
proxy_connect_timeout 60：避免连接上游阶段被过早拦截 -
proxy_buffering off：关闭缓冲，避免大响应体堆积内存；尤其适用于流式输出（SSE、分块下载） -
proxy_http_version 1.1与proxy_set_header Connection ''：防止 keepalive 连接池复用异常
后端必须具备中断感知与状态追踪能力
Nginx 层“不杀”，不等于后端“不用管”。若后端继续盲跑，就会产生大量无效计算：
- 捕获并忽略 I/O 异常：如 Tomcat 的
ClientAbortException、Spring Boot 的IOException（由 socket 关闭触发） - 关键任务引入状态机：数据库记录
status: processing→ 完成后更新为success或failed，前端通过轮询/task/status?id=xxx获取结果 - 避免直接操作原始输出流：不要在
response.getOutputStream()上循环写入；优先使用框架封装的响应体机制（如 Spring@ResponseBody、Flaskjsonify）
验证是否生效及常见失效原因
日志是判断配置是否落地的最直接依据：
- 生效表现：access log 中
$status显示200或504（而非持续 499），同时$upstream_status为200，说明请求确实走完了代理链路 - 常见失效点：
– 使用了fastcgi_pass或uwsgi_pass（该指令对非 HTTP 代理无效）
– Nginx 版本低于 1.10 或启用了 HTTP/2（旧版不支持该指令在 HTTP/2 下行为）
– CDN 或负载均衡器提前中断连接，Nginx 根本未收到 client abort 信号
– 配置未 reload，或写在了错误的 location 路径下（如接口是/export/task，却只配在/api）
