📖 教程 ⏱ 约 20 分钟阅读

Gemini CLI 连接总超时？2026 年 Clash 域名分流与 DNS 分步实测

Gemini CLI 把 Google 的对话与 Google Generative Language API拉进终端——很多人已经用 Clash把浏览器打通了，却仍遇到：Gemini CLI 超时、OAuth 登录页打不开、或「拉到一半模型列表卡住」。这并不是「再走一遍网页 Gemini 的规则」就够：命令行往往在没吃到系统代理的假阳性里打转，再配上 Clash DNS／fake-ip 与OAuth 回流本地端口的细节，就会形成「看起来像 Clash 开着、CLI 却仍断」的割裂感。本文与站内 Gemini 浏览器与网页向专文 错位互补——专写终端 AI／命令行这一跳，并按可操作顺序给你域名观察表、规则占位与自检流程。

先分清：你在排的是哪一种「Gemini CLI 超时」

对用户来说都叫超时或挂起，对内核查却可以拆成几类互不相同的断层，修复手段也不同：

  • TCP／TLS 到 Google 侧的握手长时间无应答：多是出口、地区策略或节点质量问题，但也要先排除根本没进代理栈——终端进程常见。
  • DNS 名前解析卡住或 NXDOMAIN：与 Clash DNS上游、劫持、或与 fake-ip 规则组合不当有关；往往在日志里早于第一次出站尝试就出现异常。
  • OAuth 打不开或浏览器授权后 CLI 不涨进度：通常混有 accounts／oauth／gstatic／googleapis链路里任一截断与127.0.0.1 回调是否被改写两类因素。
  • 模型枚举或单次调用慢但偶发恢复：更像分流规则抢占或会话子域没被同一组接住，而不是整机断网——这时连接日志里最值钱的是每一条失败请求的目标主机名。

你如果已经熟读本站2026 年用 Clash 稳定访问 Google Gemini：规则与 DNS 实测步骤那篇浏览器向文章，可把本文当作「同一套方法论在 Gemini CLI／终端 AI 上的增量」：关注点从 Chromium 的系统代理链路迁移到 shell 进程的出站，以及 Google Generative Language API在日志里的独立长相。

为什么装了 Clash，Gemini CLI 仍经常「像在墙外但实际没走远」

桌面上最常见的误判，是误以为「系统开着 Clash」等于「每一个进程都已自动走代理」。Clash／Clash Meta 的典型模式是：系统代理把大多数遵守系统设置的 GUI 浏览器带进来；但很多终端里的程序根本不读那张 PAC 或桌面代理对话框，除非你显式设置环境变量或使用透明代理／TUN把整个 IP 栈交出去。

于是你会看到：Chrome 里的 Gemini 能用，而同机运行的 Gemini CLI却仍直连公司网络或残缺路由，从而在握手或首包阶段表现为Gemini CLI 超时。另一类场景是：WSL2、远程 SSH、Docker 容器内的 shell拥有独立于 macOS／Windows GUI 的网络命名空间——宿主机 Clash 的 mixed-port 在子环境里甚至需要换成宿主局域网地址才能拨通，这点与Windows 宿主与 WSL2 共用 Git、npm、cargo 镜像与 Clash 代理里讲的「宿主 ↔ 子系统地址」完全一致，只是服务对象换成了 Gemini CLI（node／go 等平台实现各异）。

若你已确认终端确实带着 HTTPS_PROXY 指向本机监听，却仍看见间歇失败，才把注意力转回本站Clash 使用教程里强调的分流与 DNS一致性问题——那才是第二层的「虽已进 Clash，但规则／解析仍打架」。

Gemini CLI 链路里值得你盯紧的域名（仍以连接日志为准扩展）

