よくある症状：rule-providers が pending のまま終わらない

Clash Meta（mihomo）や対応 GUI を使っていて、プロファイルには rule-providers と RULE-SET が書かれているのに、クライアントの更新一覧では特定のルールセットだけずっと取得中（pending）のまま進まない、あるいはしばらくして timeout や取得失敗のログが出る——という相談は非常によく見られます。ブラウザでは他の海外サイトが開けるのにルールだけ落ちる、逆に「全部直結のはず」なのに GitHub だけ開けない、など出口がばらけると症状だけでは原因が掴みにくいのが特徴です。

多くの公開ルールやサンプル設定が raw.githubusercontent.com（いわゆる GitHub Raw）上のテキストを指しているため、ここが名前解決・経路・レート制限のどこかで詰まると、全体のルール更新が止まったように見えます。本稿では「DNS か」「ブラウザと違う経路で直結しているか」「到達自体が難しいか」を順に切り分け、分流（スプリットルーティング）と URL の差し替えでどう復旧するかを手順としてまとめます。YAML の全体像は YAML とルール分流の解説、購読側の話は サブスク変換の記事と役割が分かれます。

ルール取得だけ別経路になりやすい理由

rule-providers の HTTP(S) 取得は、ユーザーの Web ブラウザとは別プロセスで走ることが多く、システムプロキシを読まない実装よりコア自体がプロキシ越しに出る実装まで様々です。また、プロファイル内の rules は「すでに読み込めたルール」に対して有効ですが、ルールファイルを取りに行く通信自体にも、別途出口が割り当てられることがあります（コア・バージョン・GUI の「プロバイダ取得経路」設定に依存）。そのため「普段の閲覧はノード経由で快適」でも、「GitHub Raw への取得だけ国内直結のまま遮断されている」といった部分的不整合が起きます。

さらに、raw.githubusercontent.com はリージョンや ISP によっては遅延が大きい・不安定という報告が繰り返されるホストでもあり、単に「壁」ではなく経路品質だけでタイムアウトに達する場合もあります。まずは「名前は解けるか」「どの IP／出口に出ているか」をログと OS 側の情報で掴むのが近道です。

手順 1：DNS と名前解決を疑う

取得失敗の第一候補は DNS です。クラスタ内 DNS が外部を正しく返せない、社内フィルタが Raw ドメインを弾く、あるいは Fake-IP 環境でプロバイダ取得だけ名前解決の挙動が違う、などが典型です。コアのログで該当ホスト名が出ているか、別途端末から nslookup や dig で raw.githubusercontent.com が返るかを確認します。

Fake-IP を使う構成では、ブラウザとコアで「見えている IP」が一致しないことがあります。フィルタ対象や除外リストの設計が古いままだと、意図せず解決結果が食い違うホストが残ることがあるため、DNS 関連のパラメータは ドキュメントの DNS・Fake-IP 節と突き合わせつつ、問題再現中だけログレベルを上げて観察するのが安全です。

手順 2：直結（DIRECT）で行っているかを確かめる

第二候補は分流の結果、GitHub Raw が意図せず DIRECT に落ちているケースです。購読テンプレやコミュニティ製リストは、しばしば「国内は DIRECT」「海外は PROXY」のような粗い GEOIP 行の前後に自前のドメイン行を挿入する前提で書かれています。ところが運用中のファイルでは、自前の行が無い・順序が変わっている・別の RULE-SET が先に国内直結へ寄せる、といった理由で raw.githubusercontent.com だけまっすぐ ISP へ出てしまい、そこで詰まることがあります。

対処の基本形は、DOMAIN-SUFFIX,githubusercontent.com もしくはより狭い DOMAIN,raw.githubusercontent.com を、広い GEOIP や「最終 MATCH」より上（先）に置き、希望する proxy-groups（例：PROXY や RULES-UPDATE のような名前の select）へ送ることです。グループ名はご自身のプロファイルに合わせて置き換えてください。ポイントは「ブラウザで見ている出口」と「コアがルール取得に使う出口」を同系統に揃えることで、片方だけ直結の抜けをなくすことです。

# Sketch — adjust group names and rule order to match your profile
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - node-a
      - node-b
      - DIRECT

rules:
  - DOMAIN,raw.githubusercontent.com,PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY
  # ... your other rules and RULE-SET lines ...
  - MATCH,PROXY

