用 Clash 穩定存取 Gemini 2.5：Google AI Studio 分流

1 為何需要「Google 全系」分流，而不是只加一條網址

許多使用者第一次遇到問題，是瀏覽器能開啟搜尋首頁，但 Google AI Studio 卡在登入、模型選單載入失敗，或 API 金鑰頁面空白。這通常不是「單一網站慢」這麼簡單，而是身分驗證、靜態資源、API 端點分散在不同網域：例如 accounts.google.com 與 OAuth 相關端點負責登入流程；*.googleapis.com 承載實際的 REST／gRPC 風格 API 呼叫；前端介面又可能依賴 *.gstatic.com、fonts.googleapis.com 等資源。只要其中一條鏈路被規則誤判成直連或解析到錯誤位址，畫面上就會呈現「看似隨機」的失敗。

Gemini 2.5 作為 2026 年 Google 主力生成式模型之一，開發者常同時使用網頁試玩（Studio）與程式整合（Vertex／Gemini API）。兩條路徑的網域集合高度重疊，但逾時特性不同：網頁端偏向大量小請求與長連線；API 端則對 TLS、時間同步與 DNS 一致性更敏感。把「Google 服務存取」整理成可重複維護的規則集，比在出問題時臨時切換 Global 模式更穩定，也更省心力。

實務上，請把目標定義成：在 Rule 模式下，所有 Google 相關網域穩定命中同一策略組（例如 PROXY 或您的自訂策略組），並讓 DNS 解析結果與分流決策一致。

2 Google AI Studio、Gemini API 與開發者常見路徑

Google AI Studio（網頁）適合快速試驗提示詞、比較模型、產生範例程式碼與管理 API 金鑰；其核心價值是「產品化體驗」與低門檻上手。相對地，當您在本機或伺服器以官方 SDK、REST 客戶端呼叫 Gemini API 時，流量主要會指向 generativelanguage.googleapis.com（以及與專案、計費相關的其他 Google API 主機）。兩者看似不同入口，背後卻共用同一套 Google 身分與憑證體系，因此Clash 分流規則最好一次涵蓋「登入＋API＋靜態資源」，避免只代理 API、卻讓 OAuth 仍走直連的割裂情況。

免費額度與流量形態

2026 年許多教學與範例專案會以免費 API吸引開發者入場；這會帶來兩個網路現象：第一是尖峰時段請求更密集；第二是錯誤重試會放大連線數。若您的規則在 Retry 過程中命中不同策略（例如某些請求走直連、某些走代理），就會出現「同一段程式碼有時成功、有時失敗」的假象。這也是為什麼我們會建議把 Google 相關網域集中處理，而不是只靠瀏覽器外掛或單一應用程式內建代理。

3 網域拆解：您至少會遇到的幾類主機

以下不是「官方完整清單」，而是用於規劃 Clash 分流規則時的分類心智模型。實際部署請以您客戶端連線紀錄與訂閱規則集為準，並保留更新空間。

身分與帳號：accounts.google.com、與 OAuth 相關的 oauth2.googleapis.com、以及登入流程可能跳轉的 *.google.com 子網域。
API 端點：*.googleapis.com 是最常見的集合式寫法；其中 Gemini 相關請求常落在 generativelanguage.googleapis.com。若您使用 Google Cloud 其他產品，亦可能看到不同子網域。
前端與產品介面：包含 AI Studio 這類產品網域（可能隨產品改版調整），以及 ai.google.dev 等開發者文件站點。
靜態資源：*.gstatic.com、字型與腳本 CDN。若只代理主站不代理靜態資源，常出現頁面半白或按鈕無法點擊。
附帶但常見：googleusercontent.com 類型的內容承載網域，以及部分嵌入內容所需的額外主機。

規則順序很重要 Clash／Mihomo 由上而下匹配：請避免把過於寬鬆的 MATCH 放在前面，導致後面的細粒度規則永遠吃不到。若您使用 Rule Provider，請確認 Google 相關集合的載入順序與策略組指向符合預期。

4 Clash 規則範例：把 Google 流量導向同一策略組

下面是一段教學用途的最小示例：假設您已經在設定檔中定義好名為 PROXY 的策略組（名稱請改成您自己的）。實務上更建議以 Rule Provider 訂閱社群維護的規則集，並針對缺口補上自訂規則。若您尚未把訂閱轉成可用的 YAML，可先參考訂閱轉換教學完成匯入。

YAML

# Example only — replace PROXY with your policy group name
rules:
  - DOMAIN-SUFFIX,google.com,PROXY
  - DOMAIN-SUFFIX,googleapis.com,PROXY
  - DOMAIN-SUFFIX,gstatic.com,PROXY
  - DOMAIN-SUFFIX,googleusercontent.com,PROXY
  - DOMAIN-SUFFIX,gvt1.com,PROXY
  - DOMAIN-KEYWORD,google,PROXY

您可能會問：「DOMAIN-KEYWORD,google 會不會太寬？」在高度重視可用性的場景，它確實可能帶來誤判風險（例如某些非 Google 服務的網域恰好包含關鍵字）。因此更穩健的做法通常是：以 Rule Provider 的 Google 清單為主，再用更精準的 DOMAIN-SUFFIX 補洞；關鍵字規則僅作為過渡期手段，並在連線日誌中觀察命中結果逐步收斂。

