两个网站走不同代理出口：sing-box 域名分流

两个网站分别需要不同的代理出口：网站 A 使用节点 1 无法访问，换节点 2 可以；网站 B 恰好相反。每次访问前手动切换全局节点能解决单次访问，但不能让两个网站同时稳定使用。

在 Windows 上使用 GUI.for.SingBox v1.25.4，我采用了两条域名路由规则：让网站 A 固定走出口 2，网站 B 固定走出口 1。两个站点的访问测试已经通过，Connections 面板也分别显示了命中的域名规则和选定的出站链路。本文整理最小配置与验证方法，再说明哪些更复杂的能力值得以后使用。

这里的 IP1、IP2 是两个不同代理节点的公网出口 IP，不是 IPv4 和 IPv6。所谓「不支持」，只是这次测试中相应节点无法正常访问特定服务；没有据此推断网站采用了哪一种封禁或风控策略。

最小目标：按域名指定代理出口

期望的流量路径很简单：

Windows / Chrome
  └─ GUI.for.SingBox（规则模式）
      ├─ 网站 A 的域名 → 专用出站 A → 节点 2
      ├─ 网站 B 的域名 → 专用出站 B → 节点 1
      └─ 其他域名     → 原有分流规则

前提是两个节点都已经在客户端中配置完成，并且单独切换节点时验证过上述可访问性。最好先确认它们的实际公网出口确实不同，否则两个节点名称不同并不代表出口不同。

操作时先保留现有配置，只增加两个最具体的规则：

在「出站设置」中创建两个手动选择分组，例如 site-a-out 和 site-b-out；分别选择能访问对应网站的节点。也可以直接把路由规则指向现有节点标签，不一定非要建立分组。
在当前配置的「路由设置 → 规则」中，分别添加域名后缀（domain_suffix）匹配；动作设为 route，出站分别选择刚才的标签。
使用规则模式（rule）。将这两条专用路由放在可能提前覆盖它们的宽泛规则之前，避免被默认代理、直连或地区规则先匹配。
保存并重新加载配置，关闭相应网站的旧连接后重新访问。

GUI.for.SingBox 的官方图文指南以 v1.9.0 为例，上面的设置名称来自其公开说明；本次实测的客户端是 v1.25.4。界面位置可能改变，具体以当前软件生成的配置和连接日志为准。

在 sing-box 配置中，核心部分大致如下（仅展示规则片段，不可覆盖整个现有配置）：

{
  "route": {
    "rules": [
      {
        "domain_suffix": ["site-a.example"],
        "action": "route",
        "outbound": "site-a-out"
      },
      {
        "domain_suffix": ["site-b.example"],
        "action": "route",
        "outbound": "site-b-out"
      }
    ]
  }
}

site-a.example、site-b.example 和两个出站标签只是示例；真正配置必须替换成自己的域名和已存在的出站标签。此处省略了必要的入站、出站节点、DNS 和原有路由规则。

怎样判断真的分流成功

只看到网页能打开还不够：有时某个站点在两个节点上都临时可用，或者已有连接尚未按新规则重新建立。

本次在 GUI.for.SingBox 的 Connections 面板里看到，两条不同的 domain_suffix 分别被路由到各自的专用分组，最终链路也显示为预期节点。这与两个网站的实际访问结果一致。

公开记录时省略实际网站、节点及服务器标识，连接结构转写如下；这不是原始日志的逐字复制：

domain_suffix=<网站A域名> => route(<专用出站A>) => <节点2>
domain_suffix=<网站B域名> => route(<专用出站B>) => <节点1>

Connections 面板能证明客户端的规则命中和内部节点选择，却不直接等于「已经测到网站服务端看到的公网 IP」。想更严格地验证，可以在相同节点条件下使用可信的出口 IP 检测服务，或者在自己控制的目标服务上查看服务端记录；不要把第三方站点可访问直接解释为某种 IP 风控已经被永久解除。

如果规则没命中，先看工作模式、规则顺序和连接里的目标域名；涉及 TUN 或只拿到目标 IP 的流量时，再检查 DNS 与协议嗅探，不必一开始就重写整套配置。

为什么不通过 Windows Hosts 解决

