Clash Profileとは？複数のサブスクリプションとローカル設定を切り替えて管理する方法

Profileは設定項目であり、単一のプロキシノードではない

ClashクライアントのProfileとは、通常、設定一覧に登録された設定項目を指します。サブスクリプションURLから取得する場合も、ローカルのYAMLファイルを読み込む場合もあります。Profileを3つ登録しても、コアが3つの設定を同時に実行するわけではありません。一般的なデスクトップクライアントでは、メイン設定を1つ有効にし、クライアントが対応するオーバーライドやマージ設定、実行時オプションを適用します。

まず「設定」「サブスクリプション」「ノード」を区別しましょう。サブスクリプションは設定を取得するための配信元、YAMLは設定データを記述する一般的なファイル形式、Profileはクライアントからこれらを管理するための項目です。ノードは設定内にあるプロキシのアウトバウンドの1つです。ノードを切り替えると通常は特定のプロキシグループの選択先だけが変わりますが、Profileを切り替えるとルールやDNS、リスニングポート、プロキシグループもまとめて変わることがあります。

複数の設定の命名：配信元・用途・日付を分けて記録

まずは、サービス提供元の更新に追従するリモート設定と、テストやロールバック用のローカル設定を分けておくのがおすすめです。「サブスク1」「サブスク2」のような名前だけにしたり、サブスクリプションURL全体を表示名にしたりするのは避けましょう。URL内のトークンがアカウント権限に紐づいている場合があり、画面のスクリーンショットから漏れるおそれがあります。

3つの設定の命名例

• 日常-A-リモート：普段使い用。元のサブスクリプションを保持し、クライアントの設定に従って自動更新します。
• 予備-B-リモート：予備回線用。配信元と有効期限を別に管理し、普段使いの設定とは混在させません。
• テスト-ルール-ローカル-20261016：利用可能な設定をコピーしたローカル版。ルール変更のテストにのみ使用します。

表示名は、YAMLで共通して使えるトップレベルのフィールドではありません。Profile名を変えるために、設定へprofile-nameを追加するのは避けてください。クライアントの設定項目にある名前変更・編集機能を使いましょう。編集画面に名前の項目がない場合は、インポート前に分かりやすいファイル名を付けてください。

インポートと有効化は別の手順

1. 設定管理画面を開きます。クライアントによって「設定」「サブスクリプション」「Profiles」など表記が異なるため、実際の画面に従ってください。
2. サブスクリプションURLまたはローカルファイルをインポートし、新しい項目の名前、配信元の種類、更新日時を確認します。
3. 新しい項目を選択し、読み込み成功の表示を待ってから、現在有効な設定を示す表示を確認します。
4. プロキシグループ画面を開き、グループ名とノード一覧が切り替わったことを確認します。設定一覧に表示されているだけでは、有効になったとは限りません。

ローカルファイルをインポートすると、通常はクライアントのデータフォルダーにコピーされますが、製品によって管理方法は異なります。デスクトップ上の元ファイルを変更しても、クライアント内のコピーに反映されるとは限りません。再インポートするか、クライアントの「ファイルを編集」「設定ファイルを開く」などの機能から、実際に管理されているファイルを編集してください。

Profileの切り替え：モード・ポート・プロキシグループを確認

確実に切り替えるには、「読み込みに成功したか」と「通信が意図した経路を通っているか」の両方を確認します。設定にmode: ruleと書かれていても、画面上でルールモードが有効とは限りません。クライアントによっては、実行時の設定でファイル内の値が上書きされます。クライアントの現在の状態、コアのログ、接続詳細を合わせて判断してください。

切り替え前後に確認する4項目

1. 現在の設定をバックアップ：現在のProfile名と主なプロキシグループの選択先を記録し、必要に応じて設定のコピーをエクスポートします。
2. 読み込み結果を確認：ログにYAMLの解析エラー、未知のフィールド、参照先のないプロキシグループなどが記録されていないか確認します。
3. 通信の入口設定を確認：システムプロキシ、TUN、リスニングポートを確認します。ノード一覧だけを見て判断しないでください。
4. 新しい接続で検証：テスト用のページを開き直し、接続詳細で適用されたルール、プロキシグループ、実際のアウトバウンドを確認します。

