Antigravity Proxy 修复记录：用 DLL 方案让语言服务器稳定走代理

记录一次 Antigravity IDE AI 功能崩溃的修复过程：使用 yuaotian/antigravity-proxy 的 DLL 方案，让 language server 稳定走本地代理。

这是一篇故障复盘。问题现象是：浏览器能正常访问外网，v2rayN 的系统代理也已经开启，但 Antigravity IDE 里的 AI 功能仍然报错，提示类似：

1
Antigravity server crashed unexpectedly. Please restart to fully restore AI features.

查看 Antigravity 日志后，真正卡住的不是编辑器本体，而是它的 language server 无法稳定访问 Cloud Code API，常见日志包括：

1
2
3
Failed to start language server: Timed out waiting for language server start
WaitForReady failed: context deadline exceeded
Post "https://cloudcode-pa.googleapis.com/v1internal:listExperiments": context deadline exceeded

为什么普通系统代理不够

Antigravity 的编辑器进程、language server、node 子进程并不总是完整继承 IDE 设置里的 http.proxy 或 Windows 系统代理。于是会出现一种很烦人的状态：

浏览器走代理正常；
curl -x http://127.0.0.1:10808 ... 能看到代理隧道建立；
但 Antigravity language server 仍然启动超时；
v2rayN 改成全局模式也不一定解决。

我最后没有继续折腾 v2rayN 路由规则，而是采用了 yuaotian/antigravity-proxy 的方案：在 Antigravity 主程序目录放入一个 version.dll，通过 DLL 注入/劫持方式让 Antigravity 相关进程统一走本地代理。

前提

本机已经有一个可用的本地代理端口。例如 v2rayN 常见端口：

1
127.0.0.1:10808

如果 v2rayN 的入站协议是 mixed，通常 HTTP 和 SOCKS5 都可以用。这里我使用 SOCKS5：

1
socks5://127.0.0.1:10808

安装位置

我的 Antigravity IDE 安装目录是：

1
C:\Users\<你的用户名>\AppData\Local\Programs\Antigravity IDE

修复后，这个目录里会多出两个关键文件：

1
2
version.dll
config.json

其中 version.dll 来自 antigravity-proxy 的 release，config.json 用来告诉 DLL 应该代理哪些进程、使用哪个代理端口。

推荐配置

下面是核心配置思路。重点是把 Antigravity 主进程、language server 和 node 子进程都放进目标进程列表：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
{
  "proxy": {
    "host": "127.0.0.1",
    "port": 10808,
    "type": "socks5"
  },
  "fake_ip": {
    "enabled": true,
    "cidr": "198.18.0.0/15"
  },
  "child_injection": true,
  "traffic_logging": true,
  "target_processes": [
    "Antigravity IDE.exe",
    "Antigravity.exe",
    "language_server_windows_x64.exe",
    "node.exe"
  ],
  "proxy_rules": {
    "allowed_ports": [80, 443],
    "dns_mode": "proxy",
    "ipv6_mode": "block",
    "udp_mode": "block",
    "udp_fallback": "block",
    "routing": {
      "enabled": true,
      "priority_mode": "order",
      "default_action": "proxy",
      "use_default_private": true
    }
  }
}

几个点很重要：

language_server_windows_x64.exe 必须包含，否则 AI 后端仍可能不走代理。
node.exe 最好也包含，因为 IDE 里有不少扩展逻辑跑在 node 子进程里。
dns_mode 设为 proxy，避免 DNS 解析绕过代理。
ipv6_mode 和 udp_mode 可以先 block，减少 QUIC/IPv6 绕路带来的不确定性。

自动安装脚本

我在本地用了一个 PowerShell 脚本完成这些动作：

1
2
3
4
5
powershell -ExecutionPolicy Bypass -File .\Install-Antigravity-ProxyDll.ps1 `
  -ProxyHost 127.0.0.1 `
  -ProxyPort 10808 `
  -ProxyType socks5 `
  -RestartAntigravity

脚本做了几件事：

检查 127.0.0.1:10808 是否正在监听；
关闭 Antigravity 和 language server；
备份旧的 version.dll 和 config.json；
下载 yuaotian/antigravity-proxy 最新 release；
解压并复制 version.dll；
写入新的 config.json；
重启 Antigravity。

如何判断是否成功

成功后，Antigravity 安装目录下会生成日志：

1
logs\proxy-YYYYMMDD.log

日志里应该能看到类似下面的连接：

1
2
CONNECT daily-cloudcode-pa.googleapis.com:443
HTTP/1.1 200 Connection established

Antigravity 自己的日志里也会从原来的启动超时，变成可以继续请求模型、鉴权和生成接口，例如：

1
2
3
Auth succeeded, refreshing features and managers
URL: https://daily-cloudcode-pa.googleapis.com/v1internal:fetchAvailableModels
URL: https://daily-cloudcode-pa.googleapis.com/v1internal:streamGenerateContent?alt=sse

这说明 language server 至少已经开始通过代理访问后端，而不是卡死在启动阶段。

回滚方法

如果这个方案导致 Antigravity 无法启动，直接退出 Antigravity，然后删除安装目录里的：

1
2
version.dll
config.json

或者从备份目录恢复旧文件即可。

总结

这次问题的关键不是 v2rayN 是否“全局”，而是 Antigravity 的 language server 没有稳定继承普通代理设置。antigravity-proxy 的 DLL 方案绕开了这个不确定性，把 Antigravity 相关进程的 TCP/DNS 行为强制接到本地代理上。

对我这台机器来说，最终有效的组合是：

v2rayN 本地代理：127.0.0.1:10808
Antigravity 目录内放置 version.dll
config.json 使用 SOCKS5、本地代理端口、代理 DNS、阻断 IPv6/UDP
重启 Antigravity 后观察 proxy-YYYYMMDD.log

以后如果 Antigravity 又突然无法使用，第一步不是继续乱改系统代理，而是检查：

1
2
3
4
127.0.0.1:10808 是否监听
version.dll 是否还在 Antigravity 目录
config.json 是否还在 Antigravity 目录
logs\proxy-YYYYMMDD.log 是否有 CONNECT 记录