Clash Profileとは？サブスクリプション設定とローカル設定の違い・複数設定の切り替え方

Profileはクライアントが管理する設定プロファイル

Profileとは通常、クライアントに保存される設定プロファイルのことです。ノードそのものでも、プロキシプロトコルの種類でもありません。リモートサブスクリプションから取得する場合も、ローカルのYAMLファイルから読み込む場合もあります。クライアントは取得元や名前、更新情報、選択状態を管理し、コアは最終的な設定を読み込んで待ち受けポートを作成し、ノードを読み込み、ルールに基づいて通信を振り分けます。

完全な設定には、mixed-port、mode、dns、proxies、proxy-groups、rulesを含められます。ノードは接続情報、ポリシーグループはノードの選択先、ルールは通信に適用するポリシーを決めます。Profileを切り替えると、これら3つが同時に変わることがあります。単に接続先サーバーだけを変更する操作ではありません。

クライアントによって、設定画面の項目名は「設定」「サブスクリプション」「Profiles」など異なります。これは各アプリの画面上の名称であり、Clashやmihomoのコアが共通で定めているメニューではありません。操作が反映されたかどうかは、一覧にカードが増えたかだけでなく、現在の設定表示、コアの読み込み結果、実際に適用されたルールで確認しましょう。

リモートサブスクリプションとローカルYAMLの違い

主な違いは取得元と更新方法であり、YAMLでできることの違いではありません。リモートサブスクリプションは通常、クライアントがURLから取得します。ローカル設定はユーザーがインポート、作成、編集します。リモートから返される内容が完全なClash設定なら、通常はYAML形式です。ただし、サブスクリプションURLの応答が、そのまま読み込める完全な設定とは限りません。

比較項目	リモートサブスクリプションProfile	ローカルYAML Profile
取得元	クライアントに登録されたサブスクリプションURL	ローカルファイルまたはクライアントのエディター
内容の更新方法	手動または定期的に再取得	手動で編集、または外部ツールで更新
直接編集する場合の注意点	次回更新時に変更が上書きされる可能性がある	通常、リモートサブスクリプションの更新による影響は受けない
ノードの有効性	サービス提供元から返される内容による	コピーしたノードは自動更新されない
移行時のポイント	取得元とローカルの上書き設定を保存する	ファイルと、参照している外部リソースを保存する

サブスクリプションURLが設定ファイルのURLとは限らない

完全なYAMLを返すサービスもあれば、ノード一覧だけを返すサービスや、エンコードされたプロトコルリンクの一覧を返すサービスもあります。後者は、クライアントが該当形式のインポートに対応しているか、信頼できる変換手順を使わないと設定として利用できません。ブラウザーでURLを開けても、応答が現在のコアで使える形式だとは限りません。

インポート後に必須項目の不足や解析エラーが表示されたら、応答内容がログインページ、エラーメッセージ、非対応形式ではないか確認してください。サブスクリプションURLにはアクセストークンが含まれることがあります。トラブルシューティングでURL全体を公開したり、提供元が不明なオンライン変換サービスに渡したりしないでください。

最小構成のYAMLで設定の範囲を確認する

以下は、設定項目の関係を把握するためのローカル設定例です。127.0.0.1:7890で待ち受け、すべての通信に組み込みのDIRECTを使用します。リモートプロキシノードは含まれていないため、プロキシ経由の接続先を確認する用途には使えません。隔離したテスト用設定で、YAMLの読み込みやルール構造を確認するための例です。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: ROUTE
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,ROUTE
  - MATCH,DIRECT

mixed-port: 7890は、同じポートでHTTPとSOCKSのプロキシ接続を受け付ける設定です。ポートがすでに使用中の場合は、空いている番号に変更してください。
mode: ruleは、ルール一覧に従って通信を処理する設定です。実行中にグローバルモードへ切り替えると、この設定のルールで振り分け結果を判断できません。
ROUTEはポリシーグループ名です。ルールから参照する場合は名前を一致させてください。組み込みポリシーのDIRECTには、別途ノードを作る必要はありません。
MATCHは最後に適用するフォールバックルールです。この例では最後に置いてください。前に置くと、後続のルールがマッチしなくなります。