たとえば、以前の設定の混合ポートが7890で、新しい設定では7891に変更されていても、ターミナルが古いプロキシ環境変数を使っていると接続できない場合があります。以下は異なる設定におけるポートの例で、同じファイルに両方を記述するという意味ではありません。

# 日常使いの設定における接続ポート
mixed-port: 7890
mode: rule

# 別の設定に切り替えると、接続ポートが7891に変わる場合があります
# mixed-port: 7891

クライアントがポートを固定して管理する場合、ファイルに記述した値が上書きされることもあります。トラブルシューティングでは、まずクライアントに表示されている実際のポートを確認し、ブラウザー、ターミナル、開発ツールで手動設定したプロキシアドレスと照合してください。TUNの有効状態、仮想NICの作成、ルートの設定もそれぞれ確認が必要です。Profile名から状態を推測することはできません。

サブスクリプション更新で変更が消える場合：配信元と個人設定を分ける

リモートProfileから取得した設定を直接編集しても、通常は次回更新までしか変更が保たれません。更新時にサービス提供元から設定を再取得し、ローカルのキャッシュが置き換えられることがあります。よくある例として、追加したDIRECTルールが消える、手動で変更したDNSが元に戻る、プロキシグループ名が元の名前に戻る、といったケースがあります。

変更内容に応じて保存先を選ぶ

たとえば、intranet.example.comへの通信を直接接続にする場合、ルールは次のように記述できます。ドメインは説明用なので、実際に使う社内ドメインに置き換えてください。この断片だけでは、インポート可能な完全な設定にはなりません。

rules:
  - DOMAIN-SUFFIX,intranet.example.com,DIRECT
  - MATCH,Proxy

ここでのProxyは、最終設定に定義済みのノード名またはプロキシグループ名である必要があります。Autoグループだけを含む別のProfileに切り替えると、元の参照先が無効になることがあります。複数の設定でオーバーライドを共用する場合は、プロキシグループ名を統一するか、設定ごとに別のオーバーライドを割り当ててください。ルールのテキストをコピーするだけでは不十分です。

「マージ」が自動追加を意味するとは限りません。ツールによってはrules全体を置き換えますが、先頭・末尾への追加やスクリプト処理に対応するものもあります。ルールはMATCHなどのフォールバック項目より前に配置してください。後ろに置くと、通常は適用されません。設定後、クライアントが生成した実行時設定を確認し、既存のルールが残っていることと、順序が意図どおりであることを確かめてください。

2つのサブスクリプションを併用する方法：切り替えと統合は別の機能

設定一覧にサブスクリプションAとBをインポートすると、通常は切り替え可能な2つのProfileが作成されます。両方のノードが自動で同じプロキシグループに追加されるわけではありません。予備として使うだけなら、別々の項目として管理するほうがトラブルシューティングしやすくなります。両方のノードを同時に選択できるようにしたい場合に限り、ノードプロバイダーやクライアントが明示的に対応する統合機能を検討してください。

メイン設定とノードプロバイダーの役割

• メイン設定はproxy-groups、rules、DNSなど、全体の動作を管理します。
• proxy-providersは互換性のある形式のノード一覧を取得し、プロキシグループはuseでプロバイダー名を参照します。
• 完全な設定を返すサブスクリプションを、確認なしにノードプロバイダーとして使うことはできません。返される形式に対応しているかは、コアと配信元の内容によって異なります。

mihomoを例にすると、HTTPタイプのノードプロバイダーにあるinterval: 3600は、そのプロバイダーを3600秒間隔で更新するという意味です。クライアントがProfile全体を1時間ごとに更新するという意味ではありません。プロバイダー内のhealth-check.intervalはヘルスチェックの間隔であり、サブスクリプションの更新周期ではありません。リモートProfileの自動更新は別の画面設定になっている場合が多く、単位も分または時間で表示されることがあります。

管理時は、「設定全体の更新日時」「ノード一覧の更新日時」「ノードの接続確認」を分けて記録しましょう。「ノードは変わったのにルールは変わらない」という場合、プロバイダーだけが更新された可能性を切り分けられます。設定をすべて削除して再インポートする必要があるか、すぐに判断できます。

