Nginx 的 keepalive_timeout 需按移动端特性优化：API 服务设 15–25 秒，混合站点 5–10 秒，HTTP/2 可设为 0 或 5 秒，并配合 client_header_timeout（30s）和 send_timeout（60s）使用。
Nginx 的
对移动端连接有显著影响，但不能简单调大或调小——关键在于匹配移动网络的真实特性：高延迟、易中断、连接复用率低、后台进程常被系统回收。
移动端连接的实际行为与桌面不同
手机 App 或 H5 页面发起的请求，往往存在以下特点：
用户操作不连续，两次请求间隔可能长达几十秒甚至几分钟
弱网环境下 TCP 连接容易被中间设备（如基站、运营商 NAT）静默断开
App 切到后台后，系统可能主动关闭空闲 socket（iOS 尤其严格）
HTTP/1.1 复用效果有限，很多客户端默认不保持长连接，或只对同域名少量复用
keepalive_timeout 设置建议（非越长越好）
默认值（通常 60s）在移动端往往偏长，反而浪费 worker 进程资源。推荐按场景调整：
纯 API 接口服务（如 JSON-RPC、RESTful）：
15–25 秒
。足够覆盖多数 App 的短频请求间隙，又避免长时间占用连接
含静态资源（JS/CSS/图片）的混合站点：
5–10 秒
。移动端浏览器加载资源快，复用窗口期短，过长 keepalive 反而挤占新连接槽位
启用 HTTP/2 的服务：
可设为 0 或极短（如 5s）
。HTTP/2 本身支持多路复用，连接生命周期由客户端控制更合理，Nginx 不必强留
必须配合 client_header_timeout 和 send_timeout 使用
只控制“空闲连接等待下一个请求”的时长，而移动端更常见的是：
请求头迟迟发不完（弱网上传慢）→ 需调大
（建议 30s）
响应体下发卡顿（如动态生成大图）→ 需调大
（建议 60s）
单独调高
却忽略这两项，会导致连接在传输中途被误杀
验证是否生效的小技巧
不要只看配置文件，实际观察比设置更重要：
用
查看 ESTAB 状态连接数，高峰期若持续 > 1000，说明 keepalive 滞留过多
抓包看移动端请求的
和
响应头，确认 Nginx 是否正确透出
结合 access_log 中的
和
，识别大量 “快请求+长空闲” 模式，再针对性优化
不复杂但容易忽略：移动端优化不是堆参数，而是让 Nginx 的连接管理节奏贴合真实终端的行为逻辑。
keepalive_timeoutkeepalive_timeoutclient_header_timeoutsend_timeoutkeepalive_timeoutss -tn | grep :443 | wc -lConnection: keep-aliveKeep-Alive: timeout=xx$request_time$upstream_response_time