Antigravity 这类 IDE 的流量为何「一环卡住全盘转圈」

当你在浏览器里单独打开 Gemini 网页时，只要系统代理指向本机 Clash，绝大多数 HTTPS 会话都会落在同一套域名分流决策里：看得见命中规则，排障也相对线性。Google Antigravity 把代码编辑、Agent 编排、内嵌 Chromium 视图（登录与文档跳转）、以及内置终端打包成一个桌面进程树——这意味着不同子模块可能对代理的敏感度完全不同：有的走操作系统网络栈与会话 Cookie，有的发起独立的 TLS 的长连接；一旦你把规则写成「只代理 googleapis，其余直连」，就很容易出现半链路代理：OAuth 窗口空白而主界面看似在线，或 Gemini 已开始握手但前端脚本从 CDN 拉到一半超时。

用户最常误判的点，是把症状归因于「模型慢」或「节点劣质」，从而在订阅之间来回切换。API 超时若是间歇性的，多半是某一主机名漏匹配或 DNS 漂移；若是稳定的空白登录页，多半是OAuth 依赖的账号域或静态脚本走了不合预期的路径。桌面 IDE 场景的共通写法，可参考 Cursor 登录与 AI 超时 一文里关于系统代理与连接链路的讨论；本篇把域名层面补到与 Google Antigravity、Gemini 与 Google API 强相关的一组后缀。

ℹ 先建立三个事实：其一，连接日志里与失败同时刻出现的主机名列表是否齐全；其二，这些主机是否命中同一策略组；其三，DNS 解析是否在 Clash 侧与路由决策对齐。三项里任意一项含糊，就不要急着替换节点供应商。

域名地图：OAuth、antigravity.google、Gemini API、CDN

实务排障推荐「按链路拆分」，再把拆分结果映射到域名分流条目：账号登录通常集中在 accounts.google.com、oauth2.googleapis.com，并可能牵涉 One Tap、设备校验等附加主机（以连接日志为准）。产品前端与门户往往落在 antigravity.google 这一Google Antigravity品牌域及其子路径，用于落地页、下载或状态说明；版本迭代后也可能增加新的子域，不要用死记清单代替日志复核。Gemini 推理/SDK 默认常见主机包含 generativelanguage.googleapis.com，也可能落到其它 *.googleapis.com（取决于客户端版本与区域）；若你在组织内接入 Vertex，还会出现额外的 Google Cloud API 主机名——可把那条链路放进单独的「GCP」分组以免干扰个人开发者最小集合。

CDN 侧务必纳入同一策略意图：gstatic.com、www.gstatic.com、ssl.gstatic.com，加上 fonts.googleapis.com、fonts.gstatic.com，以及常被忽略的 googleusercontent.com、storage.googleapis.com（用于托管资源或大文件分片时）。它们不是「可有可无的加速域名」，而是IDE 前端能否完成渲染的前提；与 Google API 分流不一致时，界面会表现为无限加载或 spinner，与API 超时难以肉眼区分。

OAuth 与账号栈：内置浏览器并不等于跟随系统代理

OAuth 的体验链路很长：Google 账号站点加载脚本 → 令牌端点交换授权码 → 回调本地环回端口或由 IDE 注册的自定义 scheme → IDE 进程读取令牌后继续调用 Gemini。任意一段 HTTPS 请求在你这边直连失败，浏览器窗口都会停在空白或旋转图标上。Electron/Chromium 系桌面壳有时会读取系统代理，但在版本差异、沙箱与企业 MDM 约束下也可能偏离预期；这便是为何仅靠「浏览器能上 Google」不足以证明 IDE 登录没问题。

更稳妥的工程做法是：优先使用 TUN把整机三层流量接入 Clash / Mihomo，或在支持进程分发的内核里为 IDE 可执行文件单独指定策略，使内置 OAuth 视图与后续 Google API 调用天然走同一决策树；若坚持用系统代理，请打开连接日志核对 accounts.google.com 与 oauth2.googleapis.com 是否真的经过本机监听端口。常见问题 中关于代理模式切换的条目，可作为你改 TUN 前的安全核对表。

若你处于公司设备禁止个人账户 OAuth 的策略之下，应在合规前提下改用组织颁发的身份——本文仅描述路由层如何把域名分流写一致，不鼓励绕过单位安全策略。

