代理IP与服务器集群同题：负载均衡不是只能在一个位置做——从 DNS 到客户端，网络路径上有好几处都可以承担分摊职责，层级不同，均衡的粒度、灵活度与代价也不同。这篇按层次走一遍，让你看到「均衡」这个思路在不同环节的变体。
负载均衡的落点不止一个，这与代理IP选路本质相同——都是「决定请求去哪」的决策：任何能看到流量入口、有机会改写去向的环节，理论上都能承担这个决策。DNS 能看到解析请求、四层能看到连接、七层能看到请求内容、客户端能看到自己发出的每一个请求，于是均衡就有了多种落点，各落点的视角不同，决策的粗细也随之不同。
从 DNS 层说起
最靠前的是 DNS 层均衡：同一个域名在解析时返回多个后端地址，不同用户解析到不同机器，访问自然分散。它的好处是简单、无需改造应用，缺点是粒度粗——只能按解析分散，控制不了单个用户内部请求的分配；而且解析结果会被各级缓存记住，后端增减后要等缓存过期才能生效，改动有延迟。
四层与七层
再往中间是四层与七层均衡：四层按连接转发，看到的是地址与端口，转发快但不理解内容；七层能看懂请求内容，可以按路径、按特征精细分流，代价是多一层解析开销。选四层还是七层，取决于需不需要「看懂请求」再做决定；对走代理IP的流量，四层均衡只看连接、七层还能读到更多内容，两者对链路的感知也不同。
客户端侧也有均衡
最靠后的是客户端侧均衡：由发起请求的一方自己选择连哪个后端——连接池、重试换机都属于这类思路。它的好处是灵活，坏处是每个客户端都要自己实现逻辑，分散在不同地方、不容易统一管理。对依赖代理IP出口的客户端来说，「主动选路」的能力也是在这层体现。
均衡分层看落点：DNS 粗分散、四层按连接、七层看内容、客户端自己选——层越靠后越精细，实际系统常多层配合。
把各层放在一起看，规律很明显——对代理IP选路同样适用：越靠前的层越简单粗暴，越靠后的层越精细灵活，而实际系统常是多层配合——DNS 先粗略分散，中间层再按需细分配。理解分层，看任何「均衡方案」都能立刻知道它站在哪一段、能管到哪一层。还有一个反直觉的规律值得记住：越靠前的均衡越「看不见」——DNS 层与四层均衡对应用几乎透明，使用者常常感知不到它的存在；反而是客户端侧的均衡最「看得见」，因为它写在代码与配置里。看得见与看不见不决定重要程度，只决定排查时的入手点：出问题时先想均衡在哪一层做的，再决定去哪一层看。对代理IP使用者来说，层次视角还有一个直观应用：自己任务里的「多出口选择」发生在客户端侧，服务商侧的出口调度属于服务内部——两层各管各的；如果目标服务自己也是多实例，它的入口层均衡又与你无关，分清均衡发生在哪一侧，看架构图时才不会张冠李戴。
层次讲完，均衡的另一个关键问题浮现：算法分得再好，如果某个后端已经坏了还继续给它发请求，均衡就变成了「平均地把请求发给错误对象」。怎么保证后端是健康的——下一篇讲健康检查，均衡的可靠前提，代理IP多出口的使用者同样要补这一课。