HTML无法控制Keep-Alive，其由HTTP头部协商；Firefox需手动配置about:config参数并重启生效；Nginx需匹配keepalive_timeout等设置；预加载、IPv6、ETP等会干扰连接复用。
HTML 本身不控制 Keep-Alive，这是 HTTP 协议层的事
直接在 HTML 文件里写 <meta> 或 JS 脚本无法开启、维持或配置 HTTP Keep-Alive。Keep-Alive 是客户端（浏览器）与服务器之间通过 HTTP 头部协商的连接复用机制，发生在 TCP 连接建立之后、HTTP 请求发出之前。HTML 只是被传输的资源内容，它不参与连接生命周期管理。
常见误解是以为加个 <meta http-equiv="Connection" content="keep-alive"> 就能生效——这完全无效，http-equiv 不支持 Connection 这类 hop-by-hop 头部，浏览器会忽略。
浏览器端真正起作用的 Keep-Alive 配置都在 about:config
火狐浏览器（Firefox）对长连接的实际控制力远超其他浏览器，但必须手动调整底层参数。这些设置直接影响 TCP 连接复用率、空闲保活时长和并发上限：
-
network.http.keep-alive必须为 true（默认已是 true，但某些企业策略可能覆盖） -
network.http.max-persistent-connections-per-server建议设为10（Chrome 默认是 6，火狐默认 6，提高到 10 可缓解同源资源加载瓶颈） -
network.http.keepalive.timeout设为60（单位秒，控制浏览器主动关闭空闲连接前的等待时间） -
network.http.tcp_keepalive.interval设为60（TCP 层探测间隔，防 NAT/防火墙断连） -
network.http.http2.enabled确保为 true；network.http.http3.enabled和network.http.http3.alternative-services均设为 false（HTTP/3 在部分网络下 QUIC 连接不稳定，易导致“假断流”）
改完需重启浏览器才生效。验证方式：打开开发者工具 → Network 标签页 → 看任意请求的 Connection 响应头是否为 keep-alive，且多个请求的 Remote Address 列显示相同 IP:Port。
立即学习“前端免费学习笔记（深入）”；
服务端 Keep-Alive 参数必须与客户端匹配
即使浏览器全力复用连接，服务端若过早关闭，效果归零。Nginx 典型配置：
http {
keepalive_timeout 60s; # 与浏览器 network.http.keepalive.timeout 对齐
keepalive_requests 1000; # 避免单连接处理过多请求导致内存泄漏
}关键点：
- 超时时间建议设为
60，而非默认75或更长——太长会堆积大量空闲连接，耗尽服务器文件描述符 -
keepalive_requests不宜设为 0（无限）或过小（如 10），1000 是兼顾复用率与安全的常见值 - 若用 Node.js（如 Express），需显式启用：
app.set('trust proxy', true)并确保反向代理（如 Nginx）透传Connection头，否则中间层可能切断 Keep-Alive
容易被忽略的干扰项：预加载、IPv6、增强跟踪保护
这些功能看似无关，实则会悄悄破坏 Keep-Alive 的稳定性：
-
network.prefetch-next设为 false：预加载新页面会新建连接，干扰主页面的连接复用池 -
network.dns.disableIPv6设为 true（仅当内网无 IPv6 支持时）：IPv6 DNS 解析失败可能导致连接 fallback 延迟，触发重试并新建连接 - 地址栏锁形图标 → “连接设置” → 关闭 HTTPS-Only 模式（诊断期临时操作）：该模式强制跳转可能引入额外 302，打断原连接流程
- 增强型跟踪保护（ETP）设为标准或关闭：部分 ETP 规则会拦截资源请求，导致连接空闲超时后被回收
所有改动后务必用 curl -I http://yoursite.com 检查响应头是否含 Connection: keep-alive，再结合浏览器 Network 面板观察连接复用情况——真实连接行为永远比配置文件更诚实。
