keepalive_timeout 设得过长会导致 Nginx 日志频繁出现 "client closed connection" 和 499 状态码，表明客户端在响应完成前主动断连；需结合日志上下文、接口特征、客户端行为实测调优，设为比最短客户端超时少 5–10 秒，并验证生效。
看日志上下文，确认是不是真“过早断开”
别只扫一眼 499 或 "client closed connection" 就下结论。重点查三类线索：
- 该错误前是否刚返回过 200 响应？如果是，说明客户端已用完这次连接、自行关闭，而 Nginx 还在空等下一个请求——这恰恰是 keepalive_timeout 太长 的信号
- 错误是否集中在特定接口（如 /health、/api/v1/status）或弱网用户（如移动端 App）？这类场景下客户端保活时间往往很短，Nginx 却还守着连接
- 是否同时出现 upstream prematurely closed connection 或大量 502/504？那可能是后端先断了，但 Nginx 的 keepalive_timeout 没同步调低，造成“空等假连接”
测客户端真实保活行为，别猜默认值
浏览器、App SDK、HTTP 客户端库的保活逻辑差异很大，不能依赖文档写的“默认 5 分钟”：
- Android OkHttp 默认 keep-alive 超时约 5 分钟，但很多 App 会显式设为 30–60 秒
- iOS NSURLSession 实际生效值常在 45–60 秒左右，受系统策略影响大
- 前端 SPA 的轮询请求（如每 10 秒一次）若没取消上一个请求，可能让连接一直被“假占用”，直到超时才释放
- Postman、curl 等工具默认不发 Keep-Alive 头，或直接带 Connection: close，根本不会复用连接
建议：用真实终端（比如某款 App）发起请求，抓包看 FIN 包谁先发；如果总是客户端先发 FIN，而 Nginx 日志报 “client closed”，就说明它该更快放手。
设值原则：比最短客户端超时少 5–10 秒
不是越长越好，也不是统一设 60 秒。关键是留出安全余量：
- 实测发现某 App 平均 48 秒断连 → keepalive_timeout 设为 38s
- 健康检查接口每 5 秒一次 → 设 15–20s，确保至少能撑过 2–3 次探针
- 微服务间 gRPC/HTTP/2 调用 → 可放宽至 30–60s，因帧复用效率高
- 纯 API 网关或弱网环境为主 → 优先选 5–15s，宁可多建几次连，也不让连接空挂
配完要验证，别只改不动
改完配置不是终点，得看效果：
- 用
ss -tnp | grep :443 | grep ESTAB | wc -l查当前活跃连接数；压测时若远高于并发请求数，说明连接堆积，timeout 偏大 - 开启
stub_status，重点关注 Waiting 连接数：长期高企 + 频繁 client closed = timeout 过长 - 检查响应头是否有
Keep-Alive: timeout=XX，确认配置已生效（注意第二个参数才是写入响应头的值）
