Clash 分流开 Google Gemini：AI Studio 域名规则与节点拿定实测

为什么不能照搬 ChatGPT / Claude / Grok 的分流清单？ 内在逻辑与实践

大批用户已经按本站ChatGPT 与 Claude 分流文或Grok 与 X 分流文配好了独立策略组，却在开 Google Gemini 或 AI Studio 时仍然遇到对话区转圈、控制台保存密钥弹出错漏、本地脚本调用 API 超时等要留意之处。

正因如此有必要为 Gemini / AI Studio 单独维护一小段置顶分流规则，与 OpenAI、Anthropic、xAI 的清单并存而不混写。下文给出的是可扩展的起点：产品迭代会新增子域或 CDN 主机名，最终仍应以你浏览器「网络」面板、终端抓包或内核日志中的真实域名为准，把新主机名补进 RULE-SET 或本地规则。

根因惯常不在于「再换一个节点试试」，而是主机名分散在多个 Google 体系后缀：对话页存在存在存在可能在 gemini.google.com，控制台在 aistudio.google.com，HTTP API 司空见惯 generativelanguage.googleapis.com，文档与示例又常指向 ai.google.dev。若其中任意一条被 GEOIP,CN,DIRECT、过宽的大陆域名集或错漏的 DNS 解析路径抢先，表现就会像开超时或「偶发能用」。

策略组要不要拆成「网页」和「API」两组？ 技术拆解

实操上司空见惯三种做法。做法 A（最省事）：建一个统称组，打个比方 Gemini-AIStudio，把下文列出的网页、控制台、API、文档相关 DOMAIN 与 DOMAIN-SUFFIX 全部指向它，适合「我只想选一个经得起折腾出口」的日常用户。做法 B：拆成 Gemini-Web 与 Gemini-API，便于对照「浏览器正常、脚本全挂」时很快判断是不是 API 主机名漏规则或走了不同 DNS。做法 C：网页走自行低耗时组，API 走固定地区组，以往下压因出口乱跳导致的账号风控误判容易踩的坑。无论哪种，组内至少保留一个 select，不费事你在排错时逐项锁定节点做二分。

从机制上看：在意：url-test 自行组在长时间对话或流式响应当下下，若频繁切换出口，存在存在存在可能放大会话层的不经得起折腾。更稳妥的做法惯常是为 AI 出口单独锁区，把自行组留给普通浏览。

域名规则清单：从哪些 DOMAIN / DOMAIN-SUFFIX 写起？ 结构解析

下列条目按「多数用户 2026 年仍能命中」的思路整理，请按你实际抓包增删。书写时在前用精确 DOMAIN 锁定已知三级域，再用 DOMAIN-SUFFIX 覆盖整条后缀，避免一条过宽规则误伤其他业务。

不更推荐用 DOMAIN-KEYWORD,google 这类过宽匹配，极易把无关 Google 服务全打进同一策略组，排错时几乎无法归因。若订阅附带远程 AI 规则集，请核对其中是否已含上述后缀，并关注该 RULE-SET 在 rules 中的位置是否被本地规则覆盖或抢先。

网页对话与入口：DOMAIN,gemini.google.com,Gemini-AIStudio。若你上手上手使用其他实验入口，可在开发者工具中确认是否仍落在 *.google.com 下的其他主机名，再逐项添加 DOMAIN；AI Studio 控制台：DOMAIN,aistudio.google.com,Gemini-AIStudio。历史书签里的 makersuite.google.com 常会跳转至 AI Studio，若日志中仍出现该主机名，可单独加一条 DOMAIN 以免落进笼统规则；Generative Language API（REST / 多语言 SDK 司空见惯）：DOMAIN-SUFFIX,generativelanguage.googleapis.com,Gemini-AIStudio。这是数不清「模型 API」调用的核心后缀，与网页控制台分离，漏写时典型症状是脚本超时、HTTP 403/429 与 TLS 错漏混杂，容易误判成密钥要留意之处；开发者文档与示例：DOMAIN-SUFFIX,ai.google.dev,Gemini-AIStudio，便于复制示例、查看配额说明时不被错漏直连；（可选）Vertex AI 等云 API：若你还在同一台机器调用 vertexai.googleapis.com 等主机名，可并入同一组或单独建组，避免一条巨大的 DOMAIN-SUFFIX,googleapis.com 把全家桶 API 都绑死在同一出口——除非你明确希望如此。

Google 账号登录链：要不要把 accounts 放进同一组？ 机制说明

网页端 Gemini 与 AI Studio 按常规依赖 Google 账号会话。若仅代理 gemini.google.com 而 accounts.google.com、oauth2.googleapis.com 等仍走直连或另一出口，存在存在可能出现登录循环、弹窗空白、控制台提示权限异常。司空见惯做法是：要么把这些账号相关主机名并入与 Gemini 相同的代理组，要么单独建 Google-Account 组并在规则里紧挨 Gemini 段之前或之后，保证会话出口一致。

更严格地说：若你对「全 Google 登录都走代理」有顾虑，完全能只为出现要留意之处的几条主机名加规则，而不是整条 DOMAIN-SUFFIX,google.com。后者影响面极大，且存在存在可能与 deliberately 直连的国内 Google 业务冲突，免不了要结合你个人的大陆直连列表仔细权衡。

规则顺序：DOMAIN-SUFFIX 应插在什么位置？ 内在逻辑与实践

