Clash 分流连通 Google Gemini：AI Studio 域名规则与节点挑选实测

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

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

不少运用者已经按本站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 解析路径抢先，表现就会像连通超时或「偶发能用」。

合规提示：请遵守所在地法律法规与各产品服务条款。这篇文章仅讨论客户端路由与 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，开启流畅上网新运用感受。

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