关键不是把keepalive_timeout调大，而是让它比移动端真实空闲断连时间略短5–10秒；android okhttp实测常45–90秒断连，ios前台2–3分钟、后台60秒内回收，api服务建议15–25秒，混合h5设5–10秒，http/2可设0或5秒，并需同步调优client_header_timeout（30秒）和send_timeout（60秒）。
关键不是把 keepalive_timeout 调大，而是让它比移动端真实空闲断连时间略短 5–10 秒。弱网下重连率高，往往不是连接“没保持住”，而是 Nginx 还在等一个永远不会来的请求，而客户端早已被系统或中间设备静默关闭。
匹配主流移动端客户端的实际保活窗口
不同客户端对 keep-alive 的实际坚持时间差异很大：
- Android OkHttp 默认约 5 分钟（300 秒），但受系统 TCP keepalive 和运营商 NAT 影响，实测常在 45–90 秒内被切断
- iOS NSURLSession 更激进，后台常在 60 秒内回收连接，前台也多在 2–3 分钟内失效
- 很多 App 自研网络层会主动设为 30–60 秒保活，尤其弱网策略开启后会进一步缩短
- 浏览器（Chrome/Firefox）虽标称 5–10 分钟，但 H5 页面切换标签、锁屏、切后台后实际复用率极低
建议：用抓包工具（如 Charles 或手机端 tcpdump）观察 App 发出的请求中 Connection: keep-alive 是否持续存在，并检查响应头是否返回 Keep-Alive: timeout=xx；若超时值长期稳定在 48 秒左右，keepalive_timeout 就设为 38 秒。
按业务类型分场景设置，避免一刀切
统一设 60 秒或 30 秒，在移动端反而容易放大问题：
- 纯 API 接口服务（如登录、下单、上报）：设为 15–25 秒。App 批量请求后常进入长休眠，长连接空转浪费 worker 连接槽位
- 含图片/JS/CSS 的混合 H5 页面：设为 5–10 秒。资源加载快、复用窗口短，过长会挤占新连接资源
- 启用 HTTP/2 的网关：可设为 0 或 5 秒。HTTP/2 多路复用不依赖单连接长存，Nginx 强留无意义
必须同步调优配套超时参数
keepalive_timeout 只管“空闲等待”，而弱网下的失败常发生在传输过程中：
-
弱网上传慢 → 请求头发不完：增大
client_header_timeout至 30 秒，避免上传卡顿被误判为连接异常 -
动态接口响应慢 → 响应体下发中断：增大
send_timeout至 60 秒，防止大图生成或聚合查询中途断连 -
后端不稳定 → upstream 提前关闭：若日志频繁出现
upstream prematurely closed connection，需检查上游（如 PHP-FPM、Tomcat）的超时是否比 Nginx 的keepalive_timeout更短，确保两端对齐
验证是否真正起效
不要只改配置，要观察真实行为：
- 用
ss -tn | grep :443 | grep ESTAB | wc -l查看高峰期 ESTABLISHED 连接数。若持续 > 800，说明空闲连接滞留过多，keepalive_timeout仍偏大 - 在 access_log 中加入
$request_time和$upstream_response_time，筛选出request_time > 1000ms && upstream_response_time 的请求——这类“快响应 + 长空闲”正是重连主因，针对性调低该类 location 的 <code>keepalive_timeout - 对比优化前后客户端错误日志：重点关注
SocketException: Connection reset、ECONNRESET和重试次数统计，下降 30% 以上即为有效
