Google Gemini CLI 與 AI Studio 總逾時？2026 年用 Clash 分流穩住命令列與網頁

為什麼 CLI、AI Studio 網頁與 API 會「一起逾時」

使用者體感上只有一個產品名稱，實際上卻是多條 HTTPS（與偶發的長連線／串流）並行：瀏覽器載入控制台與靜態資源、終端機行程向官方文件所載的 API 主機送請求、背景可能還有 OAuth／帳號與專案設定相關的子網域。當其中任一條命中錯誤的策略（該走穩定出口卻直連塞車，或該直連卻被寬泛規則送去境外商業節點），常見症狀就是統一的逾時敘述——因為 UI 與 CLI 都把責任歸給「上游沒回應」。

• 主機名分散：除了 aistudio.google.com，實際推理與管理流量可能落在 generativelanguage.googleapis.com 等 API 命名空間，與其他 Google 服務共用部分基礎建設但路由敏感並不相同。
• 長回應與串流：比單次 REST 更怕中途換出口；策略組若頻繁自動切換節點，體感會像「CLI 與網頁同時死掉」。
• 代理鏈分裂：Safari／Chrome 跟隨系統代理，終端機卻完全無視；只調瀏覽器規則時，CLI 仍會在錯誤路徑上重試至逾時。

與站內 DeepSeek／Gemini 合稿、OpenRouter 有什麼不同

DeepSeek 與 Gemini 分流處理的是「多供應商、多區域」的策略邊界拆分：哪些服務直連、哪些走代理。那條線適合宏觀盤點；但如果你目前的痛點就是 Google 官方開發者入口本身，還需要再往下鑽到CLI 行程＋網頁控制台＋ API 主機名三者的同時覆蓋，否則會出現「瀏覽器沒事、終端機全跪」這類一半修好的狀況。

另一方面，OpenRouter 類第三方統一閘道要把「閘道網域」與「多家上游 API」拆成兩組策略；Google 原生情境則更像「同一生態內多個邏輯端點」，規則命名上可用單一 PROXY_GEMINI_DEV 群組承載，但在 YAML 裡仍建議把網頁入口子網域與純 API 主機分成兩條 DOMAIN／RULE-SET 段落，方便日後依日誌微調，而不與整包 googleapis.com 粗暴綁死——太多其他服務共用該後綴，過寬匹配容易帶來副作用。

把主機名分桶：網頁入口、API、共用 Google 認證

實務上請以連線日誌為準：開啟 Clash 面板，分別在瀏覽器打開 AI Studio、在終端機用 Gemini CLI 送一個最小請求，把出現的 SNI／Host 抄下來再回填規則。下列分桶協助決定規則先後順序，而非替代實測：

症狀表：看起來像逾時，可能是 DNS 或規則順序

現象	較可能原因	優先動作
AI Studio 正常，CLI 全失敗	終端機未走系統代理或 TUN 未涵蓋該行程	啟用 TUN／核對環境變數；見下文「命令列與 TUN」
CLI 正常，網頁卡在登入或白屏	帳號與 OAuth 網域命中錯誤策略或遭阻擋清單誤傷	在日誌定位 accounts／oauth 主機並前置規則
首次請求極慢，之後略好	DNS 競態、fake-ip 與應用自建解析並存	閱讀 DNS 與 fake-ip 排查 並收斂解析入口

DNS 與 fake-ip：先讓解析與規則看見同一個世界

API 與控制台都是 TLS 密集場景：fake-ip 若與終端機或瀏覽器的另一套 DoH 並存，常出現「握手卡住像逾時」的假陽性。調校建議與站內其他 AI 路由文一致：

• 調試期暫時關閉瀏覽器獨立 DoH 或限縮到單一解析路徑，確認問題消失後再恢復隱私向設定。
• 海外出口組合搭配你信任的遠端 DNS；避免兩套 resolver 在同一台機器上無序競速。
• 所有自訂規則修改後，用連線紀錄同時確認「命中規則名稱」與「解析類型」（真實 IP／fake-ip）。

分流規則與策略組：讓「開發者出口」可命名、可迭代

