浏览器切换代理IP后，检测网站仍显示旧地址，先不要连续换节点。最常见的原因不是“IP改不了”，而是已有连接还在复用、部分请求没有走新代理、IPv4与IPv6路径不同，或者检测页展示了缓存结果。
有效排查需要同时记录三个对象：旧出口IP、新代理入口与期望出口IP、实际检测请求。只看浏览器设置页，无法证明新的网络请求已经经过新代理。
先做一个低成本的四步对照
- 记下旧出口IP、切换时间、浏览器配置和当前检测页地址。
- 关闭原检测标签，打开新的无登录测试窗口，再访问同一检测服务。
- 用第二个来源不同的IP查询页面复核，避免单站缓存或数据库差异。
- 分别查看IPv4与IPv6结果；若只变化了一种地址，说明双栈路径可能没有统一。
如果新窗口已经显示新IP，原标签更可能受连接或页面缓存影响；如果所有新请求都显示旧IP，再继续检查代理覆盖范围。
原因一：浏览器仍在复用旧连接
HTTP Keep-Alive、HTTP/2多路复用和WebSocket会让多个请求继续使用已经建立的TCP或隧道连接。代理设置改变后，已有连接未必立即迁移到新入口。仅刷新页面可能沿用原连接，因此看起来像“换代理没生效”。
可先关闭相关标签和后台页面，再完全退出浏览器并确认进程结束，然后重新打开测试。对生产业务不要强制中断重要上传、表单或长连接；先保存状态，再结束旧会话。
原因二：扩展、系统代理和应用规则互相覆盖
浏览器可能同时受到系统代理、代理扩展、PAC脚本、命令行启动参数和安全软件影响。最后生效的规则不一定是刚修改的那一层。尤其在PAC或扩展分流模式下，不同域名可能分别走代理与直连。
| 现象 | 可能路径 | 检查重点 |
|---|---|---|
| 只有某个网站显示旧IP | PAC按域名直连或缓存 | 规则命中与新窗口对照 |
| 所有网站都显示旧IP | 新代理未被浏览器采用 | 系统代理、扩展与启动参数 |
| 浏览器改变，命令行不变 | 两者使用不同代理栈 | 应用自身配置与环境变量 |
| IPv4改变、IPv6不变 | IPv6直连或代理不支持 | 双栈出口与目标站支持 |
排查时每次只保留一层代理配置，完成验证后再恢复需要的分流规则，避免多层设置互相掩盖。
原因三：登录状态、缓存与服务端会话影响展示
部分检测页会缓存接口响应，网站也可能把账号地区、Cookie或历史会话与IP结果放在同一页面展示。此时“页面地区没变”不等于公网出口没变。应直接核对网络请求返回的出口地址，而不是只看推荐内容、语言、时区或账号资料。
清缓存不应成为第一反应。先用新标签、无登录窗口和第二个检测来源做对照；只有确认页面响应缓存后，再定向清理该站点数据，避免无谓退出所有账号。
原因四：代理入口变了，出口却没有变
某些代理服务提供多个入口域名或端口，但这些入口可能汇聚到同一个公网出口；也可能在一个会话周期内保持粘性出口。更换入口并不自动等于更换IP。需要查看服务的会话、轮换和故障切换规则，并以实际出口查询为准。
若商品宣称静态IP，出口保持不变反而可能符合交付；若期望轮换，应确认触发方式是新建连接、改变会话标识、等待周期，还是由服务端自动切换。
用浏览器和命令行做交叉验证
在自有或获授权的检测接口上，可分别从浏览器和明确指定代理的命令行请求，记录返回出口。两者一致说明代理路径大体相同；两者不同则应检查浏览器规则、命令行参数、DNS与IPv6，而不是直接判断代理质量。
验证中不要把代理用户名、密码或完整连接串贴到公开截图和日志。需要提交售后时，隐藏凭据，仅保留时间、入口、协议、期望出口和实际结果。
什么时候才能确认切换完成
- 新建请求在两个独立检测来源显示同一新出口；
- IPv4与IPv6的行为符合所购代理协议和预期；
- 原有长连接已结束，业务新会话使用新出口；
- 关闭一层代理配置后，结果能按预期发生可重复变化。
结论
浏览器换代理IP后仍显示旧地址，应先区分旧连接复用、代理规则覆盖、页面缓存、双栈直连和入口出口关系。用新连接、第二检测来源和单变量对照确认真实公网出口，比反复点击“切换IP”更容易找到根因。
