Nginx服务静态资源时，关键在于正确配置keepalive_timeout和keepalive_requests以复用浏览器与Nginx间的TCP连接；需启用sendfile和tcp_nopush，避免误配proxy相关指令，并确保location精确匹配、gzip_vary开启，HTTP/2下仍建议保留keepalive配置。
Nginx 服务静态资源时，默认已启用客户端长连接，但要真正降低延迟、提升并发性能，关键不是“开启”，而是合理配置并避免干扰项——尤其是不能把客户端长连接和后端长连接混淆。
静态资源场景下 keepalive 的核心逻辑
静态资源（如 .js、.css、.png）由 Nginx 直接提供，不经过 proxy_pass，所以不涉及 upstream 或后端连接复用。此时的“持久化”只发生在 浏览器 ↔ Nginx 这一层，目标是复用 TCP 连接，减少重复握手开销。
-
keepalive_timeout控制空闲连接保持时间 -
keepalive_requests控制单连接最大请求数 - 这两个参数必须放在
http或server块中，对静态服务直接生效
如何配置更有效的静态连接复用
-
keepalive_timeout 30s 30s;
第一个30s是 Nginx 等待下一个请求的超时；第二个30s会写入响应头Keep-Alive: timeout=30，提示浏览器别提前断连 -
keepalive_requests 1000;
默认 100 太保守，一次页面加载常含 20–50 个静态资源，设为 500–2000 更匹配实际链路（如 React SPA 一次首屏可能触发 80+ 请求） - 确保
sendfile on;和tcp_nopush on;已启用
这能减少系统调用和小包发送，配合长连接进一步降低延迟 - 不要设置
proxy_http_version或proxy_set_header Connection
这些只用于反向代理场景，静态服务中加了不仅无效，还可能引发配置警告
常见干扰项与规避方式
- 若用了
location ~ \.php$ { ... }类动态路由，但静态资源误匹配到 proxy 块，会导致 Nginx 降级为短连接转发 → 检查location优先级，用精确匹配location = /favicon.ico或前缀匹配location /static/明确分流 - 启用了
gzip off;或gzip_vary off;可能导致响应头缺失Vary: Accept-Encoding，部分 CDN 或浏览器缓存策略会拒绝复用连接 → 建议保持 gzip 开启且gzip_vary on; - HTTP/2 已启用时，
keepalive_timeout实际影响变小（HTTP/2 天然复用连接），但仍建议保留，兼容 HTTP/1.1 客户端
验证是否生效
- 浏览器开发者工具 → Network → 查看某
.js请求的Connection响应头是否为keep-alive - 执行
ss -tan | grep :443 | grep ESTAB | wc -l（HTTPS 端口）或:80，压测期间连接数应平稳，而非随请求数线性飙升 - 观察 Chrome 的 “Connection ID” 列：同一连接 ID 多次复用，说明成功
不复杂但容易忽略，关键是静下心区分清楚：静态服务只管自己和客户端的连接，不用操心 upstream、keepalive 指令或 Connection 头透传。
