📖 教學 ⏱ 約 15 分鐘閱讀

2026 年用 Clash 穩定存取 Google Gemini：規則與 DNS 實測步驟

生成式 AI與Google 生態系在 2026 年仍是高度關注焦點；許多人第一次感覺到「不是節點爛，而是怎麼連都不順」，往往發生在網頁版 Gemini、Workspace 整合或手機 App同時存取多個子網域時。這篇文章與本站另一篇聚焦 Cursor／GitHub 開發者分流的文章刻意區隔：這裡談的是一般使用者在瀏覽器與 Google AI 產品上，如何用 Clash（含 Clash Meta／Mihomo 核心）做好分流規則、DNS與模式選擇，並用可複現的實測順序排查「斷線、解析異常、偶發逾時」。

為什麼 Gemini「看起來能開」，卻常常用到一半不穩？

Google Gemini 相關流量很少只打單一網域。網頁端可能同時涉及 google.com 體系、googleapis.com 上的 API、以及用來載入資源與驗證的多個子網域。當你只把「瀏覽器」走代理，但某個背景請求仍被規則送去直連，或反過來被送去不相容的出口地區，體感就會變成：頁面載入一半、對話送出後卡住、或圖片／附件偶發失敗。

另一個常被忽略的因素是 DNS。Clash 類核心在 fake-ip 模式下會改變本機解析行為；若你的規則、DNS 與實際連線目標不一致，表面症狀會很像「網路品質差」，其實是解析路徑與路由沒對齊。因此本文把「規則」和「DNS」放在同一套排查流程裡，而不是只叫你換節點。

先決條件：確認流量真的經過 Clash 核心

在談任何 DOMAIN-SUFFIX 之前，請先確認你的使用情境是否真的把流量交給核心處理。很多人只開了「系統 Proxy」，但某些 App 或背景元件不吃；或只代理瀏覽器分頁，卻漏了同一個 App 內建的網路元件。若你發現「只有 Chrome 正常、其他程式怪怪的」，優先對照Clash TUN 模式深度解析，理解透明代理與路由的覆蓋範圍，再回來調規則會省很多時間。

若你完全不熟悉代理群組怎麼接到規則後面，建議先讀Clash 代理群組（proxy-groups）完全指南，確定你的 AI-PROXY（示意名稱）之類群組確實存在，而且裡面有可用的出站，否則規則寫滿也只是把流量導向空集合。

Gemini／Google AI 相關：實務上常見的網域類型

下列清單是教學用途的合理起點，不是官方永久清單；Google 會調整後端路由與子網域，你仍應以客戶端連線日誌顯示的主機名稱為準，把漏掉的網域補到規則前段（規則由上而下先命中先贏）。

  • 使用者介面與入口：例如 gemini.google.com、與 Google 帳戶體驗相關的 google.com 子網域。
  • API 與開發者資源：例如 generativelanguage.googleapis.com、ai.google.dev，以及廣泛使用的 *.googleapis.com。
  • 靜態資源與共用基礎設施：例如 gstatic.com、部分 googleusercontent.com，用來載入腳本、字型或使用者內容。

手機 App 可能還會打到額外的分析、推送或裝置管理相關網域；若你只依賴「桌機瀏覽器清單」去套手機，最容易出現「同一帳戶、不同裝置體感差很多」的情況。做法仍是：先觀察日誌再補規則，不要硬背一份「永遠正確」的清單。

💡 小提示 若你同時使用 Workspace、雲端硬碟或 YouTube，流量可能與 Gemini 交錯；此時「只為 Gemini 寫三條規則」不一定夠。你可以先把 Google AI 相關網域集中到同一個群組，再依延遲與可用性微調，必要時參考自訂規則教學：讓指定 App 走指定節點把例外條目獨立管理。

最小規則集範例：把 Google AI 流量導向指定群組

下面是一段示意 YAML（請把 AI-PROXY 換成你實際的群組名稱，並確保它已在 proxy-groups 定義）：

# Example only — verify hostnames in your client logs
rules:
  - DOMAIN-SUFFIX,gemini.google.com,AI-PROXY
  - DOMAIN-SUFFIX,ai.google.dev,AI-PROXY
  - DOMAIN-SUFFIX,makersuite.google.com,AI-PROXY
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,AI-PROXY
  - DOMAIN-SUFFIX,googleapis.com,AI-PROXY
  - DOMAIN-SUFFIX,gstatic.com,AI-PROXY
  - DOMAIN-SUFFIX,googleusercontent.com,AI-PROXY
  - MATCH,Main

說明：① 若你仍看到漏網主機名稱，請以日誌為準補上 DOMAIN 或更精準的 DOMAIN-SUFFIX；不建議貿然加入覆蓋面過寬的 DOMAIN-KEYWORD,google，以免把搜尋、地圖或其他未預期的 Google 服務一起送去代理。② MATCH 之後的群組名稱請依你的設定檔調整。③ 若訂閱內建規則已包含大型 GEOIP 或地區分流，請留意規則順序：細粒度條目要放在前面，否則會被更早的寬鬆規則吃掉。

DNS 與 fake-ip：為什麼「解析」會影響穩定度？