下面是一份高概率出镜、适合作为「第一轮观察表」的主机类型说明，不代表 Google 永久不变。实际增补必须以你客户端连接日志的真实主机名为准，方法与网页向 Gemini 专项相同，只是把观察场景换成命令行会话：

  • 产品与文档入口：ai.google.dev、gemini.google.com 及可能的重定向链路（若你从浏览器打开文档会与 CLI 会话交织）。
  • 对话与 Google Generative Language API：generativelanguage.googleapis.com 及其在具体版本里新增的接口子域；「列模型」「发请求」常与网页壳不完全同域。
  • 账号与令牌：accounts.google.com、oauth2.googleapis.com、以及相关 session／consent 流程里冒头的 *.googleapis.com 变体——Gemini CLI 登录一旦掉链子，十有八九能在这一段找到被直连或走错组的连接。
  • 脚本与静态资源：*.gstatic.com、*.googleusercontent.com 等；授权页打不开时别以为「不关 AI 什么事」——缺了它们仍会表现为浏览器侧白屏或长时间 pending。
  • 泛化兜底争议：有人用整块 DOMAIN-SUFFIX,googleapis.com 省事；这对排错见效快，但也可能与你在同一配置文件里为国内业务写的窄规则发生冲突，长期来看仍建议日志驱动收窄。

如何把一条规则插到不前不后刚刚好的位置，请参阅自定义规则教程：让指定 App 走指定节点与Clash 代理组（proxy-groups）完全指南，先保证YAML 里的组名与 rules 完全一致，再谈「是不是 Google 域名没写完」——否则很容易出现「YAML 自检通过却永远命中 MATCH 默认组」的假完成。

终端侧：三种让 Gemini CLI「真的走进 Clash」的常用路子

按侵入性从低到高排序，实战中多数读者会依次尝试：

  1. 显式导出代理变量（首推用于快速二分）：在同一个 shell里为当前会话写入 HTTPS_PROXY=http://127.0.0.1:<mixed-port>／HTTP_PROXY（端口以 GUI 显示的 mixed-port／HTTP 为准），必要时补 ALL_PROXY=socks5://127.0.0.1:<socks-port>。若 Gemini CLI 基于常见网络栈构建，这一轮往往立刻消除「CLI 独享直连」的假超时。
  2. 使用 TUN：当某些子进程忽视环境变量、或你有大量命令行工具要统一走时，可把整机流量导入内核路由；代价是要更谨慎地配置局域网与大陆流量直连段，细节见TUN 模式深度解析。Gemini CLI 超时若在打开 TUN 后显著收敛，可把根因记在「出站路径未统一」而不是「Gemini API 挂了」一侧。
  3. 平台相关的进程级策略（进阶）：在桌面 Clash／Mihomo 系里可讨论按进程出站；在移动端或专有发行版请以当地客户端文档为准。思路仍是：Gemini CLI 进程的每一个出站 SYN 都能在日志上对上一个出站策略名字。

顺带一提：如果你在 IDE 内置终端调试 AI 插件，常与2026 开发者必备：用 Clash 分流加速 Cursor 与 GitHub 的实测步骤同病相怜——宿主 GUI／IDE WebView／外置 Terminal三者可能各有各的代理认识，别把其中任意一条「能上网」推演成 Gemini CLI「必然也」能上。

Clash 分流写法：先接住 OAuth，再给 API 域名专组空间

下面是一段结构示意 YAML：GEMINI_STACK 请改名为你配置文件里确实存在的 proxy-groups。勿直接整段照搬进生产：你本地的订阅、GEOIP-CN、RULE-SET 顺序都可能不同——重点学习「先私网直连，再给 Google OAuth／API／静态栈让位」这一占位思想。

# Example skeleton — GEMINI_STACK must match your proxy-groups
rules:
  - 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_STACK
  - DOMAIN-SUFFIX,oauth2.googleapis.com,GEMINI_STACK
  - DOMAIN-KEYWORD,login,GEMINI_STACK                 # beware false positives — trim using logs
  - DOMAIN,ai.google.dev,GEMINI_STACK
  - DOMAIN-SUFFIX,gstatic.com,GEMINI_STACK
  - DOMAIN-SUFFIX,googleusercontent.com,GEMINI_STACK
  - DOMAIN,generativelanguage.googleapis.com,GEMINI_STACK
  - DOMAIN-SUFFIX,googleapis.com,GEMINI_STACK         # widen only after narrower DOMAIN entries
  - GEOIP,CN,DIRECT
  - MATCH,GEMINI_STACK

