Clash 分流存取 Google Gemini：AI Studio 網域規則與節點選擇實測

為什麼 Gemini／AI Studio 不該沿用「AI 共用一群」？

到了 2026 年，許多團隊已習慣把 ChatGPT、Claude 或 Grok 收斂到同一個 AI_PROXY。這在「快速能用」階段很省事，但Google Gemini 與 AI Studio 的主機集合、登入鏈路與 API 命名空間與 OpenAI／Anthropic／xAI 明顯不同：大量請求落在 *.google.com、*.google.dev、*.googleapis.com 與靜態資源網域上，若沿用過寬的關鍵字規則，容易誤傷其他 Google 服務；若過窄，又會出現「網頁開了、金鑰測試逾時」這類半套連線。

實務上較穩的做法，是另建 GEMINI_PROXY（名稱可自訂），把 Gemini 網頁、AI Studio 主控台與 Generative Language API 相關主機，用明確的 DOMAIN／DOMAIN-SUFFIX 規則放在寬鬆 GEOIP、RULE-SET 與 MATCH 之前。這樣您可以在圖形介面裡為 Google 系 AI 固定較乾淨的出口，並在日誌中快速分辨「是 Gemini 走錯群組」還是「一般 YouTube／搜尋被波及」。若您尚未完成訂閱匯入，建議先走一遍 訂閱匯入教學，再回頭調整規則，避免節點名稱與群組對不起來。

合規提醒：Clash 為本機網路轉送與設定管理軟體，不提供遠端節點。請在合法合規前提下使用自有或授權的服務，並遵守當地法規與 Google 各產品條款（含 API 配額與地區政策）。

Google 系主機怎麼拆：網頁、AI Studio 與 API 三路

以下分類用於建立規則時的心智地圖，不是保證永不變更的官方清單。Google 會調整微服務邊界、CDN 與實驗性子網域，最可靠的補強方式仍是開啟連線日誌，找出仍落在 DIRECT 或被錯誤規則提前命中的主機名稱，再往回補規則。與本站 ChatGPT／Claude 分流專文對照時，請記得該文主機集合無法覆蓋 Gemini。

網頁與互動主機

  • Gemini 網頁介面：常見主機包含 gemini.google.com；實際頁面可能另拉取分析、字型或實驗功能子網域，空白畫面時請優先查日誌中的阻擋或逾時主機。
  • AI Studio（網頁主控台）：aistudio.google.com 與開發者導向的 ai.google.dev 經常同時出現；若只做其中一條規則，可能出現「說明文件能開、主控台元件載入失敗」。
  • 舊版或轉址路徑：部分使用者仍會遇到 makersuite.google.com 類轉址或歷史書籤；實務上可一併納入同一策略群組，降低「點了舊連結卻直連逾時」的機率。

模型 API 與後端

  • Generative Language API：多數金鑰呼叫會落在 generativelanguage.googleapis.com（以及其下可能的區域化端點變體）。這條通常是 IDE 外掛、本機腳本與後端服務是否穩定的分水嶺。
  • 企業或 Vertex 路線：若您使用 Vertex AI 等品牌下產品，可能出現 *.googleapis.com 底下其他子網域；本篇以消費端 Gemini／AI Studio 為主，企業環境請以實際日誌擴充，避免一竿子打翻所有 googleapis.com。

登入、OAuth 與靜態資源

  • Google 帳號登入：accounts.google.com、oauth2.googleapis.com 等是否納入 GEMINI_PROXY，取決於您要不要讓「整段登入旅程」與模型請求固定同一出口。若登入走直連、對話走代理，有時會觸發額外驗證或工作階段不一致；若全部丟進代理，又可能影響一般 Google 服務體驗，需權衡。
  • 靜態與共用資源：www.gstatic.com、fonts.gstatic.com 這類主機常被多個產品共用；不建議只因 Gemini 就全域改寫，除非日誌明確指出載入失敗點。

規則順序：為什麼「抄了 DOMAIN-SUFFIX 仍沒用」？

在 mode: rule 下，核心由 rules: 頂端向下比對，命中即停。因此兩件事必須同時成立：第一，Gemini 相關規則要出現在會「提早結束」的寬鬆規則之前；第二，您要清楚訂閱商插入的 RULE-SET 是否在您自訂規則之前就已把流量帶走。

整體分流哲學可與 規則分流深度文一起讀：該文處理 GEOIP、rule-providers 與骨架排序；本篇把同一套「越具體越靠前」原則，收斂到 Google 系 AI 主機。若您使用 TUN 模式，請分開思考「流量有沒有進核心」與「進核心後規則怎麼命中」，否則很容易在錯層除錯。

可照抄的規則清單骨架（請以日誌補齊）

下列條目為教學用骨架，請視環境增刪。優先使用 DOMAIN 或夠精準的 DOMAIN-SUFFIX，避免過大的 DOMAIN-KEYWORD,google 類規則誤傷無關站點。

  • DOMAIN,gemini.google.com,GEMINI_PROXY
  • DOMAIN,aistudio.google.com,GEMINI_PROXY
  • DOMAIN,ai.google.dev,GEMINI_PROXY
  • DOMAIN-SUFFIX,makersuite.google.com,GEMINI_PROXY
  • DOMAIN-SUFFIX,generativelanguage.googleapis.com,GEMINI_PROXY
  • 可選（登入一致性）：DOMAIN-SUFFIX,accounts.google.com,GEMINI_PROXY 或改走您既有的「Google 帳號」群組，重點是不要讓登入與主功能長期分裂在不同出口卻假設它們無關。

