Clashの設定ファイル「Profile」とは？サブスクリプション・ローカル設定・複数設定の切り替え

Profileとは、読み込んで使う設定一式

ClashクライアントにおけるProfileとは、通常、選択・更新・編集できる設定のことです。設定内容に加え、名前や取得元のURL、更新間隔などの管理情報が含まれる場合もあります。設定内容には一般にYAMLが使われ、待ち受けポート、ノード、プロキシグループ、ルール、DNSなどの動作を決めます。一方、名前や更新間隔はYAMLではなく、クライアント側のデータベースに保存されることがあります。

つまり、Profileはノードそのものでも、サブスクリプションアカウントでもありません。1つのProfileに数十個のノードや複数のプロキシグループを含めることができます。また、サブスクリプションURLから取得する内容は、取得のたびに異なる場合があります。クライアントが保存するのは取得元にひもづいた設定情報で、実行時にコアが読み込むのは、読み込み・統合・上書きを経た設定です。

まず3つの要素を区別する

設定の取得元：リモートのサブスクリプションURL、ローカルファイル、またはクライアント内の編集機能。
設定内容：YAML内のproxies、proxy-groups、rulesなどの項目。
実行状態：選択中のプロキシ、プロキシモード、確立済みの接続、システムプロキシの設定。

Profileを切り替えると、主に読み込む設定が変わります。実行状態がすべて初期値に戻るとは限りません。プロキシグループの選択を記憶するClashクライアントもあれば、上書き設定でポートやTUNの設定を保持するものもあります。切り替え後の状態を確認するには、設定一覧の選択表示だけでなく、現在のProfile名と実行中の設定も確認してください。

サブスクリプション設定とローカル設定の違い

サブスクリプション設定はリモートのURLから取得し、ノードやプロキシグループ、ルールの変更を反映するのに適しています。ローカル設定は端末内のファイルから読み込み、内容を利用者自身が管理します。どちらも完全なYAML設定である場合があり、違いはファイルの拡張子ではなく、取得元と管理方法です。

項目	サブスクリプション設定	ローカル設定
読み込み方法	リモート設定のURLを貼り付ける	YAMLファイルを読み込む、またはドラッグ＆ドロップする
更新方法	手動または定期的にリモートから取得	編集後に再読み込み、またはファイルを再インポート
向いている設定	取得元に合わせて変わるノードやルール	固定ルール、実験用設定、自分で管理する構成
主なリスク	取得元の期限切れ、応答エラー、更新による変更の上書き	構文エラー、項目の非互換、ノード情報の失効

サブスクリプションURLが完全な設定を返すとは限らない

完全なClash YAMLを返すURLもあれば、ノード一覧だけを返すものや、別形式のサブスクリプションを返すものもあります。ノード一覧だけでは、完全なProfileとしてそのまま使えるとは限りません。読み込む前に、取得元が対応形式を提供しているか確認してください。URLに「clash」と書かれているだけで互換性を判断しないようにしましょう。

また、proxy-providersは設定内で定義するノードプロバイダーであり、クライアントの一覧に表示されるサブスクリプションProfileとは別のものです。ローカルProfileからリモートのproviderを参照することも、リモートProfileに組み込みノードとproviderの両方を含めることもできます。この場合、「設定全体の更新」と「providerのリソース更新」は別々の操作です。

YAMLの項目と最小限の検証用設定

まず設定の構造を理解してから、個々の値を調整しましょう。対応する項目はコアのバージョンによって異なる場合があります。Clash Metaは現在mihomoとして開発されており、mihomo独自の拡張項目が過去のすべてのClashコアで使えるとは限りません。以下の例はYAMLの読み込みとローカル待ち受けを確認するためのものです。すべての通信はDIRECTとなり、プロキシノードは含まれていません。

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

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

rules:
  - MATCH,Route

mixed-port: 7890：同じポートでHTTPとSOCKSのプロキシ接続を受け付けます。7890はこの例で指定した値で、すべてのクライアント共通の固定ポートではありません。
allow-lan: false：LAN内の端末からのアクセスを許可しません。プロキシを共有する場合は、待ち受けアドレスとファイアウォールを別途確認してください。
mode: rule：ルールに従って接続を処理します。クライアント画面で選んだモードが、この値を上書きする場合があります。
proxy-groups：Routeという名前の選択式グループを定義します。この例の選択肢はDIRECTのみです。
MATCH,Route：最後のフォールバックルールです。それ以前のルールに一致しなかった接続をRouteに渡します。

コアを使って構文をチェックする

例をprofile-test.yamlとして保存します。mihomoのコマンドライン版をインストール済みの場合は、ファイルのあるディレクトリで次のコマンドを実行してください。

mihomo -v
mihomo -t -f ./profile-test.yaml

