そもそも「ルールセット」で何が決まるのか
Clash系クライアントは、接続先ごとにDOMAIN・IP-CIDR・GEOIPなどの条件を評価し、マッチした行に従ってプロキシ・DIRECT・REJECTへ振り分けます。ここで使うリストが巨大になるほど、国内外のWebサービスをどこまで細かく区別するかという「運用の政治」が表に出ます。単一の購読YAMLだけでは、動画・SNS・開発向けCDNなどの例外をすべて手書きするのは現実的ではありません。その穴を埋めるのが、GitHub等で公開されているルールプロバイダー向けの集合体です。
ACL4SSRとLoyalsoldierは、その中でも参照回数が多い二系統です。どちらも「中国本土向け／海外向け」といった大枠の発想を共有しつつ、細目のドメイン分類・広告ブロックの同梱・GEOIPとの併用前提など、設計思想に差があります。重要なのは「どちらが絶対に正しい」ではなく、自分が優先したい価値（遅延・省メモリ・網羅性・メンテのしやすさ）に沿って選ぶことです。
ACL4SSR系ルールの特徴
ACL4SSRは、長らく中国語圏のコミュニティで共有されてきたルール群を指す総称として広く知られています。名前にSSRが入っていますが、現代のClash運用ではルールの出所としてのブランドに近く、プロトコルそのものとは直接結びつきません。特徴として、用途別に細かくファイルが分割されていることが多く、動画・SNS・Apple・Microsoftなどカテゴリ単位でrule-providersを組み合わせやすい構成が採られがちです。
メリットは、テンプレートが豊富で「まず動く」状態にしやすい点です。初めて分流を組む人でも、代表的なプリセットをそのまま取り込めば、国内外の主要ドメインが一通りカバーされることが多いです。一方で、カテゴリが細かいほどルール総量とメモリ使用量は増えます。低スペック端末やモバイルでは、更新間隔や読み込むファイル数を絞る必要が出てきます。
Loyalsoldier系ルールの特徴
Loyalsoldier名義で公開されているルール群は、GFWList系のドメイン集合や、DNSブロック用途のリストなどを、Clash向けに再配布・変換しやすい形でまとめ直している例が知られています。思想としては「よく使われるベースラインを、一つの更新フローで追いやすくする」方向が強く、単一リポジトリで種類の一覧を眺めやすい運用がしやすいです。
長所は、更新の追い方が素直で、差分の説明が読みやすいリポジトリも多いことです。ルールの「出所」が明確だと、特定サービスだけ意図せず直結してしまうといったトラブル時に、Issueやコミットログから原因を辿りやすくなります。短所としては、利用者の環境によってはACL4SSR系のプリセットほど細かいシナリオ分けが最初から揃っていない場合があり、その分はRULE-SETの追加やローカルrulesでの補強が必要になることがあります。
比較の軸：保守・網羅性・負荷・カスタムのしやすさ
保守と更新頻度
どちらの系統も、上流リストの変更や新サービスのドメイン追加に追随する継続的なメンテナンスが前提です。公開リポジトリの最終更新日・Issueの応答・Actionsの成否を定期的に見る習慣があると安心です。逆に、数か月以上止まっているミラーをそのまま固定URLで引いていると、新しいCDNドメインが取りこぼされ、遅い・繋がらない症状の原因になりがちです。
網羅性と「過剰マッチ」
網羅性が高いほど意図しない経路にもマッチしやすくなります。例えば、国内向けと思っていたドメインが実際は海外CDNの別名で解決され、プロキシを余計に踏む、といった現象です。どちらのセットを使うにせよ、クライアントの接続ログとルールヒットを一度は眺め、自分のよく使うサービスが期待どおりか確認する工程は欠かせません。
ルール量とパフォーマンス
rule-providersは、設定ファイルに直書きするより更新と差し替えが楽ですが、読み込むセットが増えるほど起動時・プロファイル切替時のコストも増えます。ACL4SSR系でカテゴリを広く取るほど、この傾向は顕著です。一方、Loyalsoldier系でミニマルな集合だけを選ぶほど軽量になりやすい反面、例外の手当ては自分で足す場面が増えます。
実務のコツ：まずは用途の少ないサブセットから始め、ログを見ながらrulesの先頭に自分専用のDOMAINを数行足す、という順が安全です。一気に「フルセット」を有効にすると、切り分けが難しくなります。
ユースケース別：どちらを優先しやすいか
とにかく代表的な国内外振り分けを早く整えたい場合は、ACL4SSR系の完成度の高いプリセットをベースにし、重いカテゴリだけ後から削る方法が向きます。リストの出所と更新履歴を自分で追いたい、あるいはルールを極力絞って軽量化したい場合は、Loyalsoldier系から必要なファイルだけを選び、足りないドメインをローカル追記する構成が合いやすいです。
ゲーム・P2P・社内VPNなど、UDPや特定ポートが絡むトラフィックは、ルールセット以前にmodeやTUN、プロファイル側の挙動が支配することがあります。分流だけいじって改善しないときは、TUNモードとクライアント設定の見直しもセットで検討してください。
Subconverterや購読との組み合わせ
購読URLを変換してYAMLを得る流れでは、テンプレート側に既製ルールがマージされることがあります。変換結果に含まれるproxy-groups名と、ルールが参照するグループ名が一致しているかは必ず確認してください。詳しい変換の型については、Subconverter完全ガイドを参照すると、購読→YAML→クライアントの一連のつながりが掴みやすくなります。
クライアントのバイナリ自体は、ダウンロードページから揃えるのが、配布物の出所を明確にできます。設定の用語や項目の意味を押さえたいときは、ドキュメント・チュートリアルと併読すると、rulesとrule-providersの関係が理解しやすくなります。
リポジトリ参照と入手経路の切り分け
ルールセットの最新の生データやIssueを確認する用途では、各プロジェクトのGitHubページを開くのが適切です。一方、日々のClashクライアント本体のインストールは、本サイトのダウンロード導線を主にすると、リリース資産の取り違えを防ぎやすくなります。ルールのURLとアプリの入手元を混同しないようにしてください。
よくあるつまずき
想定と違う出口IPになる：ルールより前にDNSが別経路を向いている可能性があります。FakeIPやDoHの設定と整合を取る必要がある場合は、DNSまわりの別記事も参照してください。
更新しても特定サイトだけ遅い：ルールセットのキャッシュが古い、あるいはCDNの別名ドメインが未収録、のどちらかが多いです。該当ドメインをログから特定し、一時的にDOMAIN-SUFFIXで直指定して切り分けます。
メモリやCPUを食う：有効にしたrule-providersの数と、behavior・更新間隔を見直します。フルセットをやめてカテゴリを減らすだけで改善することも珍しくありません。
法令と規約：プロキシとルールの利用は、居住地域の法律および各サービスの利用規約に従ってください。本稿は技術的一般論であり、特定の制限回避を推奨するものではありません。
まとめ
ACL4SSR系は、豊富なプリセットで素早く全体像を組み立てやすい一方、ルール量とメモリ負荷への配慮が必要です。Loyalsoldier系は、ベースラインを軽めに保ちつつ更新を追いやすい反面、細かいユースケースは自分で補う場面が出やすいです。どちらを選んでも、ログで実測し、ローカル例外を少しずつ足していくのが、長く安定する分流運用の近道です。
同種のルールをいくつも重ねるより、一つのクライアントにプロファイルとルールの更新フローを集約し、購読とルールプロバイダーの両方を定期的に点検する習慣を持ったほうが、結果としてストレスの少ない接続体験になりやすいでしょう。Clash Verge RevのようなMetaコア搭載クライアントであれば、GUIからプロファイル切替とログ確認が一続きになり、ルール調整の試行錯誤もはかどります。