进入 2026 年，在本地终端里跑 Gemini CLI、以及与之同类的「代码场景终端智能体」的人越来越多；它与 Claude Code、Codex 等工具常被并列讨论，但后端换成了 Google AI API 与 Google 账号体系，网络路径上的域名集合与失败形态也随之变化。实际排障里，最常见的主机之一是 generativelanguage.googleapis.com ——模型推理与流式响应往往打在这里；与此同时，登录与令牌刷新还可能牵连 oauth2.googleapis.com、accounts.google.com 等主机。浏览器里「能打开 Google」并不代表你在 Terminal、iTerm 或 IDE 集成终端里启动的同一进程走了同一策略： GUI 常跟随系统代理，而大量命令行工具只认环境变量或自有配置。本文以 Clash Verge Rev 为前端，把它当作面向开发者的终端代理与分流规则中枢：先厘清超时与鉴权异常的常见根因，再说明「规则模式 vs 全局 TUN」的边界，最后落到 HTTPS_PROXY 应写入哪里、如何写 NO_PROXY，以及如何用最小步骤证明 Google AI API 与鉴权链路已稳定命中代理。

你可能遇到的典型现象

第一类是纯链路超时：Read timed out、ETIMEDOUT、TLS 握手阶段长时间无响应；有时第一次对话能返回片段，随后连续失败，像「热路径被打爆」其实是直连抖动或节点熔断。第二类是鉴权看似异常：弹出登录后浏览器成功，终端仍报无法刷新令牌；或在公司网络下仅部分时段可复现。第三类最容易误导人：IDE 里的其它 AI 插件可用，唯独 Gemini CLI 不行——通常说明 IDE 子系统走了独立代理或内建隧道，而你在 shell 里启动的进程仍在裸连，或命中了把 googleapis 相关域名送去 DIRECT 的规则。

建立一个小习惯：打开 Clash Verge Rev 的连接面板，在超长卡顿时搜 generativelanguage、googleapis、oauth2。如果最终策略一直是 DIRECT，却指望海外节点救延迟，那是在与配置文件对抗；应先改规则顺序或覆写片段，再谈换节点。

为什么「只开系统代理」常常救不了终端 Agent

macOS 与 Windows 的系统 HTTP 代理主要影响声明遵循系统代理栈的应用；不少运行时与 HTTP 客户端默认不读取系统代理，除非你使用了绑定系统代理库的组件。对 Gemini CLI 这类持续访问 Google AI API 的工具，更稳妥的是在 shell 中显式导出：

  • export HTTPS_PROXY=http://127.0.0.1:7890（端口换成你的 mixed-port）
  • 按需补充 HTTP_PROXY、ALL_PROXY；注意不同工具对 socks5h 与 http 的支持并不一致

只有当你确认所用程序文档写明「继承系统代理」时，才可以省略环境变量；否则请把显式导出当作第一步，再去看规则。

小技巧：在同一终端标签页内先 export 再启动交互；若通过 GUI「新建窗口」但未加载 ~/.zshrc，会出现「配置明明写过却不生效」的错觉。用 env | grep -i proxy 快速确认当前会话；在 Windows 上可用 PowerShell 的 $env:HTTPS_PROXY 对照。

规则分流与全局 TUN：怎么选才不踩坑

规则分流的价值在于：国内站点、包管理镜像、企业内网 Git 可以保留 DIRECT，仅把 Google AI API 与必要的鉴权域名送进代理策略组；晚高峰的大流量下载不必全部挤进同一隧道。对日常开发而言，这是性价比最高的默认。

TUN／虚拟网卡在路由层更早接管，适合死活不认环境变量、或你希望减少漏网进程的场景；代价是要与其它 VPN、零信任客户端、虚拟机网桥协调路由优先级。一旦路由表被抢占，症状仍表现为超时，但根因已是「包没到 Clash」。

实操顺序建议：先用「系统代理或 HTTP 代理 + HTTPS_PROXY」跑通一次最短对话；若连接面板确认主机已走代理仍慢，再考虑换节点或核对出口 region；仅当明确存在绕过用户态代理的进程时，再启用 TUN，并在每次变更后重启终端与 Gemini CLI 会话。

Clash Verge Rev 侧：先对齐端口与当前配置

在 Clash Verge Rev 里先完成三件事：

  1. 确认当前激活的配置就是你编辑的那份；订阅自动更新若冲掉手写规则，会出现「昨天命中代理、今天全直连」的跳转。
  2. 记下界面里的 mixed-port（或单独的 port／socks-port）；下例以 7890 为占位符。
  3. 本机用 curl -x http://127.0.0.1:7890 https://example.org 或浏览器插件先行验证内核 alive；本机都不通时先修节点，不要归咎于 API。

如果你依赖图形覆写（Override），把自定义规则放进覆写层，避免机场一键更新把片段顶掉——这与长期维护「开发者终端代理」是同一套习惯。

HTTPS_PROXY 写在哪：shell、IDE 与 Windows

macOS / Linux：常见做法是把通用代理写进 ~/.zshrc 或 ~/.bashrc，例如：

