本稿で整理できること
リモートのドメイン・IP リストや古典ルール断片を rule-providers として購読し、rules に RULE-SET 行で取り込むときの典型 YAML と、interval（多くは秒単位）の考え方、url と path の分担、プロファイル再読込後のログ確認までを一連で押さえます。あわせて GEOSITE／GEOIP が参照する geodata 更新とは設定キーが別である点を切り分け、更新が効かないと感じたときの第一段の疑いどころを短いチェックリストでまとめます。
rule-providers が担う役割
rule-providers は、設定のトップレベルに置くマップで、各キーが「プロバイダ名」になります。各プロバイダは通常 type: http などでリモートから取得し、取得結果を path で指すローカルファイルにキャッシュします。以降、rules から RULE-SET,プロバイダ名,ポリシー の形でその集合を参照します。GUI の「ルールプロバイダ」メニューが内部で同じ宣言を書き換えている場合も、最終的にはこの構造に収束します。
behavior（例：classical、domain、ipcidr）は、購読ファイルをどの種別のルール集合として解釈するかに関わります。format（yaml、text、新しめのニーズ向けの mrs など）は利用中の Mihomo バージョンの対応表を必ず確認してください。古い記事のコピペだけだと、静かに読み込みエラーになるパターンがあります。
GEOSITE・GEOIP（geodata）とは別パイプライン
GEOSITE 行は geosite.dat などのgeodata に含まれるカテゴリ名（いわゆる geosite カテゴリ）を参照します。GEOIP 行は geoip.dat 側の国コードマッチです。これらは rule-providers の url とは無関係に、別設定やクライアント機能で geodata ファイル自体が更新されます。したがって「ルールプロバイダの更新間隔を短くしたのに GEOIP が古い」と感じる場合、見ているファイルが違う可能性が高く、geodata 側の更新ポリシーを別途確認してください。読み方の骨格は引き続き GEOIP／GEOSITE 記事 が基準になります。
整理：「リモートのルール断片を取る」＝ rule-providers。「組み込みカテゴリで巨大集合を参照する」＝ GEOSITE。「接続先 IP の国」＝ GEOIP。ログのどの段で止まっているかで、直す field が変わります。
YAML の書き方スケッチ（url・path・interval）
次の例は説明用のスケッチです。プロバイダ名は任意、url は実際に配布しているミラーを選び、path はクライアントが書き込める場所に向けます。interval は秒で、一日一回なら 86400 のようにします。環境によっては起動直後や再読込直後に即時フェッチが走るため、開発中に短い値を入れ続けると外部サービスへ負荷が乗りやすい点に注意してください。
# Sketch — replace url/path with your mirror and writable cache path
rule-providers:
community-classical:
type: http
behavior: classical
format: yaml
url: "https://example.com/rules/classical.yaml"
path: ./ruleset/community-classical.yaml
interval: 86400
rules:
- DOMAIN-SUFFIX,local,DIRECT
- RULE-SET,community-classical,PROXY_GROUP
- MATCH,DIRECT
interval の決め方とレート制限
コミュニティ公開のルール集合は、購読 URL が静的ファイル直リンクの場合もあれば、リダイレクトや CDN でキャッシュヘッダが強く効く場合もあります。テストで interval を数分単位に切っていて、本番もそのままにすると、ミラー提供者のポリシーと衝突して HTTP 429 や 403 を踏むことがあります。購読元が推奨する間隔や README の注意書きがあれば最優先し、なければ一日一回〜数時間おき程度から様子を見るのが無難です。サブスクリプション全体の更新間隔とは別タイマーなので、二重に短周期フェッチが走っていないかもダッシュボードで確認すると安心です。
path と url の棲み分け（失敗時の典型）
path：書き込み権限と相対パスの解釈
path は「取得済みルールファイルをどこに置くか」です。相対パスは作業ディレクトリやプロファイルの所在に依存するため、ポータブルに運用したい場合は絶対パスに寄せる・またはクライアント既定の ruleset ディレクトリを使う、といった決めをしておくとトラブルが減ります。書き込みに失敗していると、更新ログは成功に見えても実ファイルが空のまま、というケースが稀にあります。権限エラーやパスの打ち間違いを最初に疑ってください。
url：到達性、TLS、プロキシ経路
取得自体がプロキシ越しになる構成では、「ルール更新トラフィック」が自分自身のポリシーに巻き込まれてループしないよう、例外や DIRECT 路をどう敷くかが課題になります。TUN やシステムプロキシ環境では、ターミナルからの curl では届くのに内核フェッチだけ失敗する、といった差も起きます。ログに TLS エラーや証明書検証失敗が出ていないかを併せて見てください。
RULE-SET を rules に挿入するときの順序
Clash 系は rules を上から評価し初回マッチで停止します。巨大な RULE-SET を先頭に置くと、下流の細かい DOMAIN 例外が到達不能になります。社内ホストや決済ドメインなど確実に直結したい行は、購読ルールより上へ。逆に「購読セットに丸投げ」の構成では、ローカル追記が GUI のマージで押し下げられないかだけは定期的に目視してください。ルール順・一致優先度 の記事とあわせると、挙動の説明が容易です。
反映確認の短いチェックリスト
- プロファイルを再読み込みしたあと、rule provider の最終取得時刻が更新されているか見る。
path先のファイルサイズがゼロばかりでないか、タイムスタンプが動いているか確認する。- テスト接続を出し、ダッシュボードのルールヒットが
RULE-SET行に落ちているか見る。 - GEOSITE 期待なのにヒットしないときは、geodata のバージョンとカテゴリ名を疑う（本稿の主題は外れるが切り分けはセット）。
- 更新ログに 429／403 が連発するなら
intervalを延ばし、取得元を分散するか README を読み直す。
よくある質問（要約）
Q. format に mrs を付けたらエラーになる。 利用中のバイナリがその形式を解釈できるかを確認し、無ければ yaml や text 側の URL に切り替えます。Q. interval をゼロに近くしたい。 開発用ならローカルファイルへ退避して手動差し替えの方が外部に優しい場合があります。Q. GUI だけ触っていて YAML が分からない。 エクスポート機能のあるクライアントでは実体をダンプして差分管理すると、更新間隔と URL の所在が見えやすくなります。
コンプライアンスの注意
職場・学校・契約ネットワークではプロキシや外部ルール集合の利用が制限されている場合があります。許可された環境でのみ設定し、第三者のインフラに過剰な自動アクセスを行わないでください。
注意：本稿のコードはスケッチです。キー名・省略形・拡張フラグは Mihomo の該当バージョンの公式ドキュメントと突き合わせてください。
ドキュメントとクライアント入手
用語対照は ドキュメント・チュートリアル、入手経路の整理は 公式ダウンロードページ が安全です。自作マージ運用なら mixin／merge 記事 と併せると、ベース設定を触らず追記だけで rule-providers を足しやすくなります。
まとめ
rule-providers は、リモートのルールセットを URL で購読し、path にキャッシュし、interval で再取得するための宣言ブロックです。GEOSITE や GEOIP が見ている geodata とは別物なので、更新が「古い」と感じる場所がどちらのファイル系かをログとヒットで切り分けるのが早道です。短すぎる interval はレート制限とセットで起きやすく、運用ポリシーと衝突しない値に落ち着かせましょう。
手書き YAML だけで運ぶ場合、更新 URL の散逸や interval の置き忘れが起きやすく、トラブル時に「どのミラーを信じているか」が曖昧になりがちです。公式チャネルから入ったクライアントでは、宣言を UI に寄せつつも実体はテキストとしてエクスポートでき、ルール購読と geodata の更新ログを同じ画面から辿れることが多いです。手元の作業を減らしつつ安全に配布物を追いかけたい場合は、公式ページから Clash を入手し、本稿のチェックリストに沿って rule-providers と geodata の両脚を点検すると、原因の切り分けがかなり速くなります。