天行IP切换节点后，检测页显示的出口IP没有变化，先不要连续切换或直接判断节点无效。更常见的情况是：旧的 TCP、HTTP/2 或 WebSocket 会话仍在复用，应用进程没有读取新代理，系统代理被其他软件接管，或者检测页本身使用了缓存。正确做法是先确认“新连接是否走新节点”，再决定是否需要重启进程或联系平台。
本文只讨论可复现的本地排查流程，不把一次检测结果写成平台长期性能结论。需要查看当前入口时，可通过天行IP平台详情页进入；下单优惠信息请完整填写天行IP优惠码 blsj。实际价格、适用套餐和优惠是否生效，以当时页面及订单结算结果为准。
先用四个问题缩小范围
| 检查问题 | 结果意味着什么 | 下一步 |
|---|---|---|
| 新开的无痕窗口是否仍显示旧IP | 可能不是单个标签页缓存 | 继续检查浏览器进程与系统代理 |
| 完全退出应用后是否变化 | 若变化，多半是旧会话复用 | 以后按“断开—退出—切换—重开”操作 |
| 不同应用的出口是否一致 | 不一致说明代理作用范围不同 | 核对进程规则、协议和绕过列表 |
| 新节点参数是否真的保存 | 未保存时仍会使用旧配置 | 核对服务器、端口、协议与认证信息 |
为什么切换了节点，旧连接还在工作
代理节点的切换通常影响后续建立的连接，不会自动搬迁已经存在的会话。网页长连接、聊天客户端、下载任务、浏览器后台进程和指纹浏览器环境都可能持续占用旧连接。只刷新页面不一定会重新建立底层链路，特别是多个标签页共用一个浏览器进程时，表面上的“新页面”也可能复用旧连接池。
因此，判断切换是否成功时要把“配置已经改了”和“业务连接已经重建”分开。配置界面显示新节点，只能证明参数被选择；出口检测出现新IP，才能证明当前检测请求走了新链路。
推荐的节点切换顺序
- 暂停正在运行的上传、下载、自动化任务和需要保持登录态的页面，记录当前出口IP和切换时间。
- 在天行IP客户端或所用代理管理工具中主动断开旧节点，确认状态不再显示已连接。
- 完全退出目标应用，包括浏览器后台驻留进程；不要只关闭一个标签页或窗口。
- 选择新节点后重新核对服务器、端口、代理协议和认证方式，保存配置再连接。
- 先打开一个全新的检测窗口，连续检查两到三次；确认出口、地区和任务要求一致后，再恢复业务。
如果应用支持“清空连接池”“新建身份”或“重启内核”，可以在切换后使用，但菜单名称和效果取决于具体客户端。不要把清理 Cookie 当成必需步骤：Cookie 影响网站会话，出口IP由网络链路决定，两者不是同一层问题。
检查进程代理、系统代理和绕过列表
同一台电脑可以同时存在应用代理、系统代理、PAC 规则和虚拟网卡。天行IP配置在浏览器扩展里时，只有受扩展控制的浏览器请求会经过该节点；配置在系统层时，明确绕过代理的应用仍可能直连。反过来，老鱼加速器、有米加速器或其他网络工具如果后启动，也可能重新接管系统代理或路由。
排查时只保留一条测试链路：关闭不相关的代理工具，暂时移除 localhost、局域网地址之外的绕过规则，让一个新进程只使用一个明确节点。测试完成后再逐项恢复原配置。若同时更换协议、节点和客户端，就无法判断究竟是哪项变化带来结果。
指纹浏览器为什么容易出现“环境没切换”
指纹浏览器通常把代理参数绑定到具体环境。修改公共代理库，不代表已经运行的环境会自动更新。应先停止环境，再核对该环境实际引用的代理记录、协议、端口和认证字段。批量任务中还要防止多个环境引用同一条旧记录，造成看似切换、实际仍共用出口。
“单窗口单IP”是一种映射与管理目标，不是只靠命名就能实现。建议给每个环境记录环境ID、节点ID、预期地区、最近检测IP和检测时间；启动前比对预期值，启动后再记录实际值。两列不一致时暂停任务，而不是继续扩大批次。
排除检测缓存与DNS误判
检测页可以使用无痕窗口、不同检测服务或带时间戳的新请求交叉确认。不要仅凭网页显示的地区名称判断出口是否变化，因为不同数据库的地区标签可能不同；应优先比较完整IP地址。DNS解析位置也不能替代出口IP，两者需要分别检测。
若完全退出应用、重建连接并使用多个检测入口后仍显示旧IP，再检查新节点是否已生效、订单是否仍有效以及客户端日志中实际连接的服务器。把切换时间、旧节点、新节点、协议、错误提示和检测结果整理后再联系客服，能减少来回沟通。
结论：先证明新连接走向，再处理业务
天行IP切换节点后出口IP没变，最稳妥的排查顺序是：断开旧节点、退出进程、确认新参数、建立新连接、用新请求检测。旧会话复用、进程规则冲突和批量环境映射错误，比单纯刷新网页更值得优先检查。只有在单进程、单节点、无其他代理接管的条件下仍可复现，才适合把问题提交给平台进一步核对。