# Use your real mixed-port. Extend NO_PROXY for corp and mirrors.
export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.local,your.corp.git

NO_PROXY 要按你的内网段、公司域名、私有 PyPI／npm 镜像迭代；漏写会让仓库与注册表误走代理变慢，写得太宽又可能把不该直出的业务绕开 Clash——以连接面板真实主机名为准逐步收紧。

仅对单个项目生效时，可用 direnv、Makefile 或 systemd／launchd 用户单元在进程树根注入变量，避免污染全局。团队把「终端必须先 source 某脚本」写进文档，能显著降低新人试错成本。

Windows：可在用户环境变量里新增 HTTPS_PROXY，或在 PowerShell 会话中赋值；修改后重启终端与 Gemini CLI。若使用 WSL，请在发行版内单独导出一份，WSL 不会自动继承 Windows 图形界面的代理开关。

Google AI API 与鉴权相关的规则分流示例

下面是示意 YAML，请把 YOUR_PROXY_GROUP 换成真实策略组名，并把片段放在会在 MATCH 前生效、且不会被更宽泛的 DIRECT 截胡的位置：

# Override or rules — replace YOUR_PROXY_GROUP
rules:
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,googleapis.com,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,google.dev,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,accounts.google.com,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,oauth2.googleapis.com,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,gstatic.com,YOUR_PROXY_GROUP

说明：Google 侧可能随产品迭代增减辅助域名或使用边缘节点；以你机器连接列表里实际出现的主机为准做增量。若配置大量使用 RULE-SET，留意集合更新后规则顺序是否被插入新项。对大陆用户而言，GEOIP,CN,DIRECT 或某些「超大集合」放得太靠前，仍然是最常见的「写了 DOMAIN 却仍直连」来源——务必在面板里看最终策略而不是想当然。

鉴权流程与 NO_PROXY：别把登录域名挡在代理外

部分人为了「国内网站全直连」把 google.com 全家桶写得很死，结果 OAuth 回调或设备授权在某个子域上仍要可用出口；另一类反例是把公司 SSL 检查设备塞进路径，导致 CLI 校验证书失败。做法是：先用面板确认 accounts／oauth2 命中策略，再决定是否要在公司网改用 Split Tunnel 或专用节点。若你把 NO_PROXY 写得过宽，把本应走代理的 Google 主机排除出去，同样会得到「浏览器能登、CLI 不能续期」的分裂表现。

DNS、fake-ip 与「解析看起来对、链路却不稳」

当规则显示 PROXY 但延仍抖动，复查 DNS：fake-ip 若与特定客户端不契合，可能出现偶发握手慢；DoH 上游若未走通代理，也会表现为解析阶段无限重试。建议顺序是先看连接面板域名与策略，再看 DNS 日志，而不是一上来全局关闭 fake-ip 扩大扰动面。

注意：启用 TUN 后若与公司 VPN 冲突，常见症状是「偶尔能连、多数超时」。先退回 Rule 加环境变量定位，再逐项启用 TUN；不要在未备份配置的情况下并行折腾多款路由软件。

验证：怎样算 Google AI API 真的稳了

  1. 重载配置并确认无 YAML 语法错误。
  2. 新开终端执行 env | grep -i proxy，核对端口与协议。
  3. 使用 curl -v -x http://127.0.0.1:7890 https://generativelanguage.googleapis.com/（路径与参数按官方文档调整）观察是否快速得到 TLS 与 HTTP 反馈，而非长时间挂起。你也可以对 oauth2.googleapis.com 做类似探测以验证鉴权出口。
  4. 启动 Gemini CLI 进行最短一轮对话；同时在 Verge Rev 里搜索 generativelanguage 与 googleapis，确认连续请求为代理策略。
  5. 若仍失败，区分429／403／401与无响应：前者多半是配额、项目启用或密钥问题；后者再回到规则与代理链路。

延伸：别把配额、结算区域与代理混为一谈

当响应体已经明确提示配额、billing、API 未启用或区域限制时，继续在 Clash 里调顺序意义有限；应在 Google Cloud 或 AI Studio 控制台核对项目与密钥。反之，若面板里长期 pending 且主机命中 DIRECT，应回到本文「规则」与「HTTPS_PROXY」两段处理。

为什么开发场景仍值得用 Clash 系客户端统一管理

单模式全局 VPN 往往难以兼顾细粒度域名分流、可读的连接日志，以及与本地开发共存的 NO_PROXY；浏览器插件又对终端进程完全无效，正好卡在 Gemini CLI 这类负载上。Clash Verge Rev 把 Mihomo 内核与覆写结合起来，让你能在不改业务代码的前提下，把 Google AI API、鉴权子域与内网工具链拆开调度。与「遇事不决全局翻」相比，把 generativelanguage.googleapis.com 等主机稳定送进可用节点、其余流量按规则落在国内直连，通常更省延迟、也更易复盘。

相比之下，Clash 生态在规则模型、订阅维护与覆写工作流上更贴近长期开发者需求；本站提供与各平台对齐的客户端获取方式，便于你在同一条开源语义下完成安装与更新。

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