上个月工作室老板找我聊的时候，桌上摊着一张封号记录表：30个客户端，一周封了9个号。他一开始的诉求很直接——买更多IP。我翻了他原来那套免费代理的日志，发现一个更尴尬的事实：同一时刻有7个客户端被分到了同一个出口IP。这不是池子小，是分配逻辑压根不存在。
那天晚上我做了个决定，把免费代理整体换掉，自己写一层调度。这篇文章就是这一个多月的架构复盘，踩的坑比预想的多。
免费代理崩盘那天，我才想明白调度才是核心
先交代背景。我是独立开发者，接的这个活是游戏多开工作室，同时跑30+客户端，每个客户端要求独立且相对稳定的出口IP。之前图省事用免费代理，节点列表几百个看着挺唬人，实测可用率只有38%到45%，每5分钟批量掉线一轮，客户端重连就是一次登录异常。
我最初也以为是IP数量不够，后来把日志按出口IP聚合才看清：免费节点的复用率高得离谱，30个客户端实际只落在11个不同出口上。更麻烦的是没有健康检查，一个死节点能被反复分配十几次。说白了，代理IP的质量下限由池子决定，上限由调度决定，我当时只盯着下限。
决定转付费之后，我先做了一件事：把需求拆成三个约束——每个客户端独占会话、单IP并发不超过2、故障时5秒内切换。这三条决定了后面架构长什么样。
三层调度架构：负载均衡、故障转移和会话粘性怎么配
架构不复杂，三层：客户端层 → 调度网关 → IP资源池。网关维护一张 client_id → proxy 的映射表，分配策略不是轮询，而是可用性加权 + 一致性哈希：先按最近5分钟成功率排序取前5个候选，再对client_id做哈希取模，保证同一个客户端尽量落在同一个出口上。
故障转移靠健康检查驱动。我配置的参数是：健康检查间隔30秒、连续3次失败熔断、冷却60秒后重新入池、会话粘性TTL 20分钟。这里有个反直觉的点——游戏多开场景千万别用短效轮换，我一开始每请求换一次IP，封号率不降反升，因为每次登录都是新IP，风控直接判定异常。
核心调度逻辑大概长这样，去掉业务代码不到30行：
- 过滤掉熔断中和负载≥2的节点
- 按success_rate降序取前5
- 对client_id哈希取模选中一个并写入映射表
- 候选为空时走fallback池并触发告警
def pick_proxy(client_id, pool):
if client_id in sticky_map and sticky_map[client_id].alive:
return sticky_map[client_id]
candidates = [p for p in pool if p.health and p.load < 2]
if not candidates:
alert("pool_exhausted")
return fallback_pool.acquire()
top5 = sorted(candidates, key=lambda p: p.success_rate, reverse=True)[:5]
return top5[hash(client_id) % len(top5)]
监控告警：指标定错了，等于没监控
第一版我监控的是“IP池剩余数量”，跑了两天才发现这指标毫无意义——池子有8000个节点，可用率掉到70%时剩余数量看着还很健康。改成盯三个指标之后才靠谱：5分钟滑动可用率、出口IP关联客户端数、单IP失败次数。告警规则也简单：可用率跌破95%、同一IP关联超过2个客户端，立刻推企业微信。
三档方案我各跑了7天，30客户端全量，数据如下：
| 方案 | 可用率 | 平均延迟 | 7天封号数 | 日均成本 |
|---|
| 免费代理 | 41.2% | 780ms | 9个 | 0元 |
| 短效动态代理 | 96.5% | 45ms | 3个 | 约12元 |
| 隧道代理 | 99.9% | <10ms | 1个 | 16~20元 |
数据摆在这里，结论很清楚：免费代理省下的钱，全赔在封号和重登时间上。真正把封号从3个压到1个的，是隧道方案加上粘性会话，而不是继续堆IP。
三个坑，和我的选型结论
第一个坑是健康检查太勤。我一开始设5秒一次，结果代理服务商那边直接限流，误判成节点全挂。改成30秒后稳定。第二个坑是没做熔断，一个坏IP让10个客户端卡了4分钟，加了连续3次失败即熔断才解决。第三个坑最蠢——我没给fallback池单独限流，主池一崩，备用池瞬间被打满，等于没有备用。
说句实在话，这套架构在30个客户端的量级上够用，但如果你要做上千并发，单靠一个供应商的池子是不够的，得做多供应商路由。我目前主力用隧道代理扛长会话，按天计费16元起，对工作室这种每天十几个小时在线的场景比按IP计费划算——这里提一句我常用的蚂蚁代理，延迟和可用率跟上面的表基本对得上，具体套餐可以去 mayihttp.com 自己比价，别照抄我的。
最后给个判断标准：如果你的封号是“同IP撞车”导致的，先修调度；如果封号集中在登录瞬间，先查IP纯净度。方向搞反了，换再贵的池子也是白花钱。