インデントにはスペースを使い、タブは使わないでください。既存のサブスクリプションをインポートする場合、この例で元のファイル全体を置き換えないでください。構造を示す例であり、サービス提供元のノードやポリシーは含まれていません。各項目の詳しい説明は設定項目の解説をご覧ください。

複数の設定を管理・更新・切り替える方法

名前で用途を示し、メモに取得元を記録する

「用途－取得元－管理方法」の順で名前を付けると管理しやすくなります。たとえば「普段使い－サブスクA－リモート」「仕事－ローカルルール－上書き」「トラブルシューティング－直結－ローカル」のようにします。「設定1」「設定2」のような名前や、サブスクリプショントークンを名前に含めるのは避けてください。メモ欄が使える場合は、インポート日、コアの種類、上書き設定の保存場所も記録しておくと、情報を名前に詰め込まずに済みます。

更新と切り替えは段階を分けて確認する

更新前に戻せる状態を作る：利用可能な設定を書き出し、現在のポリシーグループの選択状態とローカルの上書き設定を保存します。書き出したファイルにはノードの認証情報が含まれる場合があるため、安全な場所に保管してください。
対象だけを更新する：操作する設定の名前と取得元を確認し、更新日時が変わったか確認します。更新日時が変わっても、その設定が有効になったとは限りません。
読み込み結果を確認する：対象のProfileを有効にしたら、コアのログを確認します。YAMLの解析エラー、未知の項目による読み込み失敗、ポリシー参照の誤りがないかチェックしてください。
実行時の設定を確認する：プロキシモード、待ち受けポート、DNS、TUNの有効・無効を確認します。クライアントによっては、全体設定がファイル内の同名項目を上書きします。
新しい接続で検証する：新たにリクエストを発生させ、接続画面でマッチしたルール、ポリシーの経路、接続先を確認します。ノードの遅延だけで判断しないでください。

たとえば、以前の設定が7890で待ち受け、新しい設定で7891に変更しても、ターミナルに設定済みのhttp_proxyは自動で切り替わりません。ブラウザーのシステムプロキシとターミナルの環境変数も別の設定です。複数の設定でローカルの待ち受けポートを統一すると、切り替え後のポート不一致を減らせます。

サブスクリプション更新で自作ルールが上書きされないようにする

個人用ルールは、サブスクリプションからダウンロードしたファイルを直接編集せず、クライアントが対応する永続的な上書き機能に保存するのがおすすめです。実装には、設定のマージ、ルールの先頭追加、設定処理スクリプトなどがありますが、名称や適用範囲、配列のマージ方法はクライアントによって異なります。すべてのクライアントで使える共通の上書きファイル形式はありません。作業前に、使用中のクライアントの説明を確認してください。

挿入位置を確認してからポリシー名を確認する

例として、指定したドメインを直接接続させる場合、以下のルールを最終的なrules一覧の前方に配置します。これは最終設定で必要となる並び順を示すもので、どのクライアントにもそのまま適用できる上書き構文ではありません。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,ROUTE

ルールモードでは、ルールを上から順に評価し、最初に一致したルールのポリシーを適用します。個人用ルールをMATCHの後に追加すると、通常は期待どおりに動作しません。ROUTEを参照する場合は、最終設定に同じ名前のポリシーグループが必要です。サブスクリプションの更新でグループ名が変わったら、既存の上書き設定も修正してください。

適用範囲を確認：上書き設定は特定のProfileだけに適用されますか？それともすべての設定に適用されますか？仕事用のルールが別の設定に意図せず適用されないよう確認してください。
リストのマージ方法を確認：クライアントによって、rules配列全体を置き換える場合も、項目を先頭または末尾に追加する場合もあります。「マージ」という表記だけで動作を判断しないでください。
最終的な設定を確認：クライアントに実行設定のプレビュー機能がある場合は、個人用ルールが追加されているか、順序は正しいか、参照先のポリシーが存在するかを確認してください。
更新後の動作も確認：上書き設定を保存した後、サブスクリプションを手動で更新し、ルールと新しい接続を確認します。変更が更新後も保持されることを確かめてください。

クライアントが永続的な上書きに対応していない場合は、設定をローカルにコピーして編集できます。ただし、そのコピーには元のサブスクリプションのノード変更が自動で反映されません。「コピーを手動で管理する」か「リモート更新を引き続き利用する」かを明確にし、ローカルの変更と自動更新を同じ一時ファイルに混在させないでください。

proxy-providersと複数のProfileは管理する階層が異なる

proxy-providersは、設定内でノードプロバイダーを参照する仕組みです。一方、複数のProfileは、クライアントが複数の設定を保存する仕組みです。mihomoでは、1つのローカル設定から複数のプロバイダーを参照し、ノードの取得元とローカルルールを分けて管理できます。ただし、ポリシーグループから各プロバイダーを正しく参照する設定が必要です。

プロバイダーの更新対象は通常、提供されるノードだけであり、メイン設定全体を再ダウンロードするわけではありません。プロバイダーURLも、現在の実装が受け付ける形式を返す必要があります。どの「サブスクリプションURL」でもそのまま使えるとは限りません。rule-providersも使っている場合、ルール一覧の取得とメイン設定の更新は分けて確認してください。

一般的な使い方なら、まず安定したサブスクリプションを1つ管理し、必要なローカル上書き設定を追加すれば十分です。ノードの取得元、ルール一覧、更新間隔を分けて管理する必要がある場合に、プロバイダー構成を検討しましょう。重複したルールを複数管理して、最終的な取得元が分からなくなるのを防げます。

設定の切り替え後に問題が起きたら、4つの層に分けて確認する

取得元：対象のProfileを更新したか、応答がWebページではなく設定データかを確認します。サブスクリプションが無効になっていないかも調べ、同じ誤ったURLを何度もインポートしないようにしてください。
読み込み：コアが新しい設定を受け付けたか確認します。インデントエラー、存在しないポリシー、非対応項目がある場合は、ノードのタイムアウトを疑う前に読み込みエラーを解消してください。
接続入口：7890または指定したポートが待ち受け中か、システムプロキシとターミナルが同じ入口を参照しているかを確認します。TUNを使う場合は、権限、ルーティング、DNSの制御状態も別途チェックしてください。
通信の振り分け：実行モードがruleになっているか、新しい接続に適用されたルールとポリシーグループの選択先を確認してから、リモートノードやサーバー側の問題か判断してください。

サブスクリプションを3つインポートすると、ノードは自動で統合されますか？

通常は統合されません。多くのクライアントでは、一度に有効にできるメイン設定は1つで、ほかのサブスクリプションは一覧に保存されるだけです。統合するには、クライアントが対応する統合機能を使うか、互換性のあるコアでプロバイダーを設定する必要があります。一覧に3つ表示されているだけでは、統合されたとは言えません。

Profileを切り替えるとTUNも自動で切り替わりますか？

必ずしも切り替わるとは限りません。TUNはクライアント全体のスイッチで管理される場合も、設定と上書きの組み合わせで決まる場合もあり、システム権限にも左右されます。インポートしたファイルにtun項目があるかだけで判断せず、クライアントの実行状態と最終設定を確認してください。

YAMLを1つバックアップすれば、完全に移行できますか？

必ずしもそうとは限りません。メイン設定がローカルのルールファイル、プロバイダーのキャッシュ、証明書のパス、クライアントの上書き設定を参照している場合があります。サブスクリプションURLや画面上のポリシー選択が別に保存されることもあります。移行前に依存関係を洗い出し、新しい端末へのインポート後にポート、ルール、新しい接続を確認してください。認証情報を含むファイルの取り扱いにも注意しましょう。

複数設定を管理するうえで大切なのは、「取得元の更新」「ローカルの変更」「実行時の選択」を分けて記録することです。利用できることを確認した設定を1つ保存し、対象だけを更新しましょう。切り替えるたびに最終的なルールと新しい接続を確認すれば、何度も削除して再インポートするより問題を特定しやすくなります。