65秒是兼顾主流浏览器兼容性与中间设备容忍度的稳妥取值；它略低于默认75秒，预留5–10秒缓冲以避免被CDN或网关提前关闭，且与Firefox内核TCP keepalive不冲突，实测在Chrome、Safari及弱网环境下复用更稳定。
keepalive_timeout 65s 是一个贴近主流浏览器默认行为的合理取值，它不是“强制匹配”，而是与多数现代浏览器在 HTTP/1.1 长连接上的空闲容忍策略基本对齐。
主流浏览器的 Keep-Alive 空闲超时范围
Chrome、Edge、Firefox 和 Safari 在 HTTP/1.1 下默认启用 Keep-Alive，但它们自身不主动断连，而是依赖服务端发送的 Keep-Alive: timeout=XX 响应头，或根据 TCP 层行为被动响应。实际观察表明：
- Chrome 和 Edge 通常能稳定复用空闲 60–75 秒的连接，超过约 90 秒后可能触发重连试探
- Firefox 默认
network.http.keep-alive.timeout为 5 分钟（300s），但实际复用倾向受服务端 header 影响更大；若 Nginx 返回Keep-Alive: timeout=65，Firefox 多数场景会尊重该值 - Safari 对服务端 timeout 值较敏感，65s 能覆盖其常见空闲窗口（实测 45–70 秒间复用率最高）
为什么 65s 比默认 75s 更稳妥
75s 是 Nginx 多个版本的默认值，但部分 CDN 或中间代理（如旧版 Cloudflare、某些企业网关）会截断或重写 Keep-Alive 头，或自身设更短的 idle timeout（常见为 60s）。设为 65s 可：
- 留出 5–10 秒缓冲，避免被中间设备抢先关闭
- 与 Firefox 的
tcp_keepalive.idle_time=300不冲突——因为那是内核级 TCP keepalive，作用于传输层，而 HTTP keep-alive 是应用层协商，二者并行不矛盾 - 减少因微小网络抖动导致的连接重建，尤其在移动端弱网环境下更稳定
需同步检查的关键点
仅设 keepalive_timeout 65; 不足以确保匹配，还需确认：
- 响应中确实出现
Connection: keep-alive，且未被 upstream 或 proxy_pass 覆盖 - 未在 location 中误配
keepalive_disable msie6;等规则（IE6 已淘汰，该配置反而可能干扰现代 UA 解析） - 客户端发起请求时带了
Connection: keep-alive（HTTP/1.1 默认隐含，无需额外加） - 未启用
send_timeout或proxy_read_timeout等更短的超时指令，造成连接提前中断
验证是否真正生效
用 curl 直接观测响应头最直接：
curl -I https://yoursite.com | grep -i "keep-alive\|connection"
理想输出应包含：
Connection: keep-alive
Keep-Alive: timeout=65
再配合 ss -tan | grep :443 | grep ESTAB | wc -l 观察活跃长连接数变化趋势，若在无请求时段 65 秒后明显回落，说明策略已起效。
