antigravity-proxy：不启用 TUN 的进程级代理方案

Table of Contents

我在大陆用 Google Antigravity，需要代理。以前一直靠 Clash 的 TUN 模式顶住，但负载明显上去，而且和公司 VPN 也容易打架。后来我想换一种更“轻”的方案：只让 Antigravity 走代理，不碰系统路由。于是找到了 antigravity-proxy。

仓库地址：https://github.com/yuaotian/antigravity-proxy

下面是我基于 README 做的专业整理，重点放在“它能做什么、怎么做、边界在哪里”。

项目定位

antigravity-proxy 是一个面向 Antigravity 的 Windows 代理注入组件（DLL）。核心目标很清晰：
在不启用 TUN 的情况下，让 Antigravity 进程稳定走 SOCKS5/HTTP 代理。

它不接管全局流量，只代理指定进程，因此更适合与公司 VPN 共存。

核心能力（整理自 README）

平台与架构：Windows x86 / x64。
免 TUN：不走系统级虚拟网卡，避免全局路由接管。
进程级代理：仅代理指定进程（默认聚焦 Antigravity）。
透明代理：目标程序无感知，配置到位即可生效。
协议支持：SOCKS5 / HTTP，README 建议优先 SOCKS5。
配置驱动：通过 config.json 控制代理地址、规则、模式。
日志与排错：内置日志路径与排查步骤，适合快速定位问题。
高级能力（可选）：路由规则、UDP/QUIC 处理、IPv6 行为控制、子进程注入等。

工作原理（高层视角）

它通过 version.dll 的加载机制进入目标进程，Hook Windows 的网络相关 API，把连接转发到你指定的代理上。
你可以把它理解为“只对目标进程生效的透明代理层”。

%%{init: {'theme': 'dark', 'themeVariables': {'primaryColor': '#1f2937', 'primaryTextColor': '#f9fafb', 'lineColor': '#93c5fd', 'secondaryColor': '#111827'}}}%%
flowchart LR
  A[Antigravity 进程] --> B[version.dll 注入]
  B --> C[Hook Winsock 连接]
  C --> D[SOCKS5/HTTP 代理]
  D --> E[外网]

快速上手（可直接照做）

Step 0：确认前置条件

系统：Windows x86/x64。
代理：本机有可用的 SOCKS5/HTTP 代理（README 建议优先 SOCKS5）。
端口：确认代理监听端口（例如 127.0.0.1:7890）。

Step 1：下载文件

从 Release 下载两个文件：

version.dll
config.json

如果你是自己编译，产物在 output/ 目录里。

注意：version.dll 的 x86/x64 位数必须与目标程序一致。

Step 2：配置代理（只改三项即可）

打开 config.json，只需要改这三项，其它保持默认：

"proxy": {
  "host": "127.0.0.1",
  "port": 7890,
  "type": "socks5"
}

Step 3：部署到 Antigravity

把 version.dll 和 config.json 复制到 Antigravity 主程序目录（与 Antigravity.exe 同级）。

常见路径示例：

C:\Users\<用户名>\AppData\Local\Programs\Antigravity

Step 4：启动并验证

启动 Antigravity 后，看日志是否生成：

<Antigravity目录>\logs\proxy-YYYYMMDD.log
或 %TEMP%\antigravity-proxy-logs\proxy-YYYYMMDD.log

日志里出现以下关键行，基本就算成功：

Antigravity-Proxy DLL 已加载
配置加载成功
SOCKS5: 隧道建立成功

Step 5：出问题怎么排（最常见三类）

没有日志：DLL 没加载，多数是放错目录或位数不匹配。
0xC0000142 / 0xC000007B：通常是位数不匹配或 VC++ 运行库缺失。
10061 (WSAECONNREFUSED)：代理没启动或端口写错。

Step 6：回退很简单

删除 version.dll 和 config.json，恢复原状。

适用边界

这是 Windows 方案，对 WSL 内部流量不生效（README 有专门说明）。
如果你的场景是 WSL，仓库里给了替代思路，可参考其 WSL 章节。

我的判断

对我来说，这个方案的价值很明确：

范围可控：只代理目标进程，避免全局污染。
与 VPN 共存：不碰系统路由，冲突成本低。
可回退：删掉 DLL 和配置，系统即恢复原状。

当然，它也意味着你需要对“注入 + Hook”这类工具保持足够谨慎，合规和安全永远是第一位。

结语

如果你的目标是“让 Antigravity 能用，但不想开全局 TUN”，
antigravity-proxy 是一个非常值得认真看的方案。

参考

antigravity-proxy 仓库：https://github.com/yuaotian/antigravity-proxy