先釐清:規則集「拉不下來」是在拉哪一段?

在 Clash、mihomo(Clash Meta)及其圖形用戶端裡,你在設定檔寫下的 rule-providers(規則集提供者)多半是遠端 URL,核心會週期性(或在你手動觸發時)向該位址發出 HTTP/HTTPS 請求,取得文字規則檔並快取於本機。因此當畫面上長時間顯示 pending、更新失敗、逾時或不斷退回舊快照,首先要理解:這不是你的瀏覽器在開網頁,而是代理核心依目前的路由規則與出站策略,自己去連那個規則集網址。任何讓這條對外連線走錯路、卡在 DNS,或被中途干擾的因素,最後都會表現成「規則集載入失敗」。

社群設定檔與規則範本最常見的外部來源之一是 GitHub Raw(主機通常為 raw.githubusercontent.com)。在部分網路環境裡,直連 GitHub 相關網域不穩定或極慢,若此時規則又把該請求視為直連(DIRECT)送出,就很容易一直轉圈圈;反之,若在尚未建立穩定代理通道前就把所有流量草率丟進某個不可用節點,也會同樣失敗。接下來的流程,是把問題拆成:DNS → 對外出站是否真的能通 → 規則順序是否對規則集請求生效 → 是否要換來源鏡像。若你已熟悉整份設定骨架,亦可先對照Clash YAML 設定深度解析確認 rulesproxy-groupsrule-providers 區塊的關係,再回到本文做針對性排查。

典型現象:pending、timeout 與「只有規則集死掉」

許多使用者回報的情境是:訂閱節點正常、依規則分流仍可上網,只有某幾組規則集標籤卡在更新中;或反過來——新匯入的設定一打開,規則集區塊全紅/全停滯,但手動連海外網站卻未必重現問題。這代表核心對「特定目標伺服器」(例如 Raw GitHub)的連線決策獨立於你看得到的一般瀏覽器流量。另一些情況是 Fake-IP 或 DNS 與規則銜接不當,導致主機名雖解析出結果,出站卻對不上 TLS 期待的 SNI 或走錯介面——症狀在 Raw 這類對延遲與連線重置敏感的端點上會被放大。

建議你先記下規則集完整的 URL(包含路徑與分支標籤),並在用戶端開啟連線紀錄/事件日誌,觀察對 raw.githubusercontent.comgithub.com 或其跳轉相關主機時,命中哪一條規則、走哪個策略組。這一步比在論壇上反覆試「換一個別人貼的清單」更能定位問題。若你的工作流還需要先處理訂閱轉換或多檔合一,可先參考訂閱轉換與相容性梳理,避免把規則集問題與純粹的鏈結格式錯誤混在一起。

第一步:確認 DNS,而不是先改十條規則

若核心使用的 DNS 上游在你當前的網路下本身就無法連通,或使用被過濾、被污染的解析路徑,那麼在 TLS 開始之前就會卡住。請在設定檔的 dns 區塊檢視:是否真的啟用了你以為會用的解析器、fallback 是否合理、是否在 Fake-IP 模式下與 fake-ip-filter 衝突。實務上可暫時關閉過度複雜的實驗選項(若有的話),換成你已驗證穩定的 DoH/UDP DNS,重啟核心後再試一次規則集更新。

除了設定檔內建的 DNS,也別忽略系統層級:某些作業環境會由路由器或電信業者下發不可控的 DNS,與 Fake-IP 疊加之後,主機名的解析紀錄在核心與在用戶端除錯工具裡看起來可能不一致。用「換一條已知乾淨的網路(例如手機網路熱點)」做對照,常能快速區分是本機設定問題還是大環境阻斷——熱點下規則集立刻更新成功,多半是原網路對 GitHub 相關解析或連線不友善。

第二步:看清 GitHub Raw 走的出站——直連還是代理?

當 DNS 正常而仍逾時時,接下來問的是:核心連 raw.githubusercontent.com 走的是 DIRECT 還是哪個 proxy-group。許多規則寫法是「國內或私有網址直連、其餘走代理」,看上去很合理;但在你的實際網路上,對 Raw 這類網域的直連品質可能就是零,於是規則集更新永遠等不到第一段回應。

處理方式不是迷信「一定得直連」,而是為規則集涉及的 GitHub/CDN 主機名準備靠前的精確規則(例如 DOMAIN-SUFFIX),把這條流量交給一個你已確認穩定能訪問 GitHub 的策略組——常見為某個可用的 自動選線或以手動選取的節點組。順序請放在廣義的 GEOIP/地區規則與模糊的 MATCH 之前;否則規則集請求早已被前者送去 DIRECT 或直接落入預設出口,你再怎麼改後面都看不到效果。若你希望兼顧隱私與延遲,也可以把這組網域名單集中到獨立策略組「RULESET-FETCH」,專門服務規則集與 GEO 檔等非瀏覽器流量。

請注意:mihomo 與原版 Clash 家族在 provider 載入行為上細節不盡相同,新版可能支援更細的快取選項(例如調整請求標頭或使用內建行為),請以你所跑的核心版本的文件為準。本文側重共通工程思路:對齊出站與紀錄,而不是硬背某個欄位的翻譯名稱。

第三步:調整規則順序與策略組示意

下面是一段結構示意(請勿直接複製到生產環境而不檢視),用來凸顯「把 GitHub 相關主機名拉高」這件事在 YAML 長什麼樣:

