一、为什么是「总在超时」：Agent IDE × Google API
当你第一次打开 Google Antigravity尝鲜 Gemini时，报错提示往往泛泛写成超时、无法连接服务端或TLS 握手卡住。若此时浏览器访问 gemini.google.com 尚能工作，很常见的原因是：规则分流只在浏览器链路生效，但 Agent IDE 触发的oauth、cloudcode与面向 Google API的后台会话仍走了不同出口，导致 OAuth 令牌刷新、CDN 脚本与*.googleapis.com流式链路在不同策略组之间「撕裂」。
另一个放大器是高并发：IDE 往往在同一时间窗口内打开多个长连接与小请求。Clash若配置了过于敏感的自动测速与切换（url-test阈值过窄），会话仍会被迫在不同节点之间迁移，从而在服务端侧看起来像异常路径，进一步触发重试风暴与体感上的“永远转圈”。
DIRECT 还是 PROXY。TUN未开时仅凭「勾选系统代理」往往解释不了 Electron 场景的半直连分叉。
二、TUN 与系统代理：谁真正覆盖 Agent IDE
系统代理的典型覆盖路径是：尊重系统 PAC/HTTP(S) 代理的那部分流量。对部分 Agent IDE或扩展宿主而言，子进程、本地回环中转、或通过 gRPC/WebSocket连接到侧车的路径，未必走你熟悉的「浏览器同款」钩子。相较之下，Clash TUN以内核层路由接管的方式，更接近「只要不是明确排除的流量，就由代理栈统一编排」这一目标。
实操上可先做一个判别实验：在不改变规则内容的前提下，仅以启用 TUN（或等价的全局 TAP/TUN）为变量，对照 Antigravity 的连接面板与客户端日志。若开启 TUN 后大量原本直连的accounts.google.com与googleapis.com请求开始稳定命中你为 Google AI 准备的策略组，则网络侧主轴基本坐实：不是 Google API 一夜之间「坏了」，而是规则触达率与进程覆盖不一致。
不同 GUI（如Verge Rev与其他 Mihomo 系客户端）在局域网绕过、Bypass 域名、进程豁免与网关场景上选项差异极大。请以你所用软件的官方文档为准；若在 macOS 上首次接触 TUN，可参考本站 《macOS TUN（Verge Rev）手记》中的前置条件与大版本差异，减少「开了 TUN 反而本地开发调试全断」的误操作。
三、Gemini / Antigravity 常见出站面（域名族）
我们在《Google Gemini 打不开或 API？规则锁定 Google 域名》里已经反复强调：OpenAI与Google走的是两套主机名图谱。对 Antigravity一类Gemini 路线而言，仍需至少覆盖：对话与产品入口所在域、账号与 OAuth（accounts.google.com 等）、静态分发（gstatic、googleusercontent 等），以及与生成式链路相关的*.googleapis.com（常见服务名会随产品与区域调整，请以你当前抓到的为准）。若企业或个人使用 Vertex/Enterprise形态，可能还会额外命中区域化后缀与控制台主机名——这类请求不能与「网页 Gemini」混在一个粗规则关键字里糊弄过去。
- 网页与控制台域：除
gemini.google.com之外，跳转与控制台相关子域请以 Network 面板为准。 - 会话与令牌：错过
accounts.google.com链路时常见「点开登录就没下文」。 - 静态与脚本资源：
gstatic.com等失败往往表现为半成品页面或操作按钮不可用。 - Google API（生成式）：请关注 SDK 与实际 TLS SNI（例如
generativelanguage.googleapis.com一类名称；以官方文档与版本为准）。 - IDE 侧本地工具链：若仍并行使用 Copilot系或 Prism/OpenAI链路，应保持各自策略前缀清晰，避免
DOMAIN-KEYWORD,ai一类的粗暴兜底抢在前面。
站内已有多篇「编程侧热点」排布：《GitHub Copilot 模型与分流》、《OpenAI Prism 域名分流》与上文 Gemini 专文。Google Antigravity题位在于：把Google API线与TUN落地绑在一起——避免只复述域名列表却忽视出口形态。
四、规则分流：把 Google AI 的流量放进同一桶
你依然需要遵从规则顺序自上而下的铁律：更精细、更确信的业务规则在前，宽泛兜底在后。对 Google AI 建议使用独立的策略组名（例如GOOGLE_AI），并在 rule-providers 或本地rules:中显式挂载 Google 后缀；避免与「国外影视」「泛国外」混在一起用高频测速乱跳。
# Example only — rename proxy groups; verify domains in your capture
rules:
- DOMAIN-SUFFIX,gemini.google.com,GOOGLE_AI
- DOMAIN-SUFFIX,accounts.google.com,GOOGLE_AI
- DOMAIN-SUFFIX,googleapis.com,GOOGLE_AI
- DOMAIN-SUFFIX,gstatic.com,GOOGLE_AI
# Optional: tighten google.com subsets if you capture concrete hostnames first
- DOMAIN-SUFFIX,google.com,GOOGLE_AI
- GEOIP,CN,DIRECT
- MATCH,FALLBACK_OR_PROXY宽窄取舍没有标准答案：DOMAIN-SUFFIX,google.com能显著降低遗漏的概率，但往往也会把全部 Google Web一起带走；若你希望「只有 AI 链路走这组节点」，需要先抓取更精确的子域清单，再分拆多条DOMAIN条目。这比复制一份所谓「AI 专用规则集」但从不验证命中，更接近工程上的诚实策略。
| 你看到的表象 | 更可能的网络分组问题 |
|---|---|
| 页面半加载、控制台网络请求大量失败 | 静态/CDN (gstatic 一类)与主业务域分叉；或CONTENT-TYPE为脚本/样式的请求走错出口 |
| OAuth 卡住或令牌刷新报错 | accounts.google.com链路未与同组 Google API同框；被关键字规则插队到直连 |
| 规则显示 PROXY，但 TLS 超时仍很多 | 更多是节点质量或对端限速；请配合TLS 日志专文检查 SNI 与抖动 |
| 仅 IDE 报错、浏览器 Gemini 没事 | 多半是TUN缺席或PROCESS-NAME补丁未覆盖次要进程；先做覆盖面再改域名 |
五、节点选择：降低「抖动切换」的伤害
当链路已经命中GOOGLE_AI这类策略组之后，体感仍主要取决于节点质量与切换策略是否过激。对 Gemini 一类的长连与流式任务，我们更关心低丢包与小抖动，而非表面上的几十毫秒 ping。实践里常见误区是：把整个机场的最大带宽节点全部塞进url-test，却使用过短的 interval与过窄的 tolerance，导致会话被频繁切换到另一侧 ASN的出口上。
- 为 Google AI 单独建
fallback而非强行负载均衡：在长会话工具里，一致性往往比瞬时延迟更重要。 - 调高容忍度或降低测频：减少「差一点就换下一个」的毛刺抖动；具体阈值以你节点的真实波动为准。
- 跨区域池混用要谨慎：若账号或服务策略对常驻区域敏感，请避免同一天内长期在多个大洲的出口间来回横跳。
- 失败分桶：把「打不开任何站」的大规模故障与「仅 Google AI 链路异常」区分开来；后者更值得怀疑SNI/DNS与对端限速。
若要在局域网里共享同一台代理机，也需确保旁路设备的流量不会在局域网策略上绕开 Google 后缀规则；这类「只有主机能用」的戏码请参考 《混合端口与局域网》中的入站与安全边界条款，不要随意向公网放行混合端口。
六、DNS、Fake-IP、SNI 与本站专文对齐
当你已经开了 TUN、配了后缀规则，却仍看到Fatali/o timeout一类的底层错误时，下一轮排查应沉入 DNS/Fake-IP与TCP/TLS层：Fake-IP 过滤不完整、IPv6 旁路分叉、或嗅探链路未命中你以为的主机名，都会造成「看起来像规则没错，但会话层仍断裂」的假舒适区。
- 先读本站 《Fake-IP 与 DNS 排查》，逐项对照：fallback、sniff与
DOMAIN-SUFFIX,googleapis.com条目是否真的能落在Gemini 实际访问名上。 - 若握手阶段特别慢或直接超时，再配合 《TLS handshake timeout：节点与 SNI》：SNI是否与规则使用的主机名一致，是否混入MitM 或企业网关干扰。
- 当你在 Windows上首次引入 TUN 时，如出现局域网整体异常或UWP 特例，请同步阅读 《Windows 下 TUN 与防火墙疑难》，避免因NIC 度量或防火墙条目误伤
SYSTEM链路。 - 若仍怀疑中国大陆侧站点被错误送往海外隧道，可把 GEOIP-CN与局域网段规则放在合适深度，避免出现「本该直连的工作流量被顺带拖 overseas」的工程事故。
七、延伸阅读与热点行并列对照
若你的日常开发栈仍以 OpenAI/Anthropic为主轴，可把本站相关专文视作不同厂商主机名拓扑的索引页：ChatGPT 线见 《ChatGPT 与 OpenAI 分流》；Cursor 侧的 GitHub/扩展模型组合见 《Cursor/GitHub：超时链路排查》。Gemini × Antigravity这道题的关键不是堆砌「AI IDE」关键词，而是在TUN × Google API × 会话一致性这三个交叉点上做对工程取舍。
常见问题
问：TUN 是否一定比手动配环境变量高明？
答：不是价值判断，而是维护成本。环境变量对部分 CLI 很好用，但一旦涉及多窗体 IDE、扩展宿主与子进程并行，你很难保证所有路径复用同一HTTPS_PROXY语义。TUN以系统路由表的方式收束分叉，但需要UAC/防火墙/VPN共驻下的额外耐心。
问：DNS已经走代理侧解析，为什么还要关心 Fake-IP？
答：因为它们解决的是不同层面的问题：DNS回答「这个名字最后落在哪些 IP」，而 Fake-IP 与 sniff 链路决定哪些连接能回到规则引擎按域名决策。缺一环时，很容易出现看起来像命中了后缀规则，实际握手目标并不一致的幻影现象。
八、小结
把Google Antigravity这类 Gemini驱动的 Agent IDE放进自家网络拓扑时，最省时间的路线不是「再找一份玄学节点」，而是：用 Clash TUN 先解决覆盖盲区，再用规则分流把 Google OAuth、CDN 分发与*.googleapis.com后缀收敛到一致的节点选择桶里，最后用 DNS/Fake-IP/TLS三章专文自上而下对照。VPN 式「一键全开」看似省事，却常常在 IDE 与工作区链路里埋下「半直连 + 乱跳出口」的长期雷；而不少脚本型小工具既没有可持续的规则维护，也缺乏对不同内核与桌面沙箱组合的尊重，一旦跨平台切换到 Windows/macOS/Linux 的另一端，就不得不推倒重来。Clash系生态把Mihomo 内核、rule-providers 与多端 GUI放在更接近工程现实的位置：你可以把热点厂牌（Gemini/OpenAI/GitHub/Microsoft）拆成各自策略线与独立健康检查分组，再配合 TUN 把 IDE 侧的细碎出站统一纳入同一可视化日志里完成迭代。立即免费下载 Clash，开启流畅上网新体验。