為什麼看起來像「轉圈」，其實是混合路由與 API 逾時

許多讀者形容 Google Antigravity 或搭載 Gemini 的 IDE「登入得了，但模型永遠在載入」「更新檢查卡住」「內建預覽能打開，送出指令後沒回應」。這類半可用狀態，網路層往往對應到：部分 TCP 連線成功握手，但某條關鍵請求在錯誤的路由上長時間等不到封包，應用層就統一呈現轉圈或 API 逾時。

Google API（例如常見於 *.googleapis.com 底下的生成式語言端點，實際路徑與主機名請以官方文件為準）與 CDN／靜態託管（例如 gstatic.com、部分 googleusercontent.com 場景）通常不同後綴。OAuth 與帳號流程又多集中在 accounts.google.com、oauth2.googleapis.com 這類位於 google.com／googleapis.com 樹下的名稱。Clash 規則若只命中其中之一，就會出現「登入頁很快、推理請求永遠 pending」的錯位——這不是玄學，而是網域分流不完整的典型徵兆。

另一個誤判是把問題等同於「節點壞了」。節點品質當然重要，但若規則把一半請求送去代理、另一半仍直連到抖動嚴重的國際路由，體感仍會像節點問題。更有效率的作法，是先用連線紀錄回答三個問題：這條請求的主機名是什麼？命中哪條規則？策略組送到哪個出口？把這三件事對齊後，再決定要不要換節點。

ℹ 心智模型：Antigravity 這類產品像「同時開了好幾個獨立 App」崁在同一個外殼裡：帳號與 OAuth 是一套鏈路，模型推理與工具呼叫是另一套，UI 資源又是第三套。任何一套走到不一致的策略，最終都會以轉圈或逾時呈現在你面前。

和 Gemini CLI／Gemini Mac 題材差在哪：IDE、OAuth 與多鏈路並行

本站已有偏終端機與原生 App 的專題，例如 Gemini CLI 與 Google AI CDN 分流、Gemini Mac 原生應用登入；它們的流量輪廓與桌面 IDE仍不相同：CLI 多半集中在少數 API 主機名與更新域名；Mac App 常見登入與套件更新路徑；而 Antigravity 這類 IDE 還疊了編輯器插件載入、內嵌瀏覽元件、整合終端機與背景同步，同一時間開啟的子網域種類通常更多。

也因此：把 CLI 文章的規則原封不動複製過來，往往仍然漏網域。本篇刻意保留與 Gemini／AI Studio 通用分流 相近的後綴骨架（googleapis.com、gstatic.com、google.dev），再補上 IDE 場景裡常見的OAuth／長連線／多進程討論；若要挑客戶端，仍可回頭看 如何選擇適合自己的 Clash 客戶端。

四條鏈路：OAuth、Gemini／Google API、CDN、gRPC／長連線

實務排障建議你把流量分成四組思考，並分別在 Clash 日誌裡確認它們是否命中同一策略組。

四組鏈路裡只要有一組仍在錯誤的預設策略（例如命中 MATCH,DIRECT 卻走了品質不佳的出境），你就會看到「偶發可用」的假象：快取命中時看似正常，換個模型或切換工作區立刻破功。

策略組與後綴打包：googleapis、gstatic、google.dev、產品網域

建議在設定檔裡宣告一個語義清楚的策略組（示例名稱 GOOGLE_AGENT_IDE，可自訂），先把與 Google Cloud／AI 開發體驗高度相關、且後綴穩定的條目映射過去：

google.com 整段後綴是雙面刃：DOMAIN-SUFFIX,google.com,GOOGLE_AGENT_IDE 能一把抓住搜尋、郵件與其他子產品，策略簡單但影響面極大。較折衷作法是以連線紀錄先列出具體主機名，例如 DOMAIN,accounts.google.com,GOOGLE_AGENT_IDE，再視需要逐步擴張；等到你確認「日常 Google 服務也必须同一出口才穩」，再考虑寬後綴。

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,googleapis.com,GOOGLE_AGENT_IDE
  - DOMAIN-SUFFIX,gstatic.com,GOOGLE_AGENT_IDE
  - DOMAIN-SUFFIX,google.dev,GOOGLE_AGENT_IDE
  - DOMAIN,accounts.google.com,GOOGLE_AGENT_IDE
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

