BotBrowser Launcher 配置代理并验证出口 IP：可复现流程

BotBrowser Launcher 可以在声明的代理下启动已授权的 profile，但不能修复供应商的上游路由，也不能证明 IP 属于某个人。本文在 BotBrowser Launcher：配置、代理与启动 之外增加可重复的出口 IP 检查，不重复介绍启动概念。

BotBrowser Launcher 支持使用已配置的代理启动已授权 profile 并记录实际路由；它不保证供应商可用性、匿名性或固定的目标 IP。

TL;DR

• 在 Launcher 输入代理 endpoint，记录实际协议和不含密钥的标签。
• 从自己控制的页面检查公网 IP，再用第二个独立 echo 服务对照。
• DNS、WebRTC、时区和语言必须分别记录；一项通过不能证明全部通过。
• 不要把凭据放进截图或 JSON。出口失败是配置或供应商信号，不是身份结论。

内容导航

• 运营价值
• 执行代理出口检查
• 保留小型证据产物
• 排查不一致
• 结论

运营价值

Launcher 指南讲解 profile、启动和代理 URL 的基本形式。实际运维还需要回答：浏览器最终使用了哪个 endpoint？在受控页面发出带时间的请求即可回答。它不替代 代理配置 对协议和 DNS 的区分，也不替代 IPv4 与 IPv6 代理一致性 的地址族检查。

第一次运行使用新的临时 profile。给运行分配 proxy-check-20261016-01，记录浏览器版本、Launcher 版本、系统、协议和 profile 生命周期。profile 标签描述测试，不描述用户。

执行代理出口检查

1. 在 Launcher 选择 profile，输入隐藏凭据的 endpoint，例如 socks5h://user:***@proxy.example.test:1080。
2. 打开自己控制的 HTTPS echo 页面，记录公网地址、地址族、时间和 HTTP 状态。
3. 在同一上下文打开第二个 echo endpoint。结果不同可能来自路由、缓存或地址族，不能直接断言某一方错误。
4. 通过受控 endpoint 判断测试域名由代理解析、本地解析还是未知。
5. 将浏览器观察到的语言、时区与预期代理区域对照，再决定是否修改 profile。

把结果保存成表格：Echo A、Echo B、DNS 边界、WebRTC 结果和语言。每行都写清它能证明什么，以及不能证明什么。

保留小型证据产物

{
  "runId": "proxy-check-20261016-01",
  "browser": "Chrome 155.0.8059.80",
  "hostOs": "macOS 15",
  "profile": "fresh-temporary",
  "protocol": "socks5h",
  "echoA": { "status": 200, "family": "ipv6" },
  "echoB": { "status": 200, "family": "ipv6" },
  "dns": "proxy-side",
  "webrtc": "no-public-candidate",
  "localeMatch": true,
  "testedOn": "2026-10-16"
}

这个记录不含凭据、cookie 或完整 resolver 日志，只表示指定 fixture 的观察结果。协议细节见代理配置和 IPv4 与 IPv6 代理一致性。

排查不一致

如果两个 echo 都看到主机地址，先检查 Launcher 保存的 scheme 和端口，再用新 profile 重试。如果只有一个服务不同，比较它的重定向链和地址族。如果 socks5h 仍显示本地 DNS，先确认供应商是否支持代理侧 DNS。

如果 WebRTC 暴露公网候选，记录确切浏览器和路由。ICE 设置不能重写供应商的上游路径。语言或时区不一致时先保存原始差异，再决定哪一项是本次测试的权威输入。

不要发布代理凭据或流量追踪。供应商超时、认证失败和直接连接回退由不同责任方处理；证据产物要保留这个边界而不是保留秘密。

结论

Launcher 配置只有在记录实际出口 IP、两次 echo 响应、DNS 边界、WebRTC 结果和 profile 后才便于复核。这是对授权流程的有限观察，不是匿名性或供应商控制能力的承诺。

来源

• 代理与隧道（MDN）
• WebRTC（W3C）
• DNS over HTTPS（RFC 8484）