做数据采集、批量注册、接口测试的朋友，几乎都会遇到同一个问题：代理IP到底什么时候换？换得太勤，请求成功率反而掉下来；一直不换，跑到中途就开始大面积超时和封禁。真正决定效果的，不是你买了多少个IP，而是切换策略有没有和业务节奏对上。
这篇文章就把三种最常见也最实用的切换方式讲清楚：按请求切换、按时间切换、按失败切换，以及它们怎么组合成一套稳定的调度方案。
一、为什么"随手换IP"反而更容易出问题
很多人的第一版代码是这样的：请求失败了就换个IP重试，成功了就一直用。看起来没毛病，但实际跑起来会踩三个坑。
坑一：换得太频繁，行为特征不像真人。同一个账号或同一个业务,几十秒内从不同IP反复发起请求，风控系统最容易捕捉的就是这种"地址乱跳"的模式。
坑二：一直不换，IP被慢慢磨死。一个IP连续跑几千次请求，即使间隔很长，累计频次也会触线。等你发现的时候，可能这个IP已经被拉黑了。
坑三：失败就换，陷入死循环。如果失败原因是目标站点的规则变了、参数错了、或者本地网络抖动，那换多少个IP都没用，只会白白消耗IP池，还让日志里全是无效重试。
所以切换策略要解决的核心问题只有一个：在合适的时机、以合适的粒度，把请求分散到不同的IP上，同时保证不浪费。
二、按请求切换：一次请求一个IP
最直接的做法。每次发请求之前，先从IP池里取一个新的代理，用完直接丢弃或归还。整个流程是无状态的，任何一个请求都不依赖上一个请求的IP。
适合的场景：公开数据采集、商品详情页批量抓取、搜索引擎结果页轮询、接口压力测试。这类任务每次请求之间本来就没有关联，换IP不影响结果。
不适合的场景：需要保持登录态的流程、需要连续翻页且服务端校验会话、需要走完整下单或提交链路。一旦IP变了，会话可能直接失效。
使用按请求切换要注意两点。第一，每次换IP都意味着重新建立连接，TCP握手、TLS握手的开销都要算进去，单机并发不要开得太夸张。第二，如果代理来源是API提取模式，提取频率本身就是瓶颈，最好配合本地IP池做缓冲，而不是每个请求都去调一次接口。
# 按请求切换的基本写法（示意）
def fetch_by_request(url, pool):
proxy = pool.acquire() # 每个请求取一个新IP
try:
return requests.get(url, proxies=proxy, timeout=10)
finally:
pool.release(proxy) # 用完立即归还，避免复用三、按时间切换：让节奏稳定下来
按时间切换就是给IP设一个"任期"。比如60秒、5分钟、或者10分钟一换，到点就自动切换到下一个IP，不管中间成功还是失败。这样做的最大好处是行为节奏稳定、可预期，看起来更像正常用户的行为。
具体落地时有三种常见写法：
1. 固定间隔。每个IP用满N秒后强制轮换。实现最简单，适合长期运行的常驻任务。
2. 请求数阈值。本质是按量切换，比如一个IP跑满100次请求就换。它比纯时间更贴近"频次风控"的逻辑，因为多数限制是按请求次数算的，不是按时间算的。
3. 混合计时。时间到或者请求数到，先到者触发切换。这个方式最稳妥，兼顾了两种维度的限制。
间隔设多长，没有标准答案，但可以这样推：先看目标站点对单个IP的容忍度（跑到多少次开始出现验证码或403），然后把阈值打个五六折作为切换点，留出安全余量。比如实测一个IP跑到150次开始被限，那就设在80到100次之间。
四、按失败切换：兜底的最后一道闸
这是三种策略里最容易被低估的一种。它不负责主动分散，只负责止损——一旦发现当前IP不好用，立刻换掉，不让它继续拖累任务。
关键在于"什么算失败"。常见的判断信号有这几类：
连接层异常：连接超时、连接被重置、代理握手失败。这类最明确，基本可以直接判定IP不可用。
状态码异常：403、429、407、503。其中429和407通常是频次或认证问题，说明这个IP已经不适合继续用了。
内容层异常：返回空白页、返回验证码页面、返回的字段结构突然变了。这类最隐蔽，需要业务侧做简单的校验，比如检查页面里是否包含预期关键词。
判失败之后还要配三件事：重试次数上限（一般不超过3次，超过就说明不是IP的问题）、熔断机制（同一IP连续失败就临时拉黑一段时间，而不是无限重试）、失败计数（记录每个IP的失败率，方便后续淘汰劣质IP）。
五、三种策略怎么选、怎么组合
先用一张表把差异看清楚。
| 策略 | 触发时机 | 适合场景 | IP消耗 | 主要风险 |
|---|---|---|---|---|
| 按请求切换 | 每个请求前取新IP | 无状态采集、接口测试、高并发抓取 | 高 | 连接开销大，会话类业务不适用 |
| 按时间切换 | 到点或到量后轮换 | 长周期常驻任务、需要稳定节奏的业务 | 中 | 节奏固定后被识别出规律 |
| 按失败切换 | 检测到异常后触发 | 所有场景的兜底 | 低 | 反应滞后，异常已经发生一次 |
实际项目中，绝大多数情况不需要三选一，而是组合使用。一个比较通用的骨架是：
基础层用按时间（或按请求数）切换，保证请求均匀分散，不给单个IP过大压力；兜底层用按失败切换，出现异常立即换人，并把失败IP打上标记逐步淘汰；关键环节按请求切换，比如对成功率要求极高、且不需要会话的那几个接口，直接每个请求换一个IP。
六、一份可以直接套用的调度代码骨架
下面这段是思路示意，把三种触发条件放在同一个调度器里，谁先满足就执行切换。
import time
class ProxyScheduler:
def __init__(self, pool, ttl=300, max_hits=100, max_fail=3):
self.pool = pool
self.ttl = ttl # 按时间：单个IP最长存活秒数
self.max_hits = max_hits # 按请求：单个IP最多承载请求数
self.max_fail = max_fail # 按失败：连续失败几次就淘汰
self.current = None
self.start_at = 0
self.hits = 0
self.fails = 0
def _rotate(self):
self.current = self.pool.acquire()
self.start_at = time.time()
self.hits = 0
self.fails = 0
def get_proxy(self):
# 按时间 + 按请求：任一条件满足就切换
if (self.current is None
or time.time() - self.start_at > self.ttl
or self.hits >= self.max_hits):
self._rotate()
return self.current
def report(self, ok):
self.hits += 1
if ok:
self.fails = 0
else:
self.fails += 1
# 按失败：连续失败达到阈值，立即淘汰当前IP
if self.fails >= self.max_fail:
self.pool.mark_bad(self.current)
self._rotate()调用的时候，每个请求前 get_proxy() 拿一次代理，请求结束把结果 report(True/False) 报回去，策略逻辑就全部收敛在这个类里，业务代码不用关心切换细节。
七、参数怎么调：几个可以照着试的经验值
间隔长度：先设一个保守值（比如5分钟或100次请求），跑一轮看失败率，再往下压。压到失败率开始明显上升，就退回去一档。
并发控制：按请求切换时，线程数不要只按CPU核数算，要按"目标站点能接受的最大并发"算。并发过高时，失败率会被放大，让你误以为是IP质量差。
超时设置：单次请求超时建议控制在8到15秒。设太长会让整体任务被几个坏IP拖住，设太短又会误判正常IP为失败。
重试上限：三次以内。三次都是同一个错误，那问题在业务侧，不在IP。
日志观察：一定要记录每个IP的成功次数、失败次数、平均耗时。切换策略调优全靠这份数据，没有日志就只能靠感觉瞎调。
八、策略的上限，取决于IP池本身
再精巧的切换逻辑，也要建立在一个稳定可用的IP池上。如果池子里的IP本身就重复率高、时延大、可用率低，那无论怎么调参数，都只是在烂IP里挑一个相对不那么烂的。
这也是为什么在实际项目里，很多人会把接入层交给专门的国内代理服务商。天启HTTP 提供短效优质代理、隧道代理、独享IP等多种接入方式，支持API提取和固定入口接入，方便把上面的调度逻辑直接套进去。IP资源覆盖国内多个地区，需要按地区分流的业务也能用得上。
选型的时候，重点看几件事：提取接口的稳定性、IP的可用率、并发承载能力、以及是否支持你有会话需求的场景。先小批量跑一轮真实业务请求，把成功率、平均响应时间测出来，再决定要不要放量——这比任何参数说明都可靠。
需要提醒的是，天启HTTP 面向的是国内IP代理场景，如果你的业务需要访问境外站点，它并不适用；同时产品线里也不包含住宅类资源，选型时要按实际需求对号入座。
常见问题
Q：三种切换策略必须选一种吗？
不用。推荐的做法是"按时间或按请求数做基础轮换 + 按失败做兜底"，关键接口再单独走按请求切换。三者是叠加关系，不是互斥关系。
Q：按请求切换是不是成功率最高？
不一定。它对无状态采集确实有效，但每次都要重新建连接，开销大；而且如果目标站点是靠账号、指纹、行为识别来风控的，换IP并不能绕过。会话类业务用按请求切换，反而会让登录态频繁失效。
Q：一个IP用多久换一次比较合适？
没有绝对标准。先做小规模测试，找到"开始出现限流"的临界点，然后把切换点设在临界值的五六折。理论上单IP承载请求数比时长更好控制，因为多数限制是按次数算的。
Q：怎么判断一次失败是IP的问题还是代码的问题？
看失败模式。如果换了IP之后同样的请求能成功，那是IP问题；如果换了三四个IP还是同样的报错、同样的返回结构，那大概率是参数、请求头、或者目标页面结构变了。这时应该停下来排查，而不是继续换IP。
Q：切换后还是被限流怎么办？
先降并发、加长间隔，再检查请求头、Cookie、访问路径是否过于规律。另外要区分是"整站限流"还是"单IP限流"，前者换多少IP都没用，需要调整业务节奏。
Q：小项目也要做这么复杂的调度吗？
不需要。业务量小的时候，一个按时间轮换加简单重试就够用了。等到失败率开始影响任务完成度，或者IP消耗明显变快时，再引入失败熔断和日志统计。策略是随规模演进出来的，不是一开始就要全上。