上述片段僅示意規則集合方向；策略組名稱、規則集引用方式與訂閱結構請依你的 Clash／Mihomo 發行版調整。若你使用遠端規則集，仍應定期核對規則順序是否被覆蓋，避免本地精細條目被上游寬規則遮掩。

antigravity.google 與產品相關主機名：用日誌迭代而非猜

搜尋與社群討論常出現 antigravity.google 這類產品入口或說明網域；可能與下載、遙測、文件或身分驗證跳轉有關，且會隨版本調整。這類非通用後綴不適合只靠臆測寫死一長串；較可靠流程是：在重現「轉圈」時開啟連線紀錄，把當下實際請求的主機名排序去重，將排名前幾的未知網域補成 DOMAIN 或 DOMAIN-SUFFIX 規則。

同時請分辨「官方網域」與「第三方套件／外掛」網域：IDE 生態裡常有 GitHub、npm registry、語言伺服器雲端後端等非 Google 主機名；它們若被錯誤規則送去錯誤出口，也會拖慢整體體驗。別把問題過度聚焦在 Google，而忽略了並行的第二供應鏈。

DNS、fake-ip、嗅探：別讓解析結果與規則決策打架

Clash 族客戶端常用的 fake-ip 模式，會讓應用先拿到本機段的「假位址」，再由內核側完成真實解析。若某些網域未進規則集或嗅探失敗，可能出現解析看似成功、連線卻一直 dial timeout 的矛盾現象。對 Antigravity／Gemini 這類會頻繁跳轉 OAuth 的場景，DNS 路徑不一致時，最常見的是「登入視窗正常，回到 IDE 主程式後請求全 pending」。

實務上請同步檢查：nameserver 是否混用 DoH／系統 DNS／路由器轉發；是否有多個 VPN 或「網路優化」工具改寫 DNS；fake-ip-filter 是否涵蓋區網與必要網域。更多概念可對照 DNS、fallback 與 fake-ip 過濾 與站內 常見問題。

規則優先序：寬規則、GEOIP 與 MATCH 怎麼擋住細粒度規則

Clash 規則自上而下命中即停。若你把 GEOIP,CN,DIRECT 或某條過寬的網域關鍵詞放在業務規則之前，就可能出現「我以為 googleapis 走代理，實際被更早的規則截胡」的情況。建議把Google agent IDE 相關細粒度規則放在不會被誤傷的位置，並定期用日誌確認第一命中規則名稱。

MATCH 即預設路由：對多數讀者 MATCH,DIRECT 合理，但若你的網路對特定區域極不穩定，而又長期漏規則，就會表現成間歇性逾時。此時應優先補齊網域覆蓋與規則集更新，而不是長期把全域預設改成代理，以免國內業務延遲全面上升。結構化維護可一併參考 規則分流最佳實踐。

系統代理 vs TUN：IDE、內嵌 Chromium、整合終端機誰沒進 Clash

許多 Electron／Chromium 系應用程式對系統代理遵循程度不一：IDE 主視窗可能走代理，內嵌瀏覽元件卻以獨立設定連線；整合終端機裡的 curl、語言 SDK、套件管理器又可能完全忽略系統代理。結果就是同一台電腦上「瀏覽器測試 Google 沒問題，IDE 裡仍然 API 逾時」。

這種縫隙通常有三種修法：（1）在環境變數顯式注入 HTTPS_PROXY／ALL_PROXY（需注意不同 Shell 與 GUI 啟動差異）；（2）啟用 TUN 透明接管系統流量（留意與公司 VPN、虛擬機橋接的相容）；（3）在 IDE 設定裡指定 HTTP／SOCKS 代理埠，確保與 Clash 開放的 inbound 一致。TUN 細節可延伸閱讀 TUN 模式深度解析 與 macOS TUN 設定。

訂閱更新與規則集：避免循環代理讓清單過期

一種隐蔽故障是：系統代理全局指向 Clash，导致拉取訂閱與規則集的請求也被錯誤二次代理或阻塞，清單長期停在舊版本，新域名永遠沒被收录。解法是为更新域名保留直連或可靠旁路，並定期確認規則集時間戳。細節可對照 訂閱管理與節點維護。

