Clash Rule Provider でルールセットが取得できない？YAML・path・interval とログの切り分け（2026）

リモートルールは「購読」とは別レイヤー

Clash や Mihomo（Clash Meta） でノード一覧を取り込む proxies の購読 URL と、広告ブロック用リストやコミュニティ製の分流リストを取り込む rule-providers は、設定上も更新タイミングも別物です。プロキシ購読が成功していても、Rule Provider だけが「更新失敗」「古いまま」「そもそもファイルが無い」となるケースは日常茶飯事です。本稿では、YAML の書き方、path と interval の意味、ログに出るメッセージとの突き合わせ方に絞って、自分の環境で何を直せばよいかを短時間で特定できる手順をまとめます。

ルールの評価順や GEOIP との組み合わせといった「分流の設計」そのものは、ルール分岐の詳解ガイドで扱っています。ここではあくまで外部ルールセットをどう取り込み、どう更新するかのインストール感覚のパートです。購読 URL 全般の取り込み手順は サブスクリプションインポートガイドと併読すると、設定ファイル全体の見通しが立ちやすくなります。

rule-providers と RULE-SET の関係

rule-providers ブロックでは、名前付きのプロバイダーを宣言します。本体の rules: からは RULE-SET,<名前>,<ポリシー> の形で参照し、プロバイダーが展開したルール群をその位置に挿入するイメージです。名前のスペルミスや、宣言していない名前を RULE-SET で指すと、起動時またはリロード時にエラーになります。GUI で追加したつもりが生 YAML では別名になっている、というケースもあるため、宣言名と参照名を必ず一致させて確認してください。

behavior は、取得したファイルをどう解釈するかを決めます。代表的には domain（ドメインリスト）、ipcidr（CIDR リスト）、classical（従来型のルール行）などです。配布元のファイル形式と behavior が噛み合わないと、ダウンロードは成功してもパース段階で失敗します。コミュニティの README に推奨 behavior が書いてある場合はそれに従うのが最も安全です。

正しい YAML の骨格（http 型）

HTTP(S) から取得する典型形は次のようなイメージです。インデントは YAML の命綱なので、エディタで空白の深さが崩れていないか必ず確認してください。

rule-providers:
  my-rules:
    type: http
    behavior: classical
    url: "https://example.com/ruleset.yaml"
    path: ./rules/my-rules.yaml
    interval: 86400

url はルールセットの実体への直リンクです。リダイレクト連鎖や認証ヘッダ必須の URL は、ブラウザでは開けても Clash 側の単純な GET では失敗することがあります。path は取得結果を保存する相対パスで、実行時の作業ディレクトリ（プロファイル所在やアプリのデータディレクトリ）基準になることが多いです。相対 path が意図せぬ場所を指していると、「ファイルはあるはずなのに読めない」「権限がない」といった症状が出ます。

interval：秒単位の自動更新間隔です。短くしすぎると配布元に負荷がかかるうえ、自分の回線でも頻繁な失敗ログが増えます。まずは配布元の推奨値や一日一回（86400 秒）程度から始め、安定してから調整するのが無難です。

PATH でハマりやすいポイント

Windows と macOS／Linux でパスの扱いが変わるため、コピペしたサンプルがそのままでは動かないこともあります。バックスラッシュとスラッシュの混在、先頭の ./ の有無、プロファイルを GUI が別フォルダにコピーしている場合のズレなどが典型です。更新後に「キャッシュが古い」と疑う前に、実際に指定パスにファイルが生成されているか、タイムスタンプが更新されているかをエクスプローラや ls で見ると早いです。

オフライン運用や自前ミラーを使う場合は type: file とローカル path の組み合わせも選べます。ネットワーク取得を完全に切る代わりに、ファイルの手動配置と権限管理が自分の責務になります。チームで配布するなら、リモート URL とローカル file を環境ごとに切り替えるコメントを YAML 側に残しておくと運用が楽です。

取得失敗：ログと HTTP ステータスの対応

ログに 403 や 404 が出る場合は、URL の誤り・期限切れトークン・リファラ検知などサーバー側要因を疑います。ブラウザで開けるのはログイン Cookie があるから、というパターンも多いです。公開 RAW URL や GitHub の raw リンクに差し替えられるか、配布元のドキュメントを確認してください。

TLS 関連のエラーは、企業プロキシのインタセプト、古いルート証明書、時刻ずれなどが原因になります。一時的に別回線で試す、システム時刻を合わせる、といった切り分けが有効です。タイムアウトばかりが続くときは、Rule Provider 用の URL だけがブロックされている可能性もあるため、同じホストへブラウザと curl で並べて試すと原因が絞れます。

ダウンロード自体は成功しているのに「parse error」「invalid」などと出る場合は、返ってきた中身が HTML のエラーページ（404 ページ）になっているケースがあります。保存された path のファイルをテキストエディタで開き、先頭が <!DOCTYPE html> になっていないか確認すると一発で判明することがあります。

behavior と中身の不一致を疑う

domain 用に最適化されたリストを classical として読み込もうとすると失敗します。逆もまた然りです。配布ページに「Mihomo 向け」「Clash Premium 向け」など複数フォーマットがあるときは、自分が引いている URL がどの形式かを取り違えていないかを再確認してください。変換ツールでフォーマットを変えたファイルを自前ホスティングする運用では、変換ミスで空行やコメント規則が壊れていないかも見ます。

RULE-SET を挿入する位置

RULE-SET は rules: リストの一行として評価順に従います。細かい例外ルールより下に巨大な RULE-SET を置くと、そこで先にマッチしてしまい意図と逆の出口に落ちます。更新失敗とは別問題ですが、「ルールセットを入れたら挙動がおかしくなった」場合は挿入位置を最初に疑ってください。ルール分岐ガイドの評価順の節とあわせて読むと整理しやすいです。

GUI 利用者向けのチェックリスト

Clash Verge 系などでは、プロファイルの保存場所と GUI が内部で行うダウンロードのパスがユーザー視界から隠れがちです。ルールプロバイダー一覧に最終更新時刻やエラー表示があればそれを手掛かりにし、無い場合はログレベルを上げてプロバイダー取得ログを有効にします。設定をいじった直後だけ失敗するなら、一時ファイルのロックやウイルス対策ソフトのリアルタイムスキャンが疑われることもあります。

オープンソースと入手経路

Mihomo／Clash 系の挙動差はリリースノートや Wiki で追えます。ソースや Issue は GitHub で公開されていることが多く、深い不具合調査には有用です。日々のクライアントの入手と更新は、説明が揃った配布ページを使うと取り違えを防ぎやすくなります。当サイトのドキュメント索引から関連ガイドへ辿れます。

まとめ

Rule Provider まわりのトラブルは、大きく分けて「URL／ネットワーク」「path と権限」「behavior とファイル形式」「RULE-SET 名の不一致」「rules: 内の挿入位置」の五つに整理すると切り分けが速くなります。interval は更新頻度のノブであると同時に、失敗ログの再試行間隔でもあるため、まず安定取得を優先しましょう。

同種ツールのなかでも Clash 系はルール表現とログの両方が扱いやすく、長期運用向きです。Windows／macOS／Linux／モバイル向けビルドはダウンロードページから環境に合わせて選べます。プロキシ購読とルールセット取得の両方が揃って初めて分流が意図どおりに効くため、設定を一段理解したタイミングでクライアントを最新に保つと安心です。→ Clash クライアントを無料でダウンロードし、Rule Provider を試す