Gemini 推理与 Google API：长连接与上传更要同一出口

Gemini 在 IDE 场景往往是连续对话 + 代码上下文上传，会话可能比单次 REST 调用更长；节点若对 HTTP/2、gRPC-Web、WebSocket（具体以客户端实现为准）支持不完整，也会在日志里落成API 超时或 RST。请先确认域名分流无误，再看传输层：当 generativelanguage.googleapis.com 与相关的 *.googleapis.com 已稳定命中你的 GOOGLE_ANTIGRAVITY（示例名）策略组后，再评估节点地区的 RTT、上行带宽与协议特征。

若你同时使用 Gemini CLI 做批处理脚本，可把命令行环境与 IDE 共用同一规则集；实现细节可参考 Gemini CLI 与 Google AI 终端分流，重点是把终端环境变量或 TUN 与 IDE 对齐，避免出现「IDE 能用、CLI 超时」或相反的割裂。

CDN 与前端静态资源：为什么必须跟 API 并列分流

IDE 的前端并非单一 HTML：图标、wasm、chunks、telemetry 配置片段都可能从不同CDN主机加载。域名分流如果只写了 API，而让静态资源落在 MATCH 直连路径上，在用户侧 DNS 污染或跨境链路抖动时就会触发间歇性 spinner。这也是为什么我们建议把 CDN 后缀与 OAuth、Google API 放进同一可视分组：不是为了「多加几条看起来很专业的规则」，而是为了消除路径分叉带来的不确定性。

Mac 原生Gemini客户端的经验同样适用：Gemini Mac 应用登录转圈 一文强调了 googleapis 与 gstatic 并列的重要性；Antigravity 作为另一类桌面壳，方法论一致，只要额外补上你在日志里看到的 antigravity.google 及相关子域即可。

规则示例：DOMAIN-SUFFIX 与策略组命名

下列 YAML 片段仅供说明策略意图并列关系：策略组名、端口、订阅源需替换为你正在使用的 GUI（Verge、mihomo-party 等）生成的真实名称；中国大陆流量仍可直连。系统化的规则优先级写法见 规则分流最佳实践。

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,accounts.google.com,GOOGLE_ANTIGRAVITY
  - DOMAIN-SUFFIX,oauth2.googleapis.com,GOOGLE_ANTIGRAVITY
  - DOMAIN-SUFFIX,antigravity.google,GOOGLE_ANTIGRAVITY
  - DOMAIN-SUFFIX,googleapis.com,GOOGLE_ANTIGRAVITY
  - DOMAIN-SUFFIX,gstatic.com,GOOGLE_ANTIGRAVITY
  - DOMAIN-SUFFIX,googleusercontent.com,GOOGLE_ANTIGRAVITY
  - DOMAIN-SUFFIX,fonts.googleapis.com,GOOGLE_ANTIGRAVITY
  - DOMAIN-SUFFIX,fonts.gstatic.com,GOOGLE_ANTIGRAVITY
  - DOMAIN-SUFFIX,storage.googleapis.com,GOOGLE_ANTIGRAVITY
  - DOMAIN-SUFFIX,ai.google.dev,GOOGLE_ANTIGRAVITY
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

MATCH,DIRECT 只是一种兜底写法示意：若你的配置文件默认「全局列表代理」，请改为与之匹配的兜底策略；关键是新增 Google 子域时不要静默落入与你设想相反的 outbound。TLS、握手失败类报错请对照 连接日志里的 timeout 与 TLS 拆解。

系统代理、TUN、内置终端：三条链路如何对齐

系统代理路线适合快速验证：把 HTTP/HTTPS 代理指到 Clash mixed-port，确认 IDE 进程内的 OAuth 视图能否命中策略；缺点是某些子进程或 Helper 工具可能仍直连。TUN 路线适合追求确定性：三层接管后，内置终端里跑的 git、npm、语言服务器下载器更容易与图形界面共用分流逻辑；代价是与第三方 VPN、虚拟网卡优先级冲突的概率上升，部署前建议阅读 TUN 模式深度解析。

若你只给内置终端导出 HTTPS_PROXY，却忘记图形界面 OAuth，依然会出现半链路代理——这也是为什么我们更强调「要么整机 TUN，要么分段核验每条链路」。需要为本机 mixed-port 写环境变量模板时，可参考 Docker 与终端 mixed-port 中的端口写法，再把 IDE 外部终端 Profile 一并同步。

