Gemini 打不開？Clash 分流規則與固定節點穩定網頁版和 AI Studio

「Gemini 打不開」的原因：網頁版和 AI Studio 走不同主機群

瀏覽器的 Google Gemini（gemini.google.com 周邊）除了對話 UI 本體，還同時向驗證、資源、統計、全球 CDN 發出並行請求。Google AI Studio 有編輯器狀態、模型列表、預覽、計費/配額呼叫，短時間內集中在 ai.google.dev 等網域上。再加上 SDK 或後端呼叫的 Generative Language API（generativelanguage.googleapis.com 等），就會出現頁面能開啟、但 API 一直逾時的部分成功現象。

Clash 分流設定中，若寬泛的 GEOIP 規則提前命中某些主機，或 url-test 策略組在工作階段中途切換節點，每個主機就會走向不同出口，體感上表現為頁面卡住、串流回應中斷。DNS 污染與 DoH 設定見配套的 DoH 指南，本文專注於網域歸組與策略設計。

💡

本文範圍 OpenAI 流量見 ChatGPT·OpenAI API 指南，Anthropic 見 Claude 路由指南。本文範圍限定在 Google AI 網域以及網頁版、AI Studio、API 的路徑分離。

三個存取面：對話網頁、AI Studio、API

按存取面分別思考可以簡化設定。第一，一般使用者操作的對話網頁 UI。第二，Prompt 工程和金鑰管理用的 Google AI Studio。第三，SDK 與伺服端的 Generative Language API。三者都走 HTTPS，但主機名稱和可接受的出口地區可能不同。例如對話介面用低延遲節點、AI Studio 用綁定計費地區的穩定節點、API 呼叫對應配額所在地區的節點——分別建立策略組即可實現這種劃分。

主機名稱隨產品更新而改變，以連線記錄為準比依賴靜態規則清單更可靠。常見起點：gemini.google.com、google.com 下的 OAuth 與資源子網域、ai.google.dev、generativelanguage.googleapis.com，以及可能的 *.googleapis.com 或 *.gstatic.com。注意 googleapis.com 是 BigQuery 等其他雲端服務共用的，避免過早擴大後綴範圍。

YAML 範例：網頁版與 AI Studio 策略組分離

以下為概念示範，節點名稱和訂閱名稱請替換為您自己的環境。

proxy-groups:
  # Browser Gemini (consumer chat UI)
  - name: GEMINI-WEB
    type: select
    proxies:
      - JP-GEMINI-WEB
      - US-GEMINI-WEB
      - DIRECT
  # Google AI Studio (developer console)
  - name: AI-STUDIO
    type: select
    proxies:
      - US-AISTUDIO-STABLE
      - JP-AISTUDIO-STABLE
      - DIRECT
  # Generative Language API (SDK / server)
  - name: GEMINI-API
    type: select
    proxies:
      - US-GEMINI-API
      - DIRECT

rules:
  # 置於寬泛 GEOIP / MATCH 之前
  - DOMAIN-SUFFIX,gemini.google.com,GEMINI-WEB
  - DOMAIN-SUFFIX,ai.google.dev,AI-STUDIO
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,GEMINI-API
  # 可選：僅在記錄有根據後再擴寬
  # - DOMAIN-SUFFIX,googleapis.com,GEMINI-API
  # ... GEOIP / MATCH ...

googleapis.com 是 Google Cloud 各服務共用的網域，建議先從特定 API 子網域開始，從記錄中補充缺少的主機。為避免訂閱重新整理時規則被覆蓋，可使用 Clash Meta 覆寫指南中介紹的 prepend-rules 或合併層。

固定節點與策略組：不要只靠健康檢測

長時間 TLS 連線和串流回應對工作階段中途切換節點非常敏感。間隔較短的 url-test 策略組在回應本文傳輸中切換出口，會觸發握手中斷和重試風暴，使用者感受是「Gemini 打不開」或「AI Studio 卡住了」——節點品質沒問題，是路由抖動造成的。

實用的解法是：除錯階段在 select 策略組裡手動固定一個驗證過的節點；穩定後再換成 fallback 策略組，同時把測量間隔拉長，減少切換頻率。需要多地區覆蓋時，先固定單一地區確認症狀消失，再逐步引入自動選擇。查連線記錄：若失敗時間段內節點名稱頻繁更換，就能確認是抖動在作怪。

