🛑 问题背景

许多开发者在使用 VSCode 的 Remote SSH 功能连接位于国内或受限网络环境下的 Linux 服务器进行开发时，发现 Google Antigravity 插件无法正常工作。

具体表现为：

• 右侧的 AI 辅助/代理栏无法加载。
• 无法选择模型或与 AI 进行对话。
• 即使在服务器上配置了 http_proxy / https_proxy 环境变量，或者使用了 proxychains，问题依旧存在。
• 但在本地 Windows/Mac 环境下（配置好系统代理）则一切正常。

🔍 根本原因分析

问题的核心原因：

1. 后端进程机制：Antigravity 在 Remote SSH 环境下，会通过 SSH 向远程服务器下载并解压一个服务端包（通常位于 ~/.antigravity-server）。
2. 特殊的二进制文件：核心服务进程名为 language_server_linux_x64（可以通过 ps -ef | grep language_server 查看）。
3. Go 语言特性：这是一个 Go 语言编写的程序。它不遵循系统环境变量中的 HTTP/HTTPS 代理设置。
4. 代理失效：由于它直接发起网络请求且忽略环境变量，导致常规的代理配置（如 export all_proxy=...）对其无效，proxychains 也往往无法生效。

✅ 解决方案

针对上述问题，社区总结了以下几种行之有效的解决方案：

方案一：使用 graftcp 强制劫持流量（推荐 🌟）

这是目前最稳定、最受推荐的方案。graftcp 可以运行任何程序，并劫持其 TCP 连接请求，将其重定向到指定的 SOCKS5 代理。

操作思路：

1. 在远程 Linux 服务器上安装并编译 graftcp。
2. 配置 graftcp 指向你服务器上可用的 SOCKS5 代理地址。
3. 使用 graftcp 包装/启动 Antigravity 的相关进程（或者通过修改启动脚本/劫持命令的方式）。

原理：graftcp 在系统调用层级（syscall）进行拦截，比 proxychains 更底层，能够强制 Go 程序走代理。

方案二：使用 SSHFS 挂载（替代方案）

如果你不想折腾服务端的网络环境，可以改变开发模式：

1. 本地运行 IDE：在本地（Windows/Mac）打开 VSCode，利用本地畅通的网络环境运行 Antigravity。
2. SSHFS 挂载：使用 sshfs 将远程服务器的代码目录挂载为本地磁盘驱动器。
3. 开发：像编辑本地文件一样编辑服务器代码。

• 优点：利用本地网络，无需配置服务端代理。
• 缺点：大项目索引或文件读写可能受网络延迟影响，不如 Remote SSH 流畅。

方案三：服务端开启 TUN 模式（进阶）

如果你的远程服务器允许（拥有 root 权限且内核支持），可以安装 Clash 等代理软件并开启 TUN 模式。

• 原理：TUN 模式会创建一个虚拟网卡，接管系统层面的所有流量，从而强制所有进程（包括那个不听话的 Go 程序）走代理。
• 注意：对于共享服务器或没有 root 权限的环境，此方法不适用。

📝 补充讨论与细节

• Windows 本地代理的影响：有用户反馈，在某些特定配置下（可能是 WSL2 的镜像网络模式），开启 Windows 本地的 TUN 模式或 Proxifier 也能神奇地解决远程连接的问题，但这通常依赖于特殊的网络拓扑，不如 graftcp 稳定。
• 验证方法：在尝试修复前，可以先在服务器终端尝试 curl -v https://www.google.com 确认基础连通性。如果 curl 通但 Antigravity 不通，基本就是上述的进程代理问题。

🔗 参考链接

• graftcp 项目地址
• Clash for Linux Install 脚本

总结：Google Antigravity 在远程 Linux 环境下的“水土不服”主要是由于其 Go 后端进程忽略系统代理变量所致。通过 graftcp 进行流量劫持是解决此类“顽固”进程联网问题的最佳实践。