Clash 設定ファイル(Profile)の構造解説:フィールドの意味と複数サブスクリプションの管理方法

Profile とは何か

Clash のエコシステムにおいて「設定ファイル」(Profile)とは、YAML 形式のテキストファイルを指す。この中にはローカルのポート、アウトバウンドノードの一覧、プロキシグループの分類ロジック、そして一連の振り分けルールがまとめて記録されている。クライアントの画面に表示されるポリシーグループ、遅延計測、ルールマッチ結果は、突き詰めればすべてこの YAML を解析・レンダリングした結果にすぎない。サブスクリプションリンクを手動で入力する場合でも、ローカルファイルをインポートする場合でも、クライアントが行っている作業は本質的に同じで、リモートあるいはローカルのこのテキストを取得し、フォーマットを検証してから、コア(Clash Premium または mihomo)に渡して読み込ませているだけである。

Profile の構造を理解しておくメリットは、トラブルシューティングが速くなるだけではない。より重要なのは「どの変更が安全で、どの変更が次回のサブスクリプション更新で上書きされてしまうか」を判断できるようになることだ。これが本稿で明らかにしたい核心の問題である。

フィールドの分解:1 つの Profile に何が書かれているか

完全な Profile はおおむね 4 つのブロックに分けられる。順序に決まりはないが、クライアントの画面では通常次のようなロジックでグループ化して表示される。

1. 基本動作パラメータ

このセクションはコアがどのポートを監視し、どのモードで動作するかを決める。代表的なフィールドは以下の通り。

これらのフィールドの大半はデフォルト値を持っており、クライアント GUI の「ポート設定」「混合ポート」「LAN 接続」といったスイッチは、実際にはこのブロックの内容を変更しているにすぎない。

2. proxies:ノード一覧

proxies は配列で、各要素が 1 つのアウトバウンドノードを表す。代表的なフィールドは name(表示名)、type(プロトコル種別。ss、vmess、trojan、hysteria2 など)、server、port、そしてプロトコル固有の暗号方式・UUID・パスワードなどのパラメータである。このセクションは基本的に手動で編集する必要がない――サブスクリプション提供者側が生成するものであり、利用者側はサブスクリプションリンク自体が有効かどうかを確認するだけでよい。

3. proxy-groups:ポリシーグループ

proxy-groups はノードをどのように「選択可能なグループ」としてまとめるかを決める。各要素の代表的なフィールドは以下の通り。

• name:グループ名。ルールセクションからこの名前が参照される
• type:グループの種別。select(手動選択)、url-test(自動測定による切り替え)、fallback(失敗時の自動切り替え)、load-balance(負荷分散)などがある
• proxies:そのグループに含めるノード、または他グループの名前
• url / interval:url-test と fallback タイプで使用し、測定先アドレスと検査間隔(秒)を指定する

クライアント画面に並ぶ「ノード選択」のドロップダウンリストは、ここに定義された select タイプの各グループに対応している。

4. rules:振り分けルール

rules は上から順にマッチングされるリストで、書式は通常 タイプ,マッチ対象,適用先ポリシー となる。代表的なタイプには DOMAIN-SUFFIX(ドメインサフィックス一致)、DOMAIN-KEYWORD(ドメインキーワード一致)、IP-CIDR(IP 範囲一致)、GEOIP(地理位置データベースによる判定)、RULE-SET(外部ルールセットの参照)などがある。最後には通常 MATCH,ポリシー名 という兜底ルールが置かれ、それまでのどのルールにも一致しなかった通信をすべてここで処理する。ルールリストは上位ほど優先度が高く、一度マッチしたら後続のルールは判定されない。

サブスクリプション更新時、どの内容が上書きされるか

ここが最も落とし穴になりやすい部分である。サブスクリプションリンクは提供者側でホストされている完全な YAML を指しており、クライアントの「サブスクリプション更新」という操作は、本質的にこのファイルを再ダウンロードしてローカルキャッシュを丸ごと置き換える処理である。つまり proxies(ノード一覧)、proxy-groups(ポリシーグループ構造)、rules(ルールリスト)の 3 つは、サブスクリプション提供者側の元ファイルに含まれていれば、更新後にすべて提供者側の最新版で上書きされる――手動で追加した独自ルールや、並び替えたグループ順序は、ほぼ確実に消えてしまう。

