2025年11月23日

避坑指南: Linux 下 Antigravity 安装与 Cl* TUN 模式配置实录

最近被 G 厂的新 IDE Antigravity 坑惨了。折腾了两个晚上，终于跑通了在 Ubuntu 20.04 上的完整安装流程。踩了两个大坑：一个是 APT 源死活连不上，装都装不上；另一个是好不容易装完了，浏览器登录成功了，客户端那边却一直在那儿转圈圈，接收不到回调，差点让我以为是软件 Bug 准备提 issue。

查了一圈才发现是网络环境的锅。普通的 HTTP 代理只能管一部分请求，但系统级的依赖下载和那些不走标准协议的回调请求，根本绕不过去。这篇就记录一下我从修安装源到配 Cl*** TUN 模式的完整踩坑过程，希望能帮到后来人。

坑一：APT 源连不上，依赖还打架

Antigravity 的安装包托管在 pkg.dev，这个域名在国内访问基本上就是随缘。我试了好几次，每次都是 Connection timed out (Err: 29)，心态差点崩了。

我一开始想直接改 /etc/apt/apt.conf 一劳永逸，但后来一想，这玩意儿是全局配置，万一污染了影响内网其他环境，到时候更麻烦。所以最后决定还是在命令行里临时注入代理地址，用完就扔，干净。

实际操作的命令是这样的。注意，如果你的 curl 也走不通，得先把代理环境变量导出来：

Terminal window
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl -fsSL https://us-central1-apt.pkg.dev/doc/repo-signing-key.gpg | sudo gpg --yes --dearmor -o /etc/apt/keyrings/antigravity-repo-key.gpg

然后带代理安装：

Terminal window
# 指定代理进行 update 和 install
sudo apt -o Acquire::http::Proxy="http://127.0.0.1:7890" -o Acquire::https::Proxy="http://127.0.0.1:7890" update
sudo apt -o Acquire::http::Proxy="http://127.0.0.1:7890" -o Acquire::https::Proxy="http://127.0.0.1:7890" install antigravity

异常情况

如果在安装时提示 Unmet dependencies，通常是因为之前中断的安装导致依赖损坏（比如 chrome-remote-desktop）。这时候可以：

Terminal window
sudo apt --fix-broken install
# 或者直接卸载有问题的包
sudo apt remove chrome-remote-desktop

坑二：登录回调为啥收不到？

好不容易装完启动，点登录跳转浏览器，授权完回来发现客户端一点反应都没有，就在那儿干等着。我盯着屏幕愣了半天，才反应过来：Antigravity 的那个登录回调监听，根本不认终端里设的 http_proxy 环境变量。

说到这儿，可能有人想用 proxychains 强行代理。我试过了，不太行。尤其是对 Go 写的程序或者 Electron 应用，proxychains 的稳定性很差，经常莫名其妙就断了。后来我一想，干脆直接上 TUN 模式，让虚拟网卡接管所有系统流量，这才是最省心的办法。

坑三：GitHub 上的开源版根本不支持 TUN

这里有个巨坑：GitHub 上搜到的那个 cl***-linux-amd64 开源版，早就没人维护了，而且压根不支持 TUN 模式。你要是配置文件里有 tun 字段，它要么直接无视，要么根本启动不了。

我一开始没注意，配置了半天 TUN，发现日志里根本没反应，还以为是配置写错了，反复检查了十几遍。后来去翻了文档才发现，得换成 M****（原 Meta 内核）才行。

下载地址：GitHub MetaCubeX/m*****。

注意：这个仓库的简介可能会伪装成什么”游戏数据解析库”（写着 Python Pydantic model 啥的），实际上是为了躲审查，内核是用 Go 写的二进制文件，别被表象骗了。

操作步骤：下载 Release 里的 m*****-linux-amd64-vX.X.X.gz，解压，给执行权限，然后重命名成 cl*** 替换掉原来的文件。

坑四：DNS 端口冲突，systemd-resolved 捣乱

开了 TUN 模式之后，DNS 劫持是必须要配的不然上不了网。但这里又有个坑：Linux 上 53 端口通常被 systemd-resolved 占着，你不改就会冲突。

我一开始没注意，启动直接报 listen udp 0.0.0.0:53: bind: address already in use，查了半天才发现是端口占用的问题。后来把监听端口改成 1053 就没事了。这是我的配置，你参考一下：

dns:
  enable: true
  # Linux 下 53 端口常被 systemd-resolved 占用，改为 1053 避免冲突
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 8.8.8.8
    - 1.1.1.1


tun:
  enable: true
  stack: system # 推荐 system，如果报错可尝试 gvisor
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

重要提醒：千万别强行关系统的 DNS 服务，改了端口就行了。

坑五：资源库缺失，启动命令还有陷阱

第一次跑 M****** 的时候，日志里一直刷这个错： can't initial GeoIP: ... context deadline exceeded

我盯着这个报错查了半小时才明白咋回事：

  1. 程序需要 geoip.metadb 和 geosite.dat 这两个路由规则库，但我目录里没有。
  2. 它默认会去系统目录找，但当时网络还没通，它也下载不了。
  3. 最关键的是：我直接用 sudo 运行，但没加 -d . 指定工作目录，它就找不到我放在当前目录下的库文件。

解决方案：

  1. 手动从 GitHub 相关仓库下载 geoip.metadb 和 geosite.dat。
  2. 把这两个文件放到 cl*** 可执行文件同级目录下。
  3. 启动时必须加上 -d . 参数，强制程序读取当前目录的数据库和配置：
Terminal window
# 假设你的配置文件叫 WestData
sudo ./cl*** -d . -f WestData

终于跑通了

配置完之后启动，盯着日志看了半天，终于看到这两行字的时候，差点没哭出来：

DNS server listening at: [::]:1053
[TUN] tunable active

（有时候也可能是 inbound tun create success，只要看到 TUN 相关的成功日志就行）

这时候系统流量已经被工具接管了。新开一个终端直接输 antigravity 启动，点击登录，浏览器授权完，客户端终于收到回调了！那一刻的心情，大概只有踩过同样坑的人才能体会。

这篇文章记录了我折腾两个晚上的成果，希望能帮到同样被这些问题困扰的朋友。如果你也遇到了其他坑，欢迎在评论区交流。