表里含一块故意「刺耳」的行：DOMAIN-KEYWORD,login,GEMINI_STACK。它只是在提醒——有些读者为了避免漏域，喜欢用过宽的关键词一把梭；实战中更安全的做法是：每次超时只补当时在日志底部新出现的那一个主机名，并把更早的试错规则注释掉存档。你的订阅里若有巨型第三方规则块，还请确认它没有在你手动规则之后又覆盖出一层 DIRECT——这是很多「YAML 越看越对、日志越看越懵」的根因。

DNS 与 fake-ip：第二层「看起来像超时更像解析分裂」的自检

当你已经断言终端进了 Clash、规则也写明 Google API，却仍得到Gemini CLI偶发卡住，下一轮请平行检查Clash DNS是否与规则假说一致——这部分与站内Linux 上使用 Clash 与 systemd-resolved：DNS、分流与共存的故障排查实录所讨论的「系统 stub 解析器／DoH／内核 DNS 缓存」一脉相承：只不过本文读者可能主力在Windows 桌面，但方法论仍是只留一条权威的解析链路。

可操作的关注点包括但不限于：

  • fake-ip：在 fake-ip 模式下，内核返回给应用的地址未必等于远端真实 A 记录——规则若混用过早的 IP-CIDR 且无 no-resolve／与域名规则的竞争关系错乱，就会制造「有时是直连有时是代理」的假随机超时。
  • fallback 触发条件：DoH／DoT upstream 若在办公网被干扰，可能造成整条解析链路慢到你的 CLI 默认值先放弃；这类失败在体感上也像 Gemini CLI「拉模型卡住」——记得对照同一时间系统 dig／resolvectl与内核日志延迟。
  • 分流型策略里「国内 DNS」与 Google 并存：若你为大陆域名配置了国内递归，却仍然让 Google／API host 走错上游，会看到第一轮解析就对不上 GEOIP／规则后缀，后续再怎么换节点都无济于事。

如果你在 Linux 宿主上跑 CLI，还涉及 systemd-resolved stub 监听 127.0.0.53与普通 Clash DNS 监听端口之间的转发关系——走错一环就会回到「看起来像 Gemini CLI timeout、其实是 NXDOMAIN／SERVFAIL」。这时不要急着骂模型，请先让generativelanguage.googleapis.com 在某个抓包／日志视图里可被「干净地解析出地址并接上 intended outbound」这一条链闭环。

OAuth 实测：别把「打不开登录页」和「打不开 API」混在一起修

Gemini CLI 或同类终端 AI在首次运行时往往拉起系统浏览器完成 OAuth；这时同时存在出站（到 Google）与回环（到本机临时端口）两条逻辑：

  • 出站部分：授权页要能加载上面提到的 accounts／oauth／gstatic／部分 googleapis／usercontent 等资源；任一被错误送进国内直连或直接黑洞，都会造成「卡在空白页」「长时间转圈」。处理办法仍是看日志上新出现的主机名，而不是盲加一整条DOMAIN-SUFFIX,google.com就以为万事大吉。
  • 回环部分：授权结束回跳127.0.0.1或localhost时，要确保不会误走 HTTP 代理或被中间人安全软件劫持；如果你在 shell 里设了激进的 ALL_PROXY，要记得给环回保留 NO_PROXY 例外（形如 localhost,127.0.0.1）。有些企业套件会重写 loopback——那是另一类「只有 OAuth 诡异、API 却已通」的现场。
  • 完成授权却仍提示未登录：往往是令牌落盘路径或磁盘权限／沙盒问题，已不是 Clash——网络侧此时应能看见已成功 hit generativelanguage 而故障发生在本地文件层；学会区分可避免无限调规则。

