Clash 自訂規則集進階設定：AI與開發工具 YAML 分流實戰

前言：為什麼要建立自訂規則集？

當 Clash 配置只依賴一份大型訂閱檔案時，短期內看起來很方便，但隨著使用時間增加，規則重複、策略組混亂、更新後被覆蓋等問題會逐漸浮現。尤其是 ChatGPT、Claude、Gemini 等 AI 服務，以及 GitHub、Docker、npm、PyPI 等開發工具，經常使用多個主域名、API 域名與 CDN 域名。如果只加入一條 DOMAIN-SUFFIX 規則，很容易出現首頁可以開啟、登入失敗，或下載套件時連線逾時的情況。

自訂規則集（Rule Provider）的價值，在於把特定用途的域名規則從主配置中拆出來，再透過 YAML 檔案集中維護。你可以為 AI、程式碼託管、容器映像檔、套件倉庫分別建立規則集，並在主配置中指定它們使用的策略組。如此一來，修改某一類服務時，不必反覆編輯整份配置，也能降低規則互相覆蓋的機率。

1先理解 Clash 的規則匹配邏輯

Clash 處理連線時，通常會按照 rules 從上到下逐條比對。當某一條規則符合目前的請求，Clash 便會停止繼續搜尋，直接將流量交給該規則最後指定的策略。因此，自訂規則集是否有效，不只取決於域名寫得是否完整，也取決於它在主配置中的排列位置。

常用的匹配類型

• DOMAIN：只匹配指定的完整域名，例如 api.openai.com，不會自動涵蓋其他子域名。
• DOMAIN-SUFFIX：匹配指定後綴及其子域名，例如 DOMAIN-SUFFIX,github.com 可涵蓋 api.github.com。
• DOMAIN-KEYWORD：只要域名中包含關鍵字便匹配，範圍較寬，應避免使用過於普通的詞語。
• IP-CIDR：依 IP 網段匹配，通常需要配合 no-resolve，避免 Clash 為了判斷規則而額外解析域名。
• RULE-SET：引用外部或內部規則集，是模組化管理的核心。
• MATCH：兜底規則。一般放在 rules 最後，用於處理前面沒有匹配到的連線。

實務上，建議先使用精確度較高的 DOMAIN，再使用 DOMAIN-SUFFIX，最後才考慮 DOMAIN-KEYWORD。例如，若你只想處理某個 API，就不應直接使用過寬的關鍵字規則。另一方面，GEOIP、廣告規則或大型訂閱規則若放在自訂規則之前，也可能提前接管流量，導致你的 AI 或開發工具規則沒有機會生效。

2建立可維護的 YAML 規則集架構

一份規則集至少要包含 payload。每一行代表一條規則，格式通常是「規則類型、參數」，而策略名稱不寫在規則集內，而是由主配置的 rules 決定。這樣同一份域名清單就能在不同環境中重複使用，例如在辦公室走代理，在家庭網絡則改為直連。

推薦的檔案分工

可以在本機建立一個專門存放規則的目錄，也可以將檔案放在自己的 Git 儲存庫中。建議依用途命名，而不是依節點名稱命名，因為節點經常更換，規則的用途卻相對穩定：

ai.yaml 用於 AI 平台，developer.yaml 用於程式碼與套件服務，container.yaml 則可處理 Docker Hub、GitHub Container Registry 等映像檔來源。若不同服務需要不同節點，也不要把策略名稱硬編碼在檔案裡，而應讓主配置負責策略分配。

AI 規則集範例

以下範例使用較保守的域名範圍。實際使用時，請依服務官方文件與連線日誌逐步補充，避免把不相關的共享 CDN 一併代理。

如果某個服務只有登入頁面需要代理，而其他資源可以直連，可以先從完整域名開始測試，再決定是否擴大到後綴規則。對於多人共用的配置，應在 YAML 檔案旁邊記錄修改原因與日期，方便日後判斷某條規則是否仍然必要。

3在主配置中引用 AI 與開發工具規則集

規則集的定義通常放在 rule-providers，而實際調用則放在 rules。不同 Clash 核心對欄位支援略有差異；使用 Mihomo 時，常見的 HTTP 規則集可以透過 behavior: classical 指定格式。若檔案是純域名清單，則應使用相符的行為類型，不要混用格式。