在 Clash Meta／Mihomo 環境中，DNS 模式會影響「域名如何對應到實際連線」。常見設定包含 redir-host 與 fake-ip：fake-ip 會給本機一個虛擬位址，讓核心有機會在真正發起連線前就做規則匹配；但若你的應用程式或額外 DNS 客戶端繞過核心自行解析，可能出現「規則以為走 A、實際連線走 B」的落差。

實務上建議你把排查拆開：先確認只有一套 DNS 決策在生效（至少在測試期間暫停衝突的 DNS 軟體或系統層的強制 DNS），再觀察核心日誌裡的域名與目標位址是否一致。若你發現某些網域反覆解析失敗，可以為測試目的指定可信的遠端 DNS（例如 DoH），但仍要理解：任何第三方 DNS 都看得到你的查詢內容類型，請自行評估風險與信任邊界。

模式選擇：規則模式、全域與「只開瀏覽器」的差異

多數使用者會以規則模式作為日常預設：讓分流規則決定哪些流量進代理。若你暫時切到全域測試，能幫助判斷「問題是不是出在規則漏抓」；但全域模式也會把本不需要代理的流量一起送出去，延遲與相容性副作用更明顯，不建議長期當成解法。

另一個常見誤解是：以為「開了瀏覽器外掛／擴充套件顯示已連線」就等於所有 Google 相關請求都走同一條路。實際上，服務工作者（service worker）、背景同步與跨網域 iframe 都可能讓請求以不同方式發起。若你只在擴充層看到成功，但核心日誌裡仍有大量直連或錯誤群組命中，就要回到系統層模式與應用程式是否吃代理來修。

實測步驟：建議你照這個順序檢查

為了避免一次改太多變因，建議用下列順序做可重複的驗證；每完成一步再進下一步。

  1. 節點與訂閱是否正常：先在客戶端內對目標群組做延遲或連通測試，排除上游全面失效。
  2. 規則是否命中：開啟連線日誌，對 Gemini 進行一次會觸發多請求的操作（開啟對話、上傳檔案、切換模型），確認主機名稱是否落在 AI-PROXY（或你的群組）。
  3. 規則順序是否被蓋掉：若較早的 MATCH 或訂閱規則先把流量送去別的群組，後面補的 Google 規則可能永遠不會生效。
  4. DNS 是否一致：觀察解析結果與連線目標；若出現大量非預期位址或反覆重試，優先處理 DNS 與 fake-ip 設定，而不是先換十顆節點。
  5. 縮小測試面：改用手機行動網路與家用 Wi‑Fi 各測一次；若只有某一種網路環境有問題，偏向是路由器 DNS、IPv6 或電信商策略，而不是 Clash 規則本身。

若你希望把「安裝、匯入訂閱、啟用規則」整段流程串起來，也可搭配本站Clash 使用教學逐步核對自己的作業系統與客戶端版本。

與開發者分流文章的差異：什麼時候該讀哪一篇？

本站另有一篇以 Cursor、GitHub、Copilot為主的開發者分流教學，重點放在 IDE、Git 與大型檔案下載網域；本篇則偏向一般使用者在瀏覽器與 Google AI 產品上的體驗。兩者都依賴「規則優先順序＋日誌驗證」，但網域集合與工具鏈不同：不要直接把開發者文章裡的規則原封不動套到 Gemini，除非你已確認日誌裡出現的主機名稱確實相同。

隱私、帳戶與合規：使用前請先想清楚邊界

代理工具在技術上可以中介你的連線；上游節點供應商也可能在其伺服器側看見相關流量型態。請只安裝來源可信的客戶端，並遵守服務條款與適用地區規範。本文僅討論網路路徑與設定思路，不提供任何規避法律、違反服務條款或侵害他人權益的操作指引。

若你需要查核開源授權、原始碼或回報問題，可自行前往專案頁；一般使用者取得安裝檔與更新，建議優先遵循本站下載頁所整理的方式，避免誤用來路不明的安裝包。

常見問題

規則加了，為什麼 Gemini App 還是不穩？

請先確認 App 流量是否經過核心（必要時使用 TUN 或該平台支援的透明代理模式），再用日誌核對實際主機名稱。手機 App 常會使用與網頁版不同的端點，規則需要跟著日誌補齊。

我把 Google 全走代理，為什麼反而變慢？

過寬的規則會把區域 CDN、本可直連的資源也帶去遠端節點，延遲反而上升。請改以日誌精準化網域，並保留合理的直連或更近的群組策略。

fake-ip 一定要開嗎？

不一定。是否啟用取決於你的核心設定、客戶端預設與相容性需求。重點是：任選一種模式後，讓「解析、規則與實際連線」保持一致，並用日誌驗證。

整體來說，2026 年想用 Google Gemini 之類的生成式服務，與其不停換節點，不如先把 Clash 分流規則與 DNS 行為對齊；這通常比盲目堆疊更多出站更能改善體感。若你正在找能長期承載規則型代理流程的客戶端，不妨從本站取得對應平台版本，實際感受規則命中與切換是否順手——→ 立即免費下載 Clash，開啟流暢上網新體驗。