一、為什麼 Agent IDE 特別像「總逾時」
當你在 Agent IDE 裡啟用代理、雲端索引或與 Gemini 互動時，底層通常不是單一 HTTP 請求，而是多條平行連線：登入狀態與同意條款頁面走瀏覽器殼層、開發者工具與延伸模組可能再開額外通道；同時，模型與工具呼叫會落到 Google API（常見於 googleapis.com 子域，實際主機名以官方文件與你環境的連線為準）。只要其中一條仍直連、另一條走代理，或不同請求被前置規則送去不同國家／ASN 的出口，上層 UI 往往只顯示「轉圈中斷」「Request timeout」之類的統稱，讓使用者以為整套服務不可用。
這種「表面逾時」與單純節點塞車不同：後者多半與頻寬或丟包有關，前者更像連線分裂。例如 OAuth 流程卡在 redirect、靜態腳本從 gstatic.com 載入失敗，或 gRPC／HTTP2 被不支援的中介節點拆壞，都會讓 Agent 行為看起來斷斷續續。若再把瀏覽器的成功經驗直接類推到 IDE，更容易忽略「IDE 行程是否吃到系統代理」這個根本問題。
二、Clash TUN 與系統代理的取捨
Clash TUN（虛擬網卡、作業系統層轉發）的核心價值，是把「不一定遵守系統 HTTP 代理」的程式也納進同一條規則鏈。對 Google Antigravity 這類桌面殼層而言，只開系統代理時，常見現象是：瀏覽器測試正常、IDE 內建網路面板卻仍顯示失敗；或因為某些子行程以不同權限啟動，讀不到你在客戶端裡勾選的全域設定。當你改為啟用 TUN，只要路由表與防火牆沒有被企業策略鎖死，較有機會讓 gRPC、長連線與背景同步一併經過 Mihomo／Clash 核心，再用 規則分流把 Google API 與一般上網拆開。
當然，TUN 不是萬靈丹：若組織裝置禁止虛擬網卡、或有其他 VPN 搶佔路由，仍需改用應用程式內代理、透明閘道或分流路由器。此時更要依日誌確認流量是否真的進到核心，而不是假設「開了客戶端就等於全部代理」。初次設定可參考站內 Clash Verge TUN 入門（macOS） 的流程，把 DNS、開機權限與允許清單一次整理好。
HTTP(S)_PROXY；但以 Agent 場景來說，長期仍建議把網路一致性收斂到 TUN 或路由層，否則規則寫對了也會遇到「半套分流」。
三、Google／Gemini 網域分流怎麼寫
與純瀏覽器看 gemini.google.com 不同，Agent IDE 往往還會碰到 AI Studio 類端點、管理後台、錯誤回報與字型／分析主機；因此規則分流建議沿用「Google 生態後綴包」的思路，而不是只 match 單一關鍵字。站內 Gemini 與 Google API 規則專文 已整理 google.com、googleapis.com、gstatic.com、googleusercontent.com 等常見後綴與 ChatGPT／OpenAI 網域的差異；本文在此之上，特別強調IDE 多連線與 Clash TUN 的組合：先把流量收進核心，再把 Google 區塊放在明確位置，避免被訂閱內建的寬鬆規則提前截胡。
實務上可將「Google／Gemini／Vertex／開發者入口」視為獨立規則區塊，與 OpenAI、Anthropic、Copilot 專線並列。當你發現 Antigravity 與瀏覽器 Gemini 表現不一致時，第一步不是改模型參數，而是用開發者工具或日誌列出失敗請求的完整網域名稱，把缺口補進 DOMAIN-SUFFIX 類規則；第二步才換 節點選擇，以免把規則問題誤判成節點品質。
| 症狀外觀 | 較可能的路由／設定原因 |
|---|---|
| 登入或 OAuth 迴圈 | accounts.google.com、同意頁與本體 API 出口不一致；或瀏覽器與 IDE 行程代理不同步 |
| 介面骨架出現但內容空白 | 靜態資源（gstatic.com 等）仍直連；被 GEOIP 前置規則帶去錯誤策略 |
| 工具呼叫／模型回應偶發中斷 | googleapis.com 長連線走擁擠節點；HTTP2／gRPC 與節點特性不相容 |
四、規則範例與訂閱插入順序
以下示例採常見 Clash／Mihomo 寫法，請將 PROXY 替換為你設定檔中的策略組名稱，並依訂閱實際內容調整插入點。請務必以 DevTools 與日誌補齊你環境中多出來的主機名，不要機械式複製：
若訂閱已含「Google」類清單，仍要檢查你的自訂段落是否被插在後面、或被大範圍 GEOIP 與 MATCH 淹沒。規則分流的本質是順序博弈：Antigravity 這類產品迭代快，官方可能新增子域；維護上寧可先記錄可復現的連線捕捉，再決定要不要把臨時 DOMAIN 收斂成 DOMAIN-SUFFIX。
需要複習語法與模式差異時，可讀 本站設定說明，對照 fake-ip、redir-port、tun 等段落，避免只看規則卻忽略 DNS 與核心的耦合。
五、節點選擇與策略組實務
把 Google 後綴指到同一 proxy-group 後，體感仍取決於節點選擇。Agent IDE 的互動與背景索引往往同時存在短請求與長連線，建議獨立一組延遲較低、切換較克制的 url-test 或備援清晰的 fallback，不要把「寫程式用的出口」跟大量下載、4K 串流塞在同一個超載節點。頻繁自動切換節點也可能讓服務端觀察到會話跳區，進而觸發風控；實務上寧可固定兩三個穩定出口做人工對照，也不要讓 url-test 每幾秒就換線。
地區選擇請以你的帳務、合約與官方政策為準；頻繁跨區嘗試不但不一定能解決逾時，還可能讓問題更難排查。若你已鎖後綴仍遇到握手階段失敗，優先在同一策略組內更換節點供應商，而不是把規則改來改去；很多 TLS handshake timeout 其實是特定節點對 SNI 或 HTTP2 的處理不完整，與 Google 本身無關。
六、DNS、fake-ip 與日誌驗證
完成 TUN 與 規則分流後，建議按下列順序自檢，並把結果寫進你的個人知識庫，以便下次產品更新時快速比對：
- IDE／瀏覽器開發者工具的網路面板：篩選失敗請求，記錄完整網域名稱與狀態碼，不要只看「API 失敗」摘要。
- Clash 日誌：確認命中規則的名稱、策略組與實際出站；若顯示直連，回頭檢查是否為前程式繞過 TUN。
- 本機解析：對
googleapis.com下的實際主機查解析；若啟用 fake-ip，對照核心日志中的真實目的地，避免「規則覺得走了代理、實際卻解析不一致」。 - 命令列：以
curl -v測試可疑主機，觀察 TLS 在哪一步停下；若握手即失敗，多半要先處理路徑與 SNI，而不是重裝 IDE。
若你同時啟用瀏覽器 DoH、企業根憑證或本地安全軟體，也可能出現「只攔截部分流程」的狀況。此時要先釐清公司政策允許的調整範圍，再決定是否把 DoH 收斂到核心上游，而不是硬關所有安全功能。
七、和 Cursor、Copilot、Prism 文章的關係
本站已有多篇「熱點 IDE × 模型 API」題材，例如 Cursor 與 GitHub 分流、GitHub Copilot 與 OpenAI Prism；方法論高度相似：先把實際主機名蒐集完整，再談節點與策略。差別在於網域族完全不同——Copilot 重 GitHub／Microsoft 曲線，Prism 重 OpenAI 生態，Google Antigravity 則應回到本文與 Gemini 專文的 Google 後綴包。混用規則最容易造成「修 A 壞 B」，維護上建議在設定檔用註解區隔區塊，必要時以 mixin 覆蓋訂閱更新。
若你已在 Cursor 場景習慣「系統代理＋精準 DOMAIN」，在遇到 Antigravity 時要警覺：後者的背景連線更雜、對 gRPC 更敏感，往往更需要 Clash TUN 把路徑收斂。你可以把 Cursor 文章當成操作流程範本，但不要把其中的 GitHub 主機名照抄到 Google 場景。
八、RULE 順序與避免誤傷
Clash 規則採首次命中，RULE 順序錯誤會讓後段針對 Google API 的精準條目永遠排不上。實務上請將服務商相關 DOMAIN-SUFFIX 置於寬鬆 GEOIP、大段 IP-CIDR 與最終 MATCH 之前；同時避免過寬的 DOMAIN-KEYWORD,google 之類寫法，以免把無關站點一併送去昂積節點。訂閱一鍵更新後，也要回頭看自訂段落是否被插入到錯誤深度。
另一個誤區是把所有「境外站」丟進單一爆量節點：Gemini 與 Agent IDE 需要低延遲的互動尾端，與下載、BT、家庭串流共享出口時，最容易出現排隊逾時。依用途拆分策略組，通常比無上限加頻寬更能改善體感。
九、常見問題
為什麼 Google Antigravity 或 Gemini 相關功能在 IDE 裡特別容易逾時？
因為同時存在多條連線與協定；任一分裂出口、或 gRPC／HTTP2 被節點錯誤處理，都會在 UI 上放大成「總逾時」。請先用日誌確認是不是只有 Google API 子集失敗。
只有系統代理不夠嗎？一定要開 Clash TUN 嗎？
不一定。但若程式未遵循系統代理設定、或環境裡還有分 App VPN，系統代理很難收攏所有流量。TUN 是 Agent 場景的保險絲；不能開時，就改以程式內代理或路由層方案補位。
規則已寫 googleapis.com，為什麼還會 TLS handshake 失敗？
常見原因包括前置規則提前命中、DNS／fake-ip 不一致、或節點對 SNI／長連線支援不佳。請在同一策略組內更換幾個出口對照，不要先大改規則。
和站內其他 Google／AI 工具文章重疊嗎？
Gemini 通用分流請見專文；本文補上 Agent IDE 與 Clash TUN 視角。IDE 類文章可以共享方法論，但網域清單請分開維護。
十、合規提醒
請遵守 Google 與相關產品服務條款、適用地區法規與帳號安全要求。本文僅提供一般網路一致性設定思路，不保證特定地區、帳戶型態或企業網路政策下的可用性；若仍無法使用，請依官方支援管道排查帳務、API 專案狀態與組織合規限制。請勿將代理設定用於未經授權的資料存取或繞過雇主／學校規範。
十一、小結
面對 Google Antigravity 與 Gemini 在 Agent IDE 中頻繁出現的請求逾時、TLS／連線失敗，網路層首要任務是把多連線分裂收起來：能用就開啟 Clash TUN，再在 規則分流里為 Google API 與常見 Google 後綴建立獨立區塊，並用日誌驗證命中。與站內 Gemini 專文相比，本文特別強調 IDE 殼層與 gRPC／長連線的現實；與 Cursor、Copilot、Prism 相比，方法可借鏡但網域清單不可混用。
市面上不少一鍵式工具強調「連上就好」，卻難以還原哪條規則命中、更難長期維護多條 IDE 專線；一旦遇到訂閱更新或企業網路變動，只能反覆重裝。相較之下，Clash 生態在規則可讀性、核心替換與跨平台客戶端上，較能把 Google Antigravity 需要的後綴、策略組與 DNS 方案整理成可版本控管的設定，並以同一套方法延展到其他模型供應商；對常換工具鏈的開發者來說，這種結構化的規則分流通常比單純切換節點更能穩定日常開發節奏。