規則順序與部分成功：防止主機漏網

最常見的失敗模式：寬泛的 GEOIP,CN,DIRECT 或全域兜底在前，Google AI 規則排在後面。DNS 解析結果不同時，部分子網域意外落到 DIRECT，導致頁面能開啟但 AI Studio API 呼叫逾時，或對話 UI 載入了但串流回應停止。解決方案是結構性的：把具體網域規則放在寬泛地區規則之前。

國內直連、海外代理的基礎分流框架見分流規則設定指南，Google AI 規則相當於疊在那之上的薄層。實際執行時的匹配順序，用記錄驗證比讀 YAML 更可靠。

DNS、fake-ip 與 SNI：消除名稱與路由的錯位

fake-ip 模式下，介面上顯示的主機名稱與實際傳輸目標的關係不是直接對應。除錯期間停用瀏覽器內建的安全 DNS，避免與 Clash DNS 產生雙解析器衝突。模式比較見 fake-ip 與 redir-host 比較文章。

HTTPS 要求 ClientHello 中的 SNI 與伺服器憑證相符。企業 HTTPS 檢測、透明代理或瀏覽器擴充套件過濾器介入時，會在 Google AI 服務上產生看似隨機的連線失敗。出現症狀時，用最簡設定（只保留 Clash、關閉擴充套件）重現，確認問題在 Clash 層內還是 Clash 之外。

運營備忘：單帳號多出口、記錄整理

用同一個 Google 帳號在地理位置相距較遠的出口短時間內頻繁存取，可能觸發重新驗證提示。如果 AI Studio 和對話網頁用了不同節點，先統一到同一地區，觀察問題是否緩解。

高效排障：按主機名稱篩選記錄，同時記錄策略名稱和實際節點。與團隊共享除錯輸出時，遮掉 API 金鑰和個人識別資訊，並將規則行號與 YAML 對應區塊標注好，方便下次碰到同類問題複用。

TUN 與系統代理：讓瀏覽器和命令列走同一條路

瀏覽器遵循系統代理或 TUN 模式擷取。命令列工具和腳本通常需要明確設定 HTTPS_PROXY 或 ALL_PROXY，並確認回環位址與 Clash 的 mixed-port 一致。從 WSL 或 Docker 向主機端 Clash 轉發時，還要確認容器內 DNS 解析沒有卡住。

所有擷取層的共同原則：用規則命中區分「延遲高」還是「主機落到 DIRECT」。長串流回應中途中斷時，先懷疑網域規則漏網而不是節點品質，往往更快找到問題。

⚠️

法律法規與服務條款 請遵守所在網路環境的政策、適用的當地法規以及 Google 的服務條款。本文是在具有合法存取權限的環境中，將流量引導至預期路徑的參考資料。

分症狀排障清單

只有對話網頁不穩定，AI Studio 能開啟

在記錄中確認 gemini.google.com 及驗證、資源相關主機命中了 GEMINI-WEB。檢查是否被寬泛規則提前吸走，臨時固定節點為單一值，驗證重現性。

只有 AI Studio 載入卡住

優先確認 ai.google.dev 和記錄中出現的相關主機落在 AI-STUDIO 上。將 API 和 Studio 流量混入同一策略組容易導致請求走向非預期出口。

只有命令列或 SDK 的 API 呼叫逾時

確認 generativelanguage.googleapis.com 等命中 GEMINI-API 而非落到 DIRECT。如果 DNS 解析路徑有疑問，結合DoH 配套指南的步驟交叉驗證。

總結：歸組、固定、驗證

2026 年，Google AI 服務仍然橫跨對話網頁、AI Studio 和 Generative Language API 三個不同主機群。本文將它們整理進獨立的 Clash 策略組，透過固定節點抑制出口抖動，並透過規則排序防止部分成功式失敗。DNS 和 DoH 的設計交給配套文章，本文聚焦網域歸組與策略架構。

如果還沒安裝用戶端和匯入訂閱，先從下載頁面取得最新版本，按照訂閱連結指南打好基礎，再疊加本文的 Google AI 規則。→ 免費下載 Clash，讓 Gemini 與 AI Studio 流量走上預期的路