ConnProof

different domains use different exit routes：不同域名出口不一致 ​

ROUTE-001different domains use different exit routes严重程度 Info
一句话结论

不同域名的请求经由不同的出口线路离开，各站点看到的来源地址因此不一致。这通常是分流规则的正常结果而非故障；需要判断的是这种不一致是否影响了你的具体业务（如登录风控），再决定是否收敛出口。

适用环境WindowsmacOSLinuxAndroidiOS
适用客户端通用客户端
最后验证：2026-07-28规则版本：v1内容更新：2026-07-28

结论 ​

先说清楚性质：出口不一致本身不是错误，它是分流规则忠实工作的结果——规则说 A 类域名走节点一、B 类走节点二、C 类直连，三类流量自然从三个出口冒头。它成为"问题"只在特定场景：同一个服务的不同域名被拆到了不同出口，而那个服务在校验请求来源的一致性。典型受害者是登录风控严格的站点：页面从出口甲来、接口请求从出口乙来，风控当场拉响警报，表现为反复要求验证、登录态莫名失效。

适用环境 ​

  • 全部平台
  • 使用分流规则（规则模式）的所有客户端；登录态敏感的站点场景

一分钟快速判断 ​

  1. 回忆症状：是"连不上"还是"登录态异常/反复验证"？前者不是本条错误的范畴；后者继续；
  2. 临时切全局模式（所有流量走同一节点）复现原操作。异常消失 → 确认是出口不一致触发了风控，转"如何收敛"；
  3. 查客户端连接记录：找到该服务涉及的几个域名（主站、API、静态资源、验证服务），看它们各自被判到了哪个分支——不一致会直接摆在眼前。

这条错误代表什么 ​

现代网站几乎没有"一个域名打天下"的：页面在主域，接口在 api.，登录在 passport.，资源在 CDN 域。分流规则按域名逐条匹配，这些兄弟域名很容易命中不同规则——尤其当规则集里只收录了主域而漏掉了 API 域时，一半流量走代理、另一半直连是常态。对绝大多数浏览场景这毫无影响；对来源敏感的业务（银行、支付、部分游戏和账号系统），同一会话的来源地址漂移则是标准的风控触发条件。

ConnProof 如何判断 ​

对该服务涉及的每个域名分别做出口一致性观察：

connproof diagnose 主站域名
connproof diagnose api域名

在客户端开启的状态下运行，报告中的连接证据（结合客户端连接记录的分流判定）可以拼出"域名 → 出口"的映射表。ConnProof 不会展示完整出口地址（默认部分遮盖），但遮盖后的地址段差异已足够判断"是否同一出口"。

最常见原因 ​

  1. 规则集只覆盖主域：example.com 在代理名单里而 api.example.com 不在（或相反）；
  2. 不同规则源的叠加：多个订阅规则集合并后，同一服务的域名散落在不同分组；
  3. 负载均衡策略：分组内开了轮询/最低延迟自动切换，同一分组的请求也在多个出口间跳动；
  4. DNS 分流：部分域名走远程解析、部分走本地解析，间接导致连接路径分叉。

Windows / macOS 排查步骤 ​

  1. 客户端连接记录里筛出目标服务的全部域名与各自分流判定；
  2. 为该服务建一条聚合规则：用域名后缀（DOMAIN-SUFFIX）把主域及其所有子域指向同一个固定节点（不是自动选择分组）；
  3. 规则顺序检查：自建规则要放在通用规则集之前，否则先匹配先赢，你的修正永远轮不上；
  4. 复测原业务操作，风控异常应消失。

手机端排查步骤 ​

  • 手机客户端同样看连接记录/日志面板做域名映射；
  • 改规则不便时，务实的替代方案：对风控敏感的操作临时切全局模式 + 固定节点，做完再切回规则模式；
  • 部分手机客户端支持按应用分流，把敏感应用整体绑定到固定节点也是干净的收敛方式。

如何区分本地问题和节点问题 ​

这条错误的"修复"更多是配置决策而非故障排除：

观察结论
全局模式下异常消失分流出口不一致（改规则收敛）
全局 + 固定节点下仍异常与出口一致性无关，另查账号/服务本身
固定节点后出口仍变化该"节点"背后是动态出口池（换真正固定出口的节点）
只有特定站点敏感该站风控严格，为它单独建聚合规则即可，不必全局收敛

最后一行值得展开：不要因为一个站点的风控就放弃整个分流体系——分流带来的速度与成本收益是真实的，正确做法是精确地为敏感服务开例外，而不是一刀切回全局。

隐私提醒：出口地址证据的处理 ​

整理"域名 → 出口"映射表时会接触到出口地址，分享前注意两点：其一，完整的出口地址属于可定位你的信息，ConnProof 报告默认只保留地址段前缀，自行整理的表格也应照此遮盖；其二，不要把客户端连接记录整页截图外发——里面往往混着与问题无关的其他域名访问记录，等于把浏览历史一并交了出去。只摘录与该服务相关的几行，遮盖地址后段，就足够支撑结论了。

仍未解决时收集什么信息 ​

  • ConnProof 错误码（ROUTE-001）与脱敏报告；
  • 该服务的域名 → 分流判定映射表（客户端连接记录整理，遮盖完整地址）；
  • 全局模式对照结果；
  • 客户端名称和版本。

禁止提交：完整订阅链接、密码、验证码、私钥、Token、完整出口 IP。

重新运行检测 ​

connproof diagnose api域名 --format markdown --output route-report.md

收敛后，同一服务全部域名的连接应稳定走向同一分流分支。

相关文档 ​

更新记录 ​

  • 2026-07-28：规则 v1 发布，明确"配置预期 vs 业务影响"的判断框架。