連線錯誤類型請搭配 從日誌讀懂 timeout 與 TLS，區分 dial 逾時、TLS 憑證問題與被 RST，避免無限換節點。

⚠ 合規提示：請遵守所在地法律法規與 Google 服務條款（含 Gemini、API、地區與用途限制），並遵守所屬組織的資訊安全政策。本文僅作路由與排錯技術說明，不鼓勵未經授權的存取或繞過安全管理。

排障清單：從現象對回主機名與命中規則

  1. 確認環境允許使用代理與存取相關 Google 服務。
  2. 校準系統時間，排除 TLS 與 OAuth token 相關誤判。
  3. 在 Clash 連線紀錄中，於 IDE 轉圈時段筛选目的地主機名，列出排名前若干。
  4. 核對 googleapis.com、gstatic.com、google.dev 是否一致命中預期策略組。
  5. 檢查 OAuth 相關 google.com 子域是否漏規則；必要时逐步加入精準 DOMAIN。
  6. 比對 IDE 主程式、內嵌瀏覽區塊、整合終端機三路徑是否都進入 Clash。
  7. 審查 DNS／fake-ip／嗅探設定與 VPN 疊加。
  8. 確認規則集與訂閱成功刷新，無循環代理。

若完成上述步驟後仍只在特定模型或特定工作區失敗，請優先懷疑非 Google 供應鏈網域（套件索引、LSP 後端、私有 registry），並在日誌裡單獨追蹤。

常見問題

為什麼登入成功後模型仍轉圈？

多半是 OAuth 鏈路已走代理，但後續對 generativelanguage.googleapis.com 或其他推理端點仍直連或命中不同策略，造成會話狀態無法完成後續 RPC。請用連線紀錄對照主機名。

我已經為 googleapis 寫了規則，為什麼還會逾時？

檢查是否有更早命中的寬規則、GEOIP、或代理鏈中的 UDP／HTTP2 相容問題；同時確認節點本身對長連線是否穩定，必要时更换線路或關閉不兼容的中繼。

TUN 會與公司 VPN 衝突嗎？

會。多個虛擬網卡與路由表修改工具並存時，優先級稍有不慎就會讓部分流量繞過 Clash。請閱讀發行版文件並在測試環境驗證，不要直接在受管控機器上強行疊加。

結語：把「一直轉」還原成可核對的連線證據

Google Antigravity 與 Gemini 在 IDE 场景下的痛點，多半不是單一「設定開關」能描述，而是多條鏈路是否在同一策略意圖下連續工作：OAuth、Google API、CDN 靜態與長連線缺一即會以轉圈呈現。Clash／Mihomo 的价值在于把這些拆解成可讀的規則與日誌，讓你能迭代域名清单，而不是把問題託付給運氣。

相較標榜「一鍵全局加速」但掩蓋命中細節的工具，可維護的網域分流在前後端並行、agent 管線愈來愈長的年代會更可預期：Google 調整子域或 CDN 時，你能快速補規則；業務流量與日常上網也能繼續分流而非綁死在同一出口。挑選連線紀錄清晰、規則編輯順手的客戶端，長期下來節省的時間通常遠高過一次性折腾。

許多泛用 VPN 客戶端雖能「整機出境」，却不易細緻區分 Google API 與一般視頻／社交流量；遇到 IDE 多進程與長連線時，也常缺乏足夠的規則可視化與命中追溯，排錯只能不停換節點。Clash V.CORE 一脉工具则围绕策略組、規則集與日誌構建，能把 Antigravity／Gemini 所需要的域名骨架固化成可版本控制的設定，並與本站既有的 Gemini、AI Studio、CLI 專題並存维护。

若你希望把 API 逾時從主觀感受變成可以截圖對照的連線證據，建議從「列出轉圈時段的 TOP 主機名」開始，再回頭調整規則優先序與代理模式。完成結論後，若想取得同款結構化工具鏈，歡迎前往本站下載頁取得 Clash V.CORE。

→ 立即免費下載 Clash，開啟流暢上網新體驗，用清楚的網域分流把 Antigravity、Gemini 與 Google API 的連線握在可核對的設定里。