一、rule-providers と RULE-SET の関係を押さえる
多くの構成ではノードリストは proxy-providers や購読 URI、細かいサイト別の命中は rules: の配列で表現されます。問題は、この配列だけを手編集すると巨大なドメイン一覧の保守にすぐ頭打ちになることです。そこでコア側がHTTP などで取得したルールセットをキャッシュとして保持し、名前付きプロバイダとして参照できるのがrule-providers:です。MihomoやClash Meta系では、この仕組みとRULE-SET, で始まる行がセットで説明されます。
流れだけ先に書くと、(1) rule-providers で名前・取得元・保存先・更新間隔を定義する、(2) ディスク上の path にクラシカル YAML／ドメインリスト／IPCIDRなど、宣言したbehaviorに合った内容が載る、(3) rules: のどこかに RULE-SET, が現れ、そこがヒットすると指定ポリシーへ進む——の三段です。購読が丸ごと上書きする環境でも、ユーザー差分・マージ機能でこのブロックを残せるようにしておくと、再セットアップのたびに手で貼り戻す手間が減ります。
behaviorは取得するファイル形式と一致させる必要があります。公開リポジトリの README に「classical 用」「domain 用」と分かれている場合は、そのラベルを崩さずに自分の YAML へ写してください。異なるラベルを当てはめると読み込み時に無音に近い失敗やログの一行エラーだけで止まりがちです。
分流の観点では、GEOIP や GEOIP ルールとも併存します。国内を DIRECT に寄せる GEOIP 記事では国コードベースを扱い、本稿は名前付きリストをリモート更新で追従させる側です。両方とも「評価順が命」ですが、使う情報源が違うだけなので混同しないようにしておけば競合は避けられます。
ノード一覧が空になりルールだけ疑っている場合は別筋の切り分けです。購読空亡とキャッシュの整理を先に片付けると、「RULE-SET はあるのに接続しない」問題の原因が proxies 側にあった、といった順序ミスが減ります。
二、YAML に rule-providers ブロックを足す（基本形）
典型的なHTTP 由来のクラシック形式は、名前（ここでは ads などの任意キー）の下に type: http、実体のbehavior、url、path、interval が並びます。path は最終的にディスクへ落ちる相対パスであり、環境によりワークディレクトリがプロファイル直下か、アプリケーションデータ配下かが変わります。書き換え権限がある場所へ寄せておけば、アップデート後も同じ設定で済みやすくなります。
rule-providers:
example-classical:
type: http
behavior: classical
url: "https://example.com/rules/sample.yaml"
path: ./ruleset/example.yaml
interval: 43200上はあくまで骨格サンプルであり、ご利用の実コア・GUI の版でキー省略や既定値があるかは要確認です。behavior に domain や ipcidr を選ぶときはソースがその型向けに生成されているかを先に見ます。二进制ルールファイル（環境により拡張子や取得方式が異なる）への対応を使うときは別途ドキュメントの「format」相当の項目を読み、単純コピペで型だけ合わせると失敗しやすいです。
名前は rules 側から参照される ID になる
rule-providers: の直下のキー名が、そのまま RULE-SET, の第二引数的な位置で参照されます。スペルミスすると起動ログに未定義として出てスキップされます。複数セットを増やすと長くなるので、_cn やサービス別の略号など、自分が grep しやすい規則に揃えておくと運用が楽です。
三、path と interval で「置き場所」と「自動更新」を設計する
path の役割は二つあります。第一に二度目以降の起動でネットワークがなくても最低限評価を継げるキャッシュファイルの所在を固定すること。第二に自分で差し替えたローカル版を読ませ続けたいときに、url を外す運用などとセットで検討することです（版によっては未取得時の挙動が異なるので、無通信での初回だけ注意）。
サンドボックス化されたモバイルクライアントではパス書き換えや外部エディタの可視領域が狭いことがあり、その場合でも GUI が path をどう組み立てているかだけは一度エクスポートして確認すると迷子になりません。また、SSD の容量より数十万行級のセットを複数並べたときのメモリ使用量の方がしきい値になるケースがあります。開発機とルーターのような薄い環境では、セットの数より一個あたりの行密度を意識した方が安全です。
intervalは秒で指定するのが一般的です。短くするほど新しいリストに追従しますが、(1) 取得失敗ログが増える、(2) 朝の時間帯に配布側がギュッとなる、(3) モバイル回線でのバックグラウンド更新が増える——といった副作用も出ます。現実的には数時間〜 1 日程度から始め、自分のリストの更新頻度に合わせて調整するのが無難です。緊急のリスト差し替えは GUI の手動更新か、ファイル直置き運用でも対応できます。
interval を極端に短くすると、公開されているルールセットのライセンスや利用規約、あるいは配布元インフラの観点で好ましくない場合があります。また、自動更新が失敗し続けると古いセットのまま誤遮蔽や誤通過が固定化するので、ログにリトライ理由がないか定期的に確認してください。
| 項目 | 設計メモ |
|---|---|
path |
ランタイムのカレントに依存しないよう、明示的な相対直下に ./ruleset/… のようにフォルダを掘ると他ファイルと混ざりにくい |
interval |
短すぎ回避。リストの実更新より短いサイクルに意味が薄いことが多い |
| 手動トリガー | GUI または API があれば、リリース直後だけ手動同期→以降自動、の二段運用も可 |
| 失敗時 | 前回キャッシュ評価にフォールバックしがち——「更新されていない」のと「リストが間違っている」の切り分けに注意 |
四、rules で RULE-SET を参照するときの並び順
rules: は上から順に最初の命中で止まります。ゆえに RULE-SET, をどこへ置くかで全体の分水嶺が変わります。典型は広い FINAL の直前に地域・広告・アプリ別のセットを並べる構成です。RULE-SET 自身にポリシー名を渡しますが、そのポリシーがproxy-groupsに存在しないとやはり起動検証で落ちます。
rules:
- DOMAIN-SUFFIX,company.internal,DIRECT
- RULE-SET,example-classical,REJECT
- GEOIP,CN,DIRECT
- MATCH,DEFAULTこの例では社内ドメインを押さえつつ、名前付きリストで拒否系をぶらさし、そのあと GEOIP で国コード分岐、と抽象的な順序イメージだけ示しています。MATCH（または FINAL 相当）の位置より上に自分のセットをすべて収める癖を付けると、思わぬ「最終行だけ効いていた」ミスが減ります。
ルールセットの評価は速い反面、巨大セットを先頭にゴンと置くとデバッグ時にログが読みにくくなることがあります。開発フェーズでは小さめのセットで線を確認し、安定後に本番セットへ載せ替えるような段階導入が安全です。
プロキシのレイテンシ選定とは別次元ですが、どのセットでどこへ張るかを揃える目的でurl-test と interval、tolerance の整理と併読すると、アプリ体感とリスト更新の両方を落ち着かせられます。また、鎖状の経路（relay）を検討しているならrelay／proxy chain の YAMLの前提も押さえてください。
五、リモート購読とのマージ、GUI が触るときの落とし穴
多くの利用者がリモートのサブスク URLから丸ごとプロファイルをダウンロードしています。このときユーザー追記ブロックへ rule-providers を書いても、GUI が保存時に同じキーを空に戻したり、並び順をソートし直したりする実装があります。症状としては「直したはずなのに次回開いたら無い」のですが、原因はYAMLの文法エラーというよりツール側のマージ規則だった、ということがあります。対処は、(1) マージ済み出力をファイルで証拠化する、(2) 名前の衝突を避ける、(3) ルールセット名をユーザー専用の接頭辞にする、程度から試します。
また、環境によりTUN とシステムプロキシだけ片方オンのとき、アプリによっては名前解決の経路やルールの見え方が変わります。DNS とセットを同じタイミングでいじるとログが複雑になるので、DNS の nameserver／fallback を整える別稿と役割分担し、変更は単層ずつ適用しましょう。
ひと段落、ツールチェーンより抽象的な視点で述べれば、クローズドアプリに閉じ込められたルールエディタは短い一覧には向いていても、数十プロバイダと長大な rules:を何年も追う用途では窮屈になりがちです。一方で純粋なテキスト運用は自由度が高い反面、版管理とバックアップを自分で背負います。
このトレードオフを踏まえると、ルールの更新・差分・Git 管理がしやすく、同じ YAML をデスクトップと薄型端末とで流用しやすいクライアントに価値が寄ります。巨大なコミュニティ資産であるルールセットをrule-providersで取り込み、intervalで追従しつつ path でローカルに残す——というパターンは、まさにその「流用しやすさ」を支える基盤です。
世の中にはブラウザ拡張一本や OS 付属の簡易プロキシ切替に留まる手法もありますが、細かなドメイン単位の制御と自動更新付きリスト、GEOIP と組んだ階段状の評価まで含めると機能が細切れになり、長期運用での再現性にも課題が出やすい傾向があります。対してClash系はルールモデルが一続きで説明でき、公開されているセットエコノミーとも相性が良いのが強みです。流れを自分の構成に沿って一度通したい方は、Clash クライアントを無料ダウンロードし、公式ドキュメントと合わせて手元の YAML を段階的に整備してみてください。
六、よくある質問
interval はいつカウントされますか？
実装詳細はコアごとですが、経過時間がしきい値を超えたタイミングで再取得が走るイメージです。イベント駆動の「リストが変わった瞬間」を即時検知できるわけではないので、作者が更新してから手元に届くまでの遅れは常にゼロにはなりません。運用上はログの更新成功行を見て安心するか、重要更新時は手動同期を併用してください。
path は絶対パスにすべきですか？
必須ではありませんが、どのプロセスがどのカレントで動いているかが曖昧な環境では絶対パスの方が事故が減ることもあります。逆にチームで設定を共有するなら、相対パス＋ディレクトリ構成の README の方が移植しやすいです。いずれにせよ書き込み可能であることが最優先です。
RULE-SET と古典的 DOMAIN／IP 行は共存できますか？
共存できます。むしろ局所的な例外的 DOMAIN 行を上に置き、広いセットをその下に置くといったチューニングが現場ではよく行われます。コメントで「なぜこの例外が必要か」を短文で残すと、数月後の自分を救います。
七、まとめ
Clash Meta／Mihomoでリモートのルールセットを真面目に運用するときの背骨はrule-providersです。pathでキャッシュ場所を明示しintervalで更新サイクルを現実値に抑え、そのうえでRULE-SET, を rules: の適切な深さに挿入する——この三本柱がそろって初めて「設定を書いたのに一覧が評価に出てこない」系の問題が減ります。購読マージや GUI の癖は出力ファイルで証拠を残し、DNS／GEOIP など別レイヤーの記事と役割分担してください。
追加の共通仕様や端末ごとの細部は、本サイトの ドキュメント索引から辿れる公式情報と、利用バージョンのリリースノートをセットで読むと抜け漏れがありません。