Nginx 默认剥离Connection和Keep-Alive头是设计行为，非bug；正确配置需三步协同：强制HTTP/1.1、清空Connection头（设为空字符串）、启用upstream keepalive连接池。

Nginx 默认会主动处理并剥离或重写与连接控制相关的请求头（尤其是 Connection 和 Keep-Alive），这不是 bug，而是设计行为——它要自主管理连接复用逻辑。所以“确保 Keep-Alive 参数不被后端覆盖”这个说法本身有偏差：后端并不依赖客户端传来的 Keep-Alive 头来决定是否复用连接；真正起作用的是 HTTP 协议版本 + Connection: keep-alive 响应头 + Nginx 的 upstream 连接池配置。

你要做的不是“保留原始 Keep-Alive 头”，而是让 Nginx 主动发出符合长连接语义的请求，并确保后端能正确响应。关键在于三点协同：协议升级、头部清理、连接池启用。

✅ 正确配置方式（避免被后端“覆盖”或忽略）

• 强制使用 HTTP/1.1
  后端只有在收到 HTTP/1.1 请求时，才可能开启长连接逻辑（HTTP/1.0 默认短连接）：

  proxy_http_version 1.1;

• 清空透传的 Connection 头
  客户端可能带 Connection: close 或其他值，若直接转发，后端会照单执行并关闭连接。必须显式清空：

  proxy_set_header Connection "";

  注意：不是设为 "keep-alive"，而是设为空字符串 "" —— 这表示由 Nginx 自主控制连接生命周期，不透传干扰。

  

  Nginx Hosting

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

  下载

• 禁用 Keep-Alive 请求头（无需设置）
  Keep-Alive 是 HTTP/1.0 的遗留头，现代 HTTP/1.1 不需要它。Nginx 作为代理不会生成该请求头，也不应手动添加：

  # ❌ 错误（多余且无效）
  proxy_set_header Keep-Alive "";
  
  # ✅ 正确：什么都不加，让 Nginx 按 HTTP/1.1 规则处理

⚠️ 常见误解与失效原因

• 后端返回 Connection: close，Nginx 就会立刻释放该连接，无法复用
  原因可能是：

  • 后端服务在错误响应、健康检查失败、WAF 干预或调试模式下主动返回 close
  • 后端配置了过短的空闲超时（如 Tomcat 的 connectionTimeout < Nginx keepalive_timeout）
  • 后端连接池已满，拒绝复用

• keepalive_timeout 和 keepalive_requests 只影响「客户端 → Nginx」，对 upstream 无效
  它们和后端是否复用连接完全无关。upstream 长连接的存活时间取决于后端自身配置（如 Tomcat 的 connectionTimeout）和 Nginx 的 upstream keepalive 设置。

• upstream 块中未配 keepalive N，即使写了 proxy_http_version 1.1，Nginx 仍用短连接
  因为默认行为是每次请求新建 TCP 连接，keepalive 才是启用连接池的开关。

? 验证是否真正生效

• 查看后端响应头是否含 Connection: keep-alive（非 close）
• 抓包观察：连续请求是否复用同一 TCP 连接（源/目的端口不变）
• 统计后端 ESTABLISHED 连接数是否稳定在 worker_processes × keepalive 附近（如 4 个 worker + keepalive 32 ≈ 128 个空闲连接）

不复杂但容易忽略。