上面的 AI 與 DEVELOPER 是策略組名稱，必須在 proxy-groups 中存在。若你的策略組實際名稱是「美國節點」或「程式開發」，就要在規則中完全一致地替換。大小寫、空格與特殊符號都可能造成配置載入錯誤，因此建議使用簡短、固定的英文識別名稱，再透過客戶端介面顯示友善名稱。

開發工具規則集範例

開發工作常見的問題是 Git 操作正常，但套件安裝或容器拉取失敗。這是因為它們使用不同的域名與連線端點，建議分開整理：

若你希望 GitHub 網頁走代理，但公司內部 GitLab 必須直連，可以將內部域名規則放在 RULE-SET,developer-tools,DEVELOPER 之前。例如使用 DOMAIN-SUFFIX,git.example.com,DIRECT，並確認它位於更寬泛的開發工具規則之前。這就是「越特殊的規則越靠前」的基本原則。

4更新、版本控管與故障排查

自訂規則集真正的難點不在第一次寫出 YAML，而在於長期維護。AI 服務與開發平台可能新增域名、調整 CDN 或更換登入端點，因此建議將規則檔案放入 Git，讓每次修改都有清楚的差異紀錄。提交訊息可以寫成「加入 Gemini API 域名」或「移除已停用的 CDN」，不要只寫「更新規則」。

建議的更新策略

1. 先在測試配置中修改，不要直接覆蓋每天使用的主配置。
2. 每次只處理一個服務或一組域名，方便定位問題來源。
3. 使用 YAML 編輯器或核心的配置檢查功能，確認縮排與冒號格式正確。
4. 重新載入配置後，先測試首頁、登入、API 請求與檔案下載四種場景。
5. 確認穩定後再提交 Git，並保留上一個可用版本以便回滾。

連線異常時的排查順序

• 先看日誌：在 Clash Verge Rev 或 Mihomo 的連線頁面搜尋目標域名，確認實際命中的規則與策略組。
• 再看規則位置：若日誌顯示先命中 GEOIP,CN 或其他兜底規則，表示自訂規則放得太後面。
• 檢查 DNS：域名解析結果可能受到本地 DNS 污染或 Fake-IP 設定影響。測試時可比較系統代理、TUN 與瀏覽器直連的結果。
• 檢查策略組：規則命中不代表節點可用。確認 AI 或開發工具策略組中有可連線節點，並避免在登入期間頻繁切換地區。
• 縮小規則範圍：若加入大量 DOMAIN-KEYWORD 後出現網站載入異常，先暫時刪除寬泛規則，再以精確域名逐條補回。

完成測試後，可以使用 curl 或 Git 指令驗證不同服務。例如，測試套件倉庫時不要只打開網站首頁，還要確認實際下載端點是否能回應。對 Docker 而言，登入、拉取 manifest 與下載 layer 可能使用不同域名，因此應分階段檢查。

常見問題

規則集已載入，為什麼仍然沒有生效？

最常見原因是 RULE-SET 排在其他寬泛規則後面，或者規則集的 behavior 與檔案格式不一致。請先在連線日誌中確認目標域名，再檢查規則排列與策略組名稱。若日誌完全沒有出現目標域名，也要考慮瀏覽器快取、QUIC 或應用程式使用獨立 DNS 的情況。

DOMAIN 與 DOMAIN-SUFFIX 應該怎麼選？

只需要匹配一個完整端點時使用 DOMAIN，需要涵蓋同一服務的多個子域名時使用 DOMAIN-SUFFIX。不要為了省事全部使用後綴規則，因為共享域名可能同時承載不同服務，過度代理會增加延遲，也可能造成登入驗證異常。

規則集一定要放在遠端 URL 嗎？

不一定。遠端 URL 適合多台設備共用與自動更新，但必須確保來源可信、連線穩定，並留意檔案被改動的風險。本機檔案更容易測試與回滾，適合個人配置。較理想的做法是使用 Git 儲存庫管理內容，再透過固定版本或可靠的靜態地址提供給客戶端。

使用規則集是否必須開啟 TUN 模式？

不是所有情況都需要。瀏覽器遵守系統代理時，HTTP 代理模式通常已足夠；但部分 IDE、命令列工具、容器服務或背景程式不讀取系統代理，這時 TUN 模式能提高接管完整度。開啟後仍需檢查 DNS 與路由設定，避免把區域網路、公司內網或本來應直連的流量一併送進代理。