Antigravity-Proxy: a Windows DLL that forces Antigravity through SOCKS5 without TUN mode

What Antigravity-Proxy actually fixes, and what it does not

Antigravity, the editor this project targets, does not follow the Windows system proxy. The README lists the consequences: users are pushed into Clash TUN mode, TUN mode captures all local traffic rather than one application, and TUN mode needs administrator rights that some environments do not grant. Antigravity-Proxy exists to remove that dependency. It is a Windows-only DLL that is placed next to the target executable and pulls only the Antigravity-related processes into your SOCKS5 or HTTP proxy. The project describes itself as transparent: the target program has no awareness that its sockets were redirected.

The scope is narrower than the name suggests. This is not a general-purpose proxy client and it does not manage your proxy server, your subscription, or your rules. You bring a running proxy on a local port, and the DLL handles the handoff for a fixed set of processes. The README is explicit that it does not take over traffic globally.

The most useful part of the documentation is a warning placed before the introduction. If Antigravity's chat pane returns `Agent execution terminated due to error`, the README says to check the proxy exit IP first, not the DLL. The confirmed scenario is a machine where `version.dll` is loaded, both `language_server_windows_x64.exe` and `node.exe` are injected, and `oauth2.googleapis.com` and `daily-cloudcode-pa.googleapis.com` both tunnel successfully over SOCKS5, yet `ls-main.log` still reports `FAILED_PRECONDITION (code 400): User location is not supported for the API use.` In that case the DLL is working and the failure is upstream policy. That distinction is the single most important thing to understand about this project.

How the injection and traffic redirection work

The mechanism is DLL injection with API hooking. The repository topics name MinHook, and the build targets C++17. The release packaging reveals the two injection strategies. The IDE package ships `version.dll`, a DLL name Windows loads from an application's own directory, which is a well-known way to get code into a process without a launcher. The CLI package ships `dbghelp.dll` plus `antigravity_proxy.dll`; `dbghelp.dll` is the loader that pulls in the actual proxy DLL. Both packages include a `config.json`, which is where the proxy endpoint is configured.

Once inside the process, the hook intercepts outbound connection attempts and routes them to the configured SOCKS5 or HTTP endpoint. The README's log excerpts show the observable result: lines such as `[成功] 已注入目标进程: language_server_windows_x64.exe`, `[成功] 已注入目标进程: node.exe`, and `SOCKS5: 隧道建立成功, 目标=oauth2.googleapis.com:443`. The log file is written to `<Antigravity install directory>\logs\proxy-YYYYMMDD.log`, and there is an optional diagnostics switch, `diagnostics.agent_ip_probe`, that adds IP probe lines such as `[诊断/IP] 当前代理出口探测完成` and a warning when the exit looks like a datacenter or hosting address.

The architecture is deliberately per-process. There is no virtual adapter, no route table change, and no service. That is why administrator rights are not required and why unrelated traffic stays on the normal path. The trade-off is that anything Antigravity spawns outside the injected set is not covered, and the hooking approach ties the project to Windows process loading behaviour rather than to a network primitive.

Installing it and getting Antigravity through a SOCKS5 proxy

Start your proxy client and confirm a local port is listening. The README's port table lists Clash and Clash Verge with SOCKS5 on 7891, HTTP on 7890, and a mixed port on 7890; V2RayN uses 10808 for SOCKS5 and 10809 for HTTP; Shadowsocks uses 1080 with SOCKS5 only. The README recommends SOCKS5 as the better-supported protocol. PowerShell can confirm the listener:

Test-NetConnection -ComputerName 127.0.0.1 -Port 7891
Test-NetConnection -ComputerName 127.0.0.1 -Port 7890

If you prefer curl, the README gives these two checks, and a successful response means the proxy is reachable before you touch Antigravity:

curl -x socks5://127.0.0.1:7891 https://www.google.com -I
curl -x http://127.0.0.1:7890 https://www.google.com -I

Next, pick the correct release archive. There are four, split by target and architecture: `antigravity-proxy-vX-ide-win-x64.zip`, the `-x86` variant, `antigravity-proxy-vX-cli-win-x64.zip`, and its `-x86` variant. The IDE archives contain `ide/` with `version.dll` and `config.json`. The CLI archives contain `cli/` with `dbghelp.dll`, `antigravity_proxy.dll`, and `config.json`. Every archive also carries `config-web.html` and `使用说明.md`.

For the desktop editor, copy the contents of `ide/` into the Antigravity main program directory, alongside `Antigravity.exe`. For the CLI, copy the contents of `cli/` into the CLI's directory. Then launch Antigravity and open the DLL log at `<Antigravity install directory>\logs\proxy-YYYYMMDD.log`. You are looking for the injection lines for `language_server_windows_x64.exe` and `node.exe` and for tunnel lines naming `oauth2.googleapis.com:443` and `daily-cloudcode-pa.googleapis.com:443`. If those appear, the transport layer is doing its job.

