代理连接池为什么会继续使用旧IP？换节点后要重建连接

代码已经把代理配置从节点A改成节点B，下一次调用IP查询接口却仍返回A。常见原因是HTTP客户端复用了旧连接池：配置变量已经更新，但此前建立的TCP、TLS、HTTP/2或HTTP/3会话仍连接着旧代理。网络连接不会因为一个对象字段改变而自动迁移。

连接池为什么会保留旧出口

建立代理连接需要DNS、TCP、认证、CONNECT和TLS握手，成本较高。客户端为了性能会把连接放入池中供后续请求复用。只要旧池仍被请求管理器引用，新请求就可能继续从旧代理发送。

为什么强制关闭所有连接也有风险

直接销毁旧池会中断在途请求、下载、流式响应和WebSocket。写操作若重试不当，还可能重复提交。正确切换要先停止给旧池分配新请求，再排空或取消在途请求，最后关闭资源。

一套安全的切换流程

1. 生成不可变的新配置。包含节点ID、协议、认证引用、超时和配置版本，不在原对象上并发修改。
2. 创建新客户端和新池。用节点B建立独立连接，不复用A的连接管理器。
3. 先做健康验证。通过自有诊断接口确认B的DNS、认证、TLS和出口。
4. 原子切换新请求。路由层把之后创建的请求交给B，同时停止A接收新任务。
5. 排空旧池。等待安全的在途请求完成；超过截止时间后按业务规则取消。
6. 关闭旧连接。释放TCP、HTTP/2、QUIC、DNS与后台线程资源。
7. 持续观察。按请求记录配置版本和节点ID，确认不再出现A。

高并发下为什么会出现A和B混合

配置切换不是瞬时清空所有任务。切换前进入队列的请求、重试任务、后台刷新和长连接仍可能使用A；切换后的新请求使用B，所以短时间看到两个出口是可解释的。

应给请求绑定“创建时的配置版本”或明确的节点ID，日志才能区分正常排空与错误复用。

HTTP/2多路复用要特别注意

HTTP/2在一条连接上并发多个请求。不能为了让一个新请求换代理而无损迁移其他流。应建立B的新会话，A进入draining状态，不再创建新流，待现有流结束后关闭。

长连接和流式请求可能永远不自然结束，需要定义最大排空时间和业务恢复机制。

DNS缓存会制造另一种“旧IP”

如果代理A和B其实是同一个主机名背后的不同地址，应用可能仍使用旧DNS缓存；这与连接池复用相似但不是同一层。记录连接的实际代理IP、DNS TTL和解析时间。不要通过无限刷新DNS解决已有连接，解析变化也不会迁移套接字。

失败重试可能又回到旧节点

客户端重试器、熔断器或备用代理列表可能仍包含A。B失败后自动回退A，IP查询又显示旧出口。检查代理选择算法、PAC、故障转移和重试上下文，而不仅是主配置。

怎样验证切换真正完成

可用IP111查询辅助核对出口，但高并发服务最好使用自有诊断端点，并把请求ID、节点ID和配置版本串联。

日志不要泄露代理凭据

记录节点内部标识、目标主机脱敏值、连接创建时间、池ID、配置版本和出口即可。不要打印完整代理URL、Authorization、Cookie或会话密钥。发生凭据泄露时及时轮换。

什么时候必须重启应用

如果客户端库不支持动态替换连接管理器、旧单例无法安全关闭，受控滚动重启可能比热修改更可靠。应先停止接流量、排空请求，再逐实例重启并验证，不直接杀死承载写请求的进程。

需要其他代理和开发工具时，可从极跃圈网址导航选择。真正的切换完成标准不是配置文件已改，而是新请求只使用新池、旧池停止接流量并最终释放。