Clash 分流访问 Google Gemini：AI Studio 域名规则与节点选择实测

为什么不能照搬 ChatGPT / Claude / Grok 的分流清单？

很多用户已经按本站ChatGPT 与 Claude 分流文或Grok 与 X 分流文配好了独立策略组，却在打开 Google Gemini 或 AI Studio 时仍然遇到对话区转圈、控制台保存密钥失败、本地脚本调用 API 超时等问题。根因往往不在于「再换一个节点试试」，而是主机名分散在多个 Google 体系后缀：对话页可能在 gemini.google.com，控制台在 aistudio.google.com，HTTP API 常见 generativelanguage.googleapis.com，文档与示例又常指向 ai.google.dev。若其中任意一条被 GEOIP,CN,DIRECT、过宽的大陆域名集或错误的 DNS 解析路径抢先，表现就会像访问超时或「偶发能用」。

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

合规提示：请遵守所在地法律法规与各产品服务条款。本文仅讨论客户端路由与 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,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 都绑死在同一出口——除非你明确希望如此。

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

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 误直连；同时不要压在你刻意保留的个人直连例外之上，以免破坏国内站点策略。

实测技巧：临时提高内核日志级别，打开 AI Studio 执行一次「获取 API 密钥」或运行一段最小 API 调用脚本，观察每条连接命中的规则名与策略组。改一条、重载一次，比盲目换节点更能区分是顺序问题还是 DNS 问题。

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，开启流畅上网新体验。

请遵守所在地法律法规与各在线服务条款；本文仅供技术原理与客户端配置教学。规则集来源请谨慎甄别，避免使用来路不明的远程列表。