nginx意外返回connection: close通常源于upstream主动关闭或自身异常降级。需检查后端响应头、连接完整性、超时设置及http版本，并通过proxy_http_version 1.1、proxy_set_header connection ''等配置强制保持长连接。
当 Nginx 本应返回 Connection: keep-alive 却意外返回 Connection: close，会导致客户端（如浏览器、HTTP 客户端库）无法复用连接，引发额外握手开销、延迟上升甚至请求失败。这通常不是配置显式设置的结果，而是由隐式条件触发的“被动关闭”行为。
检查 upstream 服务是否主动关闭连接
Nginx 默认遵循上游响应：如果后端（如 FastAPI、Node.js、Tomcat）在响应头中明确写了 Connection: close，或响应体发送完毕后直接断开 TCP 连接（未保持 keep-alive），Nginx 会继承该行为，并可能向客户端也返回 Connection: close（尤其在 HTTP/1.0 或协议协商不充分时）。
- 用
curl -v http://your-domain/查看原始响应头，确认Connection字段来源是 upstream 还是 Nginx 自己加的 - 直接访问 upstream（绕过 Nginx），比如
curl -v http://127.0.0.1:8000/，对比响应头差异 - 检查后端是否设置了
Connection: close响应头，或是否禁用了 keep-alive（如某些调试模式、健康检查接口默认短连接）
确认 Nginx 是否因错误或超时主动降级为 close
Nginx 在遇到某些异常情况时，会放弃长连接——即使配置了 keepalive，也会在响应中注入 Connection: close：
-
upstream 超时：如
proxy_read_timeout触发，Nginx 中断读取并关闭连接，响应头自动设为close -
响应体不完整：后端提前断连、写入不全、或返回了
Content-Length但实际字节数不符，Nginx 检测到后终止连接 -
HTTP 版本降级：客户端使用 HTTP/1.0 请求（无
Connection: keep-alive头），Nginx 默认按 HTTP/1.0 处理，响应不带keep-alive -
错误页响应：Nginx 自生成的 502/504 等错误页默认不启用 keep-alive，响应头固定为
Connection: close
验证并强制保持 keep-alive 的关键配置
以下配置可增强长连接稳定性，但需配合 upstream 支持：
- 在
location或server块中显式开启：proxy_http_version 1.1;<br>proxy_set_header Connection '';
（清空来自客户端的 Connection 头，避免传递close） - 启用 upstream keepalive 连接池：
upstream backend {<br> server 127.0.0.1:8000;<br> keepalive 32;<br>}
并在 location 中添加：proxy_http_version 1.1;<br>proxy_set_header Connection '';<br>proxy_set_header Upgrade $http_upgrade;
- 确保客户端请求带有
Connection: keep-alive（HTTP/1.1 默认隐含，但某些工具或旧客户端需显式设置）
快速定位是否为 Nginx 注入的 close
启用 Nginx debug 日志可精准判断 Connection 头生成时机：
- 临时在
nginx.conf的http或server块中添加：error_log /var/log/nginx/debug.log debug; - 重启 Nginx 并复现请求，搜索日志中的
"Connection: close"和"keepalive"相关行 - 关注类似
http proxy header: "Connection: close"或upstream sent no keepalive的提示
