终端为什么比浏览器更容易「总超时」

浏览器访问 Gemini 或 AI Studio 时，只要系统代理指向 Clash，绝大多数 HTTPS 请求都会按分流规则走统一出口。换成终端里的 Gemini CLI 或其它 Google AI 客户端后，情况立刻复杂：node、python、Go 编译的二进制或独立安装包，往往不读取 macOS / Windows 的系统代理，除非你自己导出 HTTPS_PROXY；不少运行时还会忽略大小写或仅认小写变量名。结果是：网页一切正常，CLI 却一直 dial 超时——这不是玄学，而是流量根本没经过你为 Google 准备的策略组。

另一类隐蔽问题是半经过代理：API 请求命中了代理，但 OAuth 回调依赖的主机名走了直连，或反过来；TLS 会话与后续长连接在不同路径上完成，终端工具的重试逻辑又会放大延迟，于是你看到的就是API 超时或卡住不动。解决思路永远是两件事：让终端整体接入 Clash（环境变量或 TUN），再用域名分流把 Google AI 相关的后缀绑定到同一策略意图，包含CDN 与字体资源。这与 IDE 场景类似，可参考 Cursor 登录与 AI 超时；本篇把焦点收窄到 Gemini CLI 与终端调用链。

ℹ 先回答两个问题：其一，当前 Shell 里的请求是否真的打到本机 Clash 端口；其二，连接日志里 generativelanguage.googleapis.com、oauth2.googleapis.com、gstatic.com 是否命中同一策略组。两者任一是否定的，就不要急着换节点。

OAuth 与账号域：登录卡住往往不是 CLI 本身

多数 Gemini CLI 首次使用会走OAuth：弹出浏览器或使用本地回调端口完成授权。流程串联的主机名通常包括 accounts.google.com、oauth2.googleapis.com，有时还会牵涉 ssl.gstatic.com、www.gstatic.com 一类的脚本或样式加载。若你在规则里只圈了 *.googleapis.com，却忘了账号域或CDN，浏览器窗口就会长时间空白，终端侧则表现为「等待登录」永不结束——本质是授权链路断裂，而不是模型配额用尽。

实务上建议把「账号 + OAuth + 常用静态域」与「生成式 API」放进同一可视分组（示例策略组名 GOOGLE_AI，按你的订阅改写）。不需要迷信关键字匹配：DOMAIN-KEYWORD,google 之类写法很容易误伤无关站点；优先使用后缀或精确域名，并用日志补漏。若组织环境禁止个人账户 OAuth，应改用服务账号或合规的企业入口——本文只讨论路由层如何对齐，不鼓励绕过单位策略。

API 网关与 CDN：三类域名要同一策略意图

生成式语言 API 与通用 googleapis

调用 Gemini 模型时，终端/SDK 往往访问 generativelanguage.googleapis.com，也可能落到其它 *.googleapis.com 子域（具体以当前 SDK 与区域为准）。若只写了单主机规则而后台切换到邻近区域，就可能漏匹配；许多用户因此采用 DOMAIN-SUFFIX,googleapis.com,GOOGLE_AI 作为基线，再审视是否要把「全部 googleapis」与「仅 AI」拆开——取决于你是否介意其它 Google API 一并走代理。

静态资源与字体

gstatic.com、fonts.googleapis.com、fonts.gstatic.com 常被低估：CLI 附带的本地网页、错误页或嵌入式视图若加载失败，也会在日志里体现为超时或空白界面。CDN 域名分流应与 API、OAuth 同步，否则你会遇到「命令已发出，但界面组件永远加载不完」的假死。

可选文档与开发者站点

查阅文档或示例时，可能额外访问 ai.google.dev、developers.google.com 等。若你希望在离线排障时一并稳定打开这些页面，可以把它们写入同一分组或单独的「Google 开发者」分组，再在规则里靠前放置，避免被宽泛的直连规则抢先匹配。

规则示例：DOMAIN-SUFFIX 与策略组命名

下面是一段说明性 YAML 片段：策略组名、端口与订阅结构需按你的客户端替换；重点是OAuth + API + CDN并列，且中国大陆流量仍可直连。更系统的写法见 规则分流最佳实践。

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,accounts.google.com,GOOGLE_AI
  - DOMAIN-SUFFIX,oauth2.googleapis.com,GOOGLE_AI
  - DOMAIN-SUFFIX,googleapis.com,GOOGLE_AI
  - DOMAIN-SUFFIX,gstatic.com,GOOGLE_AI
  - DOMAIN-SUFFIX,googleusercontent.com,GOOGLE_AI
  - DOMAIN-SUFFIX,fonts.googleapis.com,GOOGLE_AI
  - DOMAIN-SUFFIX,fonts.gstatic.com,GOOGLE_AI
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

