Nginx后端长连接必须同时满足三项：upstream块内配置keepalive N、location中设置proxy_http_version 1.1和proxy_set_header Connection ""；keepalive仅允许出现在http块下的upstream块内，且每组仅能有一个，表示每个worker进程对单台后端最多缓存N个空闲连接。
只配 keepalive 32 不生效，Nginx 到后端的连接仍是短连接；必须同时满足三项：upstream 块内写 keepalive N、location 中设 proxy_http_version 1.1、且加 proxy_set_header Connection ""。
upstream 块里怎么写 keepalive 才合法
keepalive 指令只能出现在 upstream 块内部，且该块必须定义在 http 块下——不能塞进 server 或 location 里，否则 Nginx 启动直接报错：unknown directive "keepalive"。
- 正确位置示例：
http { upstream backend { server 192.168.1.10:8080; keepalive 32; # ✅ 只能放这里 } } - 每个 upstream 组只允许一个
keepalive指令，重复写会启动失败 -
keepalive 32表示：每个 worker 进程对这台后端最多缓存 32 个空闲连接；若你有 4 个 worker、2 台后端，理论最大空闲连接数是4 × 2 × 32 = 256 - 初始值建议按
(预估峰值并发 / worker_processes) × 1.2计算，设太小会导致连接池打满，新请求被迫新建连接
location 里必须配齐的两个 proxy 指令
只开 keepalive 不设协议和头，Nginx 默认用 HTTP/1.0 转发，后端收到就关连接，长连接形同虚设。
-
proxy_http_version 1.1：强制走 HTTP/1.1，这是 Keep-Alive 语义的前提 -
proxy_set_header Connection ""：注意是空字符串，不是"keep-alive"；填非空值可能被后端误解为要关闭连接 - 这两行必须成对出现，缺一不可，且必须写在
location块里（不能写在server或http） - 不需要、也不应该写
proxy_set_header Keep-Alive——那是客户端行为，Nginx 作为代理不生成该头
keepalive_timeout 和 keepalive_requests 容易误用
这两个参数在老版本 Nginx（如 1.12）中对 upstream 完全无效；从 1.15.3+ 才支持作用于 upstream 长连接池，但很多人仍拿它们当 client 连接参数用。
-
keepalive_timeout 30s：控制 upstream 空闲连接池中连接最长存活 30 秒，超时即关闭；建议设为比后端服务空闲超时（如 Tomcat 的connectionTimeout）小 5–10 秒 -
keepalive_requests 500：单个空闲连接最多转发 500 次请求后强制关闭，防后端状态泄漏；默认 100 太保守，API 场景可设 500–1000 - 它们对「浏览器 → Nginx」这段完全无影响——那段由
http块下的同名参数控制 - 漏掉
keepalive_requests是常见误操作：只调了超时，结果连接刚复用几次就被强制断开
后端服务不配合，Nginx 配再全也没用
即使 Nginx 三要素全齐，后端拒绝复用连接，连接池照样失效。典型现象是 error log 出现 upstream prematurely closed connection 或连接数始终不降。
- Node.js（原生
http.Server）：默认支持 HTTP/1.1 长连接，但需确认没手动调用res.end()后又忽略后续请求 - Tomcat：检查
server.xml中 connector 的connectionTimeout和keepAliveTimeout是否合理 - Go（net/http）：默认开启长连接，但若 handler 中显式写了
w.Header().Set("Connection", "close")就会破坏复用 - 关键验证点：用
curl -v http://backend-url看响应头是否含Connection: keep-alive
最容易被忽略的是：upstream 的 keepalive 是 per-worker + per-backend 的连接池大小，不是全局连接数；设小了压根撑不住并发，设大了又白白占资源——得结合实际 worker 数、后端实例数、QPS 分布来算，不能拍脑袋填 32 或 1024。
