設定管理 読了時間：約9分

ClashのProfileとは？複数の設定ファイルを管理・切り替える方法

Profileとconfig.yamlの違い、ローカル設定とリモートサブスクリプションの使い分けを解説。複数設定の命名、切り替え、バックアップ方法も紹介します。

Profileとconfig.yamlの関係

Profileは一般に、ClashのGUIクライアントで「選択して使える設定一式」を指します。ローカルのYAMLファイルから作成する場合も、リモートサブスクリプションのURLに紐づく場合もあります。設定内容に加えて、名前、取得元、更新日時、オーバーライド設定などをクライアントが保存することもあります。こうした管理情報はクライアント側のもので、カーネルが読み込むYAMLに含まれるとは限りません。

config.yamlは、よく使われるカーネル設定ファイル名です。mihomoはClash Metaプロジェクトから発展したカーネルで、待ち受けポート、ノード、プロキシグループ、DNS、ルールを含む設定を読み込めます。ファイル名は必ずしもconfig.yamlである必要はありません。コマンドラインでは-fで別のファイルを指定でき、GUIクライアントが独自の実行時ファイルを生成することもあります。

  • Profile一覧：用途に応じて選べるよう、複数の設定を保存します。
  • 現在有効なProfile：クライアントが現在の設定を生成または読み込むために使います。
  • 実行時設定：カーネルが実際に使う設定内容です。グローバル設定やオーバーライド、スクリプト処理が反映されている場合があります。

そのため、問題を調べるときは「元のサブスクリプション」「クライアントで編集した内容」「カーネルが現在使っている設定」を区別する必要があります。ディスク上のconfig.yamlを開いただけでは、接続ログに反映されているすべてのルールを確認できないことがあります。

ローカル設定とリモートサブスクリプションの選び方

項目ローカルYAMLリモートサブスクリプションのProfile
取得元ローカルファイルを読み込む、または手動で作成クライアントがサブスクリプションURLからダウンロード
ノードの更新通常は再読み込みまたは手動編集が必要手動更新または自動更新で取得
変更の保持クライアントの保存方法や読み込み方法によるダウンロードした内容を直接編集すると、次回更新時に上書きされる場合がある
利用シーン固定の検証用設定、オフラインバックアップ、自分で管理するノードノード情報が頻繁に変わる普段使い

ローカル設定にproxy-providersやrule-providersを含め、ノードやルールをリモートから取得することもできます。「ローカル」とはProfileの読み込み元を示すだけで、必要なリソースがすべてオフラインで保存されているとは限りません。providerのキャッシュや依存ファイルを含めずにバックアップすると、ネットワークに接続できない環境では復元できないことがあります。

サブスクリプションURLは設定形式ではない

同じインポート欄にURLを入力しても、URLから返される内容はさまざまです。完全なClash YAMLにはproxies、proxy-groups、rulesなどが含まれます。Base64でエンコードされたノード一覧には通常ノード情報しかなく、そのまま完全なルール設定として使うことはできません。provider専用のproxies一覧を含むYAMLも、完全なProfileとは異なります。

インポートに失敗したら、まずクライアントのエラー詳細を確認し、設定ファイルではなくログインページ、期限切れの案内、HTMLのエラーページが返されていないかを調べてください。サーバー側で形式を選べる場合は、使用中のカーネルに対応するClashまたはmihomoの設定を選びます。サブスクリプションURLにはアクセストークンが含まれることが多いため、公開変換サイトやスクリーンショット、問い合わせ内容に貼り付けないでください。

複数設定の命名と整理方法

名前は用途、取得元、検証用コピーかどうかの順に分かるように付けましょう。「設定1」「新しいサブスクリプション」や「最終版」を繰り返すだけでは、どれを安全に更新できるのか判断しにくくなります。以下のような名前を使えます。

  • 普段使い-メイン購読：サーバーから更新し、日常のブラウジングに使用。
  • 予備-別サブスクリプション：別の提供元を使い、障害時に手動で切り替え。
  • 仕事用-ローカルルール：業務ドメインや社内ネットワークのアドレス向けと明示。
  • 検証-DNS-2026-08-18：DNSの変更だけをテストし、普段使いの設定には上書きしない。

日付はスナップショットや検証用コピーに付け、長期間使うサブスクリプションの名前は固定します。各設定のメモには、取得元の種類、対応カーネル、依存するオーバーライドの名前を記録するとよいでしょう。「リモートYAML、mihomo、仕事用ドメインルールを適用」のように書けば、サービス名の略称だけより移行時に役立ちます。