MATCH 是兜底：若你的默认环境是「境外列表走代理、其余直连」，务必确认列表更新及时；Google 新增子域时，未被规则收录的主机会悄悄直连失败，外在症状仍是API 超时。遇到 TLS 或握手报错时，可对照 从日志读懂 timeout 与 TLS 分段排查。

终端代理环境变量与 TUN：两种闭环怎么选

环境变量路线适合「只在当前终端会话跑 CLI」：为 Clash 打开 mixed-port，在 Shell 配置里导出 export HTTPS_PROXY=http://127.0.0.1:7890（端口按实际）、必要时再加 ALL_PROXY 与 NO_PROXY（排除局域网与内网域名）。详细模板可参考 Docker 与终端 mixed-port 一文中关于本机端口的写法。

TUN 路线适合「多种运行时混杂、环境变量难以全覆盖」：由系统在三层转发，未自觉遵循代理的程序也会被带入分流决策。代价是与单位 VPN、虚拟机桥接等可能冲突，实施前建议阅读 TUN 模式深度解析。两条路线择一为主，不要在同一台机器上叠多套互相改路由的工具而不记录优先级。

DNS、fake-ip、规则顺序与 MATCH

即便域名分流写得正确，DNS 抢答或 fake-ip 过滤遗漏也会让终端拿到错误地址，表现为连接立刻失败或长时间 hung。请记住：解析路径不等于路由路径；需要在 Clash 里统一 DNS 出口，并在日志中核对「域名 → 策略组 → 实际 outbound」是否闭环。规则顺序上，国内站点与局域网直连应靠前；细粒度 Google AI 规则紧随其后；过于宽泛的拦截类规则若排在前面，可能无声吞掉 OAuth 请求。

若同时使用系统 DoH 与 Clash 内置 DNS，易出现「浏览器问一套解析器、CLI 问另一套」的分裂；排障时临时统一到单一解析路径，更容易对照现象。常见问题 中的 DNS 条目可作为补充阅读。

用连接日志把 timeout 拆成「哪一跳错了」

建议在复现时固定三件事：时间戳、失败时的主机名、以及命中的规则名。若日志显示 OAuth 相关域名走了直连而 API 走了代理，优先修正域名分流而非更换节点；若已全部命中代理却仍超时，再评估节点协议、UDP、时钟偏移或服务端状态。对于Gemini CLI 下载依赖（npm、pip、brew）额外失败的读者，还要区分「模型请求」与「包管理器拉包」——后者往往指向 registry.npmjs.org、files.pythonhosted.org 等，需要在规则中单列，以免误判为 Google 故障。

常见问题（正文精炼版）

是否必须与 Gemini Mac 客户端 写同一套域名？方向一致即可：Mac 应用与 CLI 都依赖 Google 账户体系与 googleapis，但包名、内置浏览器壳与更新通道不同；以各自连接日志为准合并清单。

OAuth 成功后仍然 API 超时怎么办？回到三类域名是否同事走 GOOGLE_AI；再看节点是否阻断长连接或大上传；最后核对本地时钟与证书存储。

可以用全局代理一劳永逸吗？短期排障可以，长期会抬高延迟与风控概率；可持续的方案仍是分流加可读规则。

⚠ 合规提示：请遵守所在地法律法规与 Google 服务条款。本文仅描述路由与 DNS 层面的技术思路，不鼓励未授权访问、绕过组织安全策略或任何违法用途。

自检清单

  1. 确认有权在当前网络使用 Clash 与目标 Google AI 服务。
  2. 核对终端是否通过环境变量或 TUN 经过 Clash。
  3. 在日志中检查 OAuth、googleapis、gstatic、字体域是否命中同一策略组。
  4. 审视规则顺序：国内直连、局域网、业务细分、MATCH。
  5. 验证 DNS / fake-ip / 嗅探配置是否引入解析与路由不一致。
  6. 确认订阅与远程规则集更新通道未被循环代理阻断。
  7. 区分 CLI 模型请求与包管理器下载域名，避免误判。
  8. 本地因素排除后，再评估节点质量与官方服务状态。

结语

Gemini CLI 与终端场景下的故障，九成可以先还原成「哪些主机名没有分流到同一出口」加上「命令行有没有真正经过 Clash」。相比只在浏览器里测试，这类问题更需要你用域名分流把 OAuth、Google AI API 与CDN 静态资源绑在一起，并把DNS 决策写清楚。

市面上也有不少「一键全局」类代理或精简路由器固件，省事但往往看不清规则命中；出了问题只能重启碰运气，对API 超时这种间歇性问题尤其无力。Clash 系列的可读规则与连接日志，能把症状落到具体域名与策略组；在这一品类里，Clash V.CORE 兼顾桌面常见客户端的学习曲线与现代内核特性，更适合长期维护一份Google AI 专用的域名分流清单。

→ 立即免费下载 Clash，开启流畅上网新体验，把Gemini CLI 的稳定访问握在自己手里，而不是交给一次次盲目重试。