移动端连接问题关键在匹配真实空闲节奏而非单纯延长keepalive_timeout：API服务设15–25秒，H5页面设5–10秒，HTTP/2可设0或5秒，并同步调整client_header_timeout（30秒）和send_timeout（60秒）。
移动端请求频繁建连、延迟升高，往往不是因为 keepalive_timeout 太长，而是设得太短——但关键不在“加长”，而在“匹配真实空闲节奏”。默认 60 秒在桌面端合理，在手机上却常造成两种反效果：要么连接刚复用几秒就被 Nginx 主动关掉（keepalive_timeout 过短），要么空等几十秒没人用还占着资源（设太长又浪费）。真正要解决的是“断得早”和“留得久”的矛盾。
识别是否真是 keepalive_timeout 过短导致的问题
别只看配置文件。先验证现象：
- 用
ss -tn | grep :443 | grep ESTAB | wc -l查高峰期活跃连接数，若持续低于 200 且$request_time中大量请求upstream_response_time很短（如 <50ms）但总耗时高（>300ms），说明很多时间花在建连上 - 抓包看响应头是否有
Keep-Alive: timeout=5或更低——这代表 Nginx 正在强制快速关闭连接 - 对比同一接口在 Wi-Fi 和 4G/5G 下的复用率：弱网下客户端更倾向新建连接，若此时
keepalive_timeout还设成 5 秒，等于主动放弃复用机会
按业务类型调整 keepalive_timeout 的推荐值
移动端没有统一最优值，必须分场景：
- 纯 API 接口服务（App 后端、小程序调用）：设为 15–25 秒。覆盖典型操作间隙（如列表页滑到底触发下一页，间隔约 8–15 秒），又避免在用户切后台后仍空占连接
- 混合型 H5 页面（含 JS/CSS/图片）：设为 5–10 秒。页面加载快，资源请求密集但窗口期短；过长反而挤占新连接槽位，尤其当 worker_connections 有限时
- 启用 HTTP/2 的服务：可设为 0 或 5 秒。HTTP/2 天然支持多路复用，连接生命周期由客户端主导，Nginx 不必强留
必须同步调整的两个配套参数
keepalive_timeout 单独调大或调小都无效，它只管“空闲等待”，而移动端卡顿常发生在其他环节：
-
client_header_timeout：建议设为 30 秒。弱网下 App 上传请求头（如带大 token 的 Authorization）可能超时，Nginx 若按默认 60 秒等，实际早已被中间设备切断；设为 30 秒更贴近运营商 NAT 的宽容窗口 -
send_timeout：建议设为 60 秒。动态接口返回大 JSON 或生成报表时易卡在响应下发阶段，此超时控制“发一半停住”的连接释放时机，避免挂起阻塞
检查并绕过客户端与中间链路干扰
即使 Nginx 设了 20 秒，客户端也可能提前断开：
- iOS 系统在 App 切后台 10 秒内会回收 socket，再长的
keepalive_timeout也无意义；此时应配合客户端做轻量心跳（如每 15 秒发个空 GET），而非依赖长空闲 - 某些 WAF 或 CDN 会重写
Connection响应头，导致浏览器误判不支持复用；用curl -v检查响应中是否含Connection: keep-alive和正确Keep-Alive头 - 确认没开启
keepalive_disable（如msie6规则误匹配现代 UA），该指令会直接忽略keepalive_timeout
不复杂但容易忽略：移动端优化不是堆参数，而是让 Nginx 的连接管理节奏贴合真实终端的行为逻辑。