予備設定は事前に動作確認する

名前が異なる2つのProfileでも、同じサブスクリプションURLを参照している場合があります。このようなコピーは変更のテストには使えますが、独立した予備回線にはなりません。事前に予備設定を更新できること、プロキシグループでノードを選べること、目的のサイトにアクセスできることを確認してから、普段使いの設定に戻してください。メイン回線が使えなくなってから初めて読み込むと、サブスクリプションの取得とノードへの接続の両方で問題が起きるおそれがあります。

Profileの切り替え手順と確認ポイント

クライアントによって「設定」「サブスクリプション」「Profiles」など入口の名前が異なり、ボタン名もバージョンによって変わります。設定一覧から目的の項目を探し、「編集」「更新」「有効化」を区別しましょう。編集は内容の変更、更新は取得元から最新の内容を取得、有効化は現在の設定の切り替えを行います。更新後に自動で再読み込みするクライアントもあれば、別途確認が必要なものもあります。

  1. 現在の状態を記録する。現在のProfile、ルールモード、プロキシグループの選択、システムプロキシの状態をメモします。必要に応じて、サブスクリプションURLが写らない画面を撮影してください。
  2. 切り替え先を更新する。リモートProfileは先に更新し、最終更新日時とエラー表示を確認します。ローカル設定では依存ファイルのパスを確認してください。
  3. 切り替え先を有効にする。読み込みが完了するまで待ち、ログにYAMLの解析エラー、存在しないポリシー、リソースのダウンロード失敗がないか確認します。
  4. プロキシグループを選び直す。新しい設定ではグループ名が異なる場合があり、前回選択したノードが引き継がれるとは限りません。
  5. 新しい接続を作成する。テストするWebページを開き直し、接続の詳細でルール、ポリシーチェーン、接続先アドレスを確認します。

たとえば、以前の設定でmixed-port: 7890を使い、新しい設定でmixed-port: 7897に変更した場合、ターミナル側のプロキシ設定が127.0.0.1:7890のままだと接続できないことがあります。GUIクライアントがProfile内のポート設定をグローバル設定で上書きすることもあるため、ファイルを比較するだけでなく、実際の待ち受けポートを確認してください。

Linuxでは、次のコマンドで例に挙げたポートが待ち受け中か確認できます。別のポートを設定している場合は、実際の値に置き換えてください。

ss -lntp 'sport = :7890'
ss -lntp 'sport = :7897'

ダウンロード中の通信、動画再生、長時間接続は、切り替え前の接続を使い続けることがあります。確認時は新しい接続を作成してください。必要であればクライアントの接続画面から該当する接続を閉じて再試行し、古い接続の出口を見て新しい設定が反映されていないと誤解しないようにしましょう。

カスタムルールを管理しやすい場所に置く

リモートサブスクリプションは更新可能な元データとして維持し、長期的な変更はクライアントが対応するオーバーライド、マージ、スクリプトの仕組みに追加しましょう。項目のマージ方法はクライアントによって異なり、リスト全体を置き換えるものもあれば、ルールを先頭または末尾に追加できるものもあります。保存する前に生成後の設定を確認し、変更が実行時設定に反映されていることを確かめてください。

ルールの順序とプロキシグループ名を確認する

以下はルール順序の例であり、完全な設定ではありません。内部向けのサンプルドメインとプライベートネットワークの範囲を直接接続し、残りの通信を後続のルールで処理する構成です。

rules:
  - DOMAIN-SUFFIX,office.example,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,DIRECT

office.exampleは予約されたサンプルドメインです。実際の職場のドメインとして使うルールではありません。末尾のMATCH,DIRECTは例の構成を完結させるためのものにすぎず、そのまま使うと残りの通信がすべて直接接続になります。実際の設定では必要な後続ルールを残し、定義済みのフォールバックポリシーを使用してください。

ルールは上から順に評価されます。カスタムドメインのルールをMATCHの後ろに追加しても、実行されません。ルールの振り分け先が办公出口というプロキシグループの場合、切り替え先の設定にも同じ名前のグループが必要です。存在しないと読み込みに失敗することがあります。DIRECTだけを指定すればグループ名への依存は避けられますが、直結が要件に合うかどうかは用途に応じて判断してください。

一度に変更する設定は1種類にする

