Gemini 打不開？Clash 分流 Google AI 網域並關閉 QUIC 實測（2026）

1. 為什麼要單獨談 Google AI：和 ChatGPT／Claude 文章的差異

Google 的流量矩陣非常大：搜尋、Gmail、YouTube、OAuth、Cloud、API可能分佈在不同子網域與邊緣節點上。當訂閱規則只寫了「Google 相關」的粗粒度條目時，常見情況是一般瀏覽看似正常，但 Gemini 前端或 AI Studio因為命中另一組 CDN／證書路徑而表現得不穩定。相較之下，本站以 ChatGPT 為題的文章偏重策略組 fallback 與固定節點；Claude 篇偏重地區限制與 DNS／Fake-IP。Google AI 這條線則更常遇到網域遺漏與HTTP3（QUIC）走 UDP兩類問題，因此有必要獨立整理。

實務上建議把「Google AI 工作流」視為一個小專案：列出你實際會用到的網頁與 API 端點，再回頭檢查規則是否早於GEOIP或「國內／直連」類規則命中。這樣做不是堆關鍵字，而是避免同一個瀏覽器工作階段裡，OAuth 與模型對話頁面走到不同出口，造成登入狀態或配額顯示不一致。

2. 典型現象：能開 Google 搜尋，但 Gemini 或 API 工具異常

你可能遇過這類割裂感：搜尋與 YouTube 都正常，但開啟 gemini.google.com 時載入很慢、反覆轉圈，或在本機呼叫 API 時出現逾時；有時候又「什麼都沒改卻自己好了」。這類間歇性很符合兩種診斷方向：其一是規則沒有覆蓋到新子網域，流量一度落回直連或錯誤出口；其二是瀏覽器優先使用 HTTP/3，而 HTTP/3 底層為 QUIC（基於 UDP），與僅處理 TCP 的代理路徑或舊版分流認知不一致時，就會出現難以重現的錯誤。

先把期待講清楚：Clash 無法替你「解鎖」未開放的地區方案，也無法繞過帳號層級的合約限制；它能做的是把連線穩定送到你選擇的節點，並讓你在日誌中看見實際命中的規則與協定。接下來的網域表與 QUIC 對照，都是為了讓問題可重現、可驗證。

3. Clash 分流要覆蓋哪些 Google AI 網域

Google 產品迭代快，實際以你瀏覽器開發者工具（Network）與 Clash 連線日誌為準；下列清單涵蓋多數使用者與開發者在 2026 年仍常見的入口，建議以 DOMAIN-SUFFIX 方式整段覆蓋，並放在訂閱規則中「直連／國內」之前。若你使用 mihomo 的 rule-providers，請把自訂片段放在合併後仍優先的位置，避免被下游規則蓋掉。

• 網頁對話：gemini.google.com、歷史上可能仍會轉址的 bard.google.com。
• 開發者與試驗場：aistudio.google.com、ai.google.dev、google.dev（依你實際頁面為準）。
• Generative Language API：generativelanguage.googleapis.com，以及你 SDK 日誌中出現的其他 *.googleapis.com 子域（請勿一竿子打翻整個 googleapis.com，除非你確定所有依賴都可走同一出口）。
• OAuth／帳號：若登入流程異常，需同步檢查 accounts.google.com 與相關 OAuth 端點是否與前述策略組一致。

4. mihomo 規則範例：策略組與規則順序

以下片段示範如何為 Google AI建立獨立策略組，並在 rules 前段放入 mihomo 規則可讀的條目。請將策略組名稱、節點名稱替換為你環境中的實際字串，並與既有設定合併；註解使用英文以利版本控管。

proxy-groups:
  - name: 🔮 Google AI
    type: select
    proxies:
      - US-Node-A
      - US-Node-B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,gemini.google.com,🔮 Google AI
  - DOMAIN-SUFFIX,aistudio.google.com,🔮 Google AI
  - DOMAIN-SUFFIX,ai.google.dev,🔮 Google AI
  - DOMAIN-SUFFIX,google.dev,🔮 Google AI
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,🔮 Google AI
  # Add accounts.google.com / oauth endpoints if login splits across exits
  # ... your GEOIP DIRECT and MATCH rules below

