WSL2 (Manjaro) 环境下 Google Antigravity AI服务网络连接与环境配置问题本文记录在WS

注意，最近 Antigravity 更新了版本，可能只需要开启代理软件如Clash的TUN模式（虚拟网卡）模式 + WSL2网络模式为 Mirrored 即可。如果不行再参照以下内容。

背景

Google Antigravity 是 Google 推出的下一代 Agent-first 集成开发环境（IDE）。其核心智能体服务（Agent Service）后端组件 language_server_linux_x64 采用 Go 语言编写。

在 WSL2 环境下使用 Antigravity 时，可能存在一个典型的网络连接问题：Go 语言编写的静态编译程序通常不遵循系统环境变量（如 HTTP_PROXY）或 Proxychains 的劫持。这导致在开启系统代理的情况下，IDE 的 AI 功能仍然无法连接服务器，出现连接超时或无响应的情况。

本文详细记录了在 WSL2 (Manjaro发行版) 下，利用 graftcp 工具通过 ptrace 机制强制接管 Go 程序网络流量的解决方案，并解决了在此过程中遇到的系统更新崩溃及服务持久化问题。

1. 系统环境准备与修复

在开始配置网络工具前，需要确保 WSL2 环境的基础依赖完整。

1.1 安装基础依赖

需要安装 go、git、make 以及 base-devel 编译工具链：

sudo pacman -Syu go git make base-devel

1.2 可能需要处理 WSL2 系统更新导致的崩溃 (E_UNEXPECTED)

在执行 pacman -Syu 进行全系统升级时，可能会更新 glibc 和 systemd 等核心组件。在 WSL2 环境下，这可能导致 Windows 宿主机的 WSL 服务进程与 Linux 子系统状态不一致，抛出 Wsl/Service/E_UNEXPECTED 错误或“灾难性故障”，导致无法进入终端。

解决方案：

强制关闭 WSL 子系统：

在 Windows PowerShell 中执行：
```
wsl --shutdown
```
更新 WSL 内核（关键步骤）：

新版的 Linux 核心库可能依赖较新的 WSL 组件，需手动更新：
```
wsl --update
```
清理旧版 Server 缓存：

系统恢复后，旧的 VS Code Server 或 Antigravity Server 二进制文件可能与新的 glibc 不兼容，需手动清理：
```
rm -rf ~/.vscode-server
# 或
rm -rf ~/.antigravity-server
```

2. 编译与安装 Graftcp

鉴于常规代理工具失效，我们采用 graftcp。它通过 ptrace 追踪系统调用，能有效处理 Go 程序的 TCP 连接。

2.1 源码编译

# 回到用户主目录
cd ~
git clone https://github.com/hmgle/graftcp.git
cd graftcp

# 编译
make

2.2 安装至系统

sudo make install
sudo make install_systemd
sudo systemctl daemon-reload

安装完成后，二进制文件位于 /usr/local/bin/，配置文件位于 /etc/graftcp-local/。

3. 代理服务配置

为了使 WSL2 内的流量正确转发至 Windows 宿主机的代理软件（如 Clash/v2rayN），建议将 WSL2 网络模式设置为 Mirrored (镜像模式) 。

3.1 修改 Graftcp 配置文件

编辑配置文件：

sudo nano /etc/graftcp-local/graftcp-local.conf

主要修改以下两项参数：

http_proxy：指向 Windows 宿主机的代理端口（镜像模式下即为 127.0.0.1）。
select_proxy_mode：强制指定为 only_http_proxy，避免自动探测失败。

配置示例：

## graftcp-local configuration

## 监听地址
listen = :2233

## 这里填写 Windows 代理软件的 HTTP 端口 (例如 7897 或 10808)
http_proxy = 127.0.0.1:7897

## 强制使用 HTTP 代理模式
select_proxy_mode = only_http_proxy

3.2 启动并设置开机自启

Antigravity 启动时依赖该后台服务。务必设置为开机自启，否则重启 WSL 后服务将中断导致 Antigravity 会遇到报错： Antigravity server crashed unexpectedly. Please restart to fully restore AI features

