AionUI Gemini Login Failure: Root Cause Analysis and the Definitive Fix

Core conclusion upfront:
When AionUI fails to log in to Gemini with an error like:

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

the problem is not Gemini itself, not an invalid API key, and not an AionUI feature bug.
The real cause is that AionUI’s Node/Electron process cannot directly reach Google’s OAuth Token service during the OAuth login flow.

The final, proven, and minimal solution is to explicitly set system-level HTTP/HTTPS proxy environment variables:

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

This article explains why this works, where the failure actually happens, and how to reason about similar issues in the future. All explanations are strictly based on the troubleshooting process and outcomes described earlier, with no external assumptions added.

1. What Is Actually Failing?

Core question: At which exact step does AionUI’s Gemini login fail?

The key error message already tells the story:

Failed to exchange authorization code for tokens

This indicates a failure during the OAuth token exchange phase, not during initial authentication.

In practical terms, the OAuth flow looks like this:

  1. Browser phase

    • User is redirected to Google’s authorization page.
    • Login and consent complete successfully.
    • Google returns an authorization code to AionUI.

  2. Local application phase

    • AionUI (running on Node/Electron) sends an HTTPS request to
      https://oauth2.googleapis.com/token
    • The authorization code is exchanged for access tokens.

Your failure occurs entirely in step 2.

This distinction is critical.

2. Why the Browser Works but AionUI Does Not

Core question: Why can the browser log in to Google normally, while AionUI fails?

Because they are using different network paths.

From a user’s perspective, “Google login” looks like a single action. From a system perspective, it is split across two very different execution environments.

Browser vs. Local Application Networking

Aspect Browser AionUI (Node / Electron)
Uses browser proxy plugins Yes No
Automatically follows PAC rules Often No
Inherits system proxy implicitly Often Only if explicitly set
Network stack Browser-managed Node.js runtime

Key takeaway:

A browser successfully accessing Google does not imply that a local Node/Electron application can do the same.

AionUI’s OAuth token request is a direct HTTPS call from Node, not from your browser.

3. What the ETIMEDOUT Error Really Means

Core question: What does ETIMEDOUT 74.125.20.95:443 tell us?

Let’s break it down:

  • IP address: 74.125.20.95
    A valid Google global IP. DNS resolution succeeded.

  • Port: 443
    Standard HTTPS port. No misconfiguration here.

  • Error: ETIMEDOUT
    The TCP connection attempt timed out.

This combination means:

  • The request was not rejected.
  • TLS negotiation never completed.
  • The process could not establish a network route to the destination.

In short:

The request was sent via a direct connection that could not reach Google.

This strongly indicates that the Node process was not using a proxy at all.

4. Why Using an API Key Often “Fixes” the Problem

Core question: Why does switching to a Gemini API Key frequently make the issue disappear?

Because API Key authentication bypasses OAuth entirely.

  • OAuth login → must call oauth2.googleapis.com/token
  • API Key usage → no token exchange step

As a result:

  • No OAuth token request
  • No blocked endpoint
  • No timeout

This is why many users report that “API Key works, OAuth does not.”

That observation is accurate—but it treats the symptom, not the root cause.

5. The Definitive Solution: System-Level Proxy Variables

Core question: How do we make OAuth work reliably in AionUI?

By ensuring that Node/Electron traffic uses the same proxy path as the browser, via environment variables.

The Final Working Fix

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

What This Actually Does

  • Writes proxy configuration into system environment variables.
  • All newly launched processes can read these variables.
  • Node.js networking libraries (https, fetch, undici) automatically respect them.

Result:

AionUI’s OAuth token exchange request now goes through the proxy and successfully reaches Google.

6. Why This Must Be System-Level

Core question: Why not just configure the proxy in the browser?

Because AionUI is not a browser extension. It is a standalone application.

  • Browser proxy plugins do not affect Node processes.
  • AionUI does not inherit browser networking rules.
  • Environment variables are the most reliable cross-platform mechanism.

This is why the fix works consistently.

7. Important Operational Details

Core question: What can still go wrong after setting the proxy?

1. You must restart AionUI

Environment variables are read only at process startup.

  • Close AionUI completely.
  • Reopen it.
  • In some cases, logging out or rebooting ensures a clean environment.

2. Use an HTTP proxy port, not SOCKS

The example uses:

http://127.0.0.1:7890

This must be an HTTP proxy port.
Using a SOCKS-only port may silently fail.

3. How to Verify That It Works

You can validate connectivity directly from Node:

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

Interpretation:

  • 400 or 405 → success (request reached Google)
  • ETIMEDOUT → proxy not applied or incorrect port

8. A Realistic Failure Scenario

Core question: What happens if you don’t understand this distinction?

A typical experience looks like this:

  1. Google login page opens normally.
  2. Authorization completes successfully.
  3. AionUI suddenly reports “login failed.”
  4. Logs show cryptic network errors.
  5. User suspects Gemini, credentials, or account restrictions.

In reality, the failure is purely environmental.

Once you recognize that OAuth includes a hidden local network step, the behavior becomes predictable.

9. Author’s Reflection

This issue stands out not because it is complex, but because it is easy to misdiagnose.

Everything visible to the user works:

  • Browser login succeeds.
  • Google account is valid.
  • No obvious configuration errors.

The failure happens silently, inside a local runtime that most users never think about.

The key lesson is simple:

If OAuth fails after browser authorization, always examine the local process’s network path.

10. Practical Checklist

  • Confirm the error mentions oauth2.googleapis.com/token
  • Confirm the error type is ETIMEDOUT
  • Identify that OAuth login is being used
  • Set HTTP_PROXY and HTTPS_PROXY
  • Restart AionUI
  • Validate connectivity with a Node HTTPS request

11. One-Page Summary

  • Problem: AionUI OAuth login to Gemini fails

  • Root cause: Node/Electron process cannot reach Google OAuth Token endpoint

  • Common misconception: Browser access equals application access

  • Final fix:

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

  • Critical detail: Restart the application

FAQ

Q1: Is this a Gemini service issue?
No. The failure occurs before Gemini is even involved.

Q2: Why does the API Key method work?
Because it avoids the OAuth token exchange step entirely.

Q3: Why isn’t the browser proxy enough?
Because AionUI does not run inside the browser.

Q4: Do both HTTP and HTTPS variables matter?
Yes. Both must be set.

Q5: Why is a 400 response considered success?
It proves the request reached Google’s server.

Q6: Will this issue reoccur?
It can, whenever OAuth is used without proper proxy routing.

By understanding where the OAuth process actually fails and how local applications handle networking, this class of issues becomes straightforward to diagnose—and permanently solvable.