摘要：判断动态IP是否切换成功，不能只看客户端提示或代理控制台状态。应先确认产品的轮换规则，再以目标端观测到的公网出口为主证据，用会话标识和请求编号对齐日志，同时控制连接复用、缓存与并发干扰。

程序返回200，代理控制台也显示消耗了一次请求，但连续查询出口地址，结果始终没变。遇到这种情况，最容易得出两个相反结论：代理没有轮换，或者检测接口出了问题。

真正的判断轴不是“连续两次IP是否不同”，而是产品原本应该在什么条件下切换、目标端实际看到了哪个出口，以及这条记录能否对应到具体会话和请求。验证过程可以压缩成四步：定义预期、生成标识、采集出口、对齐日志。

什么情况才算动态IP切换成功？

切换成功至少需要出口证据和关联证据同时成立，业务请求成功则是另一层判断。

最直接的出口证据来自请求目标端：目标端看到的公网IP发生变化，说明流量已经通过不同出口转发。代理客户端提示“已更换节点”、接口返回新IP，或者控制台显示切换完成，都只能算控制面证据，不能代替目标端观测。

完整验证可以分为三层：

出口变化并不代表业务一定成功。新出口仍可能遇到超时、目标服务限流或请求参数错误。反过来，连续两次出口相同也不能立即判定切换失败，因为动态池可能重复分配同一地址，产品也可能采用粘性会话或按时长轮换。

验证前要先确认哪种轮换规则？

先写清楚“什么时候应该换”，否则任何检测结果都缺少判定基准。

“动态IP”只是产品类别，不代表所有服务都承诺每次请求获得不同出口。常见机制至少有以下四种：

如果产品采用五分钟有效期，十秒内连续查询相同IP属于正常现象；如果采用粘性会话，只更换本地连接却没有更换服务端会话标识，也可能继续使用原出口。

请求级轮换同样不等于“每次绝不重复”。资源池采用随机或调度分配时，短样本里重新命中同一地址并不反常。验证时应观察一组请求的出口序列，而不是只比较前后两次。

会话标识和请求编号应该怎么设计？

会话标识用于划分路由上下文，请求编号用于定位单次调用，两者不能混成一个字段。

建议为每批验证生成一个会话标识，并为每次HTTP调用生成独立请求编号。日志中至少保留以下字段：

本地生成的session_id只是日志关联键，不会自动改变代理服务的路由。若供应商支持粘性会话，还要按照其接入文档，把相同标识映射到用户名、鉴权参数或指定会话字段中。不要自行猜测参数格式。

最小验证脚本怎么写？

脚本应主动关闭连接复用，并把出口、会话和请求信息写进同一条结构化日志。

下面的Python示例从环境变量读取代理地址，每次创建新的连接会话，向公网出口检测接口发送请求。代理账号和密码不写进代码，也不会被输出到日志。

import os, time, uuid, json, requests
from datetime import datetime, timezone

proxy = os.environ["PROXY_URL"]
session_id = os.getenv("TEST_SESSION_ID", f"sess-{uuid.uuid4().hex[:8]}")
proxies = {"http": proxy, "https": proxy}

for sequence in range(1, 7):
    request_id = f"req-{uuid.uuid4().hex[:8]}"
    started = time.perf_counter()
    try:
        with requests.Session() as client:
            client.headers.update({
                "Connection": "close",
                "Cache-Control": "no-cache"
            })
            response = client.get(
                "https://api.ipify.org",
                params={"format": "json", "rid": request_id},
                proxies=proxies,
                timeout=(5, 15)
            )
            result = {
                "session_id": session_id,
                "request_id": request_id,
                "sequence": sequence,
                "started_at": datetime.now(timezone.utc).isoformat(),
                "egress_ip": response.json().get("ip"),
                "status_code": response.status_code,
                "elapsed_ms": round((time.perf_counter() - started) * 1000)
            }
    except requests.RequestException as error:
        result = {"session_id": session_id, "request_id": request_id,
                  "sequence": sequence, "error_type": type(error).__name__}
    print(json.dumps(result, ensure_ascii=False))
    time.sleep(2)

运行前通过环境变量提供完整代理连接地址：

export PROXY_URL='http://用户名:密码@代理入口:端口'
export TEST_SESSION_ID='sess-test-a'
python verify_egress.py

