开启 proxy_ignore_client_abort on 的本意是让 nginx 在客户端断开后继续等待后端完成，但若配置不当，反而会造成连接长期挂起、worker 连接数缓慢堆积、上游连接池耗尽——这不是“保活”，而是“滞留”。关键不在“开不开”，而在如何防止它变成连接残留的温床。
开启 proxy_ignore_client_abort on 的本意是让 Nginx 在客户端断开后继续等待后端完成，但若配置不当，反而会造成连接长期挂起、worker 连接数缓慢堆积、上游连接池耗尽——这不是“保活”，而是“滞留”。关键不在“开不开”，而在如何防止它变成连接残留的温床。
只在明确需要异步保活的路径启用
该指令必须写在具体 location 块中，且该 location 必须含 proxy_pass。全局启用（如放在 http 或 server 块顶层）会把所有请求都拖入长等待，极易引发连接堆积：
- ✅ 推荐：仅用于幂等、无状态、结果可查的接口，例如
/api/v1/export/task、/upload/complete、/webhook/deliver - ❌ 禁止：登录、支付、下单等强一致性操作；这些路径客户端中断即应终止，否则可能重复扣款或越权提交
- ⚠️ 注意：对
fastcgi_pass、uwsgi_pass或静态服务完全无效，开了也白开
必须收紧超时参数，堵住“无限等待”漏洞
proxy_ignore_client_abort on 不等于“永远等下去”。Nginx 仍会按自身超时机制清理连接。若未显式调大，它会在默认值（通常 60 秒）后主动断连，导致后端任务被静默截断，同时连接资源未及时释放：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- proxy_read_timeout 300：这是唯一决定“Nginx 愿意等后端多久”的参数。设为后端最长预期耗时（如导出需 240 秒，则至少设 300）
- proxy_send_timeout 300：防止弱网下向客户端发送响应时因 ACK 缺失而卡住，尤其影响流式接口
- proxy_connect_timeout 60：保持合理建连窗口即可，过高反而掩盖真实网络故障
关闭缓冲 + 清理连接头，避免连接池污染
默认开启的 proxy_buffering on 会让 Nginx 缓存整个响应体再转发。一旦客户端已断开，Nginx 可能延迟检测，持续占用连接并堆积内存：
- proxy_buffering off：强制边生成边传输，便于更快感知断连，也减少内存压力
- proxy_http_version 1.1：启用 HTTP/1.1 协议支持
- proxy_set_header Connection ''：清空 Connection 头，防止 keepalive 连接池误复用脏连接
后端必须主动释放资源，不能依赖 Nginx “兜底”
Nginx 层面的“不中断”只是起点。若后端不配合，连接残留问题会从 Nginx 转移到应用层：
- 捕获并处理 I/O 异常：如 Spring Boot 的
ClientAbortException、Node.js 的req.aborted、Go 的context.Canceled，避免线程卡死或日志刷屏 - 关键任务启动即落库：写入
task_id和status: processing，完成后更新状态，不依赖响应通道确认结果 - 避免直接操作原始输出流：不要在
response.getOutputStream()上循环写入大块数据；优先使用框架封装的响应机制（如 Spring 的StreamingResponseBody）