1つ目のコマンドで実際のコアのバージョンを確認し、2つ目で設定をテストします。Windowsでは.\mihomo.exe -t -f .\profile-test.yamlを実行できます。実行ファイル名はインストールしたファイルに合わせてください。テストに成功しても、リモートノードへの接続や、システム通信がプロキシ経由になっていることは確認できません。

YAMLのインデントにはスペースを使い、Tabは使わないでください。プロキシグループで参照する名前は、ノードまたは別のプロキシグループの名前と一致させます。たとえば、ルールをDOMAIN-SUFFIX,example.com,Routeと書く場合、Routeが定義されている必要があります。テストでエラー行が示されたら、まずその周辺のインデント、コロン、リスト記号を確認し、その後に項目の互換性を調べてください。

読み込み、名前付け、更新間隔

サブスクリプション設定の読み込み手順

Clashクライアントの設定管理画面を開き、リモートからの読み込み、またはサブスクリプションの追加を選びます。メニュー名は「設定」「Profiles」「サブスクリプション」など、クライアントによって異なります。
取得元から案内されたURLを省略せずに貼り付けます。クエリパラメーターを残し、トークンを手動で削除しないでください。現在のコアが対応する形式で返されることも確認します。
取得が完了したら、ノード、プロキシグループ、ルールが読み込まれていることを確認し、この設定を有効にします。
ログで読み込み結果を確認します。画面に「ダウンロード成功」と表示されても、その後の設定読み込みでエラーが出ていないか確認してください。

取得元と用途が分かる名前を付ける

ソースA-普段使い-リモート、ソースB-予備-リモート、ローカル-ルール検証-20260729のような名前がおすすめです。取得元で管理者を区別し、用途で切り替え先を判断し、日付で実験用のスナップショットを見分けられます。サブスクリプションのトークンやパスワードは名前に含めず、「設定1」「設定2」のような名前も避けましょう。

サブスクリプションProfileの名前は固定し、最終更新日時はクライアントに記録させると管理しやすくなります。ローカルの実験用設定には日付を付けると便利です。実験後は安定版をローカル-普段使い-安定版として保存し、日付違いのコピーから有効にする設定を探す状態を避けましょう。

更新間隔は単位を確認する

日常的に使うサブスクリプションは、まず24時間ごとの更新を試すとよいでしょう。これは管理上の目安であり、プロトコル上の要件ではありません。クライアントの単位が分なら24時間は1440、秒なら86400です。同じ数値を異なるクライアントにそのまま設定しないでください。また、接続エラーの調査のために更新間隔を毎分にするのも避けましょう。

設定内のproxy-providersやrule-providersでintervalを使う場合、単位は通常秒です。利用中のコアのドキュメントで確認してください。クライアントのProfile更新間隔とproviderのintervalは、別々のリソースを管理します。一方をもう一方の代わりにはできません。

複数設定の切り替えと接続確認

一般的なClashクライアントでは、メインProfileを一度に1つだけ有効にします。設定一覧に10件保存されていても、10件分のルールが同時に適用されるわけではありません。設定の統合、上書き、スクリプト処理に対応するクライアントもありますが、これらは明示的に設定する機能です。「サブスクリプションを複数選択した」だけで、実行時の動作を判断することはできません。

切り替え前に4項目を記録する

メイン設定：現在のProfile名と、ローカルの上書き設定の有無。
プロキシモード：ルール、グローバル、またはDIRECT。モード変更を設定の問題と混同しないようにします。
待ち受けポート：現在の混合ポートが7890か、外部アプリも同じポートを使っているか。
通信の取り込み方法：システムプロキシとTUNの有効状態、必要なシステム権限。

切り替え先のProfileを選び、クライアントの読み込み完了を待ちます。読み込み中に複数の設定を続けて選ばないでください。
プロキシグループを開き、選択肢が存在していて用途に合っているか確認します。以前のノード名が見つからない場合は、利用可能なノードを選び直してください。
新しいリクエストを実行し、接続一覧で一致したルールと最終的なプロキシを確認します。遅延テストだけに頼らないでください。
結果に問題があれば、直前の正常な設定に戻し、差分を一つずつ比較します。

切り替え後も、確立済みの長時間接続は以前の経路を使い続けることがあります。ブラウザー、ダウンロードツール、メッセージアプリが既存の接続を再利用する場合もあります。確認には新しいリクエストを使い、必要に応じて対象アプリの既存接続を閉じてください。接続を閉じる機能があるクライアントもありますが、実行中の通信が中断されるため、重要なダウンロードやセッションがないことを先に確認しましょう。

指定ポートで接続を確認する

現在の混合ポートが実際に7890の場合は、以下のコマンドでシステムプロキシの設定に依存せず、ローカルのHTTPプロキシを経由してcurlを実行できます。

curl --proxy http://127.0.0.1:7890 --head https://example.com