分步实测清单（建议你严格按顺序，一次只动一类变量）

  1. 固定复现场景：用同一终端、同一 shells 配置、同一时间窗复现 Gemini CLI login／list-models／单次对话三件事中的最小子集——不要同时开着公司 VPN／机场全局／浏览器翻墙插件四处抢栈。
  2. 二分「有没有进 Clash」：在未改规则前先给当前会话挂上 HTTPS_PROXY 或切换到 TUN 复测——若这一阶段已显著改善，把「Gemini CLI 超时」记在出站路径缺口而不是 DNS。
  3. 开连接／debug 日志并清空缓冲：重新触发失败后，从上到下阅读第一跳失败域名与policy 命中；若你连这一步都省了，就像在黑暗里轮换节点——浪费且不可复盘。
  4. 按主机名前移规则优先级：把新日志里的主机补成 DOMAIN 或受控后缀，插在会抢答的 GEOIP,CN／国内直连集之前但仍位于私网段之后。
  5. 校对 DNS：改任何上游或 fake-ip toggle 时都记录 baseline；若你与 Linux 高级网络栈共舞，可把Linux Clash systemd-resolved 排查文当作平行参考。
  6. 收口：能稳定 login＋枚举模型＋走通一次会话后，把太宽的 KEYWORD 与重复后缀删掉备份，配置文件也要像代码一样可被 diff。

常见问题（与正文 FAQ 结构化数据对齐）

我已经给 google.com 写了一堆规则，为什么还要单独提 generativelanguage？

Google Generative Language API的入口主机名并不等于搜索或普通产品首页；Gemini CLI 的许多调用落在 generativelanguage.googleapis.com 这棵树上。Gemini CLI 超时如果只发生在「已进入 CLI、准备请求模型」这一阶段，十有八九要单独核这条域名的命中情况，而不能只盯着 www.google.com是否能打开。

想用 API Key 绕过 OAuth，是不是就不用管 accounts 域名了？

部分工作流可以用 API Key 减少交互，但一旦仍要走 Google 的统一计费／项目／凭证体系，你可能仍会撞上 oauth2／googleapis／serviceusage侧主机；而且终端 AI 领域工具迭代快，别把「自己曾经绕过一次」等同于「永远都绕得过」。仍以那一次失败请求的日志域名为准。

Clash DNS 模式和「系统直接用 DoH」会冲突吗？

会。Clash DNS若在本地监听而系统又用另一套 Stub resolver 改写查询方向，就会形成你看到 dig 是一套、内核连接跟踪是另一套的画面。做法是选定单边权威：要么主要由 Clash承接，要么把 Clash嵌入系统解析链的规则讲清楚再做对照实验。

小结

把Gemini CLI 超时当成纯线路问题往往会让你无限换节点——更经济的起点是：先证明终端进程与同机浏览器共享同一出站故事，再用 Clash 分流把 Google Generative Language API、OAuth、静态栈拆成可在日志中对齐的条目，最后才把Clash DNS／fake-ip与 OAuth 回流这类「第二层错位」逐项关掉。把整个 YAML 视作可版本化资产：Gemini CLI与网页产品的域名只会继续演进，而日志驱动增补这条纪律不会过时。

相比部分传统翻墙脚本或「整包导入巨型规则列表」的方案，图形化／订阅化管理的 Clash 系客户端更容易把每一条连接对应到可读的策略名称，并在不重装的前提下迭代规则——这对grep式排错终端 AI尤其实用。想把同样的严谨做法带到日常代理体验，可先阅读站内教程建立基础分流观，再配合本文专向 Gemini CLI／命令行查漏补缺，最后从本站下载页获取仍在积极维护的一键分发客户端，少走配置回头路。→ 免费下载 Clash，把终端与浏览器出口统一交到一套可控规则里。