只让 AI 工具走代理：Claude / ChatGPT / Gemini / Copilot 域名与进程分流清单

常见的两种极端都不太舒服：全局代理一开，国内网站慢半拍、游戏延迟往上跳、公司内网直接够不着；完全不开代理，Claude Code 和 Cursor 又连不上。中间那条路是白名单式分流——只把 AI 服务的域名和进程送进代理组，剩下所有流量保持直连。

这篇给的是清单和可粘贴的 YAML，不重复讲规则语法。语法基础见规则分流入门，规则写在哪、Merge 怎么保存见Merge 自定义规则。

先决定要不要做这件事

精细分流和开 Tun 全局是两条互补的路，不是竞争关系。Tun 模式给 AI 工具配全局代理那篇解决的是「工具根本不读系统代理」——开一个开关，整机流量在虚拟网卡层被接管，所有 CLI 和编辑器一次到位。这篇解决的是另一半问题：接管之后，哪些流量该走出去、哪些该留在本地。

值得花力气写白名单的场景有三类。一是节点带宽有限，你不希望网盘下载和系统更新去抢那点出口。二是打国服游戏或用国内加速器，绕一圈代理会让延迟从 30ms 变成 80ms。三是公司内网域名和 VPN 共存，代理一接管就解析不到内网主机。这三类之外，日常只是想让 AI 工具能用，开 Tun 更快，别给自己找活干。

方向相反的需求——已经开了代理，想把游戏和下载单独放回直连——在直连规则怎么写那篇。两篇的规则可以拼在同一份 Merge 里：白名单负责把 AI 送出去，黑名单负责把重流量拉回来，中间靠订阅原有的规则兜底。

域名清单：按用途分四类

大多数人写这类规则的失败点都一样——只放行了主域名。AI 服务的一次完整会话至少牵扯四类域名：网页端资源、API 端点、登录鉴权、遥测与更新。前两类漏了会直接报错，容易发现；第三类漏了表现为「打得开、登不进」；第四类漏了最阴，症状是启动慢、偶发卡顿，但不报错。

Anthropic / Claude

platform.claude.com 是这张表里最容易漏的一条。它的名字看起来像「开发者控制台」，很多人以为自己用订阅账号就不需要，实际上 claude.ai 账号的 OAuth token 交换和刷新也走这个主机。写规则时只要 anthropic.com、claude.ai、claude.com 三条后缀，就能把上表绝大部分覆盖掉。

OpenAI / ChatGPT

challenges.cloudflare.com 值得单独说。它不是 OpenAI 的域名，是 Cloudflare 的验证服务，很多「一直卡在人机验证转圈」的案例就是这条走了直连、和主站不同出口导致验证失败。放行时用精确匹配的 DOMAIN 而不是 DOMAIN-SUFFIX，别把整个 cloudflare.com 拖进代理。文件上传下载失败但对话正常，多半是 oaiusercontent.com 漏了。

Google Gemini

Gemini 是四家里最依赖登录链路的：Google 账号登不上，后面全免谈。accounts.google.com 和 oauth2.googleapis.com 必放。另外 Gemini 对出口地区敏感，规则写对了但还是提示地区不支持，那是节点问题不是规则问题，见Gemini 地区限制排错。

GitHub Copilot 与 Cursor

Copilot 这边 default.exp-tas.com 是经典漏网之鱼——它只负责实验开关，看起来无关紧要，但连不上时 Copilot Chat 会长时间没反应，诊断面板里显示这条返回 HTTP 400。Cursor 官方推荐直接放行 cursor.sh、cursorapi.com、cursor-cdn.com 三个通配，因为它的子域名会随功能增加，逐条列反而追不上。Copilot 的其它症状见Copilot 登录与补全排错。

三种写法怎么选

同一个需求有三种表达方式，各有适用面，混着用比只用一种好。

• DOMAIN-SUFFIX / DOMAIN：精确、可读、改起来一目了然。适合上面这些已知域名。后缀会连子域一起匹配，写 anthropic.com 就覆盖了 api、statsig、mcp-proxy 三个子域，四条抵一张表。缺点是清单会过期。
• RULE-SET（rule-provider）：引用远程维护的规则集，别人更新你自动跟上。适合懒得维护清单的人。代价是多一层网络依赖，规则集拉不下来时行为不确定，而且你不知道里面到底放了什么——排错时读不懂命中的那条规则从哪来。
• PROCESS-NAME / PROCESS-PATH：按进程匹配，「这个程序的所有流量都走代理」。CLI 工具用这个最省事，不用追域名。前提条件多一些，下面单独说。

推荐的组合是：域名规则打头做精确匹配，进程规则垫底做兜底。这样已知域名走明确的组，工具偷偷换了个新端点也不会漏。

进程名的三个坑

第一，平台不同名字不同。Windows 上带扩展名（claude.exe、codex.exe、Cursor.exe），macOS 和 Linux 上不带（claude、codex、Cursor）。同一份配置在两台机器上跑，两套都得写。

