在 AI 辅助编程的开发日常中，Antigravity IDE 的 Google 账号登录、OAuth 认证及后台 AI 模型流式交互均高度依赖稳定的境外网络通道。
在过往的实践中，我们曾广泛采用 Clash TUN 模式与企业 VPN 双网并存实战指南 方案，通过操作系统的虚拟网卡（wintun/TUN）全局劫持并结合拆分隧道来维持开发与办公内网的平衡。然而，这一重度依赖底层虚拟网卡与系统网络路由栈的方案，在实际复杂环境下暴露出严重的脆弱性。
本文记录了从 TUN 模式崩溃故障到最终转向 Proxifier 进程精准劫持 + Clash 本地端口代理 的演进与配置全过程。
一、方案演进与背景回顾
1. 历史方案的运作模式
在此前撰写的 《Clash TUN 模式与企业 VPN 双网并存实战指南》 中，我们利用 Clash Verge 的 TUN（虚拟网卡模式） 接管系统所有 L3/L4 出站流量，并通过严格路由（Strict Route）和网段绕过（Bypass）来实现外网与企业 VPN 并存。
2. TUN 模式崩溃：由一次 AI 异常操作引发的故障
在后续的开发过程中，由于调试和本地环境变动，Clash Verge 的 TUN 模式底层虚拟网卡（wintun）驱动及其注册的系统路由表发生严重异常损坏，导致了灾难性的断网故障：
- 整机网络瘫痪：一旦开启 TUN 模式，不仅是境外网站，整台电脑所有浏览器的网页全部无法加载，无论是访问
google.com还是国内的baidu.com等所有网页均无法打开； - Antigravity IDE 彻底瘫痪：由于底层网络栈损坏，Antigravity IDE 无法拉起 Google OAuth 授权网页，即使登录凭证存在，后台 AI 补全和 Agent 工具交互也因连不上 Google 接口而完全停摆；
- 修复成本高、极易复发：TUN 虚拟网卡需要管理员权限对 Windows 系统的 WFP（Windows Filtering Platform）网络过滤层与路由表做全局介入，极易受到安全软件、系统休眠或并发网络工具的干扰。
3. 技术路线重构思考
既然全局代理与虚拟网卡（TUN）容易破坏系统原生网络与企业办公环境，为什么不让整台电脑的系统网络完全保持原汁原味，仅精准抓取 Antigravity IDE 自身的进程流量走代理？
基于这一思路，我们弃用了高风险的 TUN 模式，转向成熟轻量的方案：Proxifier 进程精准调度 + Clash Verge 本地端口代理。
二、新方案核心组件与架构设计
新方案的核心目标是：只解决 Antigravity Google 登录与 AI 接口网络，不改动 Windows 全局网络配置，不影响任何办公内网与浏览器原生网络。
1. Clash Verge 核心角色（轻量代理服务端）
Clash Verge 在本方案中彻底退居为“纯本地服务端”，不插手任何系统配置：
- 关闭系统代理：不修改 Windows 系统的任何全局 Proxy 设置；
- 关闭 TUN 模式：彻底规避虚拟网卡驱动崩溃、DNS 劫持失败带来的全网瘫痪隐患；
- Rule 模式 + 监听 7897 端口：保持 SOCKS5 端口监听，当 Proxifier 将外网请求送达时，依靠 Clash 的规则模式进行境外分流出海。
2. Proxifier 核心角色（进程级精准流量调度）
Proxifier 是解决问题的关键枢纽，专门弥补传统代理软件无法定向代理单一特定进程的短板：
- 精确进程名单：仅对 Antigravity IDE 相关的 3 个核心执行程序进行网络劫持，名单之外的所有软件流量 100% 直连放行；
- 本地域名解析：关闭 Proxifier 的远程 DNS 代理劫持，避免企业内部私有域名与国内域名被污染；
- 与企业 VPN 和谐共存：因为不操作全局默认网关与系统路由表，企业 VPN、内网系统无需任何复杂排除即可正常使用。
三、完整落地配置步骤
1. 前置准备：安装与激活 Proxifier
本方案的核心调度依赖 Proxifier 客户端。如果您的本地环境尚未安装或未完成激活，请先跟随以下专栏教程完成基础环境部署：
2. 第一步：Clash Verge 基础配置（轻量化运行）
- 打开 Clash Verge，将模式切换为 Rule（规则模式）；
- 务必确认关闭 首页的 「系统代理」 开关；
- 务必确认关闭 设置中的 「虚拟网卡模式（TUN）」 开关；
- 节点选择可正常访问 Google 的通畅外网节点；
- 此时 Clash Verge 仅在后台作为本地 SOCKS5 代理服务常驻（默认端口为
127.0.0.1:7897）。
3. 第二步：Proxifier 代理服务器与规则配置
1. 配置代理服务器
打开 Proxifier 客户端，点击顶部菜单 Profile → Proxy Servers → Add：
- Address：
127.0.0.1 - Port：
7897 - Type：选择
SOCKS5 - 点击
OK保存（若弹出是否将其设为默认路由，请选择 No）。
2. 配置 Antigravity 专属进程路由规则
点击顶部菜单 Profile → Proxification Rules → Add：
- Rule Name：填写
Antigravity-Route - Applications：粘贴以下 Antigravity 核心进程（包含 IDE 主进程、后台 Agent 及内置语言服务器）：text
"antigravity ide.exe";antigravity-agent.exe;language_server_windows_x64.exe - Action：在下拉框中选择刚刚添加的 SOCKS5 代理服务器（
127.0.0.1:7897）； - 检查默认规则：确保规则列表最底部的
Default规则 Action 保持为Direct（直连）。
3. 选配扩展：添加 Chrome 独立代理规则（推荐）
如果您日常还需要在 Chrome 浏览器 中访问 Google 查阅资料或登录账号，推荐为其创建一条独立的路由规则，方便在无需代理时单独关闭该条规则而不影响 IDE：
- 点击顶部菜单
Profile→Proxification Rules→Add； - Rule Name：填写
Chrome-Proxy； - Applications：填写
chrome.exe； - Action：选择
Proxy SOCKS5 127.0.0.1:7897； - 保存后确保
Chrome-Proxy处于勾选状态，且位于底部的Default之上。
智能分流机制：由于底层的 Clash Verge 处于 Rule（规则模式），Chrome 访问 Google、GitHub 等境外网站时会自动走代理节点；而访问百度、公司内网等国内网址时仍会自动走直连，兼顾速度与稳定性。
4. 规避 DNS 污染冲突
点击顶部菜单 Profile → Name Resolution：
- 取消勾选
Resolve hostnames through proxy； - 保持本地 DNS 解析激活，避免 DNS 被代理劫持导致国内网页与内网域名打不开。
4. 第三步：生效与启动流程
- 以管理员身份运行 Proxifier（抓取特定系统进程的网络套接字需要管理员权限支持）；
- 确保 Clash Verge 在后台正常运行（Rule 模式，系统代理与 TUN 均关闭）；
- 打开任务管理器，彻底结束可能残留的旧 Antigravity 进程（如需测试 Chrome，也可顺带重启 Chrome）；
- 重新启动 Antigravity IDE 或打开 Chrome 访问
https://www.google.com； - 观察 Proxifier 主界面的 Connections 连接列表：
- 当看到
antigravity ide.exe或antigravity-agent.exe且 Rule 显示为Antigravity-Route时，说明 IDE 流量代理成功； - 当看到
chrome.exe且 Rule 显示为Chrome-Proxy时，说明浏览器定向代理配置成功。
- 当看到
四、方案效果与对比验证
| 维度 | 原 Clash TUN 模式方案 | 新 Proxifier + Clash 方案 |
|---|---|---|
| 系统侵入性 | 高（安装虚拟网卡，接管全局路由表与 WFP） | 零侵入（仅在用户态钩子捕获指定进程） |
| 容灾稳定性 | 较弱（驱动或路由表损坏会导致整机无法上网） | 极高（IDE 代理失败也不会影响电脑任何网络） |
| 办公兼容性 | 需配置复杂网段排除以防企业 VPN 秒断 | 原生网络状态，天然与任何企业 VPN / 内网无缝兼容 |
| DNS 影响 | 全局接管，极易污染内网私有域名解析 | 本地原生 DNS 解析，绝无解析冲突 |
| Antigravity 登录 | 正常（在 TUN 完好时） | 完美支持 Google OAuth 与后台 AI 全链路流式调用 |
五、常见问题快速排查
- Antigravity 点击登录仍提示网络异常？
- 确认 Proxifier 是否已使用管理员身份运行，否则无法拦截部分后台服务进程；
- 确认应用程序名称中是否包含英文双引号（特别是
"antigravity ide.exe"中间有空格，必须使用英文双引号包裹）； - 确认 Clash 节点本身对 Google 域名的访问通畅度。
- 配置后日常办公软件或网页出现打不开？
- 检查 Proxifier 的
Default兜底规则是否误选了 Proxy，必须为Direct； - 检查
Name Resolution中是否取消了Resolve hostnames through proxy。
- 检查 Proxifier 的