一方、ポート・LAN スイッチ・モードといった基本動作パラメータについては、クライアントによって扱いが異なる。多くの GUI クライアントはこれらを「実行時オーバーライド」として個別に保存し、サブスクリプションファイル自体には書き戻さないため、サブスクリプションを更新してもポート設定には影響しないことが多い。ただし、ローカルの YAML ファイルを直接編集し、それを「ローカル設定」としてインポートして使っている場合は、サブスクリプションリンクの更新機構を経由していないため、そもそも「再ダウンロード」という動作自体が存在せず、上書きの問題は発生しない。

特に注意すべきケースとして、一部のサブスクリプション提供者はリンク生成時にパラメータを付加し、独自ルールの挿入や特定グループの強制指定を行える。こうした内容も更新のたびに再度書き込まれるため、ローカルでの変更とは共存できない。判断の要点は一つだけである。その内容が「ダウンロード」によって得られたものであれば、次回更新時に必ず再ダウンロードされて上書きされる。

複数の設定ファイルの管理:切り替え・重複排除・バックアップ

多くの GUI クライアント(Clash Verge Rev、FlClash、ClashX Meta など)は複数の Profile を同時に保存でき、画面上のリストからサブスクリプションやローカルファイルを互いに影響を与えずに切り替えられる。複数の設定を管理する際は、次のような原則に従うとよい。

用途ごとに分けて保存し、同じファイルを繰り返し書き換えない

複数のサブスクリプション提供者を併用している場合や、日常用と新規ノード検証用を分けたい場合は、それぞれを独立した Profile として保存すべきで、同一ファイル内でコピー&貼り付けを繰り返して切り替えるべきではない。こうしておけば、切り替え時はクライアントのリストから選ぶだけでよく、テキスト編集が発生しないためミスが起きにくい。

ローカルオーバーライドルールで、更新による消失を防ぐ

長期的に維持したい独自ルール(例えば特定の内部サービスをホワイトリスト化して直接接続させるなど)がある場合は、クライアントが提供する「オーバーライド」や「マージ」機能を使うのが最も確実である。多くの現代的なクライアントはサブスクリプションとは別にローカルオーバーライドファイルを維持できるため、サブスクリプション更新時に置き換わるのは提供者側の元コンテンツのみで、ローカルオーバーライド部分は独立したまま保持され、一緒に消えることはない。この機能がないクライアントの場合は、更新前に現在有効な YAML を手動でバックアップし、更新後に独自ルールの部分を貼り戻すという方法で対応する。

重複ノードや無効ノードの定期整理

同じサブスクリプションアカウントを長期間使い続けると、ノード一覧が冗長になったり、すでにサービス終了したノードがグループに残ったままになったりすることがある。次のような点検を習慣化するとよい。

1. 現在有効な Profile を開き、proxies の件数がサブスクリプション提供者の管理画面に表示されているノード数と一致しているか確認する
2. url-test タイプのグループに対して一度手動で速度測定を行い、長期間利用不可のノードを除外する(クライアントによっては画面上から直接グループ除外できる)
3. proxy-groups 内で同一ノードが重複参照されてグループが混乱していないか確認する

バックアップに必要な最小限のセット

新しいデバイスへ移行する場合や、クライアントを再インストールする場合でも、次の 2 種類の内容を保持しておけば、以前の利用状態をほぼ完全に復元できる。1 つはサブスクリプションリンク自体(いつでも最新のノードとルールを再取得できる)、もう 1 つはローカルオーバーライドや独自ルールファイル(存在する場合)である。クライアントキャッシュの一時ファイルを追加でバックアップする必要はなく、それらは次回サブスクリプションを取得した際に自動で再生成される。

よくあるトラブルと対応するフィールド

前述のフィールド区分に基づけば、よくある問題のほとんどは具体的なブロックに絞り込める。

• ネットに接続できない、プロキシが機能しない:まず基本動作パラメータブロックのポート設定と mode が想定通りかを確認する
• あるサイトが想定と異なるノード経由になる:rules ブロックに戻り、順番に前方のルールが先にマッチしていないか確認する。ルールリストは上から順に短絡的にマッチする
• ノードを切り替えても反映されない:対応する proxy-groups の type が select になっているか、クライアント画面で選択したグループ名とルールから参照されているグループ名が一致しているかを確認する
• サブスクリプション更新後に独自ルールが消える:これは本文第 3 部で説明した上書き機構によるもので、想定通りの動作である。独自内容を保持したい場合はローカルオーバーライド方式に切り替える必要がある

Profile を一まとまりの構造化された設定文書として理解し、読み解けない YAML テキストの塊として捉えないようにすれば、大半のトラブルシューティングは根拠のある作業に変わる。画面上のあるスイッチの効果が想定と一致しない場合は、対応するフィールドの値を確認する方が、クライアントの再インストールを繰り返すよりも効果的なことが多い。