站点图标 高效码农

AionUI Gemini OAuth登录失败？这4个环境变量设置让你从ETIMEDOUT秒通！

高效码农

AionUI Gemini 登录失败的根因与最终解决方案

核心结论先给出：
当 AionUI 在使用 Gemini 时出现 Failed to exchange authorization code for tokens 且伴随 connect ETIMEDOUT 74.125.20.95:443，问题并不在 Gemini 本身，也不是 API Key 错误，而是 AionUI 通过 Node/Electron 进行 OAuth 登录时，无法直连 Google OAuth Token 服务。
最终、有效、可复现的解决方案是：为系统级进程显式设置 HTTP/HTTPS 代理环境变量。

setx HTTPS_PROXY http://127.0.0.1:7890
setx HTTP_PROXY  http://127.0.0.1:7890

本文将围绕这个结论展开，完整回答以下问题：

  • AionUI 的 Gemini 登录到底在哪一步失败？
  • 为什么浏览器能登录 Google，而 AionUI 却不行？
  • 为什么设置系统代理环境变量可以“一步到位”解决问题？
  • 这个方案背后的技术逻辑是什么？
  • 在实际使用中需要注意哪些细节，避免再次踩坑？

文章内容严格基于前述问题排查与解决过程，不引入外部事实，仅对已有信息进行结构化整理、扩展说明与场景化解释。

一、问题的本质是什么？

本段核心问题：AionUI 的 Gemini 登录失败，真正卡在了哪一步？

从报错信息入手：

Failed to exchange authorization code for tokens:
request to https://oauth2.googleapis.com/token failed,
reason: connect ETIMEDOUT 74.125.20.95:443

这段错误已经提供了足够多的关键信息：

  • 失败阶段：exchange authorization code for tokens
  • 失败目标地址：https://oauth2.googleapis.com/token
  • 失败原因：ETIMEDOUT（连接超时）

这意味着一件非常具体的事情：

OAuth 登录流程中，浏览器已经完成了用户授权，但 AionUI 在本地尝试用“授权码”向 Google 的 OAuth Token 接口换取 Access Token 时，网络连接直接超时。

换句话说，问题不是发生在“登录”这一步，而是发生在“换 Token”这一步。

二、为什么浏览器能登录，但 AionUI 不行？

本段核心问题：既然能在浏览器中正常访问 Google，为什么 AionUI 却连不上？

这是绝大多数人最容易产生误解的地方。

1. OAuth 登录的真实流程

从用户视角看，“用 Google 登录”只有一步；但从技术实现看，至少包含两个完全不同的网络阶段：

  1. 浏览器阶段

    • 浏览器跳转到 Google 授权页面
    • 用户输入账号并同意授权
    • Google 将 authorization code 回传给本地应用

  2. 本地程序阶段

    • AionUI（Node/Electron）在本地发起 HTTPS 请求
    • 请求 https://oauth2.googleapis.com/token
    • 用授权码换取 Access Token / Refresh Token

你的问题，恰恰出现在第二步。

2. 浏览器与本地程序的网络路径并不相同

对比项 浏览器 AionUI / Node / Electron
是否自动走代理 是（插件 / PAC / 系统设置） 否（默认直连）
是否有 Google 域名白名单 常见 没有
是否继承系统代理 取决于配置 仅在显式设置时

结论非常清晰：

浏览器能访问 Google，并不代表 Node/Electron 进程也能访问 Google。

AionUI 在 OAuth Token 阶段走的是 本地进程直连网络，而不是浏览器通道。

三、报错信息能告诉我们什么？

本段核心问题：ETIMEDOUT 74.125.20.95:443 说明了什么？

逐项拆解这个错误：

  • 74.125.20.95
    Google 的全球 IP 段之一，说明 DNS 解析是成功的。

  • 443
    HTTPS 端口，说明是标准 TLS 连接。

  • ETIMEDOUT
    连接超时，而不是被拒绝、证书错误或 401/403。

这意味着：

  • 请求并未被明确拒绝
  • 程序尝试建立 TCP 连接，但一直没有成功
  • 典型直连被阻断或无路由场景

换句话说：AionUI 并没有走代理。

四、为什么“改用 API Key”通常能绕过问题？

本段核心问题：为什么很多人改用 Gemini API Key 就“突然好了”？

在前期分析中，已经明确一个事实：

  • OAuth 登录 必须访问 oauth2.googleapis.com/token
  • API Key 模式 不需要走 OAuth Token 交换流程

因此：

  • 使用 API Key → 不触发 OAuth Token 请求 → 不访问被阻断的地址
  • 使用 OAuth → 必然触发 → 网络问题立即暴露

这也是为什么很多建议会是：

“不要用 OAuth，直接用 Gemini API Key”

这条建议在工程上是成立的，但并不意味着 OAuth 不可用，而是 OAuth 对网络环境的要求更严格。

五、最终解决方案是什么？