DNS、fake-ip、嗅探与规则顺序

DNS 仍是高频翻车点：fake-ip 模式下若过滤域名遗漏，日志里的主机解析会与真实路由不一致；嗅探（sniffer）若配置过激，也可能把某些 HTTPS 会话误判。域名分流写得再漂亮，只要解析抢先返回污染地址，用户在 IDE 里看到的仍是API 超时或 TLS 报错。规则顺序上建议：局域网与大陆直连靠前 → Google Antigravity / Gemini 细分条目紧随其后 → 宽泛拦截或广告规则谨慎前置，以免无声丢弃 OAuth 预备请求。

临时排障时可关闭「多套 DNS 并行」：让操作系统与 Clash 询问同一上游，更容易对照「解析」与「出站」两步是否闭环。

连接日志：把 API 超时拆成主机名级结论

建议在失败发生的同一分钟内导出三段信息：时间戳、完整主机名、命中规则名与 outbound。若你看到 generativelanguage.googleapis.com 走了代理而 oauth2.googleapis.com 直连超时，就应回头改域名分流而不是盲目换成所谓「更低延迟」的节点；若全部主机命中同一策略却仍超时，再检查节点对大上行与长寿命连接的限制，以及本机时钟漂移导致的证书校验失败。

更新通道若指向第三方 CDN（例如软件镜像站），应与Google API分开观测：把那些域名记录下来单独分组，避免把「下载更新失败」误判为Gemini服务宕机。

常见问题（正文精炼版）

是否必须把整条 google.com 后缀送进代理？不推荐一刀切：DOMAIN-SUFFIX,google.com 容易把你常用的搜索、Workspace、Photos 一并送去境外节点；更稳妥是用日志列出 IDE 切实访问的最小集合，再按需扩充。

OAuth 成功后模型仍超时怎么办？回到CDN是否与 Google API同事走同一策略组；再看日志里是否存在被 MATCH 误直连的新子域；最后评估节点协议与 QUIC 兼容性。

Mihomo 与经典 Clash Premium 差别会影响本文吗？内核特性命名不同，但域名分流思想不变：关键是远程规则集更新通道不要被循环代理阻断，以免清单 stale。

⚠ 合规提示：请遵守所在地法律法规与 Google 服务条款。本文仅描述路由与 DNS 层面的技术思路，不鼓励未授权访问、绕过组织安全策略或任何违法用途。

自检清单

  1. 确认有权在当前网络使用 Clash/Mihomo 与目标 Google 服务。
  2. 选定系统代理或 TUN为主路径，避免多条链路互相打架。
  3. 用连接日志列出 IDE 登录与推理时段的全部主机名样本。
  4. 核对 OAuth、antigravity.google、Gemini Google API、CDN 后缀命中同一策略组。
  5. 审视规则优先级与国内直连条目是否误抢匹配。
  6. 校验 DNS / fake-ip / 嗅探是否引入解析与路由错位。
  7. 排除本地时钟、证书存储与企业 MITM 干扰。
  8. 本地链路确认无误后，再评估节点质量与官方状态页。

结语

Google Antigravity 与 Gemini 组合的痛点，往往不是「某一个超大 IP」，而是多条主机名在同一 IDE 会话里串联：任意CDN脚本慢、任意OAuth握手失败、任意 Google API长连接被重置，都会在 UI 层收敛成同一种转圈体验。把域名分流写成可读、可增量维护的一组后缀，并用连接日志验证策略意图一致，是比反复重装 IDE 更有效的路径。

「一键全局 VPN」类工具表面上省事，却很少暴露主机级命中细节；当你遇到API 超时与会话重置交织时，很难判断究竟是链路问题还是纯粹的业务限速。Clash 生态的规则透明度更适合开发者自助排障；其中 Clash V.CORE 在保持与现代 Mihomo 内核兼容的同时，侧重把策略编辑与连接观测放在同一习惯用法里，更适合长期维护一份涵盖 antigravity.google、账号域与 Gemini API 的分组清单。

→ 前往下载页获取 Clash V.CORE，把 Antigravity 登录、推理与更新的出站确定性握在自己定义的分流规则里，而不是交给无数次无效重启。