Windows 登录时 Gemini CLI 卡顿的解决方案

最近我在 Windows 环境下部署 Gemini CLI 时，遇到了一个非常典型的“开门黑”问题：执行 gemini login 或初始命令后，终端窗口就陷入了无休止的“转圈”等待状态，完全没有响应。

经过排查，我找到了根本原因并总结了一套亲测有效的解决方案。如果你也卡在了这一步，希望这篇文章能帮你快速脱困。

1. 现象描述：消失的响应

在 Windows 的 CMD 或 PowerShell 中运行 Gemini CLI 相关指令时，程序会长时间停留在空白行或加载图标处。即便你的浏览器可以正常访问 Google 服务，终端里的 Gemini 仍然像断了网一样，既不报错也不退出。

2. 核心原因：终端的“网络孤岛”

我通过分析发现，问题的核心在于 网络环境。

Gemini CLI 需要调用 Google 的 API 服务。虽然你在 Windows 系统中开启了代理软件，但 Windows 终端（CMD/PowerShell）默认并不会自动接管系统级的代理设置。由于无法建立安全的加密连接，CLI 进程会不断尝试重连，从而导致表面上的“卡死”现象。

3. 解决步骤：手动打通网络隧道

要解决这个问题，我们需要在当前的终端会话中手动指定 HTTPS 代理。请根据你使用的终端类型，选择对应的命令（假设你的代理端口是 10808，请根据实际情况修改）:

在 CMD 中设置

如果你使用的是传统的命令提示符，请执行:

set https_proxy=http://127.0.0.1:10808

在 PowerShell 中设置

如果你使用的是 PowerShell（推荐），请执行:

$env:https_proxy="http://127.0.0.1:10808"

4. 验证方法

设置完代理后，我们不需要重新启动终端。直接输入以下命令测试:

gemini "test"

如果设置正确，你会发现原本卡顿的界面瞬间秒开，并返回了 Gemini 的回复。这说明网络隧道已经彻底打通。

5. 常见问题及排查技巧

如果你设置了代理依然卡顿，可以尝试以下几个方向:

• 检查代理地址： 确保你的代理软件已经开启了“允许局域网连接”或确认监听地址是 127.0.0.1。
• 协议匹配： 建议统一使用 http:// 开头的代理地址，即便你要代理的是 HTTPS 流量，这也是最稳妥的写法。
• 永久生效： 如果你不想每次都输入命令，可以将上述命令添加到 Windows 的“系统环境变量”中，变量名为 https_proxy，值为你的代理地址。
• 端口冲突： 运行 netstat -ano | findstr :10808 确认该端口确实被你的代理程序占用。

总结

Windows 终端的网络配置往往是开发者最容易忽视的一环。通过手动指定 https_proxy 环境参数，我成功解决了 Gemini CLI 登录转圈的问题。这种方法不仅适用于 Gemini，对 GitHub CLI 或其他需要科学上网的开发工具同样适用。

如果你在操作中遇到其他错误，欢迎在评论区留言，我们一起交流解决。