若您使用第三方規則集，請先確認其中是否已含上述網域；重複規則通常無害，但順序與來源衝突會讓除錯變困難。寧可在日誌中確認實際命中來源，再決定要覆寫或關閉某段訂閱規則。

區域與節點：不是「延遲最低」就最適合 Gemini

模型服務除了延遲，還受帳單地址、工作區政策、API 啟用地區與風控影響。實務上常見做法是：在 GEMINI_PROXY 內放一個 select 讓您手動固定美西、美東或新加坡等節點，另用 url-test 子群組做備援；當網頁端頻繁出現驗證或金鑰呼叫回傳地區相關錯誤時，先換節點再換規則，可省下大量時間。

若節點本身會輪換出口 IP，也可能導致 Google 端視為環境跳動。此時比起盲目加規則，不如在策略群組中暫時固定單一節點做對照測試；確認穩定後再恢復自動測速或負載均衡。

YAML 範例：插入位置與命名

下列骨架示範在 GEOIP 與 MATCH 之前插入 Gemini 相關規則。遠端 URL、節點顯示名稱請替換為您訂閱中的真實值，勿未審核即複製為生產設定：

YAMLproxy-groups:
  - name: "GEMINI_PROXY"
    type: select
    proxies:
      - "GEMINI_AUTO"
      - "Your-Hand-Picked-Node"
      - DIRECT
  - name: "GEMINI_AUTO"
    type: url-test
    proxies:
      # Inject real proxy names from your subscription
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  # Gemini / AI Studio / Generative Language API (place BEFORE broad RULE-SET / MATCH)
  - DOMAIN,gemini.google.com,GEMINI_PROXY
  - DOMAIN,aistudio.google.com,GEMINI_PROXY
  - DOMAIN,ai.google.dev,GEMINI_PROXY
  - DOMAIN-SUFFIX,makersuite.google.com,GEMINI_PROXY
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,GEMINI_PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

重點仍是：任何會提前結束比對的寬鬆集合（含第三方 RULE-SET）若放在上述片段之前，您新增的 Gemini 規則可能永遠輪不到。若遇此情況，請改為在訂閱合併後的「自訂規則區」插入，或調整 rule-providers 的優先級與插入點（視您使用的前端而定）。

DNS 與 fake-ip：Google 系最容易被低估的變數

啟用 enhanced-mode: fake-ip 時，規則匹配與應用程式實際解析路徑可能出現落差。當您看到「瀏覽器顯示已連線、但 API 工具逾時」時，請同步檢查：fake-ip-filter 是否讓某些 Google 主機改走不同解析策略、以及作業系統或瀏覽器是否另啟安全 DNS／DoH 繞過本機。

處理原則與其他 AI 分流文相同：把 DNS 決策與規則設計放在同一個心智模型裡。必要時針對特定網域調整解析模式、暫時降低日誌等級觀察解析鏈，或在受控環境關閉瀏覽器 DoH 做 A／B 測試。

驗證步驟：建議照順序做

  1. 確認模式：客戶端為 Rule，且系統代理或 TUN 已按平台正確授權。
  2. 從網頁開始：開啟 Gemini 與 AI Studio 主控台，觀察是否仍有資源載入失敗或長時間轉圈。
  3. 分開測 API：用最小程式或官方範例呼叫 Generative Language API，對照日誌是否命中 GEMINI_PROXY。
  4. 固定節點對照：在 GEMINI_PROXY 內改為單一節點，排除自動測速誤判。
  5. 檢查寬鬆規則：暫時停用可疑 RULE-SET 或將 Gemini 規則移到更前段，確認命中是否恢復預期。
  6. 登入旅程抽查：若頻繁被要求重新驗證，嘗試讓 accounts.google.com 與主功能短期內共用同一出口，觀察是否改善。

常見踩坑（多數仍是順序與解析）

  • 過大的 googleapis.com 規則：一條後綴匹配可能涵蓋大量非 AI 服務，除錯與風險都會放大；優先精準到 generativelanguage.googleapis.com 這類子網域。
  • 只配網頁、忘記 API 主機：結果是「聊天能用、金鑰測試全失敗」或相反。
  • 以為 MATCH 會幫您「智慧選路」：MATCH 只是兜底命中，並不會自動理解 Gemini。
  • 忽略第三方規則集插入點：您在檔案底部新增的規則，若載入順序上仍在某個巨大規則集之後，可能形同沒寫。
  • 把問題誤判成節點壞掉：實際為 DNS 或登入出口分裂；先對照日誌再換訂閱。

安全提醒：請勿使用來路不明的規則集或「一鍵配置」，其可能導向惡意節點或過度寬鬆的放行規則。訂閱連結等同憑證，請勿公開分享。

結語

Google Gemini 與 AI Studio 在 2026 年仍是「模型 API＋網頁主控台」並行的高頻場景；Clash 能提供的價值，是把這條鏈路變成可排序、可觀測、可回滾的規則與策略群組，而不是一句「開全域就好」。當您用精準的 DOMAIN／DOMAIN-SUFFIX 把主機收斂到 GEMINI_PROXY、把順序放在寬鬆規則之前，並用固定節點與日誌完成驗證時，穩定度通常會明顯好於只依賴泛用 AI 規則集。

相較於零散工具拼裝，在同一套規則語意下維護桌面與行動用戶端，長期成本通常更低；若您尚未安裝合適版本，建議先從本站下載頁取得對應平台用戶端，並搭配 教學文件完成基礎設定。

當策略群組、規則順序與 DNS 設定彼此呼應時，Gemini 與 AI Studio 的載入與 API 錯誤會顯著減少。若您希望先完成安裝再逐步微調規則，可前往本站下載頁取得最新用戶端。→ 立即免費下載 Clash，開啟流暢上網新體驗