同样写代码的 AI 工具,为什么只有 Antigravity 要开 TUN 模式?

不知道大家有没有用过 Antigravity（Google 的 AI 编码 IDE）写代码，之前我用的时候，都是：开着 v2rayN 的 TUN 模式，Antigravity 能正常打开，否则就黑屏。而 TUN 模式开着，又跟公司的飞连（企业 VPN）抢路由——两个 TUN 一碰，网络直接乱套。

但是我用 Codex、Kiro 这些 AI 工具，从来没遇到过这种破事。系统代理配好了它们就能用，为什么偏偏 Antigravity 不行？

我决定今天搞定它！这一上午的排查，最后引出一个藏在 Antigravity 内部的"隐藏进程"，和一个关于工具架构差异的有趣结论。

今天从头讲，把这几个问题一次说透：TUN 为什么打架？Antigravity 为什么特殊？Codex 凭什么省心？

一、TUN 是什么？为什么两个 TUN 会打架？

先说 TUN。

TUN 模式，简单说就是"在网卡上装一个虚拟设备，让所有流量先经过它"。v2rayN 开启 TUN 后，会创建一个虚拟网卡，然后把 Windows 的路由表改成"默认出口指向 TUN 网卡"——于是所有程序的流量，先进 v2rayN，由它按规则决定走代理还是直连。

普通模式：  程序 → 系统代理（可选）→ 直连TUN 模式：  程序 → TUN 网卡 → v2rayN 规则 → 代理出口 / 直连

TUN 的好处是"无差别接管"——不管你是浏览器、命令行、还是某个固执的程序，只要它发网络请求，都得先过 TUN。这是 TUN 最猛的地方，也是它最坑的地方。

因为飞连（字节跳动的企业 VPN，进程名 CorpLink.exe）也是一个 TUN。

两个 TUN 同时存在，Windows 路由表里就有两条默认路由。谁接管，看一个叫 metric（优先级）的数字：

两个 TUN = 两个交警抢一个路口。Windows 只能有一个"默认出口"，谁 metric 高谁指挥，另一个被架空——被架空的 TUN 的主人就断网。

所以结论一：TUN 模式虽然万能，但它是"排他"的。只要你还想用飞连，v2rayN 的 TUN 就不能一直开着。

那问题来了：不开 TUN，Antigravity 为什么就黑屏？

二、排查：不开 TUN，Antigravity 为什么黑屏？

翻 Antigravity 的日志（%APPDATA%\Antigravity\logs\），真相浮出水面。

先是 main.log：

127.0.0.1？本地？哪个程序在 58020 端口等着？

再看 language_server.log：

哦——Antigravity 的本地后端要连 Google 的 API，连不上，超时。

于是拼出完整的图：

Antigravity 启动   │   ├─► Chromium 主进程（窗口、UI）   │      └─► 加载 https://127.0.0.1:58020/（本地后端的前端页面）   │   └─► language_server.exe（Go 写，监听 127.0.0.1:58020）          └─► 连 Google API（daily-cloudcode-pa.googleapis.com）✗ 超时

后端没起来 → 前端没东西可加载 → 黑屏 → 进程退出。

而这个 Go 后端连不上 Google，恰恰是因为：不开 TUN 的时候，它的流量没人接管，直连被 GFW 拦了。

三、这个"Go 服务"到底是个啥？

你可能跟我一开始一样懵：Antigravity 不是个 Electron 应用吗？哪来的 Go 服务？

它是真的。在 Antigravity 的安装目录下：

启动时，Antigravity 会拉起这个进程，参数里写着它的使命：

--api_server_url https://generativelanguage.googleapis.com   ← 调 Gemini 模型--cloud_code_endpoint https://daily-cloudcode-pa.googleapis.com  ← 调云服务--host_bridge_url=http://127.0.0.1:58018                        ← 跟前端通信

说人话，Chromium 是"显示器"，Go 服务是"大脑 + 手脚"：

• 大脑：调用 Gemini 模型，处理 AI 对话、代码补全
• 手脚：执行你的代码、读写你的文件、跑终端命令（Antigravity 是 agent 型 IDE）
• 它俩通过 127.0.0.1 的本地端口（host bridge）聊天

为什么要把逻辑拆成一个独立进程？安全隔离。Chromium 的哲学是"渲染进程不可信"——UI 这个进程没有权限碰你的文件系统、跑终端；所有特权操作收口在 Go 服务这一个进程里。前端随便崩，核心逻辑不丢。

这个设计很 Google（它就是造浏览器的），但也正是它，埋下了今天黑屏的雷。

四、为什么 Codex、Kiro 没这问题，Antigravity 就有？

