负载均衡本身不拖慢速度，但配置错误会成为性能瓶颈；常见问题包括转发策略不当、健康检查过重、连接未复用、http头处理冗余及会话绑定失效等。
负载均衡本身不拖慢速度，但配置错就会变瓶颈
负载均衡器不是“加了就快”的银弹，它是一道流量闸门——开得对，水流通畅；开得歪，全堵在门口。你观察到的 JS 加载慢、重定向循环、某些网络打不开，基本不是负载均衡“该不该用”的问题，而是它当前怎么转发、怎么健康检查、怎么维持连接的问题。
常见错误现象包括：
• 直连某台服务器秒开，走 LB 就卡 2–3 秒才开始加载资源
• 浏览器 Network 面板里看到大量 302 或重复 GET / 请求
• 某些地区用户始终触发 ERR_CONNECTION_TIMED_OUT
- 会话关联（sticky session）开启但后端无状态，导致 LB 强制绑定已宕机节点
- 健康检查间隔太长（如 30s），故障服务器还在收流量
- 未启用 HTTP/2 或 TLS 1.3，LB 与后端仍用 HTTP/1.1 明文通信，增加往返延迟
- 超时参数激进：
connect_timeout设为 500ms，但后端冷启动常需 800ms+
HTTP 头和 Cookie 是 LB 性能的隐形开关
很多慢，其实卡在头处理和重写逻辑上。LB 不只是转发 IP+端口，它常被当成“中间代理”做头注入、路径改写、Cookie 签名等操作——每一步都吃 CPU 和时间。
使用场景：你用 Nginx 做 LB，又在 location 块里写了 proxy_set_header X-Real-IP $remote_addr + proxy_cookie_path + add_header 三连，再配上正则 rewrite，那每个请求至少多一次内存拷贝和字符串匹配。
- 避免在 LB 层做复杂
rewrite，尤其带捕获组的正则；静态路径映射尽量用map或try_files -
proxy_buffering off在流式响应（如 SSE、大文件下载）下可减延迟，但对 HTML/JS/CSS 反而可能降低吞吐 - 若后端依赖
Cookie维持会话，确认 LB 是否做了cookie hash而非简单轮询——否则同一个用户反复跳机器，Session 丢失就触发重登录或重复初始化
TCP 层配置比算法选择更影响首包延迟
别急着调 least_conn 还是 ip_hash，先看连接复用是否打开。很多 LB 默认关闭 keepalive，每次浏览器发一个 JS 请求，LB 就新建一条 TCP 连接到后端——三次握手 + TLS 握手叠加，光这一项就能吃掉 200–600ms。
性能影响明显体现在首字节时间（TTFB）：实测某电商站关掉 upstream keepalive 后，TTFB 从 42ms 涨到 278ms（CDN 回源走 LB 场景）。
- Nginx LB 必配：
keepalive 32（连接池大小）、proxy_http_version 1.1、proxy_set_header Connection '' - 云厂商 LB（如 CLB、ALB）要确认“连接空闲超时”是否 ≥ 后端
keepalive_timeout，否则 LB 主动断连，后端还等着复用 - 若后端是 Node.js 或 Go（默认短连接），必须显式开启
http.Server{SetKeepAlivesEnabled: true}，否则 LB 的长连接白搭
健康检查不是“开着就行”，它可能主动制造卡顿
健康检查请求本身会占后端资源。如果检查太密、路径太重、没设超时，LB 会一边疯狂刷 /healthz，一边把真实用户请求压在队列里等。
容易踩的坑：
• 用 GET / 做检查，结果触发完整首页渲染 + DB 查询
• 检查间隔 5s，超时却设成 10s，LB 卡住 10 秒才判定失败
• 后端健康接口返回 200，但 DB 连接池已满——LB 认为“活着”，实际无法服务
- 健康检查路径必须轻量：
HEAD /ping，纯内存响应，不查库、不读文件、不打日志 - 超时时间建议 ≤ 检查间隔的 1/3（如间隔 6s，超时设 2s）
- 云 LB 需开启“主动健康检查 + 失败熔断”，但熔断阈值别设成“1 次失败即下线”，至少 2–3 次连续失败再剔除
真正卡顿的根源，往往藏在看似“保障可用性”的配置里——比如健康检查太重、连接复用关了、头处理太啰嗦。这些地方改一行配置，比加三台服务器更管用。
