Gemini CLI 访问超时怎么处理：给 Node 终端补上代理配置

很多人在 Mac 或 Windows 上装好 Gemini CLI 之后，会遇到一个很典型的问题：

浏览器能正常访问
代理软件也开着
但终端里跑 gemini 还是超时

这类问题大多数不是 Gemini CLI 本身坏了，而是：

Gemini CLI 运行在 Node.js 环境里
Node 进程默认不会自动继承你图形界面的代理设置
所以终端里的请求没有走代理，最终访问 Google 相关接口时超时

先说结论

更稳的做法不是把整台机器的所有终端都永久挂代理，而是：

给 gemini 单独包一层启动函数
在函数里临时注入 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY
只在执行 gemini 时走代理

这样做的好处是：

影响范围更小
不容易污染其他命令
后续改代理端口也更集中

一、为什么会出现这个问题

先把原因说清楚，后面你遇到类似问题就不会只会“复制配置”。

Gemini CLI 本质上是一个终端里的 Node 程序。
而很多本地代理工具虽然已经在系统里启动了，但下面两件事并不总是自动成立：

图形应用的代理已经生效
终端里的 Node 请求也一定会走代理

这两件事经常不是一回事。

所以你会看到下面这种现象：

Chrome 能打开网页
终端里的 curl 或 node 请求却超时
gemini 一调用就卡住或者报超时

本质上就是：

终端进程没有拿到代理环境变量

二、解决思路为什么是“包一层函数”

有三种常见做法：

全局给终端设置代理
每次手工 export HTTP_PROXY=...
给 gemini 包一个专用函数

这里更推荐第 3 种。

原因很简单：

第 1 种影响面太大，很多别的命令也会被带上代理
第 2 种太碎，每次开新终端都要重复
第 3 种最适合日常使用，调用也直观

也就是说，我们的目标不是“永久改环境”，而是：

需要时通过 gemini-proxy 启动 Gemini CLI

三、Mac：修改 `.zshrc`

如果你用的是 macOS，且默认 shell 是 zsh，可以把下面这段函数放进 ~/.zshrc。

注意：

下面示例里的代理端口是 7897
如果你本机代理工具端口不是这个值，要改成你自己的端口

bash

function gemini-proxy() {
  export HTTP_PROXY="http://127.0.0.1:7897"
  export HTTPS_PROXY="http://127.0.0.1:7897"
  export ALL_PROXY="socks5://127.0.0.1:7897"
  export NO_PROXY="localhost,127.0.0.1,::1"
  gemini "$@"
}

1. 打开配置文件

bash

vim ~/.zshrc

如果你不用 vim，也可以用：

bash

open -e ~/.zshrc

2. 粘贴函数并保存

保存后执行：

bash

source ~/.zshrc

3. 使用方式

以后不要直接执行：

bash

gemini

而是执行：

bash

gemini-proxy

如果要带参数，也一样：

bash

gemini-proxy --help

四、Windows：修改 PowerShell Profile

如果你在 Windows 下用的是 PowerShell，可以把下面这段函数放进 PowerShell 的 Profile 文件。

powershell

function gemini-proxy {
    $env:HTTP_PROXY="http://127.0.0.1:7897"
    $env:HTTPS_PROXY="http://127.0.0.1:7897"
    $env:ALL_PROXY="socks5://127.0.0.1:7897"
    $env:NO_PROXY="localhost,127.0.0.1,::1"
    gemini @args
}

1. 查看 Profile 路径

powershell

$PROFILE

2. 如果文件不存在，先创建

powershell

if (!(Test-Path $PROFILE)) {
    New-Item -Path $PROFILE -ItemType File -Force
}

3. 编辑 Profile

powershell

notepad $PROFILE

把上面的 gemini-proxy 函数粘进去并保存。

4. 让配置立即生效

powershell

. $PROFILE

5. 使用方式

powershell

gemini-proxy

或者：

powershell

gemini-proxy --help

五、这几个环境变量各自是干什么的

很多人复制了一堆代理变量，但其实没分清它们的作用。

`HTTP_PROXY`

给基于 HTTP 的请求指定代理地址。

`HTTPS_PROXY`

给基于 HTTPS 的请求指定代理地址。
Gemini CLI 访问外部接口时，更关键的通常就是这个变量。

`ALL_PROXY`

给更通用的代理场景兜底，尤其是某些支持 socks5 的请求链路。

`NO_PROXY`

告诉程序：

本机地址不要走代理

比如：

localhost
127.0.0.1
::1

这样可以避免本地服务也被错误转发到代理里。

六、为什么这里同时写了 HTTP 和 SOCKS5

你给的这套配置里：

HTTP_PROXY 和 HTTPS_PROXY 指向 http://127.0.0.1:7897
ALL_PROXY 指向 socks5://127.0.0.1:7897

这是一种比较常见也比较稳的写法，原因是：

大多数 Node / CLI 请求能直接识别 HTTP_PROXY、HTTPS_PROXY
有些底层库或链路会参考 ALL_PROXY

所以这套配置更像是：

以 HTTP 代理为主
用 SOCKS5 做补充兜底

七、怎么验证是否已经生效

不要配完就直接默认成功，至少做一次最小验证。

Mac

