2026 用 Clash 稳连 Gemini：域名分流与 DNS 排错

为什么 Gemini 常见「网页正常，API 或登录却掉线」？

Google Gemini 与 Google AI Studio 的流量并不只落在浏览器地址栏里那一个主机名上。账号体系走 accounts.google.com 与 OAuth 端点，对话界面与控制台页面常分布在 gemini.google.com、aistudio.google.com 等子域，而程序化调用往往指向 generativelanguage.googleapis.com 一类 Google API 主机名。Clash 在 rule 模式下自上而下匹配、先命中先生效：只要其中任意一环落在直连、错误策略组，或被 DNS 提前解析到「不符合你预期的区域」，就会出现页面勉强能开、接口长连接中断、反复要求登录或地区不可用的割裂体验。

这与泛泛的「AI 热点」无关，而是典型的域名覆盖不全 + DNS 与规则模式不一致问题。本文不重复订阅格式与节点购买，也不展开 TUN 模式总论；需要系统语法与策略组类型对比时，请先读规则分流详解，需要透明接管时再对照 TUN 模式指南。下面专注：Google 系 AI 的域名清单、专用策略组，以及 fake-ip / redir-host 下的 DNS 排错。

域名清单：从账号、网页到 API 的一条链

维护规则时，建议把「你会用到的整链」写进个人前置规则，并放在过于宽泛的 GEOIP,CN,DIRECT 或大块直连规则之前。下列后缀与主机名在 2026 年仍高频出现；实际以客户端连接日志中的 SNI 与目标主机名为准定期增补，比静态抄表更可靠。

账号与身份：google.com（含 www）、accounts.google.com、oauth2.googleapis.com、ssl.gstatic.com（部分静态资源与证书链相关请求）。
Gemini 网页与产品入口：gemini.google.com、历史上可能出现的 bard.google.com 跳转、以及实验与实验室页面所在的 labs.google.com 等（按你是否访问决定纳入）。
Google AI Studio / 控制台：aistudio.google.com、开发者文档站点 ai.google.dev。
Gemini API 与通用 Google API：generativelanguage.googleapis.com 是多数官方示例与 SDK 的默认主机名；其他客户端还可能命中 www.googleapis.com、clients.googleapis.com 等。若你希望一条规则覆盖所有 Google API，可使用 DOMAIN-SUFFIX,googleapis.com，但要意识到范围很大，可能影响非 AI 的 Google 云服务调用——更稳妥做法是自建 rule-providers 只收录你确认需要代理的 API 子域。
静态资源与附件：gstatic.com、googleusercontent.com；页面完整加载往往依赖它们，漏代理时表现为样式缺失、脚本卡住或无限加载。

若订阅自带 GEOSITE 或第三方规则集中的 Google 分类，仍建议保留一小段本地前置，以免订阅更新后顺序变化导致 AI 相关子域落入直连。与 OpenAI、Anthropic 栈不同的关键点是：Google 账号与 API 主机名高度复用，排查时要区分「只为 AI Studio 代理」与「整段 Google 服务同出口」两种需求。

# Example snippets — replace Proxy-Google-AI with your group; keep block above broad DIRECT rules
rules:
  - DOMAIN-SUFFIX,accounts.google.com,Proxy-Google-AI
  - DOMAIN-SUFFIX,google.com,Proxy-Google-AI
  - DOMAIN-SUFFIX,gstatic.com,Proxy-Google-AI
  - DOMAIN-SUFFIX,googleusercontent.com,Proxy-Google-AI
  - DOMAIN-SUFFIX,gemini.google.com,Proxy-Google-AI
  - DOMAIN-SUFFIX,aistudio.google.com,Proxy-Google-AI
  - DOMAIN-SUFFIX,ai.google.dev,Proxy-Google-AI
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,Proxy-Google-AI
  - DOMAIN-SUFFIX,googleapis.com,Proxy-Google-AI
  # ... CN / GeoIP / MATCH follow

DOMAIN-SUFFIX,google.com 会覆盖极广子域；若你只想代理 AI 而让部分 Google 服务直连，应改用日志驱动的精简列表或拆分多个策略组，避免「一刀切」带来副作用。

策略组：建议为 Google AI 单独建组

与 ChatGPT、Claude 场景类似，长连接与 API 对出口稳定性、TLS 与地区一致性更敏感。实践上可为 Gemini / AI Studio 建一个 select 策略组（例如 Proxy-Google-AI），放入延迟稳定、符合服务条款地区的节点，再把上一节的域名规则统一指向该组。这样你可以在不影响其他外站浏览的前提下，为 Google AI 固定「少折腾」的出口。

