精准修复 Google Antigravity 无法登录使用的终极解决方案

对于身处特定网络环境的开发者而言，Google 最新发布的 AI IDE —— Antigravity，带来了一种颇为讽刺的体验：软件界面设计得极简优雅，启动速度飞快，但核心功能却完全瘫痪。

最典型的症状莫过于此：启动软件后，UI 渲染完美无缺，但在尝试登录 Google 账号或进行代码补全时，界面会死锁在 “Authenticating”（正在验证）状态，或者模型加载指示器陷入无限循环。这意味着你无法登录，也无法使用任何 AI 功能。

这并非 Google 的服务宕机，也不是你的网络彻底断连。这其实是一个典型的 Windows 进程隔离问题。与其粗暴地开启系统级 TUN 模式（接管所有流量），不如通过更精准的“手术式”配置来解决。

核心病灶：被遗忘的“影子进程”

要理解为什么浏览器能访问 Google 而 Antigravity 无法登录，首先需要看透这款软件的架构。Antigravity 采用了现代 IDE 常见的前后端分离设计：

1. 前端（Frontend）：用户看到的漂亮界面，本质上是一个 Electron 容器。它通常能继承系统的 HTTP 代理设置。
2. 后端（Backend）：真正负责繁重任务的独立子进程。

当用户盯着旋转的加载圈发愁时，后台其实有一个不知名的“苦力”正在不断尝试连接 Google 云端，并不断撞墙。这个罪魁祸首就是：

language_server_windows_x64.exe

它深埋在安装目录的腹地：

antigravity/resources/app/extensions/antigravity/bin/language_server_windows_x64.exe

这是一个标准的 LSP（语言服务器）进程。当你打开 IDE 时，它负责建立通往 Google 基础设施的 gRPC 隧道，处理身份验证、代码智能分析以及与 Gemini 模型的通信。

故障解析：为什么它不走代理？

通过 Proxifier 或类似的网络抓包工具分析，可以清晰地看到错误的根源。日志显示该进程试图直接连接到 Google Cloud Code 的私有 API 端点：

[12.04 16:21:26] language_server_windows_x64.exe (17280) - daily-cloudcode-pa.sandbox.googleapis.com(142.250.99.81):443 error : connection attempt failed with error 10060

错误代码 10060 意味着连接超时。

问题的关键在于，这个由 Antigravity 派生的原生二进制文件（Native Binary），往往不会自动继承操作系统的环境变量或浏览器代理设置。它试图发起直连请求，结果被防火墙拦截。这就解释了为什么你的浏览器（甚至 IDE 的部分 Web 界面）可以上网，但核心登录和 AI 功能却处于离线状态。

解决方案：精准进程代理（无需开启 TUN）

许多教程建议开启 VPN 的 TUN 模式来强制接管所有系统流量。虽然有效，但这种做法无异于“为了杀一只蚊子而烧掉整个房子”——它会干扰游戏、局域网共享和其他国内应用的连接。

更优雅的解决方案是Process-Based Proxying（基于进程的代理）。我们只需要告诉你的代理软件：“盯着这个特定的 EXE 文件，接管它的流量。”

操作步骤

无论你使用的是 Proxifier、Clash Verge 还是其他支持规则模式的客户端，核心逻辑是一致的：

1. 定位目标文件

首先，你需要找到该文件的绝对路径。通常位于 Antigravity 安装目录下的扩展文件夹中：

antigravity/resources/app/extensions/antigravity/bin/language_server_windows_x64.exe

2. 添加代理规则

在你的网络工具中，创建一个新的规则（Rule）：

• 进程名 (Process Name)：language_server_windows_x64.exe
• 策略 (Action/Proxy)：选择你可用的代理节点（Proxy Group）。

注意：不需要将主程序 Antigravity.exe 加入规则，因为它通常只负责渲染 UI。我们需要“救活”的是那个负责语言服务的后端进程。

结果验证

一旦规则生效，无需重启系统，只需重启 Antigravity 软件：

1. Authenticating 提示将迅速消失，登录成功。
2. 后台日志中会出现该进程成功建立 HTTPS/gRPC 连接的记录。
3. AI 代码补全和 Chat 功能将瞬间恢复响应。

通过这种方式，开发者可以在保持系统网络环境清洁的前提下（无需全局 TUN），精准地解决了 Antigravity 的水土不服问题。这再次证明，在处理复杂的现代开发工具时，通过日志定位到底层进程，往往比盲目修改系统设置要有效得多。