代理IP换好了，程序也重启了，可日志里抓到的还是老身份，账号照样被踢下线，采集任务失败率反而比换之前更高——这是很多人换IP时遇到的怪事。问题往往不在代理IP本身，而在于换IP前后没有把本地的缓存、会话和连接处理干净。出口换了，但客户端还在用旧的状态跟服务器说话，服务器自然认不出你。
下面把换IP时最常见的三类问题拆开讲：缓存残留、会话失效、重连处理，并给出一套可以直接照着做的排查顺序。
一、换了IP还出问题，先看这五种现象
排查之前先别急着换服务商，把故障现象和可能原因对上号，往往能省下大量时间。
| 常见现象 | 可能原因 | 优先排查方向 |
|---|---|---|
| 查询出口IP，看到的还是旧地址 | 连接池里的旧长连接被继续复用 | 关闭会话/连接池后重新发起请求 |
| 登录态无故失效、被要求重新验证 | 会话票据与旧IP绑定 | 换IP前优雅退出，重新走登录流程 |
| 请求偶发超时、卡顿 | 旧连接未释放或DNS缓存未刷新 | 清DNS缓存、缩短超时时间 |
| 页面拿到的还是旧数据 | 浏览器或客户端本地缓存 | 关闭缓存、请求加时间戳参数 |
| 只有部分请求走了新IP | 系统代理环境变量没刷新 | 检查HTTP_PROXY等变量与进程继承关系 |
注意一个前提：代理IP只负责把你的请求从另一个出口发出去，它不会帮你清理本地任何状态。很多"换IP无效"的投诉，最后查出来都是本机缓存或长连接没处理。
二、缓存残留：三类缓存要一起清
换IP后最容易忽略的是缓存。它分成三层，任何一层没清，都可能让你的新IP"看起来没生效"。
1. 应用层缓存。Cookie、LocalStorage、页面缓存、接口响应缓存，这些东西里存着你的身份信息和上一轮的结果。换了IP但Cookie还在，服务器看到的依然是那个"熟悉的你"，风控逻辑就会觉得异常。
2. DNS缓存。域名解析结果会被系统或程序缓存一段时间。如果你的业务涉及域名切换、CDN调度，换IP后旧解析还在生效，请求就会被带到旧路径上。
3. 连接层缓存（最容易被忽视）。HTTP的长连接、数据库连接池、各类客户端连接池，会把TCP通道保留下来反复使用。你换了代理，但池子里那条旧通道仍然绑定着旧出口，于是新请求继续从旧IP出去。这就是为什么"明明换了IP，日志里还是旧IP"。
处理方式很直接：换IP时销毁旧会话对象、显式关闭连接、不要复用进程级的全局客户端。以常用的Python写法为例：
import requests
# 1. 先关闭旧会话，避免连接池里的旧通道继续被复用
old = requests.Session()
old.close()
# 2. 换好新代理后，重新建立一个干净的会话
proxies = {
"http": "http://用户名:密码@代理地址:端口",
"https": "http://用户名:密码@代理地址:端口",
}
s = requests.Session()
s.trust_env = False # 不读取系统里可能残留的旧代理环境变量
s.proxies.update(proxies)
s.headers.update({"User-Agent": "固定不变的UA"})
# 3. 换完IP先验证一下出口，再跑正式任务
IP_CHECK = "https://你的IP查询接口" # 换成任意能返回当前出口IP的接口
print(s.get(IP_CHECK, timeout=(5, 15)).text)另外提醒一句：不要每次请求都新建一个Session，那样会带来大量握手开销；正确做法是一个IP一个会话，IP变了会话就重建。
三、会话失效：IP变了，票据可能就废了
很多平台会把登录态和IP做绑定。同一账号前一秒在北京出口，后一秒从广州出口发来请求，中间隔了不到两分钟，风控系统会直接判定为异常会话，把登录态打掉。
所以换IP不是"换个出口继续用"，而是要考虑会话怎么延续。不同类型的会话，受影响的程度并不一样：
| 会话类型 | 换IP后是否受影响 | 处理建议 |
|---|---|---|
| Cookie会话 | 容易失效，可能触发二次验证 | 换IP后重新获取Cookie，别直接沿用旧文件 |
| Token会话 | 通常不受影响，但可能触发风控 | 保持请求头、UA、指纹一致，不要忽变 |
| IP绑定型会话 | 直接失效 | 同一账号固定一个长效静态IP，别频繁跳 |
| 长连接会话 | 旧连接仍走旧出口 | 主动断开后重新握手 |
实操上有三条经验：第一，换IP前先优雅退出，主动清理服务端会话，而不是直接掐断；第二，同一账号尽量固定出口IP，需要长期在线的业务选长效静态IP或独享IP，比频繁切换要稳得多；第三，请求头保持稳定，换了IP又换了UA又换了设备指纹，风控不报警才奇怪。
四、重连处理：把旧连接关干净，再建立新连接
重连不是"重试几次"那么简单。一个合格的重连流程包含四个动作：关闭旧连接、设置合理超时、失败后退避重试、最后校验出口IP。
关闭旧连接是第一步也是最多人漏掉的一步。只要旧连接还在，请求就可能继续走旧出口，你看到的错误和延迟都来自那条"僵尸通道"。
超时要分开设置。连接超时和读取超时是两个概念。连接超时短一点（比如5秒），能快速发现代理不可用；读取超时长一点（比如15秒），避免正常的大响应被误判为失败。只设一个总超时，会让排查变得非常困难。
重试要有退避。代理节点临时波动时，立刻密集重试只会把失败率放大。正确的做法是间隔逐次加长：
import time
import requests
url = "https://你的目标接口"
for i in range(3):
try:
r = s.get(url, timeout=(5, 15))
break
except requests.RequestException:
if i == 2:
raise
time.sleep(2 ** i) # 第1次等2秒，第2次等4秒，逐次加长
# 重试仍失败时，先换一个出口IP，再重建会话
# s.close(); s = requests.Session(); s.proxies.update(new_proxies)最后一步别忘了校验出口。换完IP先请求一次IP查询接口，确认返回的地址确实是新IP，再跑正式任务。这一步只要几行代码，但能挡掉八成"以为换了其实没换"的问题。
五、一套可以直接照做的排查顺序
把上面的内容整理成一个固定流程，下次换IP按顺序走一遍就行：
第1步，确认出口。调用IP查询接口，看返回的IP是不是你预期的那一个。如果不是，先查连接池和系统代理变量。
第2步，清会话缓存。清Cookie、清本地缓存文件、关掉旧的Session对象，确认没有全局单例在复用。
第3步，断旧连接。显式close旧会话、清空连接池，长连接业务要主动发断开指令。
第4步，重建并验证。用新代理建新会话，再次校验出口IP，并观察前几十条请求的成功率。
第5步，看错误类型。如果报的是认证失败，多半是会话问题；如果是超时，多半是连接或节点问题；如果是内容不对，多半是缓存问题。
六、选对IP类型，能少一半麻烦
很多换IP的坑，其实在选IP类型的时候就可以避开。不同业务对"IP要不要变、变得快不快"的要求完全不同：
| IP类型 | 主要特点 | 适合的业务 |
|---|---|---|
| 短效动态IP | 有效期短、自动更换，池子大 | 高频数据采集、批量查询类任务 |
| 长效静态IP | 地址固定不变，会话连续性好 | 需要保持登录态、长期在线的业务 |
| 独享IP | 单人使用，不受他人行为干扰 | 对稳定性和成功率要求高的场景 |
| 隧道代理 | 一个固定入口，后台自动调度出口 | 不想自己维护IP池和切换逻辑 |
如果你发现每次换IP都要处理一堆会话重建的麻烦，可以先想想是不是IP类型选错了。需要长期保持登录的业务，频繁换IP本身就是反效果。
天启HTTP是专注国内IP代理的服务商，提供短效动态IP、长效静态IP、独享IP、隧道代理等类型，支持 HTTP / HTTPS / SOCKS5 协议接入，适合数据采集、账号运营、接口测试、网络管理等场景。所有IP资源均为国内节点，不适用于需要境外IP的业务场景。
对接入方来说，比较实用的两点是：需要稳定会话的业务可以直接选长效静态或独享类型，减少频繁切换带来的会话失效；需要大批量轮换的业务用短效动态配合隧道入口，把IP调度交给服务端，客户端只负责重建会话和重连逻辑，代码会干净很多。
常见问题
Q：换了代理IP，查询接口返回的还是旧IP，是怎么回事？
九成是连接池里的旧长连接还在被复用。把旧的Session对象close掉、清空连接池，或者直接重启进程后再试，基本就能解决。其次要检查系统里的代理环境变量有没有更新，有些程序会优先读环境变量而不是你代码里传的代理。
Q：换IP后一定要重启程序吗？
不一定，但重启是最省事的兜底方案。规范的做法是在代码里显式关闭旧会话、重新创建客户端对象。如果程序里用了全局单例的连接池，重启往往比改代码更快验证问题。
Q：同一个代理IP，为什么A账号能用，B账号一登就被踢？
不同账号的历史登录地、设备指纹、行为习惯不一样。B账号之前一直在另一个地区登录，突然换了出口，风控会判定为异常。这类情况建议给账号固定一个长效静态IP，保持出口稳定。
Q：采集任务换IP后失败率反而升高，怎么办？
先看失败类型。如果是超时，说明新节点质量或并发太高；如果是返回空内容，多半是缓存或会话没有重建；如果是验证码变多，说明切换频率太密。可以先把并发降下来、把退避间隔加上，再逐步调回。
Q：为什么换IP后登录态会掉？
多数平台会把会话和IP关联。IP一变，原来的会话票据就对不上了。换IP前先主动退出登录，换完再重新登录，比硬撑着继续请求要稳。
Q：天启HTTP的代理IP能用在需要国外IP的业务上吗？
不能。天启HTTP只提供国内IP资源，适用于国内网络环境下的采集、测试、运营等场景，涉及境外IP的需求不在服务范围内。
Q：需要长期保持登录的业务，应该选哪种IP？
优先考虑长效静态IP或独享IP。地址固定、干扰少，会话连续性好，不需要反复处理重连和重新登录的问题。
