AI 域名分流教程：固定走同一个节点

如果你已经读过 Claude Code 断流排查或 Gemini 地区不支持，会发现两篇的解法都指向同一个动作：把 AI 服务的域名钉死在一个手动指定的节点上。那两篇讲的是「为什么」，Clash 教程和 Shadowrocket 教程讲的是客户端基础操作，本页只补中间那个操作层缺口——具体怎么写这套规则。

这套配置适合谁

适合：跑长任务会被中途打断的人；反复被要求重新登录的人；同一个服务时好时坏、怀疑是节点在换的人；同时在电脑和手机上用同一套订阅、希望两端行为一致的人。

不需要：只是偶尔打开网页问两句的人——固定选一个节点手动用就够了，不必配规则。

前置条件：你的客户端支持自定义规则。Clash 系需要 mihomo 内核的客户端，iOS 侧 Shadowrocket 原生支持。

动手前：备齐三样东西

1. 一个已验证可用的节点，以及它在订阅里的完整名称。打开节点列表，把名字一字不差地复制下来（包含空格、符号、emoji）。怎么判断一个节点适不适合这类场景，见 AI 场景选型标准。
2. 客户端的覆写入口。机场订阅是远程配置，直接编辑订阅生成的文件，下次更新就被覆盖。Clash 系客户端一般提供合并（Merge）或脚本类的扩展配置；找到它，你的改动才是持久的。
3. 要覆盖的域名清单。常见的一批：

服务方向	需要覆盖的域名后缀（示例）
Claude	anthropic.com、claude.ai
ChatGPT	openai.com、chatgpt.com
Gemini	gemini.google.com、aistudio.google.com、generativelanguage.googleapis.com

这张表只是起点。各家的域名会增减，以你自己在连接记录里看到的实际域名为准，本文最后一节给出核对方法。

Clash 侧：一个专用策略组 + 一批前置规则

在覆写配置里写入两段。第一段是策略组：

proxy-groups:
  - name: AI-Fixed
    type: select
    proxies:
      - '此处填你复制下来的节点完整名称'

type 必须是 select（手动选择）。写成 url-test 或 fallback 就等于又把选路权交回给客户端，配了等于没配。

第二段是规则，注意它们要被前置到规则表最上方：

rules:
  - DOMAIN-SUFFIX,anthropic.com,AI-Fixed
  - DOMAIN-SUFFIX,claude.ai,AI-Fixed
  - DOMAIN-SUFFIX,openai.com,AI-Fixed
  - DOMAIN-SUFFIX,chatgpt.com,AI-Fixed
  - DOMAIN-SUFFIX,gemini.google.com,AI-Fixed
  - DOMAIN-SUFFIX,aistudio.google.com,AI-Fixed
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,AI-Fixed

规则表是从上往下逐条匹配、命中即停。放在兜底规则（MATCH / GEOIP 那几条）后面，就永远不会被命中——这是这类配置最常见的失败原因。

检查点：保存并重载配置后，代理页应该出现一个名为 AI-Fixed 的分组，点进去能看到你指定的那个节点且已选中。如果分组是空的，说明节点名字没对上，回去重新复制。

Shadowrocket 侧：同名策略组，同一批规则

iOS 侧的思路完全一样，只是语法与入口不同。进入配置文件的编辑界面（不同版本的菜单文字略有差异，你要找的是「配置」→ 编辑当前配置这条路径），在两个段落里各加内容。

[Proxy Group] 段加一行：

AI-Fixed = select, 节点完整名称

[Rule] 段的最前面加：

DOMAIN-SUFFIX,claude.ai,AI-Fixed
DOMAIN-SUFFIX,anthropic.com,AI-Fixed
DOMAIN-SUFFIX,chatgpt.com,AI-Fixed
DOMAIN-SUFFIX,gemini.google.com,AI-Fixed
DOMAIN-SUFFIX,aistudio.google.com,AI-Fixed
DOMAIN-SUFFIX,generativelanguage.googleapis.com,AI-Fixed

同样注意：[Rule] 段末尾一般有一条 FINAL 兜底，你的规则必须在它之前。另外确认「全局路由」处于按配置分流的状态，否则规则表根本不参与判断。

检查点：回到首页，节点列表上方应出现 AI-Fixed 这个组，可以点进去手动选择。

验证：三个动作，缺一不可

配完不验证等于没配。按这个顺序做：

1. 看命中记录。Clash 系客户端有连接（Connections）页，访问一次目标站点后，找到对应域名的那条连接，看它的规则列与代理链列是不是 AI-Fixed。Shadowrocket 也有类似的流量记录。这是最直接的证据。
2. 核对出口。在浏览器里访问 IP 检测页面，确认出口与你指定的节点一致。注意这一步只能验证浏览器的默认出口，不能替代第 1 步。
3. 反向验证（最能说明问题）。把 AI-Fixed 组临时切到直连，然后刷新目标站点——应该立刻打不开。如果还能打开，说明这些请求根本没走你的规则，走的是别的分组，回去检查规则位置。

六个最常见的配置错误

现象	原因	处理
策略组是空的	节点名与订阅不一致	从节点列表原样复制
规则完全不命中	规则排在兜底规则之后	前置到规则表最上方
更新订阅后配置消失	直接改了订阅生成的文件	改用客户端的覆写层
网页能用、命令行或 App 不行	只覆盖了主站，漏了接口域名	按连接记录补齐域名后缀
出口还是会自己变	策略组类型用了自动测速	改成手动选择类型
有时命中有时不命中	DNS 解析先行导致域名信息丢失	用域名类规则而非 IP 段规则

安全提醒：整个过程中不要把订阅链接粘贴到任何在线 YAML 校验、订阅转换或「配置生成」网站——那条链接等同于你的账户凭据，交出去就无法收回。客户端只从项目官方发布页下载，不要用第三方修改版安装包或来路不明的「一键配置包」。

配完之后

这套规则是长期资产，不是一次性操作。三件事值得跟进：

• 定期回连接记录里看一眼有没有新域名漏网，尤其在服务方更新之后。
• 如果固定节点开始不稳，先换组内的另一个节点，而不是急着改回自动切换。
• 规则配好了仍然频繁断流或掉登录，说明问题不在配置层，回到 Claude Code 断流排查的第三、五步；如果怀疑是线路本身不适合这类场景，判断依据与候选名单见 ChatGPT 机场专题。