least_conn对gRPC长连接失效，因其仅在TCP连接建立时选择后端，而gRPC基于HTTP/2复用单连接发送多stream，后续请求不触发重选，导致所有stream钉死同一后端，$upstream_addr固定、$connection_requests持续增长即为明证。
least_conn 对 gRPC 长连接根本不起作用，不是配置错了，是它压根没机会介入请求分发。
为什么 $upstream_addr 固定、$connection_requests 却一路狂涨
这是最直接的证据：Nginx 的 least_conn 只在 TCP 连接建立时选一次后端，而 gRPC 基于 HTTP/2 复用单连接发成百上千个 stream。后续所有 RPC 调用都走这个已建好的连接，$upstream_addr 不变、$connection_requests 持续递增，就说明流量被“钉死”在某个后端上。
排查时务必在 log_format 中加入这两个变量，用 access_log 实时观察同一客户端 IP 的多条日志——别只看健康检查或偶发请求。
- 若
$upstream_addr不变但$connection_requests从 1 → 87 → 152，确认是连接复用导致的负载倾斜 - 若
$upstream_addr随请求频繁变化，问题大概率不在 Nginx 层，而是客户端或上游路由逻辑 - 禁用
ip_hash或hash $remote_addr：它们会强制绑定，让least_conn彻底失效
grpc_pass 和 proxy_pass 绝对不能混用
Nginx 对 gRPC 的支持必须走原生 HTTP/2 路径，proxy_pass http://... 会降级为 HTTP/1.x 处理，导致 TLS 握手失败、HEADERS 帧丢失、流中断——此时你看到的“不均”，其实是部分请求根本没成功转发过去。
正确组合只有一种：upstream 块定义后端 + grpc_pass grpc://upstream_name（或 grpcs://）。
-
grpc://可省略协议前缀，但grpcs://必须显式写出，否则明文传输，后端拒绝 -
keepalive 32要配在upstream内，控制 Nginx 到后端的空闲连接池大小，避免连接风暴 - 别在
location里写proxy_set_header干预 HTTP/2 头，gRPC 流式语义依赖原始帧结构
Go 客户端默认 pick_first 是最大隐性瓶颈
即使 Nginx 配得再准，Go 客户端若没主动启用 DNS 解析器和 round_robin 策略，它只会取 DNS 解析出的第一个 IP 建连，其余后端节点全程闲置——这在 K8s Headless Service 场景下极其常见。
验证方式：进客户端 Pod 执行 dig +short my-svc.default.svc.cluster.local，确认返回多个 A 记录；再抓包看实际建连 IP 是否始终唯一。
- 必须显式使用
dns:///前缀：grpc.Dial("dns:///my-svc.default.svc.cluster.local:8080", ...) - 必须传入
grpc.WithResolvers(dns.NewBuilder())，否则 Go 默认不用 DNS 解析器 - 必须设置服务配置：
grpc.WithDefaultServiceConfig(`{"loadBalancingConfig": [{"round_robin": {}}]}`) - 别依赖
GRPC_GO_RETRY或重连参数掩盖问题，那是治标不治本
连接复用本身不是 bug，是设计使然
HTTP/2 复用连接是性能优化的核心机制，强行拆成短连接（比如用 keepalive_timeout 0）反而会放大三次握手开销，引发更严重的延迟抖动和 CPU 消耗。真正的均衡点不在“断连”，而在“如何让多个连接合理分布”——这需要客户端策略、DNS 行为、Nginx upstream 配置三者协同。
最容易被忽略的是：Nginx 的 least_conn 看的是它自己到后端的连接数，不是客户端到 Nginx 的连接数；而客户端到 Nginx 的连接复用，又受浏览器或 SDK 的 keep-alive 行为影响。这两层复用叠加，会让负载分布变得极难直观推断。
