使用 v2rayN 后，浏览器可以正常打开网页，但 Gemini CLI 却提示连接失败、请求超时或一直停留在加载状态，最常见的原因不是节点马上失效，而是浏览器和终端使用了两套不同的代理路径。浏览器可能读取了 v2rayN 的系统代理设置，终端中的 Node.js 进程却没有继承代理变量；也可能是终端读取了错误端口、DNS 解析走了直连，或者当前路由规则没有覆盖 Gemini CLI 使用的域名。排查时应先确认本地代理端口，再单独验证终端请求，最后才考虑切换 Tun 模式。
本文面向 Windows、macOS 与 Linux 上使用 Gemini CLI 和 v2rayN 的用户，按“本地端口→环境变量→终端请求→节点与 DNS→路由及 Tun 模式”的顺序排查。文中给出 PowerShell、命令提示符和 Bash 的设置示例，并说明 HTTP 代理、SOCKS 代理、HTTPS_PROXY、NO_PROXY 与常见报错之间的关系，帮助判断问题究竟出在终端未走代理、节点不可用，还是系统网络路径。
先确认浏览器与终端是否走同一条路径
浏览器能打开网页，只能证明浏览器当前请求成功，不能证明 Gemini CLI 也使用了同一个入站端口。v2rayN 的“系统代理”主要影响支持系统代理设置的应用；终端程序是否使用代理，取决于它是否读取环境变量、是否自行实现代理逻辑，以及启动它的 Shell 是否继承了正确配置。尤其是通过 npm、npx 或 Node.js 启动的命令，实际发起网络请求的进程可能是子进程，环境变量必须在启动 Gemini CLI 之前存在。
10809 和 10808 只是常见示例，不是所有 v2rayN 版本都固定使用这两个数字。打开 v2rayN 的「设置」→「参数设置」，查看 HTTP 代理端口、SOCKS 端口或混合端口的实际值。端口必须与环境变量中的地址完全一致；如果 v2rayN 使用 7890，而终端仍指向 10809，浏览器可能正常，Gemini CLI 则会立即拒绝连接。
- 浏览器正常，curl 失败：优先检查终端代理变量或代理端口。
- curl 正常，Gemini CLI 失败：检查 CLI 使用的 Node.js 版本、代理变量继承和 CLI 自身配置。
- 所有程序都失败：先在 v2rayN 中更换节点并测试真连接延迟。
- 只有特定域名失败：继续检查 DNS、路由规则、域名分流和节点出口。
结论：先验证端口，再判断节点
浏览器可用并不能直接证明节点可用，也不能证明终端已接入代理。用一个明确指定本地代理的命令测试目标站，能够最快把“终端配置问题”和“节点线路问题”分开。
在 v2rayN 中读取正确的代理端口
Gemini CLI 访问的是 HTTPS 服务，最容易成功的方式通常是让它通过 v2rayN 的本地 HTTP 代理端口发出 CONNECT 请求。HTTP 代理并不意味着目标网站使用明文 HTTP；对于 HTTPS 网址，终端先连接本地 HTTP 代理，再由代理建立到远端 443 端口的隧道。若只设置了 SOCKS 端口，却把它写成 http://，协议类型不匹配时会出现连接重置、代理响应无效或握手失败。
适合先验证 Gemini CLI、curl 和多数命令行工具。地址格式通常为 http://127.0.0.1:10809，端口以 v2rayN 实际设置为准。
适合:优先排查终端是否走代理
适合支持 SOCKS5 的客户端或工具。常见地址格式为 socks5://127.0.0.1:10808，但不是每个 Node.js 网络库都会自动读取 SOCKS 环境变量。
适合:工具明确支持 SOCKS5
通过虚拟网卡接管更大范围的系统流量，终端通常不需要单独设置代理变量，但需要处理虚拟网卡权限、路由冲突和 DNS 接管。
适合:程序不支持代理变量
建议先使用 HTTP 端口完成验证，不要一开始同时开启 HTTP、SOCKS、系统代理和 Tun。多层代理会让故障定位变得困难，例如终端变量指向 10809，系统代理又指向另一个端口，而 Tun 模式还在接管默认路由，此时日志中的连接路径不容易判断。
为不同终端设置 HTTP_PROXY 与 HTTPS_PROXY
环境变量必须在启动 Gemini CLI 的同一个终端会话中设置。Windows 图形界面中的系统环境变量、PowerShell 会话变量、命令提示符变量和 IDE 内置终端变量并不总是即时同步。设置后应先关闭旧终端窗口，再打开新的 PowerShell 或命令提示符；如果 Gemini CLI 是从编辑器终端启动，也要确认编辑器是在变量设置完成后重新启动的。
PowerShell
- HTTP_PROXY
- http://127.0.0.1:10809
- HTTPS_PROXY
- http://127.0.0.1:10809
- NO_PROXY
- localhost,127.0.0.1
只对当前 PowerShell 窗口及其子进程生效。
命令提示符
- HTTP_PROXY
- http://127.0.0.1:10809
- HTTPS_PROXY
- http://127.0.0.1:10809
- NO_PROXY
- localhost,127.0.0.1
使用 set 设置时，关闭窗口后变量会消失。
在 PowerShell 中可以执行下面的命令。把 10809 替换成 v2rayN 设置页面显示的 HTTP 端口：
$env:HTTP_PROXY = "http://127.0.0.1:10809"
$env:HTTPS_PROXY = "http://127.0.0.1:10809"
$env:NO_PROXY = "localhost,127.0.0.1"
gemini在 Windows 命令提示符中使用以下写法：
set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
set NO_PROXY=localhost,127.0.0.1
geminimacOS 与 Linux 的 Bash、Zsh 通常使用 export。如果只是临时测试，可以把变量写在同一行，避免修改 Shell 配置文件：
export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
export NO_PROXY="localhost,127.0.0.1"
geminiHTTPS_PROXY 的值描述的是“连接代理服务器时使用的代理类型”，不是目标网址的协议。即使 Gemini 目标是 HTTPS，也可以使用 http://127.0.0.1:10809 作为本地代理地址。若 v2rayN 提供的端口确实是 SOCKS5，则应改成 socks5://127.0.0.1:10808，但遇到 Node.js 工具不识别该变量时，优先换用 HTTP 代理端口验证。
- 使用
Get-ChildItem Env:HTTP_PROXY检查 PowerShell 是否保存变量。 - 使用
echo %HTTPS_PROXY%检查命令提示符中的变量。 - 使用
printenv | grep -i proxy检查 Bash 或 Zsh 中的变量。 - 同时检查小写变量
http_proxy、https_proxy是否指向了旧端口。 - 如果设置了
ALL_PROXY，先暂时清除它，避免它覆盖或干扰 HTTP 代理测试。
先用 curl 验证终端代理，再启动 Gemini CLI
不要直接反复启动 Gemini CLI 来猜测原因。先使用能够明确指定代理的 curl 测试本地代理端口是否可以建立 HTTPS 连接。这个测试不负责验证 API 密钥、配额或 CLI 登录状态，只验证“当前终端能否通过 v2rayN 访问目标域名”。如果 curl 已经无法建立连接，继续修改 Gemini CLI 参数没有意义。
curl.exe -I -v --proxy http://127.0.0.1:10809 https://generativelanguage.googleapis.com/正常情况下，详细输出中应能看到 curl 先连接 127.0.0.1:10809，随后向代理发送 CONNECT 请求。目标返回 401、403 或其他 HTTP 错误并不一定表示代理失败，这可能说明网络路径已经打通，只是当前请求没有提供有效认证或接口参数。相反，如果输出显示 Connection refused，通常是端口没有监听；如果长时间停在连接阶段，则继续检查 v2rayN 内核、节点和防火墙。
报错: Failed to connect to 127.0.0.1 port 10809
原因与解法:本地 HTTP 代理端口没有监听，或环境变量中的端口与 v2rayN 实际端口不同——打开「设置」→「参数设置」核对端口，确认内核和本地代理已经启动。
报错: Could not resolve host
原因与解法:域名解析失败，可能是 DNS 直连被阻断或代理未接管解析——先使用 v2rayN 的远程 DNS 或 Tun 模式复测，并检查路由规则。
报错: Proxy CONNECT aborted
原因与解法:代理协议、端口或节点出口建立失败——不要把 SOCKS 端口写成 HTTP 地址，先换用 v2rayN 的 HTTP 端口并测试另一个节点。
报错: fetch failed
原因与解法:Node.js 网络层没有完成请求，可能是代理变量未继承、证书握手失败或目标连接超时——先用同一终端执行 curl，再检查 Gemini CLI 使用的 Node.js 运行环境。
如果 curl 指定代理可以连接，但直接执行 Gemini CLI 仍失败，说明 v2rayN 节点和本地 HTTP 端口大概率正常。此时重点检查变量是否在 CLI 启动前存在，以及是否同时设置了错误的小写变量。还应确认调用的是预期的命令版本：
where.exe gemini
node --version
npm --version
Get-ChildItem Env:*proxy*在 macOS 或 Linux 中可以使用：
command -v gemini
node --version
npm --version
printenv | grep -i proxy结论：把认证错误与网络错误分开
curl 能经过代理到达目标，但 Gemini CLI 返回 API 密钥、登录、权限或配额提示时，问题已经从网络层进入账号或服务层。只有持续出现连接拒绝、DNS 失败、TLS 超时和 fetch failed，才应继续沿代理链路排查。
节点、DNS 与路由规则的分层排查
当环境变量正确且本地端口可连接，仍然超时，就要把节点、DNS 和路由拆开检查。Gemini CLI 可能访问多个 Google 相关域名，实际请求还会受到认证流程、模型接口、区域出口和系统时间影响。不要只测试一个首页域名就下结论，也不要因为浏览器打开普通网页正常，就认为访问 Gemini 使用的所有域名都正常。
推荐方案：先固定节点，再逐层替换
v2rayN 侧
- 选择一个真连接延迟稳定的节点
- 查看 Xray 内核是否持续运行
- 确认路由模式没有误分流
- 记录 HTTP 端口和 DNS 设置
终端侧
- 确认 HTTP_PROXY 与 HTTPS_PROXY
- 先用 curl 指定代理测试
- 清除旧的 ALL_PROXY 变量
- 再启动 Gemini CLI 验证
每次只改一个变量并重复测试，才能知道是节点、DNS 还是终端配置产生了变化。
节点层面先在 v2rayN 主界面选择当前订阅中的另一个节点，执行真连接延迟测试。若多个节点都无法访问，而 curl 直连同样失败，可能是当前网络限制或目标服务不可达；若只有某一个节点失败，则优先删除该节点或检查其 VLESS、VMess、TLS、Reality、SNI 和端口字段。对于包含 Reality 参数的节点，应确认使用支持该配置的 Xray 内核。
DNS 层面要注意“能解析”与“通过代理解析”并不是一回事。终端或系统可能先用本地 DNS 得到地址，再把地址交给代理；也可能由代理侧解析域名。若本地 DNS 返回污染地址、解析超时或 IPv6 路径不可用，表现可能是浏览器偶尔成功、CLI 长时间等待。可以在 v2rayN 的 DNS 设置中暂时选择稳定的远程解析方式，并关闭不确定的 IPv6 分流后复测。
- 路由模式为规则模式时，确认 Gemini 相关域名没有被错误标记为直连。
- 全局模式可作为短时诊断手段，但不建议长期替代精细分流。
- 修改 DNS 或路由后，重新启动当前内核，再打开新的终端窗口。
- 检查系统时间是否准确；TLS、OAuth 和 API 请求都可能因时间偏差失败。
- 不要把
NO_PROXY=*留在环境变量中，否则可能让所有目标绕过代理。
终端不认代理时使用 Tun 模式
有些程序不会读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，或者其底层网络库只支持部分代理格式。此时即使 curl 能通过 v2rayN 成功，Gemini CLI 仍可能直接访问本地网络。Tun 模式通过虚拟网卡接管系统流量，使不支持代理变量的程序也有机会进入 v2rayN 的路由链路，但它不是“打开后必然修复”的开关，虚拟网卡驱动、管理员权限、DNS 和路由冲突都可能造成新的问题。
-
关闭旧变量
保留 v2rayN 的节点连接，暂时清除 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY，避免 Tun 与应用代理叠加。
-
启用 Tun
在 v2rayN 的「设置」→「参数设置」中打开 Tun 相关选项，按系统提示授予虚拟网卡所需权限。
-
检查路由
确认默认路由、局域网直连规则和 DNS 接管状态，避免虚拟网卡启动后出现整机断网。
-
重新测试
新开终端执行 Gemini CLI，并同时用 curl 测试目标域名；比较启用前后的连接结果。
-
保留稳定方案
如果 HTTP_PROXY 已能稳定工作，优先继续使用应用代理；只有 CLI 明确不识别代理变量时才长期启用 Tun。
Tun 模式下仍然要检查 v2rayN 日志。如果看到本地 DNS 请求循环、路由回环、虚拟网卡启动失败或默认网关冲突，应先关闭 Tun 恢复网络，再逐项调整。Windows 可能需要管理员权限；Linux 可能涉及系统服务、路由权限或 NetworkManager；macOS 则要留意系统对网络扩展的授权提示。不同版本的 v2rayN 菜单名称可能略有区别，应以当前界面实际显示为准。
结论：Tun 是兼容性方案，不是第一步
能读取 HTTP_PROXY 的 Gemini CLI，优先使用明确的本地 HTTP 代理，配置更容易复现；只有程序不读取环境变量、代理变量格式不兼容，或需要统一接管多个终端工具时，才使用 Tun 模式。
最后的完整复测清单
完成修改后不要只重复点击一次 Gemini CLI。应从本地端口、代理变量、目标域名、节点切换和 CLI 运行环境五个方面留下可比较的结果。这样即使问题之后再次出现，也能快速判断是订阅节点变化、系统更新改变了 Node.js 环境，还是 Shell 配置被覆盖。
| 顺序 | 检查内容 | 通过标准 | 未通过时的动作 |
|---|---|---|---|
| 1 | v2rayN 节点 | 内核持续运行，真连接测试成功 | 更换节点并查看 Xray 日志 |
| 2 | 本地端口 | HTTP 端口处于监听状态 | 核对「参数设置」中的实际端口 |
| 3 | curl 请求 | 通过指定代理完成 HTTPS 连接 | 检查代理类型、DNS 与路由 |
| 4 | 环境变量 | HTTPS_PROXY 指向当前 HTTP 端口 | 清除旧变量并重新打开终端 |
| 5 | Gemini CLI | 进入登录、模型或正常响应阶段 | 检查 Node.js 版本、认证和 CLI 日志 |
如果问题只发生在某个终端，比较该终端与新开的系统终端中的 PATH、Node.js 版本和代理变量。通过 npm 全局安装的 Gemini CLI 可能被不同版本的 Node.js 调用；命令提示符、PowerShell、Bash 和编辑器终端也可能加载不同的配置文件。若 curl 和 CLI 都失败，回到端口、节点和 DNS 层；若 curl 成功而 CLI 失败，则不要继续更换节点，应集中检查 CLI 进程是否继承了变量。
- 使用 HTTP 代理时，
HTTP_PROXY与HTTPS_PROXY通常都指向同一个本地 HTTP 端口。 - 使用 SOCKS5 时，先确认目标工具明确支持该协议和对应环境变量。
- 不要把远端服务器端口 443 写成本地代理端口；两者属于不同连接。
- 修改 v2rayN 路由、DNS 或 Tun 后，关闭旧终端并重新启动 CLI。
- 认证失败、配额不足和模型不可用属于服务层问题，应与代理连接超时分开处理。