url-test 自动组在流式响应场景要谨慎：探测 URL 与真实 API 主机不一致时，可能出现探测最优而业务偶发阻断。若必须自动择优，可适当放宽 tolerance、拉长 interval，减少频繁换出口导致的会话中断。fallback 更适合容错而非追求最低延迟。策略组类型细节仍以规则分流一文为准。

DNS：fake-ip 与 redir-host 如何改变「谁先被匹配」

Clash 的 DNS 模块决定域名如何变成 IP，而规则既可能在域名阶段命中，也可能在拿到解析结果之后与 IP 规则交互——这与 enhanced-mode 使用 fake-ip 还是 redir-host（及内核实现细节）密切相关。若 DNS 请求未走可信上游，出现污染或次优区域解析，即使规则写了代理，也可能表现为握手慢、证书异常或间歇断连。

fake-ip 下，部分连接会先拿到本地伪造地址，再在内部还原域名做规则匹配；此时务必维护好 fake-ip-filter（或等价列表），让需要真实 IP 的局域网主机名、某些直连业务或特殊应用跳过 fake-ip，避免与规则顺序「打架」。若你发现日志里目标显示为 fake-ip 段而策略却未按预期命中，优先核对：当前模式、过滤器列表、以及是否存在先解析再匹配的竞态。

redir-host 路径更偏向「先解析、再按结果走规则」的思维模型；与 fake-ip 相比，对依赖真实解析结果的应用有时更直观，但也更容易暴露DNS 上游选择不当的问题。无论哪种模式，都建议为 googleapis.com、google.com 等后缀配置可信 DNS 上游，并通过 nameserver-policy（或 mihomo 中等价配置）让敏感后缀不走运营商默认 DNS。

IPv6 双栈环境下，若规则或 DNS 在 IPv4 与 IPv6 之间行为不一致，可能出现浏览器与 API 客户端各走一条栈的诡异现象。排查阶段可在日志中观察目标地址族，再决定是否要在系统或路由器层统一策略。更多术语还可对照本站使用文档中的网络与 DNS 说明。

Google AI Studio 与 API Key：同账号、不同主机名

在网页里试用模型与在代码里调用 Gemini API，表面上可能都登录同一 Google 账号，但底层请求往往落在不同主机名：aistudio.google.com 侧重复合 UI 与配额展示，而 SDK 与 REST 客户端主要打 generativelanguage.googleapis.com。因此「Studio 能用、脚本全红」几乎总是API 主机名未进代理组或该组 DNS 解析异常，而不是单纯 API Key 填错——当然 Key 与项目配额仍需在 Google Cloud 控制台侧自检。

若你同时使用 ChatGPT 与 Claude 分流文中的策略，注意不要把不同厂商的域名混进同一自动切换组，除非你有意为之；分厂商拆组更有利于定位「只有 Google 挂」还是「所有 AI 都挂」。

分流粒度：减少无关流量与 AI 抢出口

稳定连接不仅取决于是否开启代理，还取决于有多少无关大流量与 Gemini 抢同一节点的连接表与带宽。国内站点与大文件下载尽量直连或走独立组，让 Google AI 流量落在轻负载出口，可显著降低「看似断连、实为排队或限流」的体验。使用规则集做国内外分流时，请再次确认：上一节列出的域名落在代理侧，且位置先于过于宽泛的直连规则。

排查清单：按顺序勾掉即可

遇到网页可用而 API 或登录异常时，建议顺序自检：① 模式是否为 rule，且 Google AI 相关域名是否被前置规则命中；② 日志中该请求的主机名与解析结果是否与预期一致；③ 命中策略组是否为期望节点；④ DNS 模式（fake-ip / redir-host）与 fake-ip-filter 是否冲突；⑤ 桌面 SDK 或脚本是否实际走了系统代理，必要时需 TUN 或在进程内指定本地端口。多数问题在前两步即可定位。

记录一次完整连接日志比反复换节点更有效：关注第一条命中规则与最终出口。团队共享配置时，把「Google AI 前置规则」与「DNS 策略」写成简短说明，可减少合并配置时的无意覆盖。

把策略跑在顺手的客户端上

域名、策略组与 DNS 写得再完整，也需要能清晰展示连接日志、策略命中与 DNS 行为的客户端来落地。图形化查看「当前节点」「规则是否加载」与「请求走向」，能显著缩短你在 Gemini 与 AI Studio 上的排错时间；与持续跟进 mihomo 等内核的发行版搭配时，规则集与订阅更新也更容易保持节奏。

相比零散工具链，一体化 Clash 客户端在订阅更新、内核升级与策略调试上往往更省心，更适合作为日常办公与学习的默认网络环境。若你希望把精力留在「Google AI 这条链是否走对」而不是「配置是否又被打断」，选择与当前内核深度整合、长期维护的版本会更省力。

→ 立即免费下载 Clash，开启流畅上网新体验