# Example only — naming is illustrative

proxy-groups:
  - name: "RULESET-USABLE"
    type: select
    proxies:
      - "你的穩定節點組"
      - DIRECT

rules:
  # Put these BEFORE GEOIP cn / FINAL / broad MATCH-style rules when GitHub RAW is flaky on DIRECT
  - DOMAIN-SUFFIX,githubusercontent.com,RULESET-USABLE
  - DOMAIN-KEYWORD,github,RULESET-USABLE

  # … your subscription-based rules ...
  # - GEOIP,cn,DIRECT  (example placement)
  - MATCH,GLOBAL_PROXY_EXAMPLE_NAME

關鍵在於:實際的 group 與規則命名必須與你檔案中既有的區塊一致,且不可與規則集載入發生在代理尚未就緒的雞生蛋問題相衝突——例如在極簡環境中只有遠端規則檔、沒有任何可用節點時,請先確保有至少一組可更新的訂閱或離線可用的基本出站。對於細節欄位(如個別版本的 rule-providers pathintervalbehavior),建議對照前文連結之 YAML 教學,逐欄確認是否與目前核心相容。

第四步:GitHub Raw 仍不通時——可替換來源(鏡像與協力服務)

當你已確認:DNS OK、出站走對節點、規則順序正確,但依然握手慢或 RST,下一層才是真實的「對端或路徑品質問題」。這時可以考慮把規則集 URL 換成仍可連線的另一個發佈鏡像——例如將原始 GitHub Raw 換成 CDN 發佈的相同檔案、維護者提供的鏡像倉儲域名,或由訂閱/社群整合包內建的替代位址。使用任何協力 CDN 時,請自行評估可信度、HTTPS 簽署與內容是否與來源相符,並定期對照哈希或官方公告,避免因第三方面被改檔而把不可預期的規則灌進路由決策鏈。

請避免把明文密鑰、私人託管位址或未授權的內網伺服器細節寫進可公開分享的設定片段;對於公開專案的 Raw URL,請保留版本標籤或 commit 固定別名,以降低上游改檔對你自動更新策略的意外衝擊。

第五步:用本機請求對照連線紀錄

除用戶端圖介面以外,你可以在已開啟系統/應用程式代理的情境下,用 curl 透過同一個 HTTP 連接埠向 Raw URL 發起 GET,觀察是否回 200/是否在中途逾時——這能與核心的連線紀錄對拍。請勿在公開場合貼上含有 token 的真實 URL。

若 curl 可走而 core 規則集仍失敗,回到「請求發起時的出口」問題:核心是依自身規則做決策,未必與你已設好的終端環境變數相同。TUN/系統代理混用時尤其容易出現只看到瀏覽器正常、規則集卻仍以不符合預期的方式對外發包的情況。建議縮小包裝為:單一模式測試、單一出站,成功後再逐一打開複雜功能。

對照:常見徵兆與優先動作

你看到的現象 較可能的根因 建議先做的動作
僅規則集卡在 pending,網頁正常 raw.githubusercontent.com 的出站與日常使用流量不同 連線紀錄找主機名;補靠前的 DOMAIN/GEOSITE GitHub
換熱點後立刻恢復更新 原網路對 GitHub 路徑不友善或 DNS 干擾 強化可信 DNS;必要時對 Raw 走穩定節點
規則相關區塊全失效且節點顯示異常 並非規則集單項,多半是訂閱或核心未啟動 先看 proxy-providers/節點池與連線紀錄
偶有 403/rate limit 對同一 Raw 發起過於頻繁或共享出口被限流 調長 interval、合併重複來源或用鏡像
切 Fake-IP 後才異常 DNS/filter 規則與規則集 URL 不匹配 檢視 dnsfake-ip-filter 對 GitHub 的覆蓋

提醒:合規使用與內容信任

更改規則集來源或使用第三方 CDN 並不會自動賦予你繞過服務提供者條款的權利;請確保連線對象在你的情境下合法可取,並理解開源規則清單本質是一份可被改寫的外部資料從可信度不明的來源自動拉規則,可能帶來安全風險;建議對主要規則集維護者與發佈路徑保有基本掌握,並在重要變更前備份可用的本機快照。

結語:規則集拉取問題,多半是「對外那一段路」而非介面詞彙

Clash rule-provider 失敗往往不是單一的開關沒開,而是一條對外 HTTPS 請求在 DNS、直連環境以及規則出口選擇上沒對齊。把 raw.githubusercontent.com(及相關 GitHub CDN)視為需要你特地照顧的出口對象,並用連線紀錄驗證每一次調整是否命中預期,就能把「規則集載不下來」從玄學變回可復現的工程問題;與只靠社群隨機範本比起來,建立自己的排查順序更值得長期投資。

若你尚未安裝與環境對應的用戶端,或希望將核心與圖介面升到一致版本再行調整規則,可先從本站用戶端下載頁取得安裝包,再依照本文順序對齊日誌與 YAML。開源協定與上下游貢獻方式若以文字說明,通常可在專案 GitHub README 查到,與安裝包取得路徑分開理解即可。

相較僅購買現成規則集模板、卻對更新鏈無感的使用方式,親手走過一次規則集拉取全流程,對日常分流穩定性與除錯速度都會有更直觀的回報。若要快速取得與本機相容的官方封裝與對應教學,建議將下載來源統一到本站以避免版本錯置。→ 立即免費下載 Clash,開啟流暢上網新體驗