nginx后端长连接不会自动生效，仅配keepalive 32无效；必须同时满足三项：upstream块内写keepalive n、location中设proxy_http_version 1.1、且加proxy_set_header connection ""，缺一不可。
Nginx 后端长连接不会自动生效，只配 keepalive 32 是无效的；必须同时满足三项：upstream 块内写 keepalive N、location 中设 proxy_http_version 1.1、且加 proxy_set_header Connection ""，缺一不可。
upstream keepalive 必须写在正确位置
很多人把 keepalive 32 放在 server 或 location 块里，Nginx 直接报错：unknown directive "keepalive"。它只能出现在 upstream 块内部，且该块必须定义在 http 块下，不能嵌套。
-
upstream块外写keepalive→ 语法错误，启动失败 - 一个
upstream组里只能有一个keepalive指令，重复写会报错 -
keepalive 32表示：每个 worker 进程对组内**每台后端服务器**最多缓存 32 个空闲连接；若你有 4 个 worker、2 台后端，理论最大空闲连接数是 4 × 2 × 32 = 256
proxy_http_version 和 proxy_set_header Connection 必须成对出现
只开 keepalive 不设协议和头，Nginx 默认用 HTTP/1.0 转发，后端收到请求后立刻关闭连接，长连接形同虚设。
-
proxy_http_version 1.1：强制使用 HTTP/1.1 协议，这是长连接语义的前提 -
proxy_set_header Connection ""：清空客户端传来的Connection: close或其他值，否则 Nginx 会透传，导致后端误判为短连接 - 不需要、也不应该写
proxy_set_header Keep-Alive—— 这是客户端行为，Nginx 作为代理不生成该头
keepalive_timeout 和 keepalive_requests 容易被误用
这两个参数从 Nginx 1.15.3+ 才支持作用于 upstream 长连接池；老版本（如 1.12）只认 keepalive，设了也无效。它们控制的是「空闲连接池中连接的生命周期」，不是客户端连接。
-
keepalive_timeout 30s：池中空闲连接最长存活 30 秒，超时即关闭；建议设为比后端服务空闲超时（如 Tomcat 的connectionTimeout）小 5–10 秒 -
keepalive_requests 500：单个空闲连接最多转发 500 次请求后强制关闭，防后端状态泄漏；默认 100 太保守，API 场景可设 500–1000 -
keepalive_timeout和keepalive_requests对「浏览器 → Nginx」这段完全无影响 —— 那段由http块下的同名参数控制
后端服务配置必须匹配，否则复用失败
即使 Nginx 配全了，后端拒绝复用也会让连接池失效。典型现象是 error log 出现 upstream prematurely closed connection 或 upstream keepalive connection failed。
- Go 服务默认
http.Server.MaxIdleConnsPerHost = 2，Nginx 设keepalive 32就连不上；需显式调大 - Tomcat 要检查
maxConnections和connectionTimeout，前者决定能接受多少并发连接，后者决定空闲连接保留多久 - Node.js http.Server 默认不限连接，但过大的
keepalive值可能耗尽其文件描述符，触发EMFILE - 后端返回响应头含
Connection: close（常见于 5xx 错误、调试开关开启、WAF 干预），Nginx 会立即释放该连接，无法复用
真正有效的长连接优化，不是堆参数，而是让 Nginx 连接池、HTTP 协议行为、后端服务空闲策略三者对齐；漏掉任意一环，ss -tan | grep :8080 | grep ESTAB 看到的都是持续上涨的连接数，而不是稳定在预期值附近。
