Nginx默认剥离Keep-Alive等hop-by-hop响应头，需用proxy_pass_header Keep-Alive;显式放行，或更优地配置proxy_http_version 1.1与upstream keepalive实现标准长连接。
为什么后端的 Keep-Alive 响应头在 Nginx 反向代理后消失了
Nginx 默认会清理上游响应中的 Connection、Keep-Alive 等 hop-by-hop 头部，这是 HTTP/1.1 协议规范要求的行为——这些头部只对单跳连接有效，不能透传。但某些老后端（如用 Python http.server、旧版 Tomcat 或自研 HTTP 服务）会依赖响应里的 Keep-Alive 头做客户端连接管理，一旦被 Nginx 剥离，客户端可能误判为短连接，频繁重连。
proxy_pass 后必须显式放行 Keep-Alive 响应头
默认情况下，Nginx 不允许透传 Keep-Alive 响应头，需用 proxy_pass_header 显式启用：
-
proxy_pass_header Keep-Alive;—— 必须加在location或server块内，仅对当前作用域生效 - 该指令只影响响应头，不影响请求头；若还需透传请求中的
Keep-Alive，要用proxy_set_header Connection "keep-alive";（不推荐，易与proxy_http_version 1.1冲突） - 注意：
proxy_pass_header在 Nginx 1.7.6+ 才支持，低于此版本需用more_set_headers（需安装headers-more-nginx-module）
更稳妥的做法是绕过 Keep-Alive 头，改用标准 HTTP/1.1 长连接机制
真正健壮的方案不是保留 Keep-Alive 头，而是让 Nginx 和后端都走标准 HTTP/1.1 长连接流程：
- 确保
upstream块中配置了keepalive 32;（连接池大小） - 在
location中设置：proxy_http_version 1.1;+proxy_set_header Connection ""; - 后端服务必须支持 HTTP/1.1 并正确处理
Connection: keep-alive请求头（现代框架默认支持） - 此时 Nginx 会复用 TCP 连接，根本不需要解析或透传
Keep-Alive响应头
验证是否生效的关键检查点
光看配置没用，得抓包或查日志确认实际行为：
- 用
curl -v http://your-nginx/api/test观察响应头里是否有Keep-Alive:字段（仅当你启用了proxy_pass_header时才应出现） - 更可靠的方式是用
tcpdump抓 Nginx 与后端之间的流量，过滤tcp[tcpflags] & (tcp-syn|tcp-fin) != 0，确认连接复用次数是否明显上升 - 检查 Nginx error log 是否有
upstream sent no valid HTTP/1.0 header类错误——这说明后端返回了 HTTP/1.0 响应，proxy_http_version 1.1就会失效
真正容易被忽略的是后端服务的协议协商能力：哪怕 Nginx 配了 HTTP/1.1，如果后端硬编码返回 HTTP/1.0 200 OK，连接照样无法复用。
