配置实战 约 11 分钟阅读

Gemini CLI国内怎么用？Clash访问配置指南

想在终端体验Gemini CLI，却总是遇到登录失败或请求超时？本文从客户端选择、订阅导入到规则分流，讲清楚如何用Clash为Gemini CLI配置更稳定的网络环境。

Gemini CLI 适合在终端里完成代码解释、文件分析、命令生成和项目问答，但在国内网络环境中，首次登录、模型请求和账号验证可能分别走不同的连接路径。常见现象包括浏览器授权后终端没有登录状态、请求长时间停在 loading、返回连接超时，或者普通网页可以打开而 Gemini CLI 仍然提示网络错误。

Clash 能解决的不是账号权限或 API 配额问题，而是把 Gemini CLI 发起的网络请求交给稳定的代理策略组，并让登录回调、API 请求和其他国内流量分别走合适的链路。本文以 Windows、macOS 和 Linux 上常见的 mihomo 内核客户端为例，说明客户端选择、订阅导入、规则分流、环境变量和故障定位的完整流程。

先确认使用方式:登录账号还是 API Key

配置 Clash 之前，先确认 Gemini CLI 当前采用哪一种认证方式。不同认证方式的请求路径、登录动作和排查重点并不相同，不能只看到“终端无法访问”就直接切换全局代理。

使用方式认证特点Clash 配置重点适合场景
浏览器账号登录终端调用浏览器完成 OAuth 或设备授权登录页面、回调地址和 API 请求都要能正常访问个人试用、快速开始
API Key通过环境变量或配置文件传递密钥重点保证 API 请求域名走代理，并保护本地密钥脚本、自动化、项目开发
企业或组织账号可能附带组织策略、区域和配额限制代理只能改善连通性，不能绕过组织权限团队账号、企业环境

如果使用浏览器登录，Clash 必须在授权动作发生前就已经启动，并且系统代理或 TUN 模式处于工作状态。浏览器跳转成功不代表终端请求一定成功，因为授权页面、回调接口和模型接口可能由不同域名提供。使用 API Key 时，则要重点确认环境变量被当前 shell 读取，且密钥没有被写进公开脚本、终端录屏或配置仓库。

先解决认证，再判断代理

“登录失败”可能来自账号地区、权限、授权过期或系统时间错误；“请求超时”才更接近网络连通性问题。建议先用同一套认证方式完成一次最小请求，再开始调整规则，避免把账号问题误判成 Clash 问题。

客户端与订阅准备:选择能运行 mihomo 的版本

Gemini CLI 本身没有图形化代理开关，通常依赖系统代理、环境变量，或者由 TUN 模式接管网络。因此客户端的重点不是界面是否漂亮，而是内核是否支持稳定的规则分流、TUN、DNS 接管和日志查看。Windows、macOS 和 Linux 上，优先选择仍在维护且明确使用 mihomo 内核的 Clash 客户端；安卓设备一般不直接运行 Gemini CLI，但可以通过 Clash 共享网络给其他设备使用。

  1. 打开本站下载中心，按操作系统选择仍在维护的 Clash 客户端，安装完成后先不要急着导入多份配置。
  2. 从代理服务商复制订阅链接，确认链接完整、没有换行和多余空格。订阅链接包含账号令牌，应当像密码一样保存。
  3. 进入客户端的“配置 / Profiles”页面，选择“从 URL 导入”，粘贴订阅地址并下载。
  4. 选中刚下载的配置使其生效，在“代理”页面确认至少有一个节点可以完成延迟测试。
  5. 在“设置”或“General”页面记录混合端口，例如 7890；如果客户端显示的是其他端口，后续命令必须使用实际端口。

第一次测试建议关闭其他 VPN、网络加速器和第二个代理客户端。多个程序同时修改系统代理、路由表或 DNS 时，终端里的请求可能被送到错误端口，日志也会出现重复连接。Clash 只需要保留一个主实例，其他工具全部退出后再开始验证。

