Clash の設定ファイルとは:Profile 構造の分解とマルチ設定切り替え管理

Profile とは何か

多くの人が「サブスクリプションリンク」と「設定ファイル」を同じものだと考えていますが、厳密にはこの2つは完全には同じではありません。サブスクリプションリンクは1つの HTTP アドレスであり、クライアントは定期的にこのアドレスへリクエストを送信します。返ってくる内容こそが本当の設定ファイルで、通常は YAML 形式のテキストであり、業界では Profile と呼ぶのが一般的です。クライアントはこのテキストをローカルにダウンロードし、解析して読み込みます。画面上で見えるノード一覧、プロキシグループの切り替えボタン、ルールのマッチング結果は、すべてこの YAML の内容から来ています。

Profile は本質的には構造化されたテキスト設定にすぎず、神秘的でも複雑でもありません。分解してみると、実際に機能している中核部分は3つのセクションだけです:ノード定義、プロキシグループの編成、ルール一覧。残りの項目の大半はポート、ログレベル、DNS といった動作パラメータで、この3つのセクションを理解すれば、Profile の動作方式はほぼ理解できたことになります。

ノード・プロキシグループ・ルール:3つのセクションがそれぞれ担うもの

Profile を上から下まで読んでいくと、内容は基本的に3つの階層で構成されていることが分かります。階層間には明確な参照関係があり、この参照の連鎖を理解していないと、その後のマルチ設定管理やルール調整で迷走することになります。

proxies:ノードとは何か

proxies セクションには利用可能なすべてのプロキシサーバーが列挙されており、各エントリにはサーバーアドレス、ポート、暗号化方式、パスワードや鍵などの接続パラメータが含まれ、それぞれ具体的なサーバーノードに対応します。この階層は最も基本的な「原材料」であり、直接トラフィックの流れを決めるものではなく、単に「利用可能なサーバーの一覧」を宣言しているだけです。

proxy-groups:プロキシグループとは何か

proxy-groups セクションは、上で宣言されたノードを論理的なグループにまとめます。よく使われるグループタイプには以下があります:

select——手動選択グループ。画面にノードボタンが並び、クリックしたノードが使われる;
url-test——自動速度測定グループ。遅延に基づいて自動的に最適なノードを選出し、通常は定期的な測定サイクルと組み合わせて使う;
fallback——フェイルオーバーグループ。メインノードが機能しなくなると自動的にバックアップノードへ切り替わる;
load-balance——ロードバランスグループ。複数のノードでトラフィックを分散する。

プロキシグループは互いに入れ子にして参照することもできます。例えば「自動選択」の url-test グループを、別の手動 select グループ内の選択肢として使うこともできます。この入れ子構造は、ルールのマッチング異常を調査する際に最も見落とされがちな部分です。

rules:ルールとは何か

rules セクションは上から下へ順に照合される一覧で、各ルールはマッチ条件と対象ポリシーで構成され、形式はおおむね次のようになります:

DOMAIN-SUFFIX,openai.com,US-Node
DOMAIN-KEYWORD,github,Auto-Select
GEOIP,CN,DIRECT
MATCH,Auto-Select

よく使われるマッチ条件には DOMAIN(完全一致のドメイン名)、DOMAIN-SUFFIX(ドメインサフィックス)、DOMAIN-KEYWORD(ドメイン内キーワード)、GEOIP(宛先 IP の所属地域に基づく)、IP-CIDR(IP レンジに基づく)があり、最後の1行は通常 MATCH で、「上記のいずれにも一致しない場合はこれを適用する」という最終ポリシーを表します。ルールは上から下へ1行ずつ照合され、一度マッチすると即座にそのポリシーが実行され、それ以降は照合を続けません——この「マッチしたら即停止」という特性が、後述するルールの上書き問題を理解する上での重要な前提になります。

Notice / 注意

ルールに記載する「対象ポリシー」は、前段の proxy-groups に既に存在するグループ名、あるいは DIRECT/REJECT という2つの組み込みポリシーでなければなりません。グループ名を誤って記述すると、そのルールがそのまま無効になったり、読み込みエラーが発生したりします。

複数のサブスクリプション設定が共存する場合の切り替えロジック

利用期間が長くなるにつれ、多くの人が手元に1つだけのサブスクリプションしか持たない、ということはなくなっていきます。プロバイダーによっては複数の経路をそれぞれ異なるサブスクリプションアドレスとして提供している場合もあれば、日常利用用のサブスクリプションと、特定用途のカスタムルール用サブスクリプションを同時に保持しているユーザーもいます。複数の設定が共存する場合、クライアントの処理方式はおおむね次のロジックに従います。

設定は排他的に読み込まれ、重ね合わせでは読み込まれない

クライアントはある時点で1つの Profile のみを読み込んで動作状態に入ります。設定の切り替えとは、本質的には「現在の設定をアンロードし、別の設定を読み込む」という過程であり、複数の設定のルールを重ね合わせて同時に有効化するわけではありません。この点は誤解されやすく、2つ目のサブスクリプションを追加すると両方のルールが統合されて有効になると思っているユーザーもいますが、実際には切り替えた瞬間に元の設定のノード、プロキシグループ、ルールはすべて置き換えられ、どちらの状態も混在して残ることはありません。

切り替えのタイミングと有効範囲

設定を切り替えるとプロキシグループとルールテーブルが再構築されますが、進行中の接続は通常中断されず、新たに開始される接続だけが即座に新しい設定のルールに従って処理されます。切り替え後に特定のサイトに突然アクセスできなくなった場合、多くは新しい設定における該当ドメインのルールポリシーが以前の設定と異なっていることが原因です。まずは新しい設定のルールマッチング結果を確認するべきで、慌ててクライアントを再起動する必要はありません。