実際の並びでは、LAN や広告ブロック、国情報ルールなど必ず通したい DIRECT 行との兼ね合いがあります。githubusercontent.com を広く一枚敷くと、意図しない GitHub ホストまで同じ出口へ寄る副作用があるため、まずは raw.githubusercontent.com の一行から試し、ログで取りこぼしがあれば段階的に足すのが無難です。

手順 3：コア／GUI の「プロバイダ取得プロキシ」設定

近年の mihomo 系や一部 GUI では、rule-providers / proxy-providers の HTTP 取得に専用のプロキシを指定できる場合があります（キー名や可否はバージョン差があります）。グローバル TUN は有効でも、プロバイダ取得だけ別ダイレクトになっていると、ここを変えない限り症状が消えません。設定画面に「provider の更新経路」系の項目があれば、通常のブラウザと同様に安定したノードを選べるか確認してください。

手順 4：ミラー URL・別ホストへの差し替え

経路を寄せても遅い・公開ミラーに頼りたい場合は、同一内容を配信する別 URL に差し替える方法があります。例として、CDN 経由で Raw を参照するパターン（コミュニティやドキュメントで紹介される jsDelivr 形式の URL など）に置き換える手があります。利用するミラーの信頼性・利用規約・更新遅延は各自で確認し、可能なら自前のリポジトリ／自前ホストにルールを置いて rule-providers の url を一本化すると運用が安定しやすいです。

差し替え後は path に古いキャッシュが残っていないか、手動でプロバイダを再取得できる GUI なら一度リフレッシュし、interval が極端に短くレート制限に触れていないかも併せて見ます。

ヒント

behavior（domain / ipcidr / classical）と実ファイルの中身が一致していないと、取得できていても RULE-SET が期待どおりに効きません。タイポではなくタイプ不一致のときも「更新できない」と誤解されがちなので、HTTP ステータスが 200 かつボディ形式も確認してください。

interval・path・失敗時の挙動

interval が短すぎると GitHub 側や中継 CDN の制限に触れ、断続的に失敗することがあります。運用上は数時間おき以上から始め、安定してから詰めるのが安全です。path はローカルキャッシュの場所：ディスク書き込み権限や同期フォルダ上のロックも稀にトラブルの原因になるため、クライアント標準の配置に戻して試すのも有効です。

また、起動時に必ず最新を取りに行く設定のままオフラインや認証付きネットワークに入ると、プロファイル全体のロードが止まる実装もあるため、出差・セキュリティソフトのプロキシ挿入など環境変化とセットで記録しておくと再現が容易になります。

チェックリスト（短時間で再走査）

  1. DNS：raw.githubusercontent.com が意図したリゾルバで解決できているか。
  2. 分流：取得通信が DIRECT に落ちていないか（ルール順とログ）。
  3. コア設定：プロバイダ取得だけ別経路になっていないか。
  4. URL：Raw 直リンク以外のミラーに切り替え可能か、url が有効か。
  5. キャッシュ：path の古いファイルと behavior の整合。
  6. 間隔：interval が短すぎて失敗を誘発していないか。
注意

ネットワーク利用条件、所属組織のセキュリティポリシー、サービス利用規約は環境ごとに異なります。本稿は技術的なルーティングの整理であり、特定地域での規制回避を助言するものではありません。社内端末では情報システム部門の方針に従ってください。

まとめ

rule-providers が GitHub Raw から落ちてこない問題は、単一の原因ではなくDNS・分流・コアの取得経路・URL 先の到達性が重なることがほとんどです。まずログでホスト名と出口を確認し、raw.githubusercontent.com を広すぎない範囲で希望の proxy-groups へ寄せ、必要ならミラー URLや自前ホストへ差し替える——この三段構えで多くの「ずっと pending」は解消方向に動きます。RULE-SET と rules の順序は YAML 解説の方針と一貫させると、更新後も挙動が予測しやすくなります。

クライアントのビルドや OS ごとのパッケージを揃えたい場合は、ダウンロードページから入手するのが追跡しやすく、ルール取得の切り分けにも集中できます。ソースコードの参照は GitHub でもできますが、実行ファイルの入手経路は分けて考えると混乱が減ります。→ 無料で Clash をダウンロードし、rule-providers の取得ログと分流を確認する