5. QUIC／HTTP3 為何會「繞過」你以為的代理路徑

傳統 HTTPS 多走 TCP，許多代理與嗅探流程也圍繞 TCP 連線建立；而 HTTP/3偏好使用 QUIC（UDP）。當用戶端與伺服器協商成功時，瀏覽器可能略過你熟悉的 TCP 代理鏈，改走 UDP 路徑；若當時環境對 UDP 的處理與 TCP 不一致（例如只開了系統代理、未開 TUN，或路由器／公司網路對 UDP 有限制），就會表現為偶發錯誤、重試後恢復或特定網站才出問題。

這不是「Clash 不好」，而是協定棧選路的差異：把 HTTP/3 關掉，讓連線回到 HTTP/2 或 HTTP/1.1 over TLS（TCP），往往可以讓代理與規則命中路徑更接近你預期。本篇把它列為對照實驗：同一組節點與規則下，只切換 QUIC 開關，觀察是否穩定重現差異。

6. 關閉 QUIC 的實測步驟（瀏覽器與開發者工具）

以下為常見桌面瀏覽器的實測取向設定方式；不同版本選單名稱可能略有差異，請以你裝置上實際畫面為準。完成後請完整重啟瀏覽器，並清掉該站點快取後再試一次 Gemini 頁面。

• Chromium 系（Chrome／Edge／Brave 等）：前往實驗旗標頁面，將 QUIC 相關項目設為停用（常見關鍵字為 QUIC）。Edge 可使用 edge://flags。
• Firefox：在 about:config 搜尋 HTTP3／QUIC 相關鍵，將啟用 HTTP3 的選項設為 false（實際鍵名隨版本變動，請以當前說明為準）。
• 對照組：維持 Clash 設定不變，只改 QUIC 開關，記錄是否仍出現逾時或憑證／連線重試。

若關閉 QUIC 後問題明顯緩解，下一步不是永久依賴關閉，而是回頭確認你是否需要TUN 模式統一承載 UDP，或調整路由器／公司網路對 UDP 的限制；但在排查階段，「先讓路徑變單純」非常有效。

7. TUN、UDP 與日誌：讓實測可重現

若你希望不必靠關閉 QUIC也維持穩定，優先檢查 Clash 是否以 TUN接管系統流量，並確認用戶端設定允許處理相關 UDP。不同用戶端介面用語不同，但核心問題只有一個：Gemini 頁面與 API 連線是否全程進入同一個隧道與同一組規則。建議在實測時打開連線日誌，觀察目標網域、協定與命中規則，而不是只看節點延遲數字。

進階使用者若使用 mihomo 的嗅探與規則集，請留意規則載入順序與DNS 模式是否仍與本篇前段一致；當 fake-ip與策略組搭配得當時，較容易避免「解析先走本地、連線才走代理」的分裂。若你對規則優先順序尚不熟，可先閱讀站內 高級規則分流指南，再回來調整 Google AI 專用段落。

8. 驗證清單與常見誤區

完成設定後，建議依序確認：① gemini.google.com 與 generativelanguage.googleapis.com 是否命中同一策略組；② 登入／OAuth 相關網域是否被另一條規則提前直連；③ 在開啟與關閉 QUIC 兩種情況下，錯誤是否仍可重現；④ API 工具是否與瀏覽器共用代理環境。

常見誤區包括：以為「節點越快越好」卻忽略規則順序；把 googleapis.com過度寬泛地導向代理，導致其他依賴 Google API 的服務跟著走錯出口；以及將本問題誤判為 ChatGPT 的封號與 IP 漂移——若你的主訴是 Google 服務，請優先對照本篇與 ChatGPT 分流、Claude 地區與 DNS兩篇的適用邊界，避免用錯劇本。