SPA首屏加载依赖HTTP/1.1连接复用，需合理设置keepalive_timeout（推荐10～25秒），避免默认值导致“半死”连接占用资源，同时须配合keepalive_requests、proxy_http_version 1.1及Keep-Alive响应头协同优化。
对现代 SPA（如 React、Vue 构建的前端应用），keepalive_timeout 应设为 10～25 秒，并需配合客户端行为、资源加载模式与反向代理链路协同调整，而非孤立设值。
为什么 SPA 特别依赖合理 keepalive_timeout
SPA 首屏加载时通常在几秒内并发发起 10–30+ 个请求（HTML、JS、CSS、字体、图标等），全部走同一域名，高度依赖 HTTP/1.1 连接复用。但加载完成后，连接常进入长时间空闲状态——浏览器不会主动关闭，而中间网络设备（运营商 NAT、企业防火墙）可能在 30–60 秒内静默中断连接。若 Nginx keepalive_timeout 设为默认 75 秒，大量连接会滞留为“半死”状态，占用 worker 进程内存和 fd，却无法被复用。
推荐配置值与依据
- 主站静态资源（/、/static/、/assets/ 等）：设为 15 秒。覆盖绝大多数 SPA 首屏资源加载窗口（通常 ≤ 3 秒），又留出约 12 秒缓冲应对弱网重试或懒加载资源；
- API 接口路径（如 /api/、/graphql）：单独在 location 块中设为 8～12 秒。SPA 的 API 调用更离散、间隔长，且常受移动端心跳/推送干扰，过长 timeout 易积累无效连接；
- 避免使用 0 或 60+ 秒：设为 0 会强制禁用 keepalive，导致首屏每个资源都新建 TCP 连接，HTTPS 场景下 TLS 握手开销陡增；设为 60 秒以上，与多数浏览器实际 keep-alive 行为（Chrome/Firefox 通常 5–10 秒后主动发 FIN）及云厂商 LB 超时（如 AWS ALB 默认 60 秒，Azure LB 常为 4 分钟但含探测延迟）不匹配，易引发 RST 或超时重传。
必须同步配置的三项关键配套
- keepalive_requests 设为 100～300：防止单个连接因异常请求（如大文件断点续传、错误重试）无限累积，也避免设为过低（如 10）导致连接未空闲就提前断开，削弱复用效果；
-
location 块内显式启用 HTTP/1.1 协议协商：添加
proxy_http_version 1.1;和proxy_set_header Connection '';（若为反向代理 SPA 后端）； -
响应头中声明一致 timeout：使用双参数写法
keepalive_timeout 15 15;，让Keep-Alive: timeout=15准确告知浏览器服务端策略，提升两端协同效率。
上线前验证要点
- 用
ss -tn state established | grep :443 | wc -l对比压测前后 ESTABLISHED 连接数增幅，理想情况应比默认值下降 30%–50%； - 检查 Nginx 日志中
$connection_requests字段：若大量连接只处理 1–2 个请求即关闭，说明 timeout 过短或客户端未复用；若平均 > 50 且 Waiting 状态持续高企，说明 timeout 过长； - 在 Chrome DevTools → Network → 右键表头勾选 “Connection ID”，观察同域名下多个资源是否共享相同 connection ID，确认复用生效。