bash

gemini-proxy --help

如果你还想顺手确认环境变量，可以执行：

bash

function gemini-proxy-check() {
  export HTTP_PROXY="http://127.0.0.1:7897"
  export HTTPS_PROXY="http://127.0.0.1:7897"
  export ALL_PROXY="socks5://127.0.0.1:7897"
  export NO_PROXY="localhost,127.0.0.1,::1"
  node -e 'console.log(process.env.HTTP_PROXY); console.log(process.env.HTTPS_PROXY); console.log(process.env.ALL_PROXY)'
}

然后执行：

bash

gemini-proxy-check

Windows PowerShell

powershell

gemini-proxy --help

如果还想检查变量：

powershell

function gemini-proxy-check {
    $env:HTTP_PROXY="http://127.0.0.1:7897"
    $env:HTTPS_PROXY="http://127.0.0.1:7897"
    $env:ALL_PROXY="socks5://127.0.0.1:7897"
    $env:NO_PROXY="localhost,127.0.0.1,::1"
    node -e "console.log(process.env.HTTP_PROXY); console.log(process.env.HTTPS_PROXY); console.log(process.env.ALL_PROXY)"
}

然后执行：

powershell

gemini-proxy-check

八、如果还是超时，还要再查什么

如果配置了代理还是不通，优先排查下面几件事：

1. 代理端口是不是写对了

很多人代理工具实际端口并不是 7897，而是：

7890
7891
1080
其他自定义端口

2. 代理工具本身是不是可用

如果代理软件本身没连上，终端当然也不会通。

3. `gemini` 命令是不是当前 shell 里的真实命令

先确认：

bash

which gemini

或者在 PowerShell 里：

powershell

Get-Command gemini

4. 你的 shell 配置有没有重新加载

比如：

Mac 改了 .zshrc 但没 source ~/.zshrc
Windows 改了 $PROFILE 但没重新加载

九、为什么不建议一上来就全局开代理

因为全局代理很容易带来额外问题：

其他 Node 命令也被带上代理
某些内部地址访问变慢
本地开发服务联调出现奇怪问题

所以对于 Gemini CLI 这种场景，更推荐：

只在执行它时加代理

这也是这篇文章一直在强调 gemini-proxy 函数的原因。

十、回退也很简单

如果你后面不想用了：

Mac 就把 .zshrc 里的函数删掉，再执行 source ~/.zshrc
Windows 就把 PowerShell Profile 里的函数删掉，再执行 . $PROFILE

不会影响你的其他命令结构。

一句话总结

Gemini CLI 在终端里访问超时，很多时候不是客户端本身的问题，而是 Node 进程没有拿到代理环境变量。

最稳的方案不是把整套终端环境都改成全局代理，而是给 gemini 单独包一层 gemini-proxy 启动函数，让它在 Mac 的 .zshrc 或 Windows 的 PowerShell Profile 里按需走代理。

Gemini CLI 访问超时怎么处理：给 Node 终端补上代理配置 ​

先说结论 ​

一、为什么会出现这个问题 ​

二、解决思路为什么是“包一层函数” ​

三、Mac：修改 .zshrc ​

1. 打开配置文件 ​

2. 粘贴函数并保存 ​

3. 使用方式 ​

四、Windows：修改 PowerShell Profile ​

1. 查看 Profile 路径 ​

2. 如果文件不存在，先创建 ​

3. 编辑 Profile ​

4. 让配置立即生效 ​

5. 使用方式 ​

五、这几个环境变量各自是干什么的 ​

HTTP_PROXY ​

HTTPS_PROXY ​

ALL_PROXY ​

NO_PROXY ​

六、为什么这里同时写了 HTTP 和 SOCKS5 ​

七、怎么验证是否已经生效 ​

Mac ​

Windows PowerShell ​

八、如果还是超时，还要再查什么 ​

1. 代理端口是不是写对了 ​

2. 代理工具本身是不是可用 ​

3. gemini 命令是不是当前 shell 里的真实命令 ​

4. 你的 shell 配置有没有重新加载 ​

九、为什么不建议一上来就全局开代理 ​

十、回退也很简单 ​

一句话总结 ​

Gemini CLI 访问超时怎么处理：给 Node 终端补上代理配置

先说结论

一、为什么会出现这个问题

二、解决思路为什么是“包一层函数”

三、Mac：修改 `.zshrc`

1. 打开配置文件

2. 粘贴函数并保存

3. 使用方式

四、Windows：修改 PowerShell Profile

1. 查看 Profile 路径

2. 如果文件不存在，先创建

3. 编辑 Profile

4. 让配置立即生效

5. 使用方式

五、这几个环境变量各自是干什么的

`HTTP_PROXY`

`HTTPS_PROXY`

`ALL_PROXY`

`NO_PROXY`

六、为什么这里同时写了 HTTP 和 SOCKS5

七、怎么验证是否已经生效

Mac

Windows PowerShell

八、如果还是超时，还要再查什么

1. 代理端口是不是写对了

2. 代理工具本身是不是可用

3. `gemini` 命令是不是当前 shell 里的真实命令

4. 你的 shell 配置有没有重新加载

九、为什么不建议一上来就全局开代理

十、回退也很简单

一句话总结