登录和 API 请求通常需要代理，国内包管理器、局域网地址和本地开发服务则不一定需要代理。日常模式建议使用“规则”，不要一开始就把整台电脑固定在全局模式。全局模式适合短时间确认“代理链路本身是否可用”，不能替代正确的规则设计。

配置规则分流:只让 Gemini CLI 相关请求走代理

Gemini CLI 运行在 Node.js 环境中，进程本身可能显示为 node，因此仅使用进程规则会把其他 Node.js 程序也一起送进代理。更稳妥的方式是“域名规则为主、进程规则为辅”：先从 Clash 日志中观察 Gemini CLI 实际访问的域名，再针对这些域名建立策略组；如果命令行流量没有经过系统代理，再用 TUN 模式补齐。

下面是一份适合 mihomo 内核的结构示例。AI-PROXY 是自定义策略组名称，必须替换成配置中真实存在的节点组；示例域名仅用于说明格式，实际使用时应以客户端日志中显示的 Gemini CLI 请求域名为准。

mixed-port: 7890
mode: rule
allow-lan: false

proxy-groups:
  - name: AI-PROXY
    type: select
    proxies:
      - 节点自动选择
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.invalid,AI-PROXY
  - PROCESS-NAME,node,AI-PROXY
  - MATCH,DIRECT

这段配置的关键不在示例域名，而在规则顺序。需要代理的域名必须出现在 MATCH 之前，否则兜底规则会提前结束匹配。PROCESS-NAME,node,AI-PROXY 可以作为临时诊断规则，但长期使用时可能让 npm、构建工具和本地脚本全部走代理，导致下载变慢或访问内网失败。

如果不确定域名，可以先打开 Clash 的连接日志，再执行一次 Gemini CLI 的最小请求。记录请求的主域名、端口、连接结果和命中的策略组。不要把完整请求 URL、API Key 或带有账号信息的日志直接发布到网上。观察到域名后，再把精确域名或后缀规则放进配置，最后删掉过宽的临时进程规则。

规则不是越宽越好

直接写 DOMAIN-KEYWORD,google,AI-PROXY 可能把完全不需要代理的服务一起匹配。优先使用明确的 DOMAIN 或 DOMAIN-SUFFIX，并把域名拆成认证、模型请求和更新服务分别观察。遇到域名变化时，更新规则比长期使用关键词兜底更容易维护。

动手操作:让终端正确读取 Clash 端口

系统代理开关只对遵守系统代理设置的程序有效，终端里的 Node.js 应用是否读取它，取决于 Gemini CLI 版本、运行环境和启动方式。为了排除系统代理识别差异，可以先在当前终端显式设置 HTTP、HTTPS 和 SOCKS5 代理变量，再执行测试命令。

Windows PowerShell

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7890"
gemini

PowerShell 中使用 $env: 设置的变量只对当前窗口及其子进程生效。关闭窗口后变量会消失，适合先做验证。若确认有效，再通过系统环境变量或 PowerShell 配置文件持久化，但不要把包含密钥的完整命令写进公共脚本。

macOS 与 Linux

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7890"
gemini

如果本地 Clash 的混合端口不支持你当前程序使用的 SOCKS 写法，可以只保留 HTTP 和 HTTPS 两个变量进行测试。命令执行前用 printenv | grep -i proxy 检查变量是否存在；Windows PowerShell 可用 Get-ChildItem Env: | Select-String -Pattern "PROXY" 查看。

代理变量写入后，先运行一次不涉及复杂项目的最小命令，例如让 Gemini CLI 解释一段短文本。若命令立即返回认证错误，说明网络请求大概率已经发出，应转向检查账号登录、API Key 和权限；若一直超时，则回到 Clash 日志确认是否出现连接记录、是否命中 AI-PROXY，以及节点是否能建立 TLS 连接。