# 启动服务并设置为开机自启
sudo systemctl enable --now graftcp-local

# 验证状态 (应为 active running)
sudo systemctl status graftcp-local

4. 实施 Wrapper 脚本替换

这是解决问题的核心步骤。我们需要找到 Antigravity 的核心二进制文件，将其替换为一个 Wrapper 脚本。该脚本将通过 graftcp 启动原程序，并注入必要的环境变量。

4.1 定位目标文件

Antigravity 更新频繁，且路径包含随机哈希值。使用以下命令定位当前版本的 language_server_linux_x64：

Bash

find ~/.antigravity-server -name "language_server_linux_x64"
# 示例路径输出：
# /home/user/.antigravity-server/bin/[HASH_VALUE]/extensions/antigravity/bin/language_server_linux_x64

4.2 替换与脚本注入

进入目标目录后，执行以下操作：

备份原程序：

mv language_server_linux_x64 language_server_linux_x64.bak

创建 Wrapper 脚本：

新建 language_server_linux_x64 文件，写入以下内容：

#!/bin/bash

# Graftcp 安装路径
GRAFTCP_BIN="/usr/local/bin/graftcp"
LOG_FILE="/tmp/antigravity_wrapper.log"

echo "[$(date)] Wrapper启动. 参数: $@" >> "$LOG_FILE"

# 关键环境变量优化
# 1. 强制使用系统 CGO 解析 DNS，避免 Go 原生解析器在代理环境下解析失败
export GODEBUG=netdns=cgo
# 2. 强制关闭 HTTP/2，解决 Go HTTP/2 客户端在代理转发时的断流/EOF问题
export GODEBUG=$GODEBUG,http2client=0

# 使用 graftcp 启动原程序
exec "$GRAFTCP_BIN" "$0.bak" "$@"

赋予执行权限：
```
chmod +x language_server_linux_x64
```

4.3 验证

重启 Antigravity IDE。在 WSL 终端中监控日志：

tail -f /tmp/antigravity_wrapper.log

若出现 "Wrapper启动" 字样且 AI 功能恢复正常，即表示配置成功。

5. 自动化维护脚本（踩过雷）

5.1 ⚠️ 警示：全自动化脚本的“套娃”陷阱

由于 Antigravity 具有自动更新机制，更新后会生成新的哈希目录，导致上述手动修改失效。为此，应该考虑编写一个自动化脚本来检测并修复新版本。

在早期尝试中，我曾试图将修复脚本加入 .zshrc（启动终端自动执行）或 Crontab（定时执行）以实现“无感全自动修复”。但这导致了一个严重的 递归覆盖（Recursive Overwriting） 事故，具体表现为：

竞态条件：当 VS Code/Antigravity 启动并连接 WSL 时，会同时启动 Shell 和 Antigravity 的下载/启动进程。
误判：如果脚本在 Antigravity 刚下载完新文件、甚至正在下载时触发，脚本会将原始二进制文件重命名为 .bak 并生成一个 Shell Wrapper。
死循环：当下一次 Shell 启动（或脚本重复运行）时，脚本可能会错误地将 “上一次生成的 Wrapper 脚本” 识别为原程序，再次对其进行包裹。
后果：Wrapper 包裹了 Wrapper，而真正的 160MB+ 二进制核心文件在多次重命名中被覆盖丢失，导致 IDE 彻底崩溃报错:Antigravity server crashed unexpectedly. Please restart to fully restore AI features，且无法恢复。

因此，强烈不建议在 .zshrc 中静默运行修复脚本。或许应采用 “基于文件大小检测” 的防御性编程，并配合 “半自动化命令” 来平衡安全性与便捷性。

5.2 编写“防误伤”的安全修复脚本

新的脚本增加了核心逻辑：只有检测到目标文件是大于 1MB 的二进制文件时才执行替换。如果目标文件很小（说明是脚本或未下载完成），则自动跳过。

创建 ~/safe_fix_antigravity.sh：

#!/bin/bash

