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 连接，减少重复握手开销。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 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 头透传。