499是nginx自定义状态码，表示客户端在nginx转发请求或处理完成前主动关闭连接，常见于弱网下tcp丢包、rst/fin提前触发，导致nginx向后端发送rst并中止任务；开启proxy_ignore_client_abort on可让nginx继续等待后端响应，但必须同步调大proxy_read_timeout等超时参数，并配合后端幂等设计与流式输出优化，否则仅转移问题而非解决。
开启 proxy_ignore_client_abort on 能防止弱网下客户端断连导致后端任务被中止，但必须配合超时参数调整和后端幂等设计，否则只是把问题从“中断”转成“堆积”。
为什么移动端弱网会触发 499 并杀掉后端任务
用户在 3G/地铁/电梯等场景下，TCP 连接容易因丢包、RST 或 FIN 提前关闭，Nginx 默认行为是：一旦检测到客户端连接关闭（哪怕只发了部分响应），立刻向后端发送 RST 或关闭 upstream 连接。此时 Java 后端抛 ClientAbortException，Spring Boot 若未捕获，线程可能直接退出，长任务（如导出、渲染、批量处理）就此中断。
典型现象：access.log 中出现大量 499，upstream_response_time 却远大于 proxy_read_timeout（说明后端其实还在跑，只是 Nginx 已放弃）。
proxy_ignore_client_abort on 必须配哪些超时参数
单独开 proxy_ignore_client_abort on 没用，Nginx 仍可能自己先超时断连——它不会因为客户端走了就无限等后端。关键三参数必须同步调大：
-
proxy_read_timeout 300：后端响应最大等待时间，不能低于业务最长耗时（比如导出要 240s，这里至少设 300） -
proxy_send_timeout 300：Nginx 向客户端发响应的超时，弱网下流式传输易卡住，需放宽 -
proxy_connect_timeout 60：与后端建连超时，保持默认或略增即可，过高反而掩盖网络故障
注意：proxy_read_timeout 是唯一真正影响“后端能跑多久”的参数；其他 timeout 改了但这个没改，照样 504。
为什么还要关 buffering 和升级 HTTP 版本
移动端弱网常伴随高延迟、低吞吐，如果 Nginx 开启缓冲（proxy_buffering on，默认值），它会攒满 buffer 才转发，导致后端以为响应已发出、实际卡在 Nginx 层，进而误判超时或重复提交。
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
必须加这两行：
-
proxy_buffering off：确保后端流式输出（如 SSE、chunked）能直通客户端 -
proxy_http_version 1.1+proxy_set_header Connection ''：避免 keepalive 连接池复用旧连接，引发Connection: close冲突
不关 buffering 的后果：后端日志显示“已返回 200”，但客户端收不到任何字节，Nginx 日志却是 499 或 502。
后端必须自己扛住“客户端已走，但我还在跑”的状态
proxy_ignore_client_abort on 只解决 Nginx 层的中止，不解决业务逻辑层面的脆弱性。常见坑：
- Java 中未捕获
ClientAbortException，导致事务回滚、线程中断、资源泄漏 - 任务无唯一
task_id，无法幂等重试或查询进度 - 使用同步阻塞 I/O（如
FileOutputStream.write()）写大文件，线程卡死无法响应中断信号 - 数据库连接未设 query timeout，一个慢 SQL 拖垮整个 worker
真实案例：某导出接口开了 proxy_ignore_client_abort on，但后端没做幂等，用户反复刷新导致生成 7 个重复 Excel 文件，磁盘被打满。
最易被忽略的一点：这个配置对 DNS 失败、TCP 握手失败、SSL handshake timeout 完全无效——那些阶段客户端都还没走到 Nginx，压根不会记 499，而是直接报 502/504 或前端 network error。排查时别只盯 access.log 里的 499。
