Antigravity 国内使用：代理 / TUN 模式 / 节点配置全攻略

不少朋友在国内装好 Antigravity 后，都会撞上同一堵墙：软件界面能打开，却卡在登录页一直转圈；Linux 下装包时报 GPG 签名校验失败；好不容易连上了，用两下又莫名断线。折腾半天以为是软件有 bug，其实问题几乎全出在网络这一环。原因只有一个——Antigravity 深度依赖云端的 Gemini 3，国内网络直连基本走不通，不配一套干净稳定的网络工具，它几乎无法正常工作。这篇教程按”你会遇到什么障碍 → 怎么一步步解决”的思路，把代理、TUN 模式、节点选择三件事讲透，照着做基本能一路顺到能用。

为什么”装好却用不了”：先搞懂它的网络脾气

Antigravity 的核心能力全在云端，本地客户端更像一个壳，真正干活的是远端的 Gemini 3。这意味着从激活登录到每一次对话请求，都要能稳定访问 Google 系服务。国内直连这些地址通常是不通的，所以你看到的”转圈””超时””连接被重置”，本质都是网络没接通，而不是软件坏了。

更关键的一点很多人踩坑：Antigravity 默认跟随操作系统的代理设置，听起来只要电脑挂了代理就行。但实测里，这款软件的相当一部分流量并不走普通的系统代理（HTTP/HTTPS 代理只能接管一部分应用层请求）。结果就是——你系统代理明明开着，浏览器能开 Google，Antigravity 却依旧连不上、登不进。要彻底解决，必须让代理以更底层的方式接管全部流量，这就是下面要重点讲的 TUN 模式。

黄金两点：踩准这两条，少走 90% 的弯路

在展开细节之前，先给结论。经过大量实测，只要把下面这两点踩准，安装、登录、日常使用基本一路顺，很少再遇到所谓的”玄学问题”：

1. 把 Google 账号的地区改成美国——很多区域限制、登录异常，源头是账号地区与节点地区不一致。
2. 代理全程开 TUN 模式（或全局模式）——从 Linux 安装校验签名，到 Google 账号登录，再到日常调用，全程都要开着 TUN，中途别关。

这两点是纲，其余都是目。如果你时间紧，先照这两条做，再回头看细节。

第一步：把 Google 账号地区改成美国

为什么先动账号？因为账号地区决定了 Google 对你身份的”默认判定”。如果账号地区还停留在国内，而你的节点又落在美国，两边打架，很容易触发风控，表现为登录卡住、反复要求验证、或者部分功能直接不可用。

操作思路很简单（以网页端为准）：

• 先挂好美国节点并开启 TUN，再打开 Google 账号管理页，避免在国内 IP 下修改反而被标记异常。
• 进入账号的个人信息 / 一般偏好设置，找到地区（Region / Country）一项，改为 United States。
• 保存后不要立刻反复切换地区，给系统一点生效时间，通常等待片刻即可。

一句话总结：账号地区、节点地区、使用地区三者尽量一致（都锚定美国），Google 眼里你就是一个”正常的美国用户”，登录和使用的阻力会小很多。

第二步：代理必须开 TUN 模式（本篇重点）

这是全篇最关键、也是最容易被忽略的一步。前面说过，Antigravity 很多流量不走普通系统代理，所以哪怕你系统代理开着，也可能连不上。TUN 模式的作用，就是在系统里虚拟出一张网卡，把整机的全部流量（包括那些不认系统代理的程序）统统接管、导向你的节点，做到真正的”全局接管”。

为什么系统代理不够，一定要 TUN

可以这样理解两者的区别：

• 系统代理（HTTP/SOCKS 代理）：像给”愿意配合的应用”发了一张通行证，只有主动读取代理设置的程序才会走。Antigravity 的部分底层请求恰恰不读这张证。
• TUN 模式（虚拟网卡 / 全局模式）：像在整栋楼门口设了统一关卡，不管哪个程序、走什么协议，流量都必须经过节点，从根上堵住了”漏网”的可能。

所以只要涉及 Antigravity，无论是 Linux 安装时连 pkg.dev 源做 GPG 签名验证，还是 Google 账号登录，都建议全程开 TUN，否则就会出现”装包报签名错误””登录一直失败”这类障碍。