One prerequisite is easy to miss. The README documents error `0xc0000142` on startup as a missing Windows runtime, and the repository ships an installer at `microsoft\微软常用运行库合集-2025.exe`. Run it and restart the target program if you hit that code.

The failure mode the README puts first: a clean tunnel and a rejected exit

The limitation that matters most is not a bug in the hooking code. It is that a fully working proxy can still leave Antigravity unusable. The README's confirmed case is a machine where injection succeeded for both processes, SOCKS5 tunnels opened to `oauth2.googleapis.com:443` and `daily-cloudcode-pa.googleapis.com:443`, and the agent path still failed with `FAILED_PRECONDITION (code 400): User location is not supported for the API use.` The README's phrasing is that country support does not equal acceptance of a particular exit IP, and that under the same country, different ASNs and different address types can produce different outcomes.

That reframes the tool. Antigravity-Proxy solves reachability, not authorization. If your symptom is a connection that never establishes, the DLL is the right layer to inspect. If your symptom is a 400 from the agent path while the tunnel log looks healthy, replacing the DLL or reinstalling it will not help. The README's recommended order is to read `proxy-YYYYMMDD.log` first to rule out injection failure, then read `%APPDATA%\Antigravity\logs\<latest directory>\ls-main.log`, and only return to the DLL when the log shows no successful injection or no successful proxy handshake at all.

There is also a platform boundary. The badges and the packaging cover Windows x86 and x64 only. Anyone on macOS or Linux is outside the supported surface, and the related search phrases about Linux and Mac have no answer in this repository.

Where a system-wide TUN client is the better choice

The obvious alternative is the TUN mode this project was built to avoid, as implemented by Clash, Mihomo, and similar clients. The difference is architectural rather than a matter of quality. A TUN client creates a virtual network interface and routes traffic at the IP layer, so every process on the machine is captured without any per-application configuration. Antigravity-Proxy hooks connection attempts inside specific processes, so coverage is limited to what it injects but nothing else on the machine is affected and no administrator rights are needed.

That makes the choice depend on your environment. If you are on a managed machine where you cannot install a network adapter or elevate, the DLL approach fits and TUN does not. If you need several unrelated applications proxied, or you want one rule set applied uniformly across the system, a TUN client does that with less per-application work. If you run Antigravity on macOS or Linux, a TUN client is not merely an alternative, it is the only option among these two, because this project ships Windows binaries.

There is a second difference in failure visibility. A TUN client fails at the interface level, which is usually obvious. This project can fail silently in the sense that injection succeeds and the application still cannot complete its agent request, which is exactly why the README spends its opening section teaching you to read two log files before changing anything.

Maintenance, build cost, and the licence question

The repository is not archived, and the last push was on 2026-09-01. Releases v2.2, v2.3, and v2.4 landed on 2026-06-19, 2026-08-31, and 2026-09-01 respectively, so the two most recent releases are close together. The top level contains `CMakeLists.txt`, `build.ps1`, `cmake/`, `src/`, `include/`, `tests/`, `tools/`, and `scripts/`, so building from source is a supported path rather than an afterthought. The README notes that a local build produces two output directories, `output/ide` and `output/cli`, matching the two release package layouts.

Upgrade cost is low if you keep the deployment simple. There is no service to restart and no system state to migrate; you replace the DLL and `config.json` in the Antigravity directory. The real upgrade risk is version coupling. The IDE package depends on Windows loading `version.dll` from the application directory, and the CLI package depends on `dbghelp.dll` doing the same, so an Antigravity update that changes its directory layout or ships its own DLL of either name can break the mechanism. Re-checking the log after an Antigravity update is the cheap way to catch that.

The licence is the least clear part. The repository's `LICENSE.txt` exists and the README badge says BSD-2-Clause, but the repository metadata reports the licence as NOASSERTION, meaning GitHub could not classify it automatically. Read `LICENSE.txt` yourself before redistributing anything, especially the bundled `microsoft\微软常用运行库合集-2025.exe` runtime installer, which is a third-party redistribution and not covered by a statement in the README. Nothing here is legal advice.

Editorial conclusion

Adopt Antigravity-Proxy if you run Antigravity on Windows and want per-process proxying without TUN mode or administrator rights, and if you accept that the DLL only fixes the transport layer. Do not adopt it if you are on macOS or Linux, or if your problem is a location-blocked agent path rather than a blocked socket. Before relying on it, verify that your proxy port answers, that proxy-YYYYMMDD.log shows both injection lines and a SOCKS5 tunnel, and check what ls-main.log says before you blame the DLL.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. yuaotian/antigravity-proxy on GitHub