第二，npm 安装的 CLI 可能不叫自己的名字。Claude Code 现在有原生安装器，会在用户目录下放一个独立的 claude 可执行文件；但通过 npm 装的旧版本、或者走 cli-wrapper 的场景，实际发起请求的是 node 进程。Gemini CLI 是 npm 包，同样表现为 node。写 PROCESS-NAME,node 能解决问题，但代价是所有 Node 程序都被送进代理——包括你本地的开发服务器。这种情况改用 PROCESS-PATH 指到具体路径更安全。

第三，进程匹配要内核拿得到进程信息。桌面端最稳的做法是开 Tun 或装服务模式；只开系统代理时，部分平台的进程归属拿不全，连接页那一列会是空的。同时确认配置里的 find-process-mode 不是 off——它有 strict（默认，内核自行判断）、always（强制匹配）、off（完全不匹配）三个取值，跑在路由器上的配置常写 off，抄过来就会全军覆没。

可以直接粘的完整 YAML

先说清楚入口，抄错地方会白忙一场：v1.6.x 的 Merge 配置认 prepend-rules / prepend-proxy-groups；v1.7.x 起 Merge 改名「扩展配置」，官方文档说明它只做键值覆写，列表值会被整体覆盖，prepend/append 已移到订阅右键菜单的「编辑规则」「编辑代理组」里。下面这份就按当前版本的编辑器来分两段填。

第一段填进「编辑代理组」的 prepend 区，建一个手动组：

  - name: AI
    type: select
    proxies:
      - 节点选择          # 改成你订阅里真实存在的组名或节点名
      - DIRECT

第二段填进「编辑规则」的 prepend 区，顺序就是匹配顺序：

  # --- 1. 本地与内网，任何时候都排最前 ---
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,corp.example.com,DIRECT    # 换成你公司内网后缀

  # --- 2. Anthropic / Claude：三条后缀覆盖 API、鉴权、更新 ---
  - DOMAIN-SUFFIX,anthropic.com,AI
  - DOMAIN-SUFFIX,claude.ai,AI
  - DOMAIN-SUFFIX,claude.com,AI
  - DOMAIN-SUFFIX,claudeusercontent.com,AI

  # --- 3. OpenAI / ChatGPT ---
  - DOMAIN-SUFFIX,openai.com,AI
  - DOMAIN-SUFFIX,chatgpt.com,AI
  - DOMAIN-SUFFIX,oaistatic.com,AI
  - DOMAIN-SUFFIX,oaiusercontent.com,AI
  - DOMAIN-SUFFIX,workos.com,AI              # 企业 SSO 登录
  - DOMAIN-SUFFIX,statsig.com,AI             # 功能开关
  - DOMAIN-SUFFIX,statsigapi.net,AI
  - DOMAIN-SUFFIX,featuregates.org,AI
  - DOMAIN-SUFFIX,featureassets.org,AI
  - DOMAIN,challenges.cloudflare.com,AI      # 人机验证，用精确匹配

  # --- 4. Google Gemini：登录链路必须一起放 ---
  - DOMAIN-SUFFIX,gemini.google.com,AI
  - DOMAIN-SUFFIX,aistudio.google.com,AI
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,AI
  - DOMAIN-SUFFIX,cloudcode-pa.googleapis.com,AI
  - DOMAIN-SUFFIX,accounts.google.com,AI
  - DOMAIN-SUFFIX,oauth2.googleapis.com,AI
  - DOMAIN-SUFFIX,apis.google.com,AI

  # --- 5. GitHub Copilot ---
  - DOMAIN-SUFFIX,githubcopilot.com,AI
  - DOMAIN-SUFFIX,exp-tas.com,AI
  - DOMAIN,copilot-proxy.githubusercontent.com,AI
  - DOMAIN,copilot-telemetry.githubusercontent.com,AI
  - DOMAIN,api.github.com,AI
  - DOMAIN-SUFFIX,github.com,AI

  # --- 6. Cursor：官方建议用通配，子域会变 ---
  - DOMAIN-SUFFIX,cursor.sh,AI
  - DOMAIN-SUFFIX,cursor.com,AI
  - DOMAIN-SUFFIX,cursorapi.com,AI
  - DOMAIN-SUFFIX,cursor-cdn.com,AI

  # --- 7. 进程兜底：接住清单里还没有的新域名 ---
  - PROCESS-NAME,claude,AI
  - PROCESS-NAME,claude.exe,AI
  - PROCESS-NAME,codex,AI
  - PROCESS-NAME,codex.exe,AI
  - PROCESS-NAME,Cursor,AI
  - PROCESS-NAME,Cursor.exe,AI

三处必须自己改：AI 组里的 proxies 要填订阅中真实存在的组名，写错名字整份配置可能加载失败；corp.example.com 换成你公司的内网后缀，没有内网就删掉这行；进程名按你实际装的方式核对，用 npm 装的 Gemini CLI 要写 node 或用 PROCESS-PATH。

这份配置里没有 MATCH，也没有 GEOIP,CN,DIRECT，这是故意的。prepend 区里一旦出现兜底规则，订阅自带的整套规则就全废了，等于你手写了一份残缺的分流表。兜底交给订阅原有的最后一条。