怎么确认 TUN 真的生效了

开了开关不等于生效，按下面几步确认一下：

1. 在客户端里打开 TUN Mode / 虚拟网卡 开关，首次开启通常会提示安装虚拟网卡驱动，允许即可。
2. 路由模式尽量设为全局，让所有流量都走节点，而不是只走浏览器或规则内的域名。
3. 用命令行做一次硬验证：在终端里 curl 一个 Google 域名，能正常返回，说明底层流量已经通了；如果超时，说明 TUN 没真正接管。

需要提醒的是，TUN 模式对节点的稳定性和协议要求更高：它接管的是全机流量，一旦节点抖动或频繁跳区，整台电脑的网络都会跟着卡。所以 TUN 能不能用得舒服，很大程度上取决于你手里的节点质量——这就引出了下一节。配一个稳定不跑路的机场是前提，具体可参考本站的机场推荐。

节点怎么挑：美国 / 台湾专线优先，别用链式代理

节点选不对，前面两步做得再标准也白搭。针对 Antigravity 这种”全程要联云端、还要开 TUN”的场景，选节点记住三条：

• 地区选美国或台湾：与账号地区对齐，兼容性最好；美国节点对接 Gemini 系服务通常最顺，台湾则胜在延迟低、离得近。
• 拒绝链式代理（多重跳转）：有些节点为了绕路会经过好几跳中转，延迟高、还容易在中途被判定为异常 IP。一跳直达目标区域最稳，别搞多重嵌套。
• 要稳、延迟低、不频繁跳区：TUN 下节点一跳区，登录态可能直接掉、请求全断。宁可延迟略高但地址固定，也别用那种一会儿美国一会儿其它地区的”漂移”节点。

说白了，TUN 模式是把整台机器的身家性命都押在这条线路上，对线路质量的要求远高于随便开网页。这种场景更适合用稳定不跑路的美国 / 台湾专线机场，一般在中高端专线或口碑好的性价比口粮里挑就够用。具体机型对比，可以参考本站的机场推荐，按预算和落地区域挑一个延迟低、跳区少的即可。

连不上 / 登不进？照这份排查清单走一遍

如果你已经按上面配好，却还是有问题，别急着重装软件，先按这个顺序自查，绝大多数故障都能定位：

Google 账号登录卡住、登不进去

这是最高频的报错。按优先级排查：

1. 先查 TUN 是否真的开着：这是第一嫌疑。关掉再开一次，确认虚拟网卡已启用、路由为全局。
2. 再查节点是不是美国 / 台湾：账号地区改成了美国，节点却落在其它区，两边不一致就容易卡登录。
3. 是否走了链式代理：多重跳转会让 Google 觉得 IP 可疑，关掉中转、改用直连一跳的节点再试。
4. 以上都对还不行，就换一个同区节点再登一次，排除单节点被临时限流的可能。

Linux 装包时 GPG 签名验证失败

这类错误通常发生在安装脚本去连 pkg.dev 等源做签名校验时，网络没通导致校验失败。解决思路一致：确认 TUN 全程开启再重新执行安装命令，让校验请求也能顺利出海；不要”装包时临时关代理”，那正是很多人失败的原因。

能登进去，但用一会儿就断

大概率是节点稳定性问题——节点抖动或悄悄跳了区。换一个更稳、延迟更低、不频繁跳区的美国 / 台湾专线节点，通常就能治好这种”时好时坏”。

小结

Antigravity 在国内能不能用顺，说到底就是网络这一关。把逻辑捋清楚其实很简单：它重度依赖云端 Gemini 3，直连不通；系统代理又接管不全，所以必须开 TUN（或全局）让全部流量走节点；再把Google 账号地区改成美国、与节点地区对齐，风控阻力立刻小一大截。踩准这黄金两点，配合一个美国 / 台湾的稳定不跑路专线节点、拒绝链式跳转，安装、登录、日常使用基本就能一路顺。真遇到卡壳，别慌，回到那份排查清单：先看 TUN 有没有开，再看节点是不是美 / 台，最后看是不是链式代理——三板斧走一遍，大多数”玄学问题”都会现原形。工具配对了，Antigravity 才谈得上好用。

主题授权提示：请在后台主题设置-主题授权-激活主题的正版授权，授权购买：RiTheme官网