Clash 規則集拉取失敗？Rule Provider 寫法與更新排查步驟

這篇和「規則分流教學」有什麼不同？

站內的 規則分流詳解偏重在策略意涵、GEOIP 與 RULE-SET 怎麼排順序。若您已能讀懂 rules:，卻在遠端規則集（常見寫在 rule-providers 或介面上的 Rule Provider）遇到 URL 不對、本機路徑錯、或定時更新一直失敗，需要另一條「安裝與除錯」路徑：先確認核心真的拿到規則檔內容，再談命中哪一條規則。

在 Mihomo（Clash Meta 系）語境下，Rule Provider 本質上是「有名字的規則來源」：可以從 HTTP／HTTPS 拉取、也可以指向本機檔案。核心把來源內容展開成可用的規則集後，才會在 rules: 裡以 RULE-SET,名稱,動作 參與比對。因此「規則集拉取失敗」多數是下載、快取、格式或權限層面出了問題，而不是分流邏輯寫反。

rule-providers 在設定裡怎麼接線？

一個最常被忽略的重點是：rule-providers 區塊只負責「定義來源與更新策略」；真正讓流量走進該規則集，還要在 rules: 中引用對應名稱。若只加了 provider 卻沒有 RULE-SET,…，行為上就像訂了資料卻從沒在路由表掛上。

實務上常見的骨架包含：行為類型（如 classical 或依版本而定的其他行為關鍵字）、遠端位址 url、本機儲存路徑 path、以及 更新週期 interval。不同核心版本在鍵名與預設值上可能略有差異，但若您理解「url 決定從哪裡下載、path 決定寫入哪裡、interval 決定隔多久重試一次」，多數畫面與日誌就能讀得很快。

YAML 寫法：遠端 URL 與本機 PATH

YAML 對縮排極度敏感；多一個空白或少一層，整份設定可能無法載入。為 Rule Provider 取名時，建議用英數與底線，避免在部分介面中與特殊符號產生轉義問題。下列為教學用精簡範例，其中的網址與路徑請依您的環境替換，勿未經審核就沿用：

YAMLrule-providers:
  example_remote:
    type: http
    behavior: classical
    url: "https://example.com/rules/ads.yaml"
    path: "./rules/ads.yaml"
    interval: 86400

rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - RULE-SET,example_remote,REJECT
  - MATCH,PROXY

說明重點：type: http 表示由網路拉取；path 則是核心要把規則快取到的本機相對或絕對位置（依用戶端實作而定）。若您想完全離線、或自行維護清單，可改用本機型別（在支援的前提下改為讀取檔案，鍵名仍以您所用核心文件為準），此時就更要確認 path 指向的檔案真實存在、且執行使用者有讀寫權限。

interval 是什麼？會不會因為設太短而「一直失敗」？

interval 以秒為單位，表示多久嘗試重新整理一次該 Rule Provider 的內容。把數值設得很小，並不會讓首次下載比較快，反而可能在網路不穩或上游限速時，讓日誌反覆出現更新失敗的訊息。一般社群規則集以「每日一次」之類的間隔就足夠；若您剛在除錯，與其狂縮 interval，不如在手動觸發「重載」或刪除快取檔讓核心重新下載，更能看清楚一次完整錯誤。

也要留意：有些 GUI 會顯示「下次更新倒數」與實際 HTTP 成敗是分開的──倒數歸零只代表「又試了一次」；若 DNS、TLS 或出口被攔，仍會是失敗。此時與 interval 本身無關，而是根本連不到 url。

常見的「更新失敗」從何查起？

第一層是靜態檢查：用瀏覽器或 curl -I 在同樣的網路環境下請求您寫的規則集 URL。若出現 404、需要登入的 401／403、或被轉到錯誤的鏡像，代表問題在遠端或連結本來就變了，核心不可能憑空修復。少數情況是上游改用 HTTP→HTTPS 或永久搬移，導致舊網址仍活著但內容不是您預期的 YAML。

第二層是本機 path 寫法：相對路徑通常相對於核心的工作目錄或設定檔目錄（依產品而定），若寫了 ./rules/foo.yaml 卻從沒有建立上層資料夾，寫入可能失敗。權限方面，在 Linux 或 macOS 上若以系統服務執行，要確認執行身分對該目錄可寫；在容器或沙盒環境，也要確認掛載卷是否包含 path 所指的磁碟路徑。

第三層是雞生蛋的網路問題：若此台裝置尚未能透過訂閱節點上網，卻把規則集 URL 放在「必須能連外直連的網站」上，有時候會導致第一次下載就卡住。實務上可暫時用手機熱點、或把規則檔下載到本機再以檔案型式載入，等連線穩定後再改回遠端。關於訂閱與匯入流程，可搭配 訂閱匯入教學 確保 proxies 本來就可用，再疊上規則集。

從日誌對照：該看哪些關鍵字？

建議把 log-level 暫時調到 info 或 debug（依產品接受度），重新載入後搜尋與 Rule Provider、rule provider、update、fetch、download、HTTP 相關的片段。多數實作會在失敗時附帶狀態碼或 TLS 提示，能直接呼應上一節的靜態檢查。若日誌顯示寫入成功但行為不對，就要改查格式與 behavior 是否和規則集內容相符，那已偏向「內容解析」而非單純下載失敗。

和「規則沒被命中」不同：若純粹是 RULE-SET 沒被載入，部分用戶端會在圖形介面顯示紅色或「尚未更新」圖示；行為上可能變成該條 RULE-SET 整段不生效，後面才由 GEOIP 或 MATCH 接走。別忘了同步檢查您是否真的把 rules 寫在正確的設定檔，以及是否有多份設定在切換導致改錯檔案。

可複製的排查清單

• 驗證 url 可連：同網路下用瀏覽器或 curl 看狀態碼與內容型別。
• 核對 path 可寫：目錄存在、權限足夠、路徑未指到唯讀卷。
• 理順 interval：除錯階段勿過度縮短；必要時刪快取重載而非只靠倒數歸零。
• 確認 rules 有 RULE-SET：provider 存在不代表規則已掛上。
• 讀日誌一次完整失敗脈絡：從 fetch 到寫入的整段訊息比口頭推測有效。

結語

把 Rule Provider、遠端規則集、path 快取、interval 更新週期想成同一生產線上的四個關卡，任何一關斷掉都會在介面或日誌留下痕跡。相較於反覆重灌用戶端，先從 url 與 path 兩點靜態驗證，再用日誌定位 HTTP 與寫入失敗，通常半小時內就能收斂問題。

相較於只依賴內建訂閱而缺乏規則集更新意識，能清楚掌握 遠端規則從何而來、何時重載、失敗了該看哪裡，長期維護成本會低很多。若您尚未安裝合適用戶端，建議從本站取得對應平台版本並參考 教學文件 完成基礎設定。相較其他零散方案，在同一份配置語意下把節點、規則與日誌串起來，體感會明顯穩定。