排查 Antigravity 登录卡住：从 OAuth 超时到 TUN 路由接管

今天同时遇到 Antigravity App 和 CLI 登录异常：App 在浏览器授权回跳后没有继续，CLI 粘贴授权码后一直停在 signing in。因为 Codex 和 Claude Code 都能正常联网，最开始很容易把问题误判成 Antigravity 自身 bug、账号异常，或者授权码失效。

最后的结论是：Antigravity 的部分后台请求没有只走系统 HTTP 代理，而是会直接发起到 Google API 的 TCP 连接；当 v2rayN 的 TUN 开关看起来已开启、但系统路由实际没有接管这些直连流量时，Antigravity 就会卡在登录后的初始化阶段。

症状

主要表现有三个：

1. Antigravity App 能打开浏览器授权页，授权完成后回到 App，但状态没有变好。
2. Antigravity CLI 能进入 OAuth 流程，粘贴授权码后停在 signing in。
3. Codex、Claude Code 等其他工具都能正常使用，因此看起来不像是全局网络故障。

App 日志里最关键的错误是：

Post "https://oauth2.googleapis.com/token": dial tcp ...:443: i/o timeout
Post "https://daily-cloudcode-pa.googleapis.com/v1internal:loadCodeAssist": context deadline exceeded

这说明浏览器授权并不是核心问题。真正失败的是 Antigravity 后台拿授权结果去换 token，或者登录后加载 Code Assist 配置时连不上 Google API。

第一层排查：确认不是账号和授权码

CLI 日志里出现过这样的记录：

consumerOAuth: authentication completed successfully
ChainedAuth: interactive auth completed via consumer

这说明授权流程本身已经成功完成。后来 CLI 还成功请求了：

https://daily-cloudcode-pa.googleapis.com/v1internal:loadCodeAssist
https://daily-cloudcode-pa.googleapis.com/v1internal:fetchAvailableModels

因此，授权码不是根因。反复重新登录只会让现象变得更乱。

第二层排查：HTTP 代理可用，但直连失败

先看系统代理：

scutil --proxy

当时系统代理指向本地端口，例如：

HTTPProxy  : 127.0.0.1
HTTPPort   : 10808
HTTPSProxy : 127.0.0.1
HTTPSPort  : 10808

再用 curl 分别测试 HTTP 代理和直连：

curl -I https://oauth2.googleapis.com/token
curl --noproxy '*' -I https://oauth2.googleapis.com/token

结果是：

• 走代理能拿到 HTTP 响应。
• 禁用代理后直接连 Google API 超时。

这就解释了为什么 Codex 和 Claude Code 正常：它们大概率走了 HTTP 代理或自己的网络层；而 Antigravity 后台有一部分请求会绕过 HTTP 代理，直接走系统路由。

第三层排查：TUN 开着，但路由没有接管

v2rayN 的 TUN 页面显示已经开启，甚至处于全局模式。但关键不是 UI 开关，而是系统路由实际怎么走。

用下面的命令看目标 IP 走哪个网卡：

route -n get 8.8.8.8
route -n get 142.250.69.170

一开始看到的是：

interface: en0

这代表 Google API 的直连流量仍然走普通 Wi-Fi 网关，而不是 TUN 虚拟网卡。也就是说，TUN 开关亮着，但没有真正接管默认 IPv4 出口。

同时进程里只有 xray 在跑：

ps -axo pid,command | grep -E 'sing-box|mihomo|xray'

当时能看到 xray，占用本地代理端口，但没有真正承担系统级 TUN 接管。

修复：切到 sing-box TUN，并确认路由进入 utun

后来切换到 sing-box core 后，再看进程：

sing-box run -c .../binConfigs/config.json --disable-color
xray run -c config.json

再看路由：

route -n get 8.8.8.8

结果变成：

gateway: 172.18.0.1
interface: utun26

再检查 Google API IP：

route -n get 142.250.69.170
route -n get 142.251.33.202
route -n get 173.194.203.95

也都进入了：

interface: utun26

这时再禁用 HTTP 代理测试：

curl --noproxy '*' -I https://oauth2.googleapis.com/token
curl --noproxy '*' -X POST https://daily-cloudcode-pa.googleapis.com/v1internal:loadCodeAssist -i

结果能拿到正常 HTTP 响应，例如 OAuth token endpoint 返回 404，Cloud Code endpoint 返回 401。这里的 401 是正常的，因为测试请求没有带登录 token；重点是已经不再 timeout。

Antigravity 恢复

TUN 真正接管后，Antigravity App 不再报网络超时，而是进入账号验证流程：

Further action is required to use Antigravity
Please verify your account, then sign in again to continue.

完成 Google 账号验证后，App 可以正常登录。

CLI 重新登录后，日志显示：

consumerOAuth: authentication completed successfully
ChainedAuth: interactive auth completed via consumer
URL: https://daily-cloudcode-pa.googleapis.com/v1internal:loadCodeAssist
URL: https://daily-cloudcode-pa.googleapis.com/v1internal:fetchAvailableModels
Propagating selected model override to backend: label="Gemini 3.5 Flash (High)"

这说明 CLI 也已经恢复。后面看到的：

Terminal gone, shutting down

不是登录失败，而是终端会话退出或被关掉了。

关于 Ctrl+Z 卡住的 CLI

还有一个小坑：终端里按 Ctrl+Z 并不是退出程序，而是把进程暂停到后台。此时进程状态会显示为 T。

查看：

ps -axo pid,ppid,stat,etime,command | grep agy

如果看到：

T agy

可以先恢复到前台再结束：

jobs
fg %1
# 然后按 Ctrl+C

如果终端已经乱了，也可以直接找进程并结束：

pgrep -fl agy
kill -9 <pid>

最终检查清单

以后遇到类似问题，可以按这个顺序查：

1. 不要先反复重新登录，先看日志里的 endpoint 是不是 timeout。
2. 测 HTTP 代理是否通：

curl -I https://oauth2.googleapis.com/token

3. 测直连是否也被 TUN 接管：

curl --noproxy '*' -I https://oauth2.googleapis.com/token

4. 看系统路由是否进入 TUN：

route -n get 8.8.8.8
route -n get 142.250.69.170

5. 如果仍然显示 interface: en0，说明 TUN 没有真正接管。
6. v2rayN 里优先确认 core 是否为 sing-box 或 mihomo，而不是只看 TUN 开关是否亮着。
7. 修好后再重新打开 Antigravity App 和 CLI。

复盘

这次最容易误导人的点是：Codex 和 Claude Code 都正常，所以直觉上会觉得网络没问题。但实际网络路径分了两类：

所以判断 TUN 是否生效，不能只看代理软件 UI，也不能只看浏览器能不能打开网页。最可靠的证据是：

route -n get <目标 IP>
curl --noproxy '*' <目标 URL>

这两个都通过，才说明系统级直连流量真的被接住了。