示例日志可能如下：

{"session_id":"sess-test-a","request_id":"req-91e734ab","sequence":1,"egress_ip":"203.0.113.10","status_code":200,"elapsed_ms":412}
{"session_id":"sess-test-a","request_id":"req-f8209c16","sequence":2,"egress_ip":"198.51.100.24","status_code":200,"elapsed_ms":538}

示例使用的是文档保留地址，不代表真实代理出口。若需要验证粘性会话，应先用同一个服务端会话参数运行一组请求，再更换会话参数运行第二组；只修改本地日志字段没有意义。

出口日志应该怎样判读？

不要只统计不同IP数量，要同时比较会话边界、时间间隔和产品预期。

一个实用的验收起点是：每种会话策略至少执行两组测试，每组采集10—20次请求，分别记录出口去重数、连续重复长度、成功响应比例和P95耗时。这只是测试起点，不是所有代理池通用的合格线。

为什么控制台显示切换，检测结果却没变？

多数误判来自连接复用、代理未实际生效或日志顺序错误，而不是轮换服务本身。

1. 连接池复用了旧隧道

requests.Session、浏览器连接池和HTTP/2都可能复用已有连接。即使程序发起了新的业务请求，底层仍可能沿用同一个代理隧道。验证轮换时可以暂时关闭连接复用；正式业务是否保留长连接，则要根据产品机制决定。

2. 部分请求没有经过代理

系统代理、程序代理和单次请求代理可能同时存在。环境变量中的NO_PROXY、代码分支或协议配置错误，会让部分请求直接连接目标端。检测日志应同时记录代理模式，但不能输出完整账号、密码或鉴权令牌。

3. 检测接口存在缓存

检测地址如果经过缓存层，而请求又没有携带唯一参数，连续响应可能返回旧结果。可以附加request_id作为查询参数，并设置禁止缓存请求头。关键验收最好使用两个独立检测端交叉确认。

4. 并发日志打乱了顺序

并发任务按照完成时间写日志时，第五个发出的请求可能先于第二个返回。只看日志行顺序会误判轮换轨迹，应使用请求序号、发起时间和完成时间重新排序。

5. IPv4和IPv6口径混在一起

一个检测端可能优先返回IPv6，另一个只返回IPv4。对比之前要统一协议族，否则看起来像出口变化，实际只是检测路径不同。

代理服务的轮换能力该如何验收？

产品能力要转成可观测条件验收，不能把官网参数直接当作业务测试结果。

以国内持续请求为例，极安官网国内隧道产品口径包含请求级切换和异常IP自动切换。验证这类能力时，不应机械要求“每次请求必须出现不同IP”，而应在选定的换IP规则或异常恢复条件下，检查目标端出口记录是否发生变化，以及变化能否与session_id、request_id准确对应。

异常IP自动切换只能说明服务具备节点恢复机制，不代表每次业务请求都必然成功。正式接入前，应使用公开、授权、合规的目标端，在统一并发、超时和请求间隔下完成小样本验证，再决定是否扩大任务规模。

FAQ

Q：连续十次都是同一个IP，能直接判定动态代理失效吗？

不能。先确认产品采用请求级、定时、粘性还是异常触发轮换，再检查连接是否复用、代理是否真正生效。若预期是请求级轮换，可关闭长连接、扩大样本并更换会话参数复测。

Q：只调用公网IP查询接口够不够？

适合验证基础出口，但不足以证明业务正常。完整验收还要记录目标业务的状态码、响应耗时和关键返回字段。出口变化证明路由发生变化，不能替代业务成功率测试。

Q：会话标识应该由客户端生成还是服务商返回？

本地日志标识通常由客户端生成，用于关联请求；影响代理路由的会话参数则由服务商定义。两者可以使用同一个值，但必须按照产品文档完成映射，不能只在日志里改名。

Q：怎样避免代理密码出现在日志中？

连接地址放入环境变量或密钥管理系统，日志只记录代理入口别名、会话标识和请求编号。捕获异常时也不要直接打印包含完整代理URL的请求对象。

Q：IP已经变化，为什么仍然出现请求失败？

出口轮换只解决节点切换问题。请求仍可能受到目标服务状态、访问频率、超时设置、连接质量和请求参数影响。应把出口日志与状态码、错误类型、耗时放在同一分析窗口内判断。