合規提醒 請在您所在地法律與服務條款允許的範圍內使用代理與跨境連線。本文僅討論網路工程上的分流與連線品質，不提供任何違法用途的操作指引。

5 DNS、FakeIP 與 TUN：讓「解析結果」跟規則一致

只寫規則卻忽略 DNS，常見症狀是瀏覽器顯示連線逾時、或同一網域在不同 App 表現不一致。對 Google 這類大量子網域的服務，建議您把 DNS 設定視為分流系統的一部分：讓解析走可信管道，並避免本機／路由器上的污染結果把流量導向錯誤目標。若您使用 Meta（Mihomo）核心，可延伸閱讀DNS 防洩漏與 FakeIP，把「解析 → 規則命中 → 實際出口」串成同一條邏輯鏈。

至於系統代理與TUN 模式的選擇：若您主要在瀏覽器使用 Google AI Studio，系統代理常常就足夠；但若您同時在終端機跑 SDK、或在多個語言環境設定 API 代理，TUN 往往更省心，因為它能在封包層面統一接管，降低「某個子程序沒讀到 Proxy」的機率。TUN 的細節可對照Clash Verge Rev TUN 模式指南中的概念與注意事項。

6 開發者向：讓 Gemini API 走同一個本機出口

當您在終端機以 Python、Node.js 或其他語言呼叫 Gemini API 時，請記得：許多 HTTP 客戶端預設不讀系統 Proxy，除非您明確設定。最通用的作法之一，是在執行環境中設定標準環境變數，指向 Clash 的混合埠（常見為 7890，請以您的設定為準）：

Shell

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7890"

若您已啟用 TUN，且確認所有 TCP 連線都正確進入核心，則有時可以減少對環境變數的依賴；但仍建議用最小可重現範例（例如以 curl 測試）驗證「API 主機實際命中哪條規則」，再回頭調整 SDK 設定。這種方法論與「只加速瀏覽器」完全不同：您要的是可重複的連線品質，而不是一次性的速度測試數字。

7 為什麼這套規則也能改善 Gmail、Drive、Colab

一旦您把 Google 相關網域以一致的策略組處理，受益範圍通常不會只限於 Gemini 2.5。例如郵件同步、雲端硬碟檔案上傳、Colab 筆記本載入，往往同樣依賴 Google 身分與 API 流量。您會發現：許多「Google 服務偶爾可用」的問題，本質上是規則碎片化與DNS 不一致，而不是單一產品本身「壞掉」。

這也是為什麼我們會強調「Google 全系域名規則」的通用價值：它不是為了堆砌關鍵字，而是反映真實的流量形態。當您把維護成本從「每個 App 各設定一次」降成「同一套 Clash 規則」，長期下來會明顯更穩。

8 與「Cursor + Clash」教學的系列定位（切入點不同）

站內另有一篇Cursor IDE 與 Clash 代理，聚焦在 IDE、擴充市集與本機開發工具鏈的連線穩定性；本文則聚焦在 Google 生態與 Gemini API 的網域與規則面向。兩者可以並存：前者偏「開發工具鏈」，後者偏「雲端 AI 服務與 Google APIs」，核心關鍵字與故障型態都不同，適合讀者依使用情境各取所需。

9 除錯清單：先縮小範圍，再換節點

能開首頁但登入失敗：優先檢查 OAuth 與帳號相關網域是否同樣走代理，並確認系統時間正確。
只有 API 失敗、網頁正常：高度懷疑終端機／SDK 未走代理；用 curl 對 generativelanguage.googleapis.com 做對照測試。
Rule 模式異常、Global 正常：回到規則順序與 Rule Provider 更新；不要急著把問題歸咎於節點「不快」。
間歇性逾時：同時檢查 DNS 與是否啟用 QUIC／HTTP3 相關路徑被誤判；並觀察是否為尖峰時段重試造成連線數暴增。

需要挑選合適的桌面用戶端與安裝包時，建議優先使用本站下載頁取得與教學一致的版本，再依需求開啟 TUN 或僅使用系統代理。

10 總結

Gemini 2.5 與 Google AI Studio 的體驗，表面上是「開一個網頁／呼叫一個 API」，實際上卻是多網域協作的長鏈路。把 Google 服務存取收斂到同一套 Clash 分流規則，並讓 DNS 與 TUN／系統代理彼此對齊，才能讓開發者與重度 AI 使用者獲得可預期的連線品質；同時，這套方法也能讓 Gmail、Drive、Colab 等日常服務一併受益。

相較於遇到問題就切換 Global，長期更划算的做法是：固定維護一份您信賴的 Google 規則集合、保留連線日誌作為根因分析依據，並在終端機與瀏覽器之間使用一致的出口策略。若您尚未安裝或更新用戶端，建議從本站下載頁開始，與站內其他教學保持相同版本基準。

→ 立即免費下載 Clash，開啟流暢穩定的 Google 服務與 AI 開發體驗

用 Clash 穩定存取 Gemini 2.5：
Google AI Studio 分流規則配置教學