想用远程规则集

不想维护清单的话，用 rule-provider 引一份别人维护的。rule-providers 是映射不是列表，可以直接写进「扩展配置」；引用它的那一行仍然放「编辑规则」的 prepend 区。

rule-providers:
  ai-services:
    type: http
    behavior: classical
    format: yaml
    url: "https://你选定的规则集地址.yaml"
    path: ./ruleset/ai-services.yaml
    interval: 86400

然后在「编辑规则」的 prepend 区加一行：

  - RULE-SET,ai-services,AI

URL 自己去规则仓库里复制，别抄文章里的——规则集的路径经常改，抄到失效地址后表现是「规则像没写」，排查半天才发现是 provider 拉取失败。behavior 要和规则集的实际类型对上：classical 支持完整规则语法，domain 只放域名，写错类型会解析失败。用了 provider 之后，建议同时保留几条手写的 DOMAIN-SUFFIX 兜底，provider 挂了还有路可走。

规则顺序：写了等于没写的头号原因

Clash 从上到下匹配，第一条命中就停止，后面的规则再对也不看。这条机制决定了绝大多数「规则不生效」的真相：你的规则被前面某条更宽的规则截胡了。

1. 本地与内网直连排最前。回环地址、私有网段、公司内网后缀。这几条要是排在 AI 规则后面倒不至于出事，但排在最前面能省掉一类奇怪问题。
2. AI 域名规则排第二层。它们必须在订阅的 GEOIP 与 MATCH 之前，写进「编辑规则」的 prepend 区天然满足这一点。
3. 进程规则排 AI 域名之后。因为进程匹配比域名匹配开销大，让能被域名命中的先走掉。
4. 其余交给订阅。你的自定义规则到此为止，剩下的国内直连、广告拦截、兜底全部由订阅原有规则处理。

典型的翻车写法是把 AI 规则贴在订阅配置文件的末尾，或者写进 append 区。那个位置在 GEOIP,CN,DIRECT 和 MATCH 后面，AI 域名早被兜底吃掉了，你写多少条都没用。同一份 prepend 区里还有直连规则时，把更具体的那条放前面——PROCESS-NAME 和 DOMAIN-SUFFIX 谁优先，只取决于谁写在上面。

怎么确认某条规则真的命中了

改完规则不要凭感觉判断，跑一次验证只要一分钟。

1. 保存 Merge，重载配置（订阅更新或手动重载，不重载等于没改）。
2. 打开连接页，清空现有连接列表。
3. 触发一次真实请求：在 Claude Code 里发一句话，或在 Cursor 里让它补全一行。别用 ping 或浏览器打开首页代替，那走的可能是另一条路径。
4. 回连接页找这条连接，看「规则」列。显示 DOMAIN-SUFFIX,anthropic.com 并且代理组是 AI，说明命中了你写的那条；显示 GEOIP 或 MATCH，说明被兜底吃了，回去检查顺序。
5. 还想更细，把日志级别调到 info，日志里会有一行写明这条连接匹配了哪条规则、用了哪个策略组。命中信息和连接页对不上时，以日志为准。

连接页完全没有这条连接的记录，问题不在规则——流量根本没进 Clash。那是系统代理或 Tun 的问题，转系统代理不生效。有记录、进了 AI 组、还是失败，那是节点问题，换地区节点，参考Claude Code 代理配置里的分层排查。日志读法见日志排查。

清单会过期，学会自己抓

上面这张表的保质期大概是几个月。举个近的例子：GitHub 在 2026 年 2 月改了 Copilot 编码代理的网络配置，按订阅计划把端点拆成 api.business、api.enterprise、api.individual 三个主机，原来只放行 api.githubcopilot.com 的人得跟着改。指望文章永远最新不现实，自己抓才是长久办法。

抓法很简单：清空连接页，只做一个动作——登录一次、发一条消息、触发一次补全，然后看列表里新增了哪些域名。一次只做一个动作是关键，同时打开三个工具会分不清哪条属于谁。抓到可疑域名后，先整条加进 AI 组确认能用，再逐条挪回 DIRECT 做二分，找出真正必需的那几条。这个过程比一次性照抄一百条规则可靠得多，也顺便让你知道每条规则为什么存在。

遥测类域名（statsig、sentry、telemetry 系列）漏掉通常不会报错，只表现为启动慢或偶发卡顿。碰到「能用但就是慢」，优先怀疑这一类，而不是换节点。

什么时候该停手

验收标准三条：AI 工具能正常登录并对话；打开国内网站、下载器、游戏时连接页显示 DIRECT；公司内网域名能解析能访问。三条都过就停下，不要再「预防性」加规则——加得越多，下次出问题时你越难判断是哪条在作怪。

改之前把 Merge 文本复制一份存别处，越改越乱时粘回去，止损只需要一步。规则调稳后记得备份配置，换机器时这份清单比订阅链接更难重建。客户端版本太旧会不支持部分规则类型，安装包在下载中心。