Nginx七层代理gRPC负载不均排查

本文深入剖析了Nginx七层代理gRPC时负载严重不均的根本原因：并非配置失误，而是least_conn等传统负载均衡策略在HTTP/2长连接复用场景下天然失效——它仅在TCP建连时选择后端，而gRPC的海量stream全复用同一连接，导致流量被“钉死”；同时指出问题常被误判，需结合$upstream_addr和$connection_requests日志精准识别，并强调必须严格使用grpc_pass+grpcs://、禁用ip_hash、配齐upstream keepalive，更关键的是Go客户端必须显式启用DNS解析器与round_robin策略，否则再完美的Nginx配置也形同虚设——真正的负载均衡是客户端、DNS、Nginx三层协同的结果，而非单点优化。

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 行为影响。这两层复用叠加，会让负载分布变得极难直观推断。

好了，本文到此结束，带大家了解了《Nginx七层代理gRPC负载不均排查》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！