场景资讯 · Clash 技术博客

ChatGPT、Gemini、Claude 怎么用 Clash 分流？

ChatGPT、Gemini 和 Claude 的网页、登录与模型接口可能使用不同域名。给每个服务绑定稳定策略，并从真实连接记录补规则，能减少登录和长回复时的出口漂移。

阅读正文返回博客
  • ChatGPT
  • Gemini
  • Claude
本文目录
文章作者
Clashare
发布日期
更新时间
预计阅读
约 6 分钟

ChatGPT、Gemini、Claude 要分流，先把网页、登录和 API 分开

ChatGPT、Gemini 和 Claude 的首页能打开，只能证明前端页面的一部分请求成功。账号登录会跳到认证域名，发送消息会访问模型接口，上传文件还会使用对象存储或内容域名；其中一条直连、被拒绝或换了出口，用户看到的往往只是转圈。

先把失败动作写清楚：页面白屏、登录循环、消息发不出去、流式回答中断、文件停在上传中，分别对应不同请求。把它们统称为“AI 打不开”，只能得到一份越来越长却无法验证的域名表。

症状先对应到请求阶段

看到的现象先观察什么不应先做什么
页面白屏或缺少样式脚本、静态资源和 DNS反复更换账号
登录后又回到登录页认证跳转、Cookie 与出口地区只补模型 API 规则
消息一直转圈或中途断开模型接口、流式连接与节点切换只测试首页
文件上传停住上传域名、对象存储和请求体大小把所有 CDN 都加入代理

登录期间先固定出口，不让自动测速组换地区

认证请求和登录后的第一批接口请求如果来自不同出口，可能触发重新验证或让会话失效。排查时建立一个手动策略组，固定一条可用节点，让账号页、主站和接口在一次登录过程中使用同一出口。

这不是说三个服务必须永久共用一个节点。问题确认后可以按 ChatGPT、Gemini、Claude 分组；但每个服务自己的认证和数据请求仍应保持地区一致。账号不可用、服务未对所在地区开放或产品侧限流，也不会因为多写几条 Clash 规则而消失。

域名从真实会话里找，不从旧清单里整包复制

清空连接记录后，只完成一个动作，例如登录 Claude、在 Gemini 发送一条短消息，或从 ChatGPT 上传一个小文件。记录失败前后出现的主机名、命中规则和出站，才知道遗漏发生在哪一层。

从明确的产品入口开始记录：ChatGPT 使用 chatgpt.com，OpenAI API 使用 api.openai.com；Gemini 网页使用 gemini.google.com，Gemini API 常见入口是 generativelanguage.googleapis.com。

Claude 网页使用 claude.ai，Anthropic API 使用 api.anthropic.com。登录跳转、静态资源和上传地址仍要从自己的连接记录补齐。

新规则放在宽泛的 GEOIP、规则集和 MATCH 之前。Google 登录域名还会被 Gmail、YouTube 等服务共用，不要为了 Gemini 直接把 accounts.google.com 之类的宽域名永久绑进 AI 组。

连接记录确认认证请求走错出口时，再把当次出现的主机加入 AI 组并重新验证。

下面不是可直接粘贴的完整配置。先在当前订阅的代理组列表里找一个确实存在的组名，用它替换每一处 YOUR_EXISTING_GROUP；否则配置检查一定会报 group not found。三个 AI 组建好以后，再加入规则。

先把现有组名替换正确，再建立三个 AI 策略组
# 必须先把 YOUR_EXISTING_GROUP 替换成当前配置里真实存在的组名
proxy-groups:
  - name: AI-OPENAI
    type: select
    proxies:
      - YOUR_EXISTING_GROUP
      - DIRECT
  - name: AI-GOOGLE
    type: select
    proxies:
      - YOUR_EXISTING_GROUP
      - DIRECT
  - name: AI-CLAUDE
    type: select
    proxies:
      - YOUR_EXISTING_GROUP
      - DIRECT

rules:
  - DOMAIN-SUFFIX,chatgpt.com,AI-OPENAI
  - DOMAIN,api.openai.com,AI-OPENAI
  - DOMAIN,gemini.google.com,AI-GOOGLE
  - DOMAIN,generativelanguage.googleapis.com,AI-GOOGLE
  - DOMAIN,api.anthropic.com,AI-CLAUDE
  - DOMAIN-SUFFIX,anthropic.com,AI-CLAUDE
  - DOMAIN-SUFFIX,claude.ai,AI-CLAUDE
  - GEOIP,CN,DIRECT
  - MATCH,YOUR_EXISTING_GROUP

这组规则真正生效的证据

  • 配置检查通过，没有 group not found
  • ChatGPT、Gemini、Claude 的测试请求分别命中自己的策略组
  • 登录跳转和发送消息期间出口没有变化
  • 未加入规则的 Google 服务没有被意外带进 AI-GOOGLE

网页正常而 CLI 超时，多半不是同一条代理入口

浏览器通常读取 Windows 或 macOS 的系统代理，Python SDK、命令行工具、IDE 插件和容器未必这样做。先看失败请求有没有出现在 Clash 的连接页面；完全没有记录，说明请求还没有进入规则引擎。

命令行工具可以临时设置 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY，桌面开发环境也可按应用说明填写代理。确实有多个不遵循系统代理的进程时再考虑 TUN。若连接已经出现在记录里，就不要继续折腾环境变量，而应检查它命中的规则、策略组和节点。

同一服务偶尔白屏，先统一 DNS 入口

浏览器安全 DNS、系统 DNS 和 Clash DNS 同时工作时，同一服务可能在不同程序里得到不同地址。排查阶段可暂时关闭浏览器独立 DoH，让域名查询和连接都从 Clash 经过，再看白屏或资源加载失败是否仍然出现。

解析成功而 TLS 握手或连接继续超时，问题才回到节点质量和规则。不要因为一次 DNS 失败就更换十个城市，也不要在没有观察结果时同时改 Fake-IP、嗅探和上游 DNS。

长回复和上传更怕出口变化，而不是测速数字多几毫秒

AI 对话会维持较长的流式连接。自动组过于频繁地重新选择节点，可能让首页始终很快，回答却在中间断开。测试时用一条固定节点完成长回复、重新生成和文件上传，再比较自动组是否真的带来改善。

上传失败还要区分请求是否已经发送。进度从 0% 不动，先看上传地址是否命中；传到一半返回明确 HTTP 状态，则查看大小限制、文件类型和服务响应。Clash 只能改变网络路径，无法绕过产品本身的限制。

最后分别测试登录、长回复、上传和 API

比打开首页更有意义的测试

  1. 重新登录

    确认认证跳转结束后不会回到登录页，出口地区没有变化。

  2. 发送一段长对话

    观察首字时间、流式输出和结束状态，不只看能否出现第一句话。

  3. 上传一个小文件

    核对上传域名、进度和最终处理结果。

  4. 调用一次 API

    记录主机、HTTP 状态码和客户端是否使用了正确代理入口。

某一项失败时，只回到对应阶段处理。登录稳定、对话中断，就保留认证规则不动；浏览器正常、API 客户端没有连接记录，就处理进程代理。文章的规则不应比问题本身扩张得更快。

参考资料