設定のバックアップと移行：元ファイル・オーバーライド・状態を別々に保存

実行時のYAMLを1つエクスポートするだけでは、普段の環境を完全に復元できない場合があります。実行時ファイルにはオーバーライドがマージされていても、リモートサブスクリプションのURLが残っていないことがあります。また、ノードのパスワードやサブスクリプションのトークン、ローカルのリスニング設定が含まれている場合もあります。実行時ファイルは当時の設定内容を再現する助けになりますが、クライアントデータのバックアップの代わりにはなりません。

バックアップしておきたい項目

1. 設定の配信元：配信元の情報、Profile名、必要に応じてサブスクリプションURLを保存します。機密性の高いURLは、アクセスを保護した場所に保管してください。
2. ローカルYAML：手書きの設定と、テスト前の正常なコピーを保存します。例：daily-local-20261016.yaml。
3. 個人用オーバーライド：ルールやスクリプトと、その適用先を別々に保存し、処理順も記録します。
4. 実行設定：ポート、システムプロキシ、TUN、DNS関連の設定に加え、クライアントとコアの実際のバージョンを記録します。
5. 選択状態：よく使うプロキシグループの選択先を記録します。保存先や保存方法はクライアントによって異なります。

移行時は、まずクライアントが提供するエクスポート・復元機能を使ってください。データフォルダーのコピーが必要な場合は、クライアントを終了してから、保護されたローカルの場所にコピーします。書き込み中のデータベースや状態ファイルをコピーしないよう注意してください。固定パスを推測してはいけません。インストール方法、ポータブルモード、OSによって実際の保存場所は異なります。

復元後は順番に検証

まず設定をインポートし、次にオーバーライドを復元し、最後にシステムプロキシまたはTUNを1つずつ有効にします。最初の検証では、必要な通信経路を1つだけ有効にすると問題を特定しやすくなります。設定の読み込み、ドメイン名の解決、接続を確認してから、自動更新とバックグラウンド起動を有効にしてください。

クライアント間の移行では、YAMLの基本フィールドを再利用できる場合がありますが、クライアント固有の設定インデックス、オーバーライドスクリプト、画面の状態は互換性がないことがあります。コアをまたいで移行する場合は、専用フィールドも確認してください。読み込みに失敗したら、まずログから該当フィールドを特定します。以前のクライアントのデータフォルダー全体を、新しいクライアントにそのまま上書きしないでください。

よくある質問：設定があるのに、なぜ想定どおりに動かない？

切り替えたらノードは変わったのに、ルールが変わらないのはなぜ？

まず、2つの設定がもともと同じルールを使っていないか確認し、次にクライアントに共通のオーバーライドが設定されていないか確認してください。共通のオーバーライドがrulesを置き換えている場合、元のProfileを切り替えてもルールが同じままになることがあります。判断する際は、元ファイルのプレビューではなく、最終的な実行時設定と新しい接続で適用されたルールを確認してください。

Profileを削除すると、サブスクリプションのアカウントも削除されますか？

ローカルの項目を削除しても、通常はクライアントに保存された設定が削除されるだけで、サービス提供元のアカウントは解約されません。ただし、キャッシュや関連するオーバーライド、ローカルのコピーも削除されるかどうかは、削除時の確認画面で確かめてください。必要なデータは操作前にエクスポートしましょう。サブスクリプションURLが漏れた場合は、ローカルProfileを削除するだけでなく、サービス提供元でURLを再発行してください。

ローカル設定は自動で変更されない？

ローカルファイル自体は通常、リモートProfileのように更新されません。ただし、自動更新されるproxy-providersやrule-providersを参照していたり、クライアントの実行設定が適用されたりする場合があります。問題を再現するときは、外部の配信元と更新時刻も記録してください。トップレベルのYAMLだけを保存しても不十分です。

普段の管理で最低限必要なことは？

正常に使える設定をロールバック用に保存する。リモートサブスクリプションとローカルのテスト設定を区別して命名する。長期的に使う変更は、更新後も保持できるオーバーライドに保存する。切り替えるたびに、新しい接続でルールとアウトバウンドを確認する。初回インポートの手順はサブスクリプションのインポートガイド、フィールドの関係はYAML構造リファレンスをご覧ください。