Clash Meta 遠端規則集下載失敗？path 與更新間隔逐項修復
許多教學會帶您寫好 rules 與策略組，卻較少單獨講遠端規則集本身：當您在設定裡加了 rule-providers，介面上卻顯示規則未載入、日誌出現下載錯誤，或檔案明明存在卻好幾週都沒更新，問題往往出在 path 怎麼解析、更新間隔怎麼填，以及規則 URL 在您的網路環境下是否真能連上。本文以 Clash Meta（社群核心常見實作為 Mihomo）為對象，用「先驗證檔案與目錄，再驗證網路與週期」的順序，協助您把規則自動更新拉回正軌。
典型現象：規則「寫了像沒寫」
若 rule-providers 未成功下載或快取損毀，常見徵兆包括：啟動後日誌出現 HTTP／TLS 相關錯誤、規則集狀態一直停在載入中、或 rules 裡引用 RULE-SET 時整段規則不生效。另一種較隱蔽的情況是初次成功之後長期沒有再拉取：不一定是壞掉，而是 interval 設得太長，或核心認為快取仍有效而跳過更新。
與純 DNS、純分流場景不同，這類問題要回到「核心怎麼把遠端檔案落到本機」這條鏈路：URL 是否可達、寫入路徑是否正確、行程是否有權限建立目錄與檔案、以及更新排程是否符合預期。下面分項說明。
rule-providers 在做什麼
簡單說，rule-providers 會依您提供的 url（或部分型別的本地／內嵌來源）週期性取得規則資料，解析後供 RULE-SET 使用。落地檔案位置由 path 決定；多久重新抓一次由更新間隔控制——在 Meta 系設定裡，鍵名通常是 interval，單位為秒。部分圖形客戶端會用「每小時／每天」這類文案顯示，背後仍會換算成秒寫回設定檔。
與訂閱分開想
proxy-providers 管節點列表，rule-providers 管規則片段；兩者都可能下載失敗，但錯誤訊息與快取目錄不同。請勿把「訂閱能更新」直接等同於「規則集也一定沒問題」。
第一步：檢查 path 與工作目錄
path 多半是相對於設定工作目錄的路徑（視客戶端啟動參數與封裝方式而定，例如以 -d 指定的資料夾）。若您寫 ./rulesets/cn.yaml，請確認該資料夾在執行當下真的存在；若目錄不存在，部分環境不會自動建立，導致寫入失敗。
- 改用絕對路徑：在 Docker、Windows 服務或 macOS App 沙盒中，相對路徑常讓人誤判；可暫時改為絕對路徑驗證是否為路徑問題。
- 權限與使用者：Linux 上以專用使用者跑 systemd 服務時，請確認該使用者對目標目錄具備寫入權。可對照站內 《Clash Meta Linux 無頭部署》 的目錄與權限段落。
- 多份設定檔：若您同時有「原始訂閱檔」與「合併後檔」，請確認正在執行的那份裡，
path沒有被覆寫或指到唯讀掛載點。
# Illustrative rule-provider — paths are relative to your runtime working directory
rule-providers:
reject-domains:
type: http
behavior: domain
format: yaml
url: "https://example.com/reject.yaml"
path: ./rulesets/reject.yaml
interval: 86400
第二步：更新間隔與「長期不更新」
interval 過大時，表面上像「規則壞了」，其實只是核心依排程尚未再次抓取。例如 86400 代表約一天一次；若您預期幾小時內就要跟上上游清單，請酌調（並接受略高的請求頻率與對上游的禮貌）。若設為 0 或依版本支援的「不自動更新」語意，則可能完全依賴手動觸發。
另一種情況是：您剛修改了 url 或上游檔案大改版，但本地檔名與 path 未變，快取仍被視為有效。可嘗試關閉核心後刪除對應快取檔再啟動，或在圖形介面使用「更新規則／重新整理」類按鈕（名稱依客戶端而異），強制重新拉取。
| 設定印象 | 實際含義（常見） | 建議 |
|---|---|---|
interval: 3600 |
約每小時檢查／更新一次 | 開發或除錯時可縮短；穩定後再拉長 |
| 圖形介面顯示「每天」 | 多對應 86400 秒 |
以設定檔實際數值為準 |
| 長時間沒動靜 | 可能仍在間隔內，或下載靜默失敗 | 看日誌並手動更新一次對照 |
第三步：規則 URL 的網路與 TLS
規則源若託管在 GitHub、Cloudflare R2、對岸 CDN 等，在您所在網路可能需穩定出口才能連線。若 Clash 本身依賴代理上網，而抓取規則集的 HTTP 客戶端卻走直連，就可能出現逾時、RST、或證書驗證失敗。部分進階設定允許為提供者指定出站（視版本與欄位名稱而定），或在系統層為該主機配置路由；核心思路是：讓「下載規則」這條請求與您能正常瀏覽該 URL 的路徑一致。
若日誌出現 403、空回應或非預期內容，請用瀏覽器或 curl -I 在同一台機器上測試 URL：是否需要特定 User-Agent、是否被重定向到驗證頁、或 raw 連結是否填錯成 HTML 頁面。規則檔必須是核心支援的格式（如 yaml 與對應 behavior），誤把網頁當 raw 會解析失敗。
謹慎對待「跳過證書驗證」
為了下載規則而全域關閉 TLS 校驗會放大中間人風險。若您遇到證書問題，優先對齊系統時間、根憑證與是否被安全軟體攔截，再考慮針對性設定；亦可參考站內 Sniffer 與 HTTPS 排查 文中對憑證與嗅探衝突的說明。
第四步：behavior、format 與引用方式一致
behavior（如 domain、ipcidr、classical 等）必須與規則檔實際結構相符；錯配時可能載入失敗或產生空規則。請沿用規則集作者建議的型別與下載 URL；若上游同時提供 .yaml 與 .mrs 等格式，請確認 format 欄位與核心版本支援一致。
在 rules 區引用時，請確認 RULE-SET 名稱與 rule-providers 鍵名一致，且規則順序符合預期（過早的 MATCH 會讓後段規則集根本輪不到）。這類問題看起來像「下載失敗」，有時其實是規則沒被走到，建議搭配連線日誌觀察實際命中的規則列。
Docker 與圖形客戶端的額外注意點
在 Docker 中，請確認卷掛載包含會寫入的規則目錄，且容器內路徑與設定檔一致；映像升級後若更換了工作目錄，舊的相對 path 可能整批失效。對 《Clash Meta Docker Compose》 使用者，建議把規則快取與設定放在同一持久化卷，並在 README 或 compose 註解中寫明目錄結構。
圖形客戶端若提供「規則集管理」視窗，除錯時可對照匯出的完整 YAML，避免 UI 僅顯示別名而實際 path 指向暫存區、重啟後遺失。
與 DNS／fake-ip 的邊界
規則集下載發生在核心對規則 URL 主機名的連線上，與您瀏覽網站時的 DNS 模式可能不同但會互相影響：若 fake-ip 或分流導致解析異常，仍可能表現為「下載卡住」。當您同時遇到能上網但規則異常時，可一併閱讀 《DNS 與 fake-ip 排查》，但每次只改一個變因，以免混淆因果。
常見問題
介面顯示成功但規則像舊的
可能是快取未過期、或 rules 引用名稱與您以為的不同。請直接檢視落地檔案的修改時間，並在日誌中搜尋該 provider 的更新記錄。
只有某一條 rule-provider 失敗
優先單獨對該 URL 做連線測試；若其他規則源正常，多半是該主機被擋、需要代理出站，或格式／behavior 不匹配。
核心升級後才開始失敗
查發行說明是否調整了欄位名稱、預設行為或對二進位規則格式的支援；必要時暫時鎖定上一個已知可用的核心版本比對差異。
實操檢查清單
- 確認執行中的設定檔與您編輯的是同一份，且
path父目錄存在、可寫。 - 用瀏覽器或命令列在同一環境驗證規則 URL 可 200 取得正確內容。
- 核對
interval是否符合預期更新頻率；必要時刪除快取檔強制全量拉取。 - 檢查
behavior、format與RULE-SET引用是否一致，規則順序未被過早MATCH吃掉。 - 在 Docker／服務帳號場景確認掛載與檔案擁有者，避免因權限導致寫入失敗。
從可靠的客戶端開始維護規則
遠端規則集讓分流可讀、可更新，但多了一條對外依賴鏈路。把 path、interval 與規則 URL 的連線條件寫進自己的維運筆記，未來換機、換容器或升級核心時，就能快速復現同一套行為。