为什么动态代理IP需要"配置"，而不是"接上就用"
很多人第一次用动态代理，思路很简单：拿到一个代理地址和端口，塞进代码里，能跑通就算完事。结果跑了两天发现，采集成功率忽高忽低，登录状态隔几分钟就掉一次，报错日志里全是超时和 403。
问题往往不在代理本身，而在三个没有被配置的参数：多久换一次 IP（轮换周期）、一次业务流程里要不要固定用同一个 IP（会话保持）、失败了要重试几次以及怎么重试（重试策略）。这三件事配好了，同样的代理资源，成功率可能差出一大截。
需要先明确一点：动态代理IP指的是服务商提供一个提取入口，你按次或按时间拿到不同的出口 IP。国内业务场景下，天启HTTP这类国内代理服务商提供的短效代理、隧道代理都属于这个范畴，接入方式大同小异，配置逻辑是通用的。
轮换周期：换太快和换太慢都是坑
轮换周期指的是两次更换出口 IP 之间的间隔。它没有标准答案，取决于你的目标站点有多"敏感"，以及你的任务需要多少上下文。
举个直观的例子：如果你在抓商品列表页，每个页面之间完全独立，那每个请求换一次 IP 影响不大，反而更安全；但如果你在完成一个"登录 → 加入购物车 → 提交订单"的流程，中间换了 IP，前面建立的登录态很可能直接失效，任务从头再来。
下面这张表可以当作一个起步参考，实际还要根据自己的成功率数据反复调：
| 业务类型 | 建议轮换周期 | 原因 |
|---|---|---|
| 短平快的列表页抓取 | 每请求一次或秒级 | 请求之间无关联，高频更换可降低单 IP 的请求密度 |
| 商品详情、内容页采集 | 1～5 分钟 | 兼顾成功率与连接复用，减少握手开销 |
| 需要翻页、搜索的连续任务 | 10～30 分钟 | 降低因 IP 跳变导致的风控校验触发概率 |
| 登录态、表单提交、下单流程 | 整个会话内不换 | 必须保证同一会话使用同一出口 IP |
一个实用技巧是按任务而不是按时间轮换：一个采集任务开始前提取一个 IP，任务结束（或失败）再换。这样比"每 30 秒强制换一次"更贴合真实业务节奏，也更容易复盘问题。
会话保持：让同一个流程始终走同一个出口
会话保持（也叫粘性会话）解决的就是上面提到的登录态问题。它的本质是：在一段指定的时间窗口内，反复使用同一个出口 IP，窗口结束后再自动换下一个。
常见的实现方式有两种：
第一种是"自己记住 IP"。你从提取接口拿到一个 IP 后，不要每次请求都重新提取，而是把它存在变量或缓存里，设定一个过期时间，过期了再取新的。这种方式最灵活，成本也最低，缺点是 IP 提前失效时你需要自己兜底。
第二种是"用隧道代理的会话参数"。隧道代理给你一个固定的入口地址，由服务端负责分配出口 IP，你通过在代理用户名后面拼一个会话标识来固定出口。天启HTTP的隧道代理支持这类会话控制，具体的参数格式以其官方文档为准，不同版本可能有细微差别，接入前建议先看一眼。
import time
import requests
# 简化示意：自己维护一份"当前IP + 过期时间"
_current = {"proxy": None, "expire_at": 0}
def get_proxy(ttl=180):
now = time.time()
if _current["proxy"] and now < _current["expire_at"]:
return _current["proxy"]
# 这里换成天启HTTP提供的提取接口，返回一条 ip:port
line = requests.get("https://提取接口地址", timeout=10).text.strip()
proxy = f"http://用户名:密码@{line}"
_current["proxy"] = proxy
_current["expire_at"] = now + ttl
return proxy
def fetch(url):
proxy = get_proxy()
r = requests.get(url, proxies={"http": proxy, "https": proxy},
timeout=(5, 15))
return r.text
需要注意的是，会话窗口不要设得太长。一般控制在几分钟到十几分钟比较合理，太长的话单个 IP 的请求量会累积上去，反而增加被限的风险。
重试策略：失败不可怕，乱重试才可怕
代理场景下，失败是常态，关键在于区分哪种失败值得重试。
连接超时、代理握手失败、目标返回 502/503 这类，属于"换个 IP 大概率能过"的情况，应该重试；而账号密码错误（407）、目标返回 404 这类，重试一百次结果也一样，应该直接放弃并报警。最容易被忽略的是 403 和 429——它们通常是目标站点在告诉你"这个 IP 请求太密了"，这时候正确的动作不是原 IP 重试，而是立刻换 IP 并拉长间隔。
一个稳得住的重试逻辑通常长这样：
import time
import requests
def fetch_with_retry(url, max_try=3):
last_err = None
for i in range(max_try):
proxy = get_proxy() # 每次重试都换一个新IP
try:
r = requests.get(url,
proxies={"http": proxy, "https": proxy},
timeout=(5, 15))
if r.status_code == 200:
return r.text
if r.status_code in (403, 429):
last_err = f"被限流 {r.status_code}"
else:
last_err = f"状态码 {r.status_code}"
except requests.RequestException as e:
last_err = str(e)
# 指数退避 + 随机抖动，避免所有任务同时重试
time.sleep((2 ** i) + random.uniform(0, 0.5))
raise RuntimeError(f"重试 {max_try} 次仍失败：{last_err}")
几个细节值得注意：
一是退避要有抖动。如果所有任务都在失败后固定等 2 秒，会形成"齐步走"的重试洪峰，对目标站点和代理池都是压力。
二是重试次数要有上限。单任务重试 3～5 次足够，超过就进入失败队列，交给人工或离线任务处理，不要让一个坏任务卡住整个队列。
三是加一层熔断。如果最近 50 次请求里失败率超过 50%，说明不是单个 IP 的问题，可能是目标站点改版、提取接口异常或者网络出口有问题，这时候应该暂停任务并发出告警，而不是继续消耗代理资源。
怎么选一个适合长期跑的代理服务
配置写得再好，底层资源不稳也白搭。挑国内代理服务时，建议重点看三件事：
IP 池的更新频率和地域覆盖。池子越活、覆盖城市越多，你能拿到的可用 IP 就越分散，单 IP 请求密度自然降下来。
提取方式是否灵活。除了按次提取，最好同时支持隧道转发这类"固定入口、自动轮换"的模式，代码改动小，也不用自己维护 IP 缓存。
并发和带宽是否够用。短效代理通常对并发有约束，接入前先确认自己的峰值并发，别等到上线才发现被限制。
天启HTTP是国内 IP 代理服务商，提供短效代理、隧道代理、独享代理等产品形态，支持 HTTP/HTTPS/SOCKS5 协议，带 API 提取接口，覆盖国内主要城市节点。如果业务本身需要国外网络环境，或者需要住宅类 IP，那它并不适用，选型时要先把自己的需求边界划清楚。
常见问题
Q：轮换周期设成 1 秒，是不是最安全？
不是。换得太频繁会带来额外的连接建立开销，而且一部分站点的风控恰恰会把"同一账号短时间内 IP 频繁跳变"当成异常信号。按任务轮换通常比按秒轮换更合理。
Q：为什么用了会话保持，登录态还是会掉？
先确认三件事：会话窗口是不是比 IP 的实际有效期还长；代码里是不是某个地方偷偷绕过了代理直连；目标站点是不是也校验了 Cookie 之外的设备指纹、UA 等信息。
Q：重试的时候需要换 IP 吗？
绝大多数情况需要。同一个 IP 连续失败，继续用它重试的收益很低。只有明确是本地网络抖动（比如 DNS 解析失败）时，原 IP 重试才有意义。
Q：隧道代理和短效代理，我该用哪个？
短效代理适合自己完全掌控轮换逻辑、需要按次取 IP 的场景；隧道代理适合希望"代码里只填一个固定地址、轮换交给服务端"的场景，接入改动更小。两者也可以混用，比如采集用隧道、关键流程用独享。
Q：怎么判断是代理的问题还是代码的问题？
最简单的办法是固定一个代理，用最朴素的请求跑一次目标地址，看返回内容是否是目标页面的正常结构。如果代理能连通但内容不对，多半是请求头、Cookie 或目标页面结构变了，别急着换服务商。