这是最让我好奇的问题。我之前用 Codex（OpenAI 的 AI 编码工具，有 CLI 也有桌面版）、Kiro，配好系统代理就能用。为什么 Antigravity 不行？

答案藏在"谁在跟 Google 通信"里：

看出区别了吗？

Codex、Kiro、Cursor 的"大脑"都在主进程里，主进程是浏览器内核，天生读 Windows 系统代理——所以你"设置系统代理"这一个动作，就把它们全搞定了。

Antigravity 的"大脑"是一个独立的 Go 进程，而 Go 的 net/http 客户端有个"固执"的设计：只认环境变量（HTTPS_PROXY / HTTP_PROXY），不读 Windows 系统代理、不读 PAC 文件——因为 Go 是跨平台语言，不能假设你跑在 Windows 上（Linux 上根本没有"系统代理"这个概念）。

于是：

设了系统代理（127.0.0.1:10809）   ├─► Chromium 主进程：收到 ✓ → UI 正常   └─► Go 服务：无视 ✗ → 直连 Google → 被 GFW 拦 → 黑屏

Antigravity 双进程架构的收益（安全隔离）和代价（代理配置地狱），在这一刻同时兑现了。

注：Codex 有桌面版，Kiro 也有，它们都是正经的 GUI 应用。但不管 GUI 还是 CLI，Codex 的核心逻辑都在主进程里，读系统代理，所以不踩 Antigravity 这个坑。

五、不开 TUN，怎么救活 Antigravity？

既然 TUN 跟飞连打架，又不能改 Antigravity 的架构，那就给那个固执的 Go 进程喂环境变量：

@echo offset HTTPS_PROXY=socks5h://127.0.0.1:10808set HTTP_PROXY=socks5h://127.0.0.1:10808set ALL_PROXY=socks5h://127.0.0.1:10808set NO_PROXY=127.0.0.1,localhost,::1start "" "C:\...\Antigravity.exe"

原理一句话：cmd 进程设置环境变量 → 启动 Antigravity → Go 进程继承父进程的环境 → 走代理 → 通。

这套方案的好处：

• 不碰 TUN → 不抢路由表 → 飞连照常用 
• 作用域隔离 → 环境变量只对 Antigravity 这一个进程树生效，飞连、浏览器、Git 全都不受影响 
• 免费，不用装 Proxifier 
  

如果你嫌 .bat 双击时闪一下黑色 cmd 窗口，可以换成 .vbs——它的宿主是 wscript.exe（图形进程），没有控制台窗口，全程无感：

Set sh = CreateObject("WScript.Shell")sh.Environment("Process")("HTTPS_PROXY") = "socks5h://127.0.0.1:10808"sh.Environment("Process")("HTTP_PROXY")  = "socks5h://127.0.0.1:10808"sh.Environment("Process")("ALL_PROXY")   = "socks5h://127.0.0.1:10808"sh.Environment("Process")("NO_PROXY")    = "127.0.0.1,localhost,::1"sh.Run "C:\...\Antigravity.exe", 1, False

.bat 是让驿站小厮在衙门口喊话（有声音、有人影）；.vbs 是写封信悄悄塞进门缝（无声无息）。

六、为什么不能把环境变量放进 Windows 系统环境变量？

写到这，肯定有人问：既然环境变量这么好使，干嘛不直接写进 Windows 系统环境变量？一劳永逸。

千万别。

Windows 系统环境变量是全局继承的——所有从资源管理器、任务栏、快捷方式启动的程序，都会读到它。你设一个全局 HTTPS_PROXY：

系统环境变量没有"进程粒度"概念，它是一刀切。.bat / .vbs 的妙处，恰恰在于把环境变量限制在一个进程树里——出了这条线，谁都不知道它的存在。

收笔

今天这一趟，从"两个 TUN 打架"出发，追到一个藏在 Antigravity 里的 Go 服务，最后用一行环境变量收尾。

回头看，真正值钱的不是那个 .bat，而是这个过程暴露的心智模型：

• TUN 是"排他"的，想跟别的 VPN 共存，就得绕开它
• 代理有"进程粒度”：系统代理只管"读它的应用"，环境变量只管"继承它的进程树"，TUN 才管"所有进程"
• 架构决策都是取舍：Antigravity 用安全隔离换来了配置地狱，Codex 用主进程逻辑换来了省心——没有谁对谁错，只有谁更懂自己要什么

技术圈最常被忽视的，不是多高深的协议、多精妙的算法，而是"边界"这两个字——进程的边界、权限的边界、作用域的边界。

你能看清一个工具把边界画在哪，你就知道它为什么会坏、该怎么修。

永远对世界保持好奇。

码字不易，感谢「在看」。

点点赞

点分享

点喜欢