本段核心问题：如何让 AionUI 在 OAuth 模式下也能正常登录 Gemini？

最终被验证、并成功解决问题的方案非常简单：

setx HTTPS_PROXY http://127.0.0.1:7890
setx HTTP_PROXY  http://127.0.0.1:7890

这是一个系统级的配置，而不是针对浏览器。

1. 这两行命令做了什么？

  • 将 HTTP_PROXY 和 HTTPS_PROXY 写入系统环境变量
  • 所有 新启动的进程 都可以读取到这个代理配置
  • Node.js 的 https、fetch、undici 等网络库会自动使用它

结果是：

AionUI 在进行 OAuth Token 交换时，HTTPS 请求终于走了代理。

2. 为什么是“系统级”而不是“应用级”？

因为 AionUI 是基于 Node/Electron 的桌面或本地应用：

  • 它不会读取浏览器插件的代理设置
  • 也不会自动识别“你平时科学上网用的代理”
  • 唯一可靠的方式，是通过环境变量明确告诉它“代理在哪里”

六、这个方案的适用边界与注意事项

本段核心问题：设置了代理环境变量，还需要注意什么？

1. 必须重启 AionUI

环境变量只对 新启动的进程 生效：

  • 已经打开的 AionUI 不会自动更新

  • 正确做法是：

    • 关闭 AionUI
    • 重新启动
    • 必要时重启系统或注销用户

2. 代理端口必须是 HTTP 端口

示例中使用的是：

http://127.0.0.1:7890

这是一个 HTTP 代理端口，而不是 SOCKS5。

如果误用了 SOCKS5 端口，即使端口存在，也可能无法生效。

3. 如何验证代理是否真的生效？

一个简单的验证方式是使用 Node 直接请求 OAuth Token 地址：

node -e "require('https').get('https://oauth2.googleapis.com/token', r=>console.log(r.statusCode)).on('error',console.error)"

判断标准：

  • 返回 400 或 405
    → 网络已通（这是预期结果）
  • 仍然是 ETIMEDOUT
    → 代理未生效或端口错误

七、一个真实的使用场景复盘

本段核心问题：如果不理解这套机制，实际使用中会发生什么？

一个典型场景是这样的：

  1. 用户在浏览器中能正常登录 Google
  2. 在 AionUI 中选择 Gemini → Google 登录
  3. 浏览器授权页顺利完成
  4. AionUI 突然提示登录失败
  5. 日志中只看到一串“看不懂”的错误

如果不理解 OAuth 的两阶段结构，很容易误判为：

  • Gemini 服务异常
  • AionUI Bug
  • Google 封号
  • Key 或权限问题

而实际上，只是本地 Node 进程没有走代理。

八、作者反思：这是一个“工程师很容易忽略”的问题

在复盘整个问题时，有一个非常明显的感受：

这个问题并不难，但极其隐蔽。

原因在于：

  • 浏览器已经“替你”解决了 80% 的网络问题
  • OAuth 登录在视觉上完全依赖浏览器
  • 出问题的步骤，恰恰发生在你“看不见”的地方

这类问题的共同特征是：

  • 错误信息并不指向业务逻辑
  • 配置项并不在应用界面中
  • 必须从运行时环境角度思考

一旦理解了这一点，解决方案反而变得异常简单。

九、实用操作清单

  • 确认错误包含 oauth2.googleapis.com/token
  • 确认错误类型为 ETIMEDOUT
  • 明确 AionUI 使用的是 OAuth 登录
  • 为系统设置 HTTP_PROXY / HTTPS_PROXY
  • 重启 AionUI
  • 使用 Node 命令验证网络是否打通

十、一页速览（One-page Summary）

  • 问题本质：AionUI 在 OAuth Token 交换阶段无法直连 Google

  • 根因：Node/Electron 进程未走代理

  • 误区：浏览器能访问 ≠ 本地程序能访问

  • 解决方案：

    setx HTTPS_PROXY http://127.0.0.1:7890
setx HTTP_PROXY  http://127.0.0.1:7890

  • 关键点：重启应用，使用 HTTP 代理端口

常见问答（FAQ）

Q1：这是 Gemini 的问题吗？
不是。错误发生在 OAuth 网络阶段，与模型能力无关。

Q2：API Key 能用，为什么 OAuth 不行？
因为 API Key 不需要访问 OAuth Token 接口。

Q3：只给浏览器设置代理为什么不够？
因为 AionUI 不运行在浏览器环境中。

Q4：必须设置两个环境变量吗？
是的，HTTP 和 HTTPS 都需要。

Q5：设置后立刻生效吗？
只对新启动的进程生效。

Q6：为什么返回 400 反而是成功？
说明请求已经到达 Google 服务器，只是参数不合法。

Q7：以后还会再遇到类似问题吗？
只要使用本地 OAuth、并且网络需要代理，就可能再次遇到。

到这里，你已经完整理解了 AionUI Gemini 登录失败的根因、解决路径以及背后的工程逻辑。

退出移动版