前言：Google Antigravity 为什么需要配置 Clash
Google Antigravity 是 Google 面向开发者和 AI 用户推出的新型智能工具，通常会涉及账号登录、模型请求、项目资源加载、代码仓库同步以及实时接口通信等多个环节。对于国内用户来说，最常见的问题并不是客户端完全无法打开，而是页面长时间停留在加载状态、登录按钮没有反应、验证码反复出现，或者进入工作区后请求频繁超时。
这类现象往往与单个网页打不开不同。Antigravity 可能同时访问多个 Google 服务域名，浏览器主页面能够打开，并不代表登录接口、静态资源、API 请求和 WebSocket 连接都已经正常。如果只在系统中打开一个简单的 HTTP 代理，部分请求仍可能直连，最终表现为“页面能开但功能不可用”。
Clash 的价值在于提供统一的节点管理、规则分流、DNS 处理和 TUN 接管能力。本文以 Clash Verge、Clash Verge Rev 和 Mihomo 客户端为主要示例，介绍从订阅导入、模式选择到 Antigravity 专属规则的完整配置思路。不同客户端的菜单名称可能略有差异，但核心参数基本一致。
先确认使用条件
请使用来源可靠、状态稳定且明确支持 Google 服务的订阅，并遵守所在地区的法律法规、网络管理要求以及 Google Antigravity 的服务条款。代理配置只能改善连接路径，不能保证账号一定通过地区、风控或资格审核。
1准备客户端与订阅配置
在开始排查之前，建议先选择一个仍在维护的 Clash 图形客户端。Windows、macOS 和 Linux 桌面用户可以优先考虑 Clash Verge Rev 或其他支持 Mihomo 内核的客户端；Android 用户应选择支持当前内核的 Clash 客户端；macOS 用户则需要确认系统代理权限和网络扩展权限已经允许。客户端本身不提供节点，必须准备一个合法、可用的订阅链接。
选择客户端并完成基础安装
安装完成后，首次打开客户端不要急着修改大量高级参数。先进入“配置”“Profiles”或类似页面，添加订阅链接并点击更新。正常的订阅通常会包含节点、代理组、DNS 和规则等内容。更新成功后，在代理页面确认列表中确实出现了可用节点，再进行后续测试。
- 打开客户端的订阅管理页面，粘贴服务商提供的订阅链接，并为配置设置一个容易识别的名称。
- 点击更新或下载配置。若提示超时，先检查订阅链接是否过期，再尝试切换当前网络或使用浏览器确认链接是否能返回内容。
- 进入代理页面，选择延迟较低、丢包较少且能够稳定访问 Google 服务的节点。不要只看一次测速结果，连续观察几分钟更可靠。
- 将运行模式设置为
Rule，不要一开始就长期使用Global。规则模式更容易保留国内网站直连，也便于定位是哪一类域名没有正确分流。
- 系统代理开关已经打开，并且 HTTP、HTTPS 代理端口显示正常。
- 客户端状态栏显示内核正在运行，没有端口冲突或权限错误。
- 当前代理组不是“故障转移”到一个已经失效的节点。
- 浏览器没有启用另一个 VPN、代理扩展或 PAC 文件，避免多个代理同时接管。
2导入订阅并开启正确的流量接管方式
Antigravity 的访问不仅包含浏览器页面请求，还可能包含后台 API、证书校验、实时连接和开发工具相关请求。仅开启系统代理时，Chrome 或 Edge 的大部分网页流量能够被接管，但某些应用进程、后台服务和非标准连接可能仍然绕过代理。因此，在系统代理正常但页面功能不完整的情况下，可以考虑启用 TUN 模式。
先用系统代理完成基础验证
建议先关闭其他网络工具，只保留 Clash，然后开启系统代理。使用浏览器访问 Google 的普通页面和账号登录页面，观察是否能够稳定加载。此时不要立刻判断 Antigravity 是否正常，因为第一次加载可能需要建立多个连接。若普通 Google 页面可以打开，而 Antigravity 仍然失败，通常说明需要补充域名规则、清理浏览器缓存，或处理 DNS 与 WebSocket 问题。
系统代理无效时启用 TUN 模式
TUN 模式会在系统网络层创建虚拟网卡，让更多应用流量经过 Clash。启用前请确认客户端已经获得管理员权限或系统网络扩展权限，并关闭其他 VPN 软件。不同版本的菜单可能叫“TUN”“增强模式”或“服务模式”，其目标都是让未遵循系统代理设置的连接也能进入 Clash。
开启 TUN 前请注意
TUN 会接管更多系统流量，错误配置可能造成国内应用变慢、局域网设备无法访问或 DNS 冲突。启用后如果出现网络异常，应先关闭 TUN，确认系统恢复，再逐项检查 DNS、路由和绕过局域网设置。
在 Clash Verge Rev 中，建议使用规则模式配合 TUN，而不是直接全局接管所有流量。局域网地址、打印机、路由器管理页和本地开发服务通常应设置为直连；Google 账号、Antigravity 以及相关静态资源则交给专用策略组处理。
3为 Google Antigravity 设置专用分流规则
稳定访问的关键不是把所有流量都丢到同一个节点，而是将相关域名集中到一个稳定的策略组。你可以在订阅原有规则的基础上添加自定义规则，也可以通过客户端提供的覆写、Merge 或规则集功能进行管理。规则必须放在通用规则之前，否则可能先被更宽泛的 Google、代理或直连规则匹配。
推荐的域名分流思路
Antigravity 的实际域名可能随产品版本、地区和账号状态变化，因此不要把下面的示例当成永久完整名单。配置后如果开发区、登录页或模型调用仍然异常，可以在 Clash 的连接日志中查看真实请求域名，再将确认属于 Antigravity 或 Google 账号体系的域名补充进去。
上面的写法适合用于理解规则结构。实际使用时，建议优先采用订阅服务商维护的 Google 服务规则集，避免自行把全部 Google 流量强制代理而影响国内可用服务。若你的订阅已经包含同名策略组，请直接复用；如果没有，则需要在配置文件的 proxy-groups 中创建一个对应组。
建议将策略组设置为手动选择或延迟测试模式，并准备两个以上质量相近的节点：
- 优先稳定：登录和开发工作区需要长连接，稳定性通常比单次测速速度更重要。
- 固定出口：同一个账号尽量保持相对稳定的地区和出口，频繁切换国家或节点可能触发额外验证。
- 避免拥堵：如果页面能打开但模型请求频繁超时，优先更换节点，而不是不断刷新网页。
- 保留直连组：国内网站、局域网和本地开发服务应继续使用
DIRECT，减少不必要的绕行。
DNS 与浏览器缓存也要同步处理
DNS 解析结果会影响 Clash 是否能够正确识别和分流域名。使用 Mihomo 时，可以启用内置 DNS，并根据客户端支持情况选择 Fake-IP 或 Redir-Host 模式。若启用 Fake-IP 后某个本地服务无法访问，应将局域网域名和本地网段加入 fake-ip-filter，而不是直接关闭整个 DNS 模块。
规则更新后，完全退出浏览器再重新打开，并清理 Antigravity 站点的缓存和 Cookie。登录状态异常时，不要反复快速点击登录按钮；先确认系统时间准确、浏览器没有阻止第三方 Cookie，并检查 Google 账号本身是否需要完成安全验证。
4页面加载失败与登录异常排查
配置完成后，可以按照“节点、模式、规则、DNS、浏览器、账号”的顺序排查。不要一次性修改所有设置，否则即使问题消失，也很难知道真正起作用的是哪个步骤。
- 页面完全打不开：先检查当前节点是否在线，再确认系统代理或 TUN 是否真的启用。可以查看 Clash 连接日志，判断请求有没有进入代理。
- 页面能开但资源缺失：通常是静态资源域名没有匹配规则。打开开发者工具的 Network 面板，观察失败请求的域名，并将确认相关的域名补充到 Google-AI 策略组。
- 登录按钮无响应：检查浏览器 Cookie、弹窗权限和第三方登录窗口是否被拦截，同时确认
accounts.google.com没有被错误地分到直连组。 - 请求超时或工作区断线：更换稳定节点，避免使用高延迟或频繁变更 IP 的自动组；如果浏览器扩展也在代理，先停用重复代理。
- 反复出现验证：不要短时间内连续更换多个地区节点。保持网络出口相对稳定，并完成 Google 账号要求的安全验证。
- 国内网站变慢：检查是否误用了 Global 模式，或自定义规则放置位置不正确。将国内域名、局域网地址和常用本地服务恢复为直连。
推荐的验证顺序
先确认 Clash 连接日志中出现 Antigravity 相关请求，再确认这些请求使用的是 Google-AI 策略组，最后检查浏览器控制台是否还有 DNS、证书、Cookie 或 WebSocket 错误。
完成配置后，建议保存一份可用的配置备份，记录当前使用的客户端版本、内核版本、节点地区和规则修改内容。以后订阅更新导致规则变化时，可以快速对比差异。若服务端更改了域名或访问策略，应以官方公告和客户端日志为准，不要长期依赖来源不明的“万能规则”。
总结：用稳定分流替代盲目全局代理
Google Antigravity 的访问体验通常由多个因素共同决定：可用节点、正确的订阅配置、稳定的代理出口、完整的域名分流、可靠的 DNS 解析，以及浏览器和 Google 账号状态。最推荐的做法是先以 Rule 模式完成基础测试，再根据连接日志补充规则；系统代理无法接管全部流量时，才进一步启用 TUN 模式。
如果你仍然遇到问题，应优先判断是网络连接问题还是账号资格问题。Clash 可以改善请求路径和连接稳定性，但无法替代 Google 对地区、账号、服务资格或安全风险的判断。保持规则简洁、节点稳定、出口一致，并定期更新客户端和订阅，通常比堆叠大量未知规则更有效。