1 為何 Gemma 4 一釋出，開發者會立刻想到 Clash 分流
開放權重模型的價值在於「本機或自管環境可重現」：您會同時面對輕量試用（網頁端點幾下看推理品質）與重量下載（數 GB 級權重、分片、校驗檔）。前者流量型態接近一般 SaaS：大量小請求、OAuth、靜態資源與 API 交錯；後者則像軟體發行管道：單一連線長時間佔用頻寬、對中途斷線與重試極度敏感。若 Clash 規則在這兩條鏈路上把不同子網域送去不一致的策略組，表面症狀會非常混亂：Studio 能開但無法完成登入、模型卡片看得到卻無法建立工作階段，或 git lfs pull／huggingface-cli 顯示進度條卻在固定百分比卡住。
2026 年的開發者工作流裡，Google AI Studio 與 Hugging Face 幾乎是同一個「搶先試用」敘事的兩個入口：前者適合快速對照提示詞、工具呼叫與延遲體感；後者適合把權重接到既有訓練／推理管線。兩者背後的網域圖譜並不完全重疊，因此需要分平面維護，再用同一套分流哲學收斂：先分類、再寫可排序的規則、最後用連線日誌驗證，而不是只靠「全局代理開關」賭運氣。
請把目標定義成：凡與「試跑 Gemma」或「下載 Gemma 權重」直接相關的主機名，在 Rule 模式下穩定命中同一出口，且 DNS 解析路徑與規則決策一致。
2 與站內《Gemini 2.5 × Google AI Studio》專題如何分工
本站已有一篇以 Gemini 2.5 與 Google AI Studio 為核心的分流教學，偏重 generativelanguage.googleapis.com、API 金鑰與 OAuth 整體架構。那篇文章的讀者輪廓，多半是「已在使用或評估 Gemini 商業 API」的開發者。相對地，Gemma 4 在 2026 年的討論熱度，很大一部分來自開放權重與本機／開源生態：讀者更常搜尋「哪裡能試跑」「HF 上哪個 repo」「safetensors 怎麼拉」。
因此本文刻意不重複同一題，而是把 Gemma 當成「第二個切入點」：仍會覆蓋您在 Google AI Studio 試 Gemma 時需要的 Google 身分與前端資源，但會把篇幅重心放到 Hugging Face 的網頁、API、LFS 與常見 CDN 後綴，以及如何與既有 Google 規則並存排序。若您尚未建立 Google 側底層規則，建議先讀Gemini 2.5 與 Google AI Studio把「Google 全系策略組」搭好，再回到本文補上 HF 平面，維護成本最低。
若訂閱仍是二進位或第三方格式，亦可先完成訂閱轉 Clash YAML，再把下方條目插入 rules 前段；需要模組化管理社群清單時，可延伸閱讀Rule Provider 與 ACL4SSR類型的整理方式。
3 Google AI Studio 平面：試跑 Gemma 時別漏掉身分與靜態資源
在瀏覽器內試跑 Gemma 4，體驗鏈路與「用 Studio 玩 Gemini」高度相似：accounts.google.com、oauth2.googleapis.com、廣義的 *.google.com／*.googleapis.com、以及 *.gstatic.com 等靜態資源，仍可能以不同順序並行。若您只代理主站卻讓 OAuth 直連，或只代理 API 卻讓字型與腳本走另一出口，就會出現「按鈕看得到、點了沒反應」的碎片化故障。
開發者文件與入口網域
除 Studio 本體外，您可能同時開著 ai.google.dev 這類開發者文件分頁查詢範例與限制條款。實務上建議把這類網域與 Studio 放在同一策略組，避免文件頁與試跑頁因規則順序不同而落在不同地理位置，進而觸發額外的風控挑戰。若您使用企業帳戶或 Workspace，亦可能遇到 step-up 驗證；此時更應保持出口穩定，而不是在除錯過程中頻繁切換節點。
與 Gemini 規則的合併方式
若設定檔內已存在「Google → 某策略組」的寬鬆條目，請確認 Gemma 相關流量不會被更早的 GEOIP 或地區直連規則截斷。典型作法是：要嘛把 Google 全圖收斂到單一高優先規則區塊，要嘛在社群 Rule Provider 之上加一層自訂 override，並確保 override 在合併結果裡排序靠前。核心原則仍是「同一身分鏈上的主機名，命中結果要一致」。
4 Hugging Face 平面：模型倉庫、CLI 與 LFS／CDN
Hugging Face 作為模型下載與社群 hub，流量型態比 Google 單一產品頁更分散：網頁 UI、Hub API、Git／LFS、以及實際承載大檔的 CDN 主機名，可能落在不同後綴底下。只寫一條 DOMAIN,huggingface.co 往往不足以涵蓋完整下載鏈路；反之，過度寬鬆的 DOMAIN-KEYWORD,google 類寫法也會帶來誤傷，因此仍以 DOMAIN-SUFFIX 分層最穩健。
- 主要站台與短鏈：
huggingface.co與常見的hf.co（短網址與部分導向）。 - 大檔與 LFS：實際觀察連線紀錄時，常見額外後綴如
cdn-lfs.huggingface.co（請以您下載當下日誌為準，名稱可能隨基礎建設調整）。 - 研究／Spaces：若您從 Spaces 或推論 API 試跑，可能出現
*.hf.space等子網域；同樣建議以日誌驗證後再後綴化。 - 第三方整合：部分企業鏡像或快取服務可能使用不同 FQDN；若下載工具支援自訂端點，請勿假設與官方 Hub 完全相同。
使用 huggingface-cli、git lfs 或訓練框架內建的下載器時，請留意這些程式未必繼承瀏覽器代理。若只開啟系統代理而終端機未走同一出口，會出現「瀏覽器能開模型頁、終端機卻逾時」的落差。此時可評估 TUN 模式，或為終端機單獨設定 HTTP(S)_PROXY 環境變數，並確保其解析到的介面與 Clash 監聽埠一致。
5 可維護的 YAML 骨架：DOMAIN-SUFFIX 與 Rule Provider
下列片段僅示範結構；請將 PROXY-GEMMA 換成您實際的策略組（可以是與 Google 共用的 PROXY，或獨立組以便日誌篩選）。重點是：把本文條目放在寬鬆規則與最末 MATCH 之前，並以小型清單檔＋Rule Provider 承載會變動的後綴，避免每次熱更新都手動整包貼上。
# Example only — rename PROXY-GEMMA to your policy group
rule-providers:
gemma_hf_override:
type: http
behavior: classical
url: "https://example.com/your-team/gemma-hf-rules.yaml"
path: ./rulesets/gemma_hf_override.yaml
interval: 86400
rules:
# Hugging Face hub + common delivery suffixes (verify in your logs)
- DOMAIN-SUFFIX,huggingface.co,PROXY-GEMMA
- DOMAIN-SUFFIX,hf.co,PROXY-GEMMA
- DOMAIN-SUFFIX,cdn-lfs.huggingface.co,PROXY-GEMMA
- DOMAIN-SUFFIX,hf.space,PROXY-GEMMA
# Google plane (often already covered by your Gemini / Google block)
- DOMAIN-SUFFIX,google.com,PROXY-GEMMA
- DOMAIN-SUFFIX,googleapis.com,PROXY-GEMMA
- DOMAIN-SUFFIX,gstatic.com,PROXY-GEMMA
- DOMAIN-SUFFIX,ai.google.dev,PROXY-GEMMA
- RULE-SET,gemma_hf_override,PROXY-GEMMARule Provider 的價值在於「把會變的東西移出主設定檔」：當 Hub 調整 LFS 端點或前端改走新的 CDN 後綴時，您只需更新遠端清單或本機檔案，而不必重排整份訂閱。若團隊內多人共用，建議在清單檔頂端用英文註解標註用途與最後驗證日期（檔案內註解請維持英文以利工具鏈處理），並在變更後用連線日誌抽查數筆實際命中。
若您希望 Google 與 HF 使用不同出口（例如 HF 走高頻寬家寬、Google 走低延遲機房），請拆成兩個策略組並分別綁定後綴；但請注意 OAuth 與 Cookie 仍可能要求同一瀏覽器工作階段內出口不要無預警跳動，否則風控與登入狀態可能異常。
6 大檔下載與 CDN：節點策略比「測速第一名」重要
開放權重檔案常為多片壓縮包，下載器會平行建立多條連線；若策略組啟用積極自動選路，可能在傳輸中途切換節點，導致 TLS 會話中斷或校驗失敗。實務上更建議為「大型權重下載」指定延遲穩定、丟包低的節點，並暫時關閉過於激進的容錯切換，把目標從峰值 Mbps 改成可完成的斷點續傳。
若同一台機器同時開著 Google AI Studio 試跑與 HF 下載，請留意本機連線數與 UDP／QUIC行為：瀏覽器可能偏好 HTTP／3，而部分 CLI 仍走傳統 TCP。若您只在系統代理層處理瀏覽器，而未讓終端機流量進入同一規則世界，很容易出現「網頁試跑順、下載卻抖動」的錯覺。此時可對照TUN 模式指南，讓未自帶代理的程式也納入一致的路由決策。
DNS 側亦不可忽略：FakeIP、DoH 與規則命中若不對齊，會表現為「同一網址有時能解析、有時不行」。建議延伸閱讀Meta 核心 DNS 與 FakeIP，把解析鏈與 Clash 規則鏈視為同一套除錯對象。
7 除錯順序：先日誌、再排序、最後才換節點
建議固定流程：先在連線列表以 google、huggingface、hf.co 等關鍵字篩選，確認每一條命中規則與策略組；再切換 Global 與 Rule 對照。若 Global 正常而 Rule 異常，幾乎可斷定要調整規則或 DNS，而不是急著更換用戶端版本。對於間歇性問題，請特別檢查是否有「同一主機名在不同時間命中不同規則」的情況，通常代表 Rule Provider 更新或合併順序改變。
若您同時使用其他大型語言模型服務，可參考ChatGPT／OpenAI或Claude等篇：網域集合不同，但「拆身分、拆 API、拆 CDN」的思維可直接類比，方便在單一設定檔內模組化管理。
尚未選定桌面用戶端時，可先從本站下載頁取得與站內教學一致的版本，再依本機環境決定只開系統代理或一併啟用 TUN。
8 總結
Gemma 4在 2026 年帶來的熱度，本質上是「開放權重＋可用工具鏈」的組合：讀者會在 Google AI Studio 快速試跑，也會在 Hugging Face 拉模型與 tokenizer。兩條路徑的網域圖譜不同，但對 Clash 分流的要求一致——把相關後綴用 DOMAIN-SUFFIX 與可更新的 Rule Provider 綁到可預測的策略組，並讓 DNS、瀏覽器與終端機走同一套決策邏輯。相較單純追求測速數字，穩定的長傳與低抖動的小請求互動，更能減少「以為模型不好、其實是線路半套代理」的冤枉路。
與站內 Gemini 2.5 專題並讀時，可把 Google 平面視為共享基礎建設，把 HF 平面視為獨立模組；日後若 Google 或 Hub 調整端點，也只需更新對應清單而不必整份重寫。若您希望本機與教學文章使用同一套用戶端體驗，歡迎透過站內入口取得安裝包；相較僅依賴零散外掛，圖形化用戶端在連線紀錄與模式切換上通常更省時間。
