带宽评估需分层验证：查出口链路利用率、看后端服务器承载、区分流量类型；按带宽能力设加权轮询，结合健康检查与动态权重，并辅以DNS GSLB实现源头分流。

带宽评估是配置负载均衡器实现公网流量均摊的前提。不能只看总带宽数字，而要结合实际请求特征、后端服务器处理能力、网络链路质量来综合判断——否则容易出现“带宽有余但服务卡顿”或“服务器空闲但用户连不上”的矛盾现象。

先摸清真实带宽瓶颈在哪

公网带宽是否真成了瓶颈，需分层验证：

• 查出口链路利用率：登录路由器或云平台监控（如阿里云ESA、天翼云ELB），观察外网入口的实时带宽使用率。持续超过70%且伴随丢包或延迟升高，说明链路已趋饱和；
• 看后端服务器承载情况：检查各业务服务器的CPU、内存、连接数（如netstat -an | grep :80 | wc -l）和响应时间。若带宽未满但服务器已满载，问题不在公网带宽，而在应用处理能力；
• 区分流量类型：静态资源（图片、JS/CSS）占大头时，CDN更有效；动态API请求多，则需关注七层负载均衡的并发连接处理能力，而非单纯带宽数值。

按带宽能力分配权重，而非简单轮询

当确认多台服务器分别接入不同带宽的公网线路（例如一台接200M电信，一台接100M联通），直接轮询会导致高带宽线路闲置、低带宽线路过载。此时应启用加权轮询（Weighted Round Robin）算法：

• 在HAProxy、Nginx或云厂商控制台（如ESA、天翼云ELB）中，为每个后端服务器设置权重，比例参考其上行带宽比，如200M:100M → 权重设为2:1；
• 注意：权重仅影响请求分发频次，不改变单个请求大小。大文件下载类业务还需配合最小连接数算法，避免某台服务器堆积大量长连接；
• 若使用多WAN企业路由器（如TP-LINK），可开启“带宽均衡”模式，并在WAN口配置中准确填写各线路实测上下行带宽值，让设备自动按比例调度出向流量。

用健康检查+动态权重防止“假均摊”

固定权重无法应对服务器临时过载或网络抖动。必须开启主动健康检查，并支持动态调整：

• 配置HTTP/HTTPS探针（如每5秒请求/health），失败连续3次则临时摘除该节点；
• 部分高级负载均衡器（如Nginx Plus、阿里云ESA）支持基于实时响应时间或连接数自动降低异常节点权重，无需人工干预；
• 避免仅依赖ICMP Ping——它不反映应用层可用性，可能造成“能ping通但服务不可用”的误判。

DNS层辅助分流，缓解单点带宽压力

当后端服务器分布在不同地域或运营商时，仅靠单台负载均衡器转发，所有流量仍需经过它，容易形成新的带宽瓶颈。此时可叠加DNS负载均衡：

• 为同一域名配置多条A记录，指向不同地域的负载均衡器IP（如北京LB、广州LB）；
• 启用GSLB（全局服务器负载均衡）或EDNS Client Subnet（ECS）功能，使DNS根据用户所在地返回最近的LB地址；
• 这样公网流量从源头就分散，既降低了单台LB的带宽压力，又提升了终端访问速度。