自動更新と手動切り替えの境界線

各サブスクリプションは個別に自動更新の間隔を設定できますが、自動更新はそのサブスクリプション自身の内容を更新するだけで、現在どの設定が選択されているかには影響しません。つまり、バックグラウンドでは複数のサブスクリプションがそれぞれの周期で並行して更新され続けることができますが、画面上で有効になっているのは常に手動で選択した1つだけであり、更新の動作と切り替えの動作は互いに独立した2本のロジックであり、一方が他方を引き起こすことはありません。

命名習慣:マルチ設定を混乱させないために

設定の数が増えると、最初に問題になるのは技術的な部分ではなく「設定を見誤る」という人的ミスであることが多く、業務用のルールセットに切り替えたいのに、内容の似た別のサブスクリプションをクリックしてしまう、といったことが起こります。分かりやすい命名習慣を身につけておくことで、こうした確認作業に費やす時間を大幅に減らせます。

用途別に接頭語を付けて命名する:例えば「日常-XXプロバイダー」「業務用-ルールサブスクリプション」「テスト-自前ノード」のように、一目で使用シーンが分かるようにする;
更新周期や有効期限を記載する:速度測定のために一時的に使う短期のサブスクリプションであれば、名前に日付や「一時」といった文字を加え、正式な設定リストに長期間混在させないようにする;
デフォルトのファイル名を使わない:多くのクライアントではサブスクリプションを取り込むと「config.yaml」のようなデフォルト名が自動生成されますが、複数のサブスクリプションが同じ名前になるとほぼ区別できなくなるため、取り込んだら真っ先に名前を変更する;
サブスクリプションの出典を記録する:クライアントがメモ欄をサポートしている場合、対応するサービス提供元や用途をメモに記入しておくと、半年後にリストを見返してもすぐに思い出せる。

ルールの上書きを避ける管理方法

「ルールが互いに上書きされる」というのは、通常は2つの設定のルールが本当に統合されて衝突するという意味ではなく、ユーザーが同じ設定内で手動で追加・変更を行った後、次回のサブスクリプション自動更新でこれらの手動変更がサーバーから返された新しい内容によって丸ごと上書きされ、変更の痕跡が消えてしまうことを指します。これはマルチ設定管理において最も陥りやすい落とし穴の1つです。

上書きが発生する根本的な原因

ほとんどのクライアントはサブスクリプションを更新する際、リモートから返された完全な YAML の内容でローカルファイルを丸ごと置き換える方式を取っており、フィールドごとにマージするわけではありません。つまり、ローカルでルール一覧に手動でカスタムルールを1行追加していて、そのルールがサーバー側の元のサブスクリプションに存在しない場合、次回の自動更新が発生した瞬間、そのファイル全体が置き換えられることで手動追加したルールも消えてしまい、何の通知もありません。

3つの回避方法

クライアントの「オーバーライド」または「追加ルール」機能を使う:一部のクライアントはサブスクリプションとは別にローカルのオーバーライドファイルを個別に維持できる機能をサポートしており、サブスクリプションを更新してもサブスクリプション自体の内容だけが置き換わり、ローカルのオーバーライド部分は独立して保持・有効化される。これが最も推奨される方法;
該当サブスクリプションの自動更新をオフにし、手動で管理する:この設定でルールを頻繁に手動調整する必要があり、かつプロバイダー側の更新頻度が高くない場合は、自動更新を直接オフにしてしまうという手もあります。変更は自分が明示的に「更新」をクリックしたときのみ上書きされるため、リスクを抑えられる;
カスタムルールを独立した設定として保存し、サブスクリプション変換ツールで結合する:多少の作業ができるユーザーに向いています。手動ルールを独立したルールファイルとして管理し、サブスクリプション変換サービスを使って元のサブスクリプションとカスタムルールを結合して新しいサブスクリプションアドレスを生成する方法です。この方法なら毎回の更新で取得するのは既に統合済みの内容になり、クライアント側で繰り返し手動でルールを補完する必要がなくなります。

Notice / 注意

クライアントがローカルオーバーライド機能をサポートしているか分からない場合は、まず手動変更のテストをしてみましょう:変更したらすぐに手動で「サブスクリプションを更新」を実行し、変更が消えてしまうかどうかを確認します。挙動を確認した上でどの方法を長期的に採用するか決める方が、後からルールが失われて慌てて対処するより手間がかかりません。

日常メンテナンスでのチェック項目

設定数が増えてきたら、いくつかの定期チェックを習慣化しておくと、問題が大きくなる前に異常を発見できます:

定期的にルール一覧を開き、最後の1行の MATCH 最終ポリシーが指しているプロキシグループが期待通りかを確認し、サブスクリプション更新によって最終ポリシーが密かに変更されていないかを避ける;
設定を切り替えた後は、クライアント内蔵の遅延テスト機能でノードの状態を1回リフレッシュする。新しい設定のノードプールは以前の設定と完全には一致しないことが多い;
複数の設定を同時に維持している場合は、一定期間ごとに使わなくなった古いサブスクリプションを整理し、誤って切り替えてしまう確率を減らす;
手動で追加したルールについては、その都度ローカルにバックアップを取る習慣をつける。オーバーライド機能を使っている場合でも、クライアントのデータ消失に備えてテキストのコピーを1つ保存しておくことを推奨する。

ノード、プロキシグループ、ルールという3階層の参照関係を整理し、それに分かりやすい命名と適切な更新戦略を組み合わせれば、複数の設定が共存していても負担にはならず、逆にシーンごとのトラフィック振り分けをより精密かつ制御しやすくできます。