隧道代理不支持API提取IP，程序里的“领取地址”还要保留吗？

如果所购产品明确不提供提取接口，程序就不应继续等待一批出口地址返回。需要改的是代理配置的来源：把“请求接口领取 IP”换成“读取已交付的隧道入口”，再让 HTTP 客户端通过这个入口发送请求。业务目标 URL 不需要改成代理地址。

这里有一个明确的产品例子：青果隧道代理（全球 HTTP）接口文档说明，该产品不支持 API 提取 IP，提供的是白名单相关接口，接入信息从会员中心查看。这是该产品的文档边界，不能推广成所有品牌、所有隧道产品都没有提取接口，更不能据此判断悟空产品的接口能力。

把“取地址”的一步换掉，而不是伪造一份 IP 列表

下面是迁移思路的伪代码，不是任何服务商的 SDK，也没有真实地址或凭据：

原来的提取模式：
  地址列表 = 调用提取接口()
  当前代理 = 从列表分配一条地址()
  HTTP客户端(代理=当前代理).请求(业务目标URL)

隧道接入模式：
  隧道配置 = 读取受控配置中的入口、端口、协议及鉴权引用()
  HTTP客户端(代理=隧道配置).请求(业务目标URL)

这意味着，本地原先针对“已领取地址”的过期淘汰和补池逻辑，不能直接套到隧道入口上。但请求超时、有限重试和业务结果检查仍然需要保留；套餐有效期、会话时长也仍需管理。入口没有变化，不代表出口不会变化。

如果现有软件只有“粘贴提取 API 链接”的输入框，没有代理主机与端口的配置入口，应先确认它是否另有隧道接入模式。白名单接口不是替代品：把它粘到提取框里，不会得到软件期待的代理列表。软件确实不支持时，需要改接入适配层，或选择它支持的交付方式。

白名单 API 管的是谁能接入

添加、删除和查询白名单，是管理接入资格的操作；提取接口交付的是代理资源。这两类接口的输入和返回含义不同。新增白名单成功，既不代表领取到了一个出口，也不等于业务请求已经经过代理。

因此，不应把白名单调用嵌进每次业务请求之前当作“领 IP”。需要更新白名单时，按该产品的鉴权规则维护；业务请求则使用已经配置好的隧道入口。密钥通过受控配置引用，不写进普通日志。

删掉提取调用后，怎样知道改对了？

在自有或明确授权的测试端点上发起一次低频请求，确认客户端实际使用了代理配置，且目标端收到预期请求。仅看到程序不再报“提取失败”不够，因为某些配置遗漏可能让请求直连。

若任务要求保持同一出口，还需单独按产品会话规则验证；“统一入口”本身不能证明出口固定。需要理解入口与出口的区别，可继续阅读隧道代理 IP 的接入说明。这次迁移的完成标志，是业务请求已经使用正确的隧道配置，而不是终于找到一条并不存在的提取 URL。