まずルールを確認し、次にDNSを調整し、最後にTUNを確認します。サブスクリプションの差し替え、DNSの変更、ポート変更、TUNの有効化を一度に行うと、障害の原因を特定しにくくなります。グローバルオーバーライドがすべてのProfileに影響することもあるため、検証用設定だけで新しいDNSを使いたい場合は、オーバーライドの適用範囲を先に確認してください。

バックアップ、設定テスト、ロールバック

バックアップには最低限、元の設定、クライアントの管理データ、カスタムオーバーライドを含めます。実行時のconfig.yamlだけをコピーすると、サブスクリプションURL、自動更新の間隔、スクリプト、プロキシグループの選択履歴が失われることがあります。クライアントの一覧だけをエクスポートした場合、providerの実データが保存されないこともあります。

  1. クライアントにエクスポートまたはバックアップ機能がある場合は、その機能でコピーを作成し、クライアントとカーネルのバージョンも記録します。
  2. 手動で管理しているルール、オーバーライド用スクリプト、providerファイル、必要な証明書などの依存ファイルも一緒に保管します。
  3. 変更前後のスナップショットにはdaily-2026-08-18.yamlのように日付を付け、唯一の使用可能なコピーを上書きしないようにします。
  4. ノードのパスワード、サブスクリプショントークン、コントロールインターフェースのキーを含むバックアップは、アクセス制限のあるディレクトリに保存してください。共有する前に機密情報をマスキングします。

mihomoで設定候補をテストする

コマンドラインを使う場合は、まずカーネルのバージョンを確認し、別のディレクトリで設定候補をテストできます。以下では、現在のディレクトリにcandidate.yamlがあり、mihomoがコマンド検索パスに含まれているものとします。

mihomo -v
mkdir -p ./profile-check
mihomo -t -d ./profile-check -f ./candidate.yaml

-tは設定のテスト、-dは作業ディレクトリ、-fは設定ファイルの指定に使います。相対パスで参照するファイルや外部リソースは、実際のディレクトリに用意してください。ルールセットなどのリソースは、ダウンロードが必要な場合もあります。テストに成功しても、ノードが利用可能であること、DNSが正しいこと、システムプロキシが有効になったことを保証するものではありません。

ロールバックする場合は、まず前回正常に動作したProfileを戻し、それに対応するオーバーライドも復元します。再読み込み後、新しい接続を作成して動作を確認してください。コマンドラインで使っている場合、ディスク上のファイルを差し替えた後、既存の管理方法で設定を再読み込みするか、対象サービスを再起動する必要があります。ファイルを上書きしただけでは、カーネルに設定が読み込まれたことにはなりません。

Profile管理のよくある質問

Profileを削除すると、サブスクリプションも解約されますか？

通常、削除されるのはクライアント内のローカル項目だけで、サーバーのアカウントが退会処理されたり、有料契約が解約されたりすることはありません。再インポートには元のサブスクリプションURLが必要です。削除する前に、取得元の情報を安全に保存しているか確認してください。

サブスクリプションを更新すると、カスタムルールが消えるのはなぜですか？

よくある原因は、リモートサブスクリプションのダウンロード結果を直接編集し、更新時にサーバーの内容で上書きされたことです。長期的に使うルールはクライアント対応のオーバーライドに移し、ルールの挿入順と実行時設定を確認してください。オーバーライドの形式はクライアントごとに異なり、互換性がない場合があります。

Profileをコピーすると、プロキシグループのノード選択も引き継がれますか？

引き継がれるとは限りません。選択状態はYAMLの本文ではなく、クライアントのデータベースやカーネルのキャッシュに保存されている場合があります。選択状態の記憶を有効にしていても、グループ名やノード名が変わると復元できないことがあります。コピー後は、重要なプロキシグループを一つずつ確認してください。

2つのProfileで同時にポート7890を待ち受けできますか？

設定ファイルを2つ保存しても、ポートの競合は起きません。2つのカーネルインスタンスを同時に起動する場合は、待ち受けアドレスとポートを分ける必要があります。通常、同じアドレスの同じTCPポートを2つのインスタンスが同時に使用することはできません。複数インスタンスを使う場合は、作業ディレクトリ、コントロールインターフェース、TUNのルーティングも分けてください。日常的な切り替えには、単一インスタンスの設定管理機能を使うのがおすすめです。

日常のメンテナンスでは、元の取得元を残す、長期的なルールはオーバーライドで管理する、切り替え後に新しい接続を確認する、重要な変更前に復元可能なスナップショットを作成する、という流れを固定するとよいでしょう。設定の数を増やすより、取得元と適用範囲が明確で、復元手順を再現できることが重要です。

Clash最新版のダウンロード