# === 配置区域 ===
# Antigravity 存放 bin 的根目录
TARGET_ROOT="$HOME/.antigravity-server/bin"
GRAFTCP_BIN="/usr/local/bin/graftcp"
MARKER="# WRAPPER_BY_ZYM"
# ================

echo "🔍 正在扫描 Antigravity 目录..."

# 查找目录下所有的 language_server_linux_x64
find "$TARGET_ROOT" -name "language_server_linux_x64" 2>/dev/null | while read -r BIN_PATH; do
    
    # 1. 安全检查核心：检查文件大小 (单位 kb)
    # 真正的 AI 引擎二进制文件通常 > 100MB。如果小于 1MB (1000kb)，说明它是脚本或异常文件。
    FILE_SIZE=$(du -k "$BIN_PATH" | cut -f1)
    if [ "$FILE_SIZE" -lt 1000 ]; then
        # 静默跳过，不报错，防止误伤
        continue
    fi

    # 2. 二次检查：读取文件头，避免重复处理
    FIRST_LINE=$(head -n 1 "$BIN_PATH")
    if [[ "$FIRST_LINE" == *"$MARKER"* ]]; then
        echo "✅ 跳过：$BIN_PATH (已修复)"
        continue
    fi

    echo "🛠️  发现新版本二进制文件 ($((FILE_SIZE/1024)) MB)，正在执行“偷梁换柱”..."
    echo "   目标: $BIN_PATH"

    # 3. 备份真身 (原子操作)
    mv "$BIN_PATH" "${BIN_PATH}.bak"

    # 4. 写入 Wrapper 脚本
    cat > "$BIN_PATH" <<EOF
#!/bin/bash
$MARKER
# 这是一个代理 Wrapper，原程序在 .bak 中
GRAFTCP_BIN="$GRAFTCP_BIN"
LOG_FILE="/tmp/antigravity_wrapper.log"

# 记录启动日志，方便排查
echo "[$(date)] Wrapper启动..." >> "$LOG_FILE"

# 关键优化：强制使用系统 DNS 并关闭 HTTP/2 (解决 EOF 问题)
export GODEBUG=netdns=cgo,http2client=0

# 启动真身
exec "$GRAFTCP_BIN" "$0.bak" "$@"
EOF

    # 5. 赋予执行权限
    chmod +x "$BIN_PATH"
    echo "🎉 修复完成！请重启 VS Code。"
    
    # 通常只需要修最新的一个，修完即退
    break
done

赋予脚本执行权限：

chmod +x ~/safe_fix_antigravity.sh

5.3 最佳实践：使用 Alias 半自动维护

为了避免上述的启动冲突，建议将脚本绑定为一个简短的别名（Alias）。平时无需理会，仅在 Antigravity 更新后出现连接问题时，手动执行一次即可。

编辑 Shell 配置文件（如 ~/.zshrc）：

# Antigravity 网络修复快捷指令
alias fixai="~/safe_fix_antigravity.sh"

应用更改：

source ~/.zshrc

5.4 维护流程总结

日常使用：无需任何操作。
遇到问题：当 Antigravity 提示更新或 AI 功能突然无法连接（报错 Network Error / Crashed）时。
一键修复：在 VS Code 终端输入 fixai，脚本会自动识别新下载的二进制文件并进行代理注入。
重启：重启 VS Code 即可恢复。

这种“按需调用”的方式虽然多了一步手动操作，但避免了脚本误删系统文件的风险。

6. 其他注意事项

权限问题：如果在后续启动 Antigravity 时遇到报错： Antigravity server crashed unexpectedly. Please restart to fully restore AI features，也有可能是因为之前使用 sudo 运行过某些命令导致 ~/.gemini 或 ~/.antigravity-server 目录权限归属为 root。

可以先尝试：
```
sudo chown -R $(whoami):$(whoami) ~/.gemini ~/.antigravity-server
```
Windows 代理设置：务必确保 Windows 端代理软件（Clash/v2rayN）开启了“允许局域网连接 (Allow LAN)”。检查 WSL2 网络模式为 Mirrored 。

WSL2 (Manjaro) 环境下 Google Antigravity AI服务网络连接与环境配置问题

背景