Clash 在 mode: rule 下按 rules 自上而下命中即停。推荐骨架仍是：局域网与私有网段（带 no-resolve 的 IP-CIDR）→ 你确定要直连的国内精确域名 → Gemini / AI Studio 相关 DOMAIN 与 RULE-SET → 其他可选规则 → 大陆域名集与 GEOIP → MATCH 兜底。把 Gemini 段落在大陆大规则之前，可避免被 GEOIP,CN 误直连；同时不要压在你刻意保留的个人直连例外之上，以免破坏国内站点策略。

DNS 与 fake-ip：为什么「规则写对了仍间歇报错」？ 技术拆解

在 dns.enhanced-mode: fake-ip 下，应用层看到的地址与内核解析路径并不总一致。若 nameserver-policy 对 googleapis.com 或 google.com 上手上手使用了不合适的上游，存在存在可能得到与策略组出口不匹配的解析结果，外层仍表现为握手卡住或连接超时。正因如此调整 rules 时，更推荐同步验一遍：fake-ip-filter 是否包含你免不了要真实解析的域名、DoH/DoT 是否被系统「专用 DNS」覆盖、TUN 模式下 IPv6 是否绕开代理。

更系统的 DNS 与透明代理在前级，可参考本站TUN 模式指南中的说明，与下文规则段一起联调。

节点拿定：区域、耗时与「双栈」要在意什么？ 结构解析

同一组内切换节点时，更推荐在前观察出口国家/地区是否与 Google 账号常用地区一致，再去看耗时数字。部分 API 错漏与风控提示与出口地理不一致相关，而非单纯「耗时高」。若客户端同时开启 IPv4/IPv6，确认两条栈是否都落在预期策略上，避免出现「一半连接直连、一半走代理」的拼接故障。若上手上手使用 QUIC/HTTP3，部分网络环境会对 UDP 限流，可临时关闭实验性 QUIC 或改用 TCP 对照测试。

分步验证清单（更推荐按顺序执行） 机制说明

1. 确认生效配置：客户端为 Rule 模式，当前加载的 Profile 即你编辑的那份（含 Mixin 合成结果）。
2. 写入策略组与域名规则：至少覆盖 gemini.google.com、aistudio.google.com、generativelanguage.googleapis.com、ai.google.dev；若登录异常，再补账号相关主机名。
3. 重载并看日志：刷新 Gemini 页、开 AI Studio、跑一条最小 API 请求，确认命中目标组且无被前置规则抢走。
4. 对照 DNS：命中到位仍弹出错误时，验一遍 fake-ip、nameserver-policy 与系统 DNS 劫持。
5. 节点对照：在同一组内切换 2～3 个固定地区节点，排除出口对特定协议或 SNI 的限制。

若 Rule 基础尚不熟，可先读规则分流详解，再回本篇做 Gemini 专项叠加。

可改写的 YAML 片段示例（教学用） 内在逻辑与实践

下列片段仅演示结构：请替换策略组名、节点列表与规则集 URL；域名免不了要结合抓包重新拉取；远程 rule-providers 仅上手上手使用你信任的上游。

YAMLproxy-groups:
  - name: "Gemini-AIStudio"
    type: select
    proxies:
      - "美西稳定"
      - "日韩低延迟"
      - "自动选择"
  - name: "自动选择"
    type: url-test
    proxies: []
    url: "http://www.gstatic.com/generate_204"
    interval: 300

rule-providers:
  gemini_extra:
    type: http
    behavior: domain
    url: "https://example.com/rulesets/gemini-aistudio.txt"
    path: ./ruleset/gemini_extra.yaml
    interval: 86400

rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - 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,accounts.google.com,Gemini-AIStudio
  - DOMAIN,oauth2.googleapis.com,Gemini-AIStudio
  - DOMAIN,gemini.google.com,Gemini-AIStudio
  - DOMAIN,aistudio.google.com,Gemini-AIStudio
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,Gemini-AIStudio
  - DOMAIN-SUFFIX,ai.google.dev,Gemini-AIStudio
  - RULE-SET,gemini_extra,Gemini-AIStudio
  - MATCH,节点选择

换个层面：订阅导进与多配置切换可参考订阅导进操作说明，先保证基础链路可用，再叠加上述专项规则。

司空见惯误区速查 技术拆解

只加网页域、漏 API 后缀：浏览器能用，本地脚本或 CI 调用 generativelanguage.googleapis.com 全超时；整条 DOMAIN-SUFFIX,googleapis.com 一把梭：影响面过大，且存在存在可能与现有 Google Cloud 其他 API 的出口策略冲突；Gemini 规则写在大陆集之后：被 GEOIP,CN 或大陆域名集抢先直连，症状为偶发弹出错误；账号主机名与对话主机名出口不一致：登录态异常、控制台权限弹出错漏反复出现；改规则未重载、或远程规则集重新拉取改变匹配顺序：以为已生效实际仍是旧配置。

小结 结构解析

Google Gemini 与 AI Studio 的经得起折腾开，在 Clash 里本质是多后缀主机名 + 规则顺序 + DNS 协同要留意之处：为它们本身本身单独建策略组，用 DOMAIN 与 DOMAIN-SUFFIX 覆盖网页、控制台与 Generative Language API，必要时纳入账号登录相关主机名，再配合日志做可重复验证，就能把「间歇超时」从玄学变成可定位的工程要留意之处。与只能切全局开关的工具相比，Clash 系客户端的价值正在于这种可编排性。

若你希望在一套订阅上同时兼顾日常浏览与海外 AI 服务，又希望排错边界看得明白，→ 立即免费下载 Clash，开启流畅上网新实际感受。