移动端连接问题关键在匹配真实空闲节奏而非单纯延长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 很短（如 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 的连接管理节奏贴合真实终端的行为逻辑。