最小可行 YAML 仍然遵循 Meta 系核心理念：高信心 DOMAIN／RULE-SET 置頂，寬鬆 GEOIP 或 MATCH 置底。下面片段僅示意，請把 PROXY_GEMINI_WEB／PROXY_GEMINI_API 換成你實際的 proxy-groups 名稱；兩者在實體節點池上可以相同，但分開命名能讓你哪天只在 API 側調整健康檢查時不必波及網頁控制台。

# Illustrative — verify hostnames in your Clash logs; avoid over-broad googleapis rules
rules:
  - DOMAIN-SUFFIX,aistudio.google.com,PROXY_GEMINI_WEB
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,PROXY_GEMINI_API
  - DOMAIN-SUFFIX,accounts.google.com,PROXY_GEMINI_WEB
  - DOMAIN-SUFFIX,oauth2.googleapis.com,PROXY_GEMINI_WEB
  # Optional: console for API key / quota pages
  - DOMAIN-SUFFIX,console.cloud.google.com,PROXY_GEMINI_WEB
  - GEOIP,CN,DIRECT
  - MATCH,PROXY_GEMINI_API

若你使用遠端規則集，請把上述段落放进本機覆寫並確認合併後順序仍優先於泛用廣告／追蹤封鎖表——後者偶爾會誤傷遙測或灰度開關網域，表現為「無限等待」。

節點選擇：長回答與串流要「穩」勝過測速畫面好看

Gemini API 與網頁端點在 2026 年仍是長連線敏感流量：自動 fallback 若過於積極，會在 chunked 回應中途換出口，體感即「CLI 與 AI Studio 輪流逾時」。挑節點時可優先考慮：

• 較少中途重置的線路，降低 TLS 會話在長回應期間被整段重negotiation 的機率。
• 拉長 url-test／fallback 間隔或暫時手動鎖定節點，對照 url-test 與 tolerance 調到對長回答友善的區間。
• 區域一致：帳號安全與部分 API 行為會與「短期內頻繁跨區」不相容，盡量在單一工作階段內固定地理出口。

命令列、TUN 與環境變數：別讓 CLI 成為漏網之魚

Gemini CLI 與各種 Node／Python 包裝工具往往不讀瀏覽器代理設定。若你已確認規則無誤仍逾時，請依序檢查：

1. TUN 模式是否開啟，並在 Rule 下驗證 CLI 行程已被核心攔截（對 Windows 可先完成 Clash for Windows 與 TUN 基線；macOS 參考 Clash Verge Rev）。
2. 若不能用 TUN，至少對照 終端機 HTTP／Git 代理，把 HTTPS_PROXY 等變數寫進正確的 shell 設定檔與整合式終端機外掛。
3. 與其他「CLI + MCP」場景可並讀 Claude Code 與 MCP 路由——概念互通，但 Google 端點集合不同，勿硬抄 YAML。

合規與使用邊界

請遵守所在地法規、網路使用政策與 Google 各產品條款；API 金鑰、專案額度與資料處理條款以官方文件為準。本文僅討論讀者對自有或獲授權裝置的路由與 DNS 設定，不提供任何規避服務條款或地區政策的指引。

常見問題

為什麼網頁與 CLI 會同時逾時？

多半是共用 DNS／TLS 路徑或策略組正在頻繁切換節點；請先在日誌確認 aistudio.google.com 與 API 主機是否命中同一策略，並暫時鎖定節點交叉驗證。

只有 CLI 逾時，瀏覽器完全正常？

幾乎可斷言為終端機代理鏈未接上。優先啟用 TUN 或補齊 proxy 環境變數，再回頭看規則。

登入成功但無法建立工作階段？

檢查 accounts.google.com、oauth2.googleapis.com 等是否被錯誤分類或遭清單誤擋；把它們前置到與 AI Studio 相同的穩定出口通常能排除「權杖拿一半」的狀況。

實務檢查清單（2026）

用可維護規則迎戰開發者工具鏈波動

Gemini CLI 與 AI Studio 代表 2026 年「終端機與網頁控制台雙入口」的工程趨勢；把兩者與 API 主機名一起納入 Clash，長期比來回猜測節點或只修一半規則更省力。

立即免費下載 Clash，從透明的分流與日誌開始，穩住 Gemini 開發者工作流