应改用Nginx原生主动健康检查，或单独拦截心跳路径（如/location /health{return 200;}），或确保心跳为短连接（响应头加Connection: close），以避免干扰least_conn连接统计。
在 Nginx 中使用 least_conn 负载均衡策略时，如果上游服务频繁发送健康检查心跳请求（如 /health、/ping），这些请求也会被计入连接数统计，导致真实业务连接数被稀释，削弱 least_conn 的调度准确性。要让 least_conn “忽略”这类心跳请求的干扰，核心思路不是真正忽略请求，而是**避免将心跳请求转发给后端，或确保它们不建立长连接、不占用连接计数**。
1. 将健康检查改为 Nginx 原生主动健康检查（推荐）
最干净的解法是：**不再依赖后端主动发起的心跳请求，改用 Nginx 自身的 health_check 指令做 TCP 或 HTTP 主动探活**。这样心跳完全由 Nginx 内部完成，不经过 upstream 流程，自然不影响 least_conn 的连接统计。
示例配置：
upstream backend {
least_conn;
# 使用 Nginx 主动健康检查（不走业务请求路径）
server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
<pre class="brush:php;toolbar:false;"># 启用 HTTP 主动健康检查（每 5 秒 GET /health，2xx/3xx 视为健康）
health_check interval=5 fails=3 passes=2 uri=/health match=health_ok;}
match health_ok { status 200; header Content-Type = "application/json"; body ~ '"status"\s:\s*"up"'; }
✅ 优势：心跳与业务流量彻底分离；✅ 不增加后端连接负载；✅ least_conn 统计只反映真实业务连接。
2. 对心跳请求单独路由，不走 least_conn upstream
如果必须保留后端主动心跳（例如用于外部监控），可将心跳路径（如 /health）在 location 中单独拦截，直接返回或转发到固定节点（甚至 mock），**绕过 upstream 块和 least_conn 调度逻辑**。
示例：
server {
location /health {
# 直接返回，不进入 upstream
return 200 '{"status":"ok","nginx":"healthy"}';
add_header Content-Type application/json;
}
<pre class="brush:php;toolbar:false;">location / {
proxy_pass http://backend; # 这里才走 least_conn upstream
proxy_set_header Host $host;
}}
⚠️ 注意：确保心跳路径不匹配到其他 location（如 location /），否则仍会进入 upstream。可用更精确的前缀匹配或正则隔离。
3. 确保心跳请求不建立持久连接（避免“假连接”）
即使心跳请求进了 upstream，只要它用完即断（HTTP/1.0 或显式关闭连接），就不会被 least_conn 长期计数。Nginx 默认对上游使用 keepalive，但心跳请求本身应设计为短连接。
可在 upstream 中限制连接复用，或在后端响应头中强制关闭：
- 后端响应心跳时加
Connection: close头 - Nginx 配置中禁用该 upstream 的 keepalive：
（默认已禁用，除非显式配置了keepalive指令） - 避免在心跳请求中携带
Connection: keep-alive或Upgrade头
? 关键点：least_conn 统计的是当前活跃的、未关闭的连接数（即处于 ESTABLISHED 状态的 socket）。短连接心跳几乎不产生持续连接，影响极小。
4. 不推荐：尝试用 map 或 if 动态切换 upstream
有人想通过 map 判断 URI，对 /health 使用另一个只有单节点的 upstream。这虽可行，但增加了配置复杂度，且无法完全规避：若心跳并发高，单节点 upstream 仍可能堆积连接，且违背“健康检查应轻量独立”的原则。不如直接拦截或改用原生健康检查。
