关键是在特定路径启用proxy_ignore_client_abort on并配齐超时、缓冲等参数，后端需兜底、落库、幂等、返回task_id供轮询确认。
要让后端耗时任务在用户关闭页面、刷新或网络中断后仍能完整执行，关键不是简单打开 proxy_ignore_client_abort on，而是把它作为一整套协同机制中的一环——它负责“不杀后端”，但后端能否跑完、是否安全、结果如何确认，全靠配套配置和业务设计。
只在真正需要的路径上启用
这个指令不能全局开启，否则可能掩盖前端异常、干扰敏感操作（如支付、登录）。应精准作用于那些“发出去就不管前端”的接口：
- /api/v1/notify：Webhook 推送、异步通知类请求
- /report/generate：报表导出、批量处理等长耗时任务入口
- /upload/complete：大文件上传完成后的后台转码、校验、归档回调
在对应 location 块内添加配置，例如：
location /api/report/generate {
proxy_pass http://backend;
proxy_ignore_client_abort on;
proxy_read_timeout 300;
proxy_send_timeout 300;
proxy_connect_timeout 60;
proxy_buffering off;
proxy_http_version 1.1;
proxy_set_header Connection '';
}
必须同步调大三个超时参数
proxy_ignore_client_abort on 只是告诉 Nginx “客户端走了我也继续等后端”，但它不会无限等待。若后端响应慢过设定值，Nginx 仍会主动断连并返回 504。真正起决定性作用的是：
Bailian Usage Proxy
下载
阿里百炼大模型平台多人共享账号用量统计代理服务。解决公司共用账号时无法区分个人用量的问题。适用场景：1)部署用量统计代理；2)统计多人Token用量和调用次数；3)管理大模型API调用配额。
-
proxy_read_timeout：Nginx 等待后端响应体的最长时间（秒），必须 ≥ 后端最长预期耗时（如导出需 240s，这里至少设 300） -
proxy_send_timeout：Nginx 向客户端发送响应的超时，弱网流式输出易卡住，建议同步放宽至 300 -
proxy_connect_timeout：与后端建连超时，保持 60 即可，过高反而不利于故障发现
后端自身必须兜底和可追踪
Nginx 不再中止连接，不等于任务就一定成功。后端需承担起最终责任：
- 设置自身执行超时（如 PHP 的
set_time_limit(300)，Go 的context.WithTimeout），避免卡死拖垮进程 - 任务启动即落库/写 Redis，标记为“进行中”；完成后更新状态为“成功”或“失败”
- 接口返回应尽量轻量（如只返回 task_id），前端通过轮询
/task/status?id=xxx或监听消息队列确认结果 - 所有关键操作需幂等设计，防止因重复提交或重试导致数据异常
关闭缓冲并注意日志含义
开启后，建议加 proxy_buffering off;：
- 避免 Nginx 缓存大响应体造成内存堆积（尤其后端流式返回日志、进度或大文件）
- 确保后端能实时输出，便于观察执行状态
日志中仍会记录真实后端返回码（200/500/503），但客户端已断开，所以 access log 中该请求的状态码仍是 499——这不是错误，而是“客户端先走，Nginx 继续跑完后端并记下结果”的正常表现。排查时要结合 upstream_response_time 和后端日志交叉验证。
