负载均衡测试访问服务器，负载说白了就是均衡验证两件事：流量有没有被正确分发，以及后端服务器能不能扛住压力。何测我见过太多团队把这事搞复杂——上来就堆一堆压测工具，试访结果连最基本的问服务器轮询策略都没验证清楚。

先做最基础的负载验证。你配好Nginx或LVS之后，均衡别急着上高并发。何测打开浏览器，试访连续刷新十次页面，问服务器看每次请求落到哪台后端机器上。负载如果后端是均衡两台服务器，你可以在每台的何测访问日志里加上标记，或者干脆写个接口返回服务器IP。试访刷新十次，问服务器两台机器收到的请求次数应该大致均衡——轮询的话就是5比5，加权轮询就按权重比例来。我遇到过最坑的情况：配了轮询，结果会话保持的cookie没清干净，十次请求全打到一台机器上，另一台闲得发慌。

接下来测健康检查。这步很多人忽略，但恰恰是生产环境最容易出事故的环节。你手动停掉一台后端服务，看负载均衡器能不能在几秒内把它摘掉。再启动它，看能不能自动加回来。记得用真实的服务端口测，别用telnet凑合——我之前见过有人只检查了80端口通不通，没检查应用层的健康状态，结果后端应用已经报错500了，负载均衡还以为它活着，照样往那边转发请求。

然后才轮到压力测试。别一上来就上ab或wrk，先用curl做单请求延迟测试，确认网络链路没问题。压测时注意看两个指标：响应时间曲线和错误率。曲线如果突然从平稳变成锯齿状，说明后端某台机器开始扛不住了。这时候你得看负载均衡器的连接数分布——是不是所有新请求都挤到了同一台机器上？如果是，八成是会话保持策略配置错了，或者某台机器的keepalive参数没调好。

测到一半，我习惯故意搞点破坏。比如在压测进行中，突然kill掉一台后端进程。这时候观察负载均衡器的表现：请求会不会瞬间大量失败？还是平滑地转移到其他机器？好的负载均衡器应该能在几秒内完成摘除，错误率只出现一个短暂的尖峰。如果错误率持续不降，说明健康检查的间隔时间设置得太长，或者转发超时时间不合理。

最后说说容易被忽略的细节：连接超时和响应超时。默认配置往往不适合真实场景。你拿一个需要处理5秒的慢接口去测，如果负载均衡的超时时间设成了3秒，那这个请求就会被误判为失败，导致客户端看到502。反过来，如果超时时间设得太长，后端挂了之后，用户会一直卡在那里等。我一般建议响应超时设成后端接口最慢响应时间的1.5倍，连接超时设成3到5秒。

还有个土办法特别实用：压测的时候盯着负载均衡器的系统负载。如果负载均衡器本身CPU被打满，那瓶颈就不在后端，而在分发层本身。这时候你该考虑是不是用了太复杂的转发规则，或者SSL卸载全压在负载均衡器上了。硬件负载均衡器还好，软件方案（比如Nginx）在高并发下很容易自己先撑不住。

测完这些，你才算真正摸清了这套系统的脾气。生产环境出问题的时候，你才能快速判断：是后端哪台机器慢了，还是负载均衡策略出了问题。别想着一次测试就能覆盖所有场景——保持测试脚本，每次变更配置后都跑一遍回归，这比什么都管用。