Windows Hosts 是本地主机名到目标 IP 地址的映射，例如把 example.com 指向某个服务器地址。微软对 Hosts 的说明也明确了这一用途。它改变的是「去哪个目标地址」，不是「经过哪个本地代理节点出站」。

这两个问题处在不同层：

Hosts / DNS       域名 → 目标服务器 IP
sing-box 路由     访问目标 → 哪个出站节点

如果网站通过 CDN 或多区域部署，强行固定目标地址还可能因为地址迁移、证书与服务端路由差异而出现故障；某些代理侧解析路径也未必使用 Windows 本机的 Hosts。

Hosts 当然仍有用：例如自己维护的网站在 DNS 切换前验证新服务器。但对「网站 A 走代理 IP2，网站 B 走代理 IP1」这个需求，它并不能直接完成出口选择。

域名增多之后：rule-set 才值得考虑

只需要两个网站、两条域名后缀规则时，逐条写最清楚。未来若某项服务同时使用主站、登录域名和独立 API 域名，可以把它们放入一个 rule-set（规则集），再把整个规则集指向同一个出站。

sing-box 官方支持 inline（内联）、local（本地文件）和 remote（远程文件）规则集。下面仅展示内联规则集与一条路由的关系，仍是局部配置示例：

{
  "route": {
    "rule_set": [
      {
        "type": "inline",
        "tag": "service-a-domains",
        "rules": [
          {
            "domain_suffix": [
              "site-a.example",
              "auth-a.example"
            ]
          }
        ]
      }
    ],
    "rules": [
      {
        "rule_set": ["service-a-domains"],
        "action": "route",
        "outbound": "site-a-out"
      }
    ]
  }
}

优势是多个域名共用一条出站策略，后续增删域名更集中；代价是多出规则集维护、引用标签及更新失败的排障成本。远程规则集还能自动更新，但要额外考虑来源可信度、内容变化、下载链路和缓存。对两个稳定域名，用远程规则集反而容易增加不必要的依赖。

其他官方设置：什么时候值得升级

能力	什么时候有用	代价或限制
`domain` 与 `domain_suffix`	只匹配确切域名，或连同子域名一起管理	后缀规则的覆盖范围更广；服务还可能使用第三方认证域名
`selector` 手动选择	某服务需要稳定的指定出口	节点不可用时需要人工切换或预先安排备用节点
`urltest` 自动选择	同一组节点对目标服务都兼容，只需优化连接延迟	测速链接可用、延迟低，不代表特定网站一定能访问
进程匹配	同一电脑上不同应用需要不同路由	只匹配进程不能区分 Chrome 里的两个网站，还依赖客户端取得进程信息
DNS 规则与 `sniff`	连接只有 IP，域名规则没有按预期命中时	必须结合入站、解析路径和协议条件排查；不是所有流量都可稳定提取域名
TUN 入站	需要代理不主动遵循系统代理设置的应用流量	透明接管范围更广，但涉及虚拟网卡、路由、防火墙与网络回环排查

这些能力不必一次启用。尤其不建议把互不兼容的两个出口放进同一个 urltest 分组：自动选择通常依据测试 URL 的延迟，而不是按照网站 A、B 的实际可访问性判断。

如果目前仅在遵循系统代理的浏览器中访问两个网站，先用规则模式和域名路由即可。确实有需要接管的非代理感知应用，再评估 TUN，并遵循官方对自动检测出站接口等设置的说明。

边界：解决了路由，不代表解决所有访问限制

这次办法成立的范围是：本机的流量已经进入 sing-box；能够获得用于匹配的目标域名；两条规则优先命中；两个指定节点仍然可用，且它们的公网出口符合预期。

它不保证网站的账号、会话、地区政策或服务端访问限制一定允许使用，也不会自动处理主站之外的第三方登录和资源域名。遇到登录异常，应该先查连接日志中实际调用了什么域名，再最小范围补规则；不要直接把一整个大型 CDN 的域名都绑到某个节点。

目前两个网站的访问问题已通过最小分流解决。接下来保持这两条规则可读、可检查即可；只有当域名规模或应用覆盖范围真的增长时，才值得引入规则集、复杂 DNS 策略或 TUN。

写作说明：GPT-6 起草；实测结果和连接截图由作者提供。