需要注意的是，NO_PROXY 可能让某些地址绕过代理。局域网开发服务可以加入 localhost,127.0.0.1，但不要把需要代理的服务域名误写进去。修改环境变量后必须重新启动 Gemini CLI，因为已经运行的进程不会自动读取后来新增的变量。

TUN 与 DNS 排查:解决能开网页却连不上 CLI

当浏览器能够正常打开目标服务，而 Gemini CLI 仍然超时，常见原因是浏览器使用了系统代理，终端进程却没有；另一种情况是终端走了代理，但 DNS 查询仍由本地网络完成，导致域名解析结果错误。此时可以短时间开启 TUN 模式进行对照测试。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

Windows 通常需要安装服务模式并授予管理员权限，macOS 需要允许网络扩展或帮助程序，Linux 可能需要 root 权限或相应的网络 capabilities。开启 TUN 后，先关闭系统中其他 VPN，再启动 Clash，确认虚拟网卡已经出现。不要在多个客户端里同时打开 TUN，否则路由优先级可能互相覆盖。

fake-ip 模式下，域名可能解析到 198.18.x.x 网段，这是 Clash 的虚拟地址，不是异常公网地址。若本地开发域名、局域网设备或某些需要真实 IP 的程序出现问题，可以把相应域名加入 fake-ip-filter，不要为了迁就单个程序直接关闭全部 DNS 接管。

  • Clash 日志完全没有 Gemini CLI 连接：优先检查进程是否读取代理变量，或用 TUN 接管。
  • 日志有连接但策略组显示 DIRECT：检查域名规则顺序，确认目标规则位于 MATCH 之前。
  • 命中代理但 TLS 握手失败：切换同组其他节点，检查系统时间，并暂时关闭节点测速以外的网络工具。
  • 登录成功但模型调用报权限错误：检查账号资格、API Key、项目配置和配额，这类问题不是 Clash 规则可以修复的。
  • 请求偶尔成功、偶尔超时：为 AI 服务单独建立选择型策略组，避免频繁自动切换节点导致连接复用失败。

稳定性优化:节点、策略组与安全习惯

Gemini CLI 的一次命令可能持续较长时间，节点的持续连接能力比瞬时测速更重要。自动测速组适合网页访问，却可能在长输出过程中切换出口。建议为 AI 请求设置一个选择型策略组，先手动选择延迟稳定、丢包少的节点，连续运行几次长回复后再考虑使用 url-test。

现象优先调整项不要先做的事
启动即提示无法连接检查端口、环境变量和 TUN 状态不要立刻更换整份订阅
登录页面能打开但回调失败确认浏览器与终端使用同一代理链路不要重复点击授权造成多个会话
短请求成功，长输出中断换稳定节点，固定 AI 策略组不要只看一次延迟测试结果
国内命令和 npm 下载变慢把国内域名和局域网放回 DIRECT不要长期使用全局模式

安全方面，API Key 不应写入项目提交、shell 历史或公开日志。可以使用操作系统环境变量、密码管理器或客户端支持的安全存储。订阅链接同样包含可用凭据，导入后不要复制到截图和排障帖中。遇到密钥或订阅链接泄露，应立即在服务商后台撤销或重置，而不是只修改本地 Clash 配置。

最后保留一套最小化配置作为排障基线：一个可用节点、一个 AI 策略组、一条明确的域名规则和一条 MATCH,DIRECT 兜底规则。基线配置能正常工作后，再逐步加入国内规则集、DNS 优化和自动测速组。每次只改一个变量，才能知道问题究竟来自规则、节点、认证还是终端环境。

继续使用:下载客户端并完成首次配置

如果还没有安装 Clash，建议先选择支持 mihomo、日志查看和 TUN 的客户端，再按本文顺序导入订阅、确认端口、设置终端变量，最后用最小请求验证 Gemini CLI。

前往下载 查看教程
下载Clash