このコマンドで確認できるのは、その接続口を通じてリクエストを完了できるかどうかです。リモートのプロキシノードを使ったことまで証明するものではありません。接続記録で最終的なプロキシを確認してください。ルールの判定結果がDIRECTなら、リクエストは直接接続されます。実際のポートが7897の場合は、コマンド内のポートも7897に変更してください。

TUNモードはシステムレベルで通信を取り込む機能で、Profileと同じ意味ではありません。新しい設定に切り替えると、TUNが有効なままでもDNS、ルーティング、振り分け結果が変わる場合があります。まずTUNを無効にして指定ポートでの接続を確認し、その後でTUNによる通信の取り込みを確認すると、設定の問題とシステム権限の問題を切り分けやすくなります。

更新による上書きとローカル変更の管理

リモートから取得したYAMLを直接編集すると、次回の更新で変更が上書きされることがあります。ポート、ルール、DNSを継続的に管理する場合は、Clashクライアントが正式に提供する上書き、統合、拡張機能を優先してください。そうした機能がない場合は、ローカル設定としてコピーして管理できますが、以降のノード同期は自分で行う必要があります。

設定内容ごとに管理担当を分ける

内容	おすすめの管理場所	更新後の確認項目
ノードのアドレスと認証情報	信頼できるサブスクリプション元またはノードプロバイダー	ノードが残っているか、認証情報が有効か
ローカルの待ち受けポート	クライアント設定または明示的な上書きレイヤー	実行中のポートとアプリのプロキシアドレスが一致しているか
個人用ドメインルール	ローカルルールの拡張または自分で管理する設定	ルールの順序とプロキシ名が正しいか
DNSとTUN	管理場所を一つ明確に決める	実行時の値、システム権限、ルーティングが合っているか

ルールの順序は特に重要です。通常のルールは上から順に照合されます。新しいドメインルールをMATCHの後ろに追加すると、その接続は意図どおりに処理されません。ルール一覧を上書きする場合は、クライアントが一覧全体を置き換えるのか、先頭または末尾に追加するのかも確認してください。実装によって動作は異なります。

変更前に、正常に動作する設定を保存し、クライアント名、コアのバージョン、上書き内容を記録してください。設定は一度に一種類だけ変更します。たとえば、まずルールを変更し、その後DNSを変更します。そうすれば更新後に問題が起きても、クライアント全体をリセットせず、該当する変更だけを戻せます。

よくある質問と管理チェックリスト

サブスクリプションの更新に成功したのに、ノードが変わらないのはなぜですか？

取得元の内容自体に変更がない場合や、ノードが独立したproviderから取得され、そのproviderの更新が必要な場合があります。また、一覧内の予備設定ではなく、現在有効なProfileを更新したか確認してください。クライアントに表示される更新日時だけでは、ノードが更新されたとは限りません。

設定の読み込みに成功したのに、接続できないのはなぜですか？

読み込み、解析、設定の適用、実際の接続はそれぞれ別の段階です。ログで設定の適用が成功しているか、プロキシグループで有効なノードを選んでいるか、7890などの実際のポートで待ち受けているか、アプリの通信がシステムプロキシまたはTUNを経由しているか、順に確認してください。ノードの遅延テストが成功しても、すべてのサイトが同じルールに一致するとは限りません。

2つのサブスクリプションを1つにまとめられますか？

対応する設定統合機能や自分で管理するproviderを使ってノードをまとめることはできますが、2つのYAMLファイルを単純につなげることはできません。同名のトップレベル項目、重複するノード名、プロキシグループの参照先、ルールの順序を調整する必要があります。慣れないうちは2つのProfileを分けたまま用途に応じて切り替えるほうが、動作確認や切り戻しを簡単に行えます。

別の端末へ移行するとき、何をコピーすればよいですか？

設定ファイルだけでなく、サブスクリプション元、更新間隔、ローカルの上書き設定も記録してください。移行後はポート、システムプロキシ、TUNの権限をあらためて確認します。デスクトップ向けのパス、ネットワークインターフェース名、ルーティング設定をスマートフォンにそのまま適用しないでください。ファイルをコピーする前に、保存先と転送方法がアカウント情報を安全に扱えるか確認しましょう。

普段使い用、予備用、実験用の設定を1つずつ残し、不要と確認できたコピーは定期的に削除します。
リモート設定には取得元と更新間隔を、ローカル設定には変更日と用途を記録します。
更新後は読み込み結果を確認し、切り替え後は新しい接続のルールと最終的なプロキシを確認します。
変更前にバックアップを取り、問題が起きたらまず正常に動作していた設定に戻してから、具体的な差分を調べます。

Profileの管理では、取得元、設定内容、実行状態を分けて考えることが大切です。リモートの更新とローカルの変更を分け、設定の切り替えと接続確認をセットで行えば、ノードの変更、クライアントのアップデート、端末の移行があっても、設定の追跡と切り戻しが容易になります。