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

Profileは設定単位であり、単一のノードではない

ClashクライアントにおけるProfileとは、選択して読み込める設定単位を指します。サブスクリプションURLから取得する場合もあれば、ディスク上のYAMLファイルを使う場合もあります。クライアントは通常、名前や取得元のURL、更新日時、更新方法などもProfileごとに保存します。こうした管理情報は、コアが読み込むYAMLに含まれるとは限りません。

完全な設定には、待ち受けポート、DNS、プロキシノード、プロキシグループ、ルールなどを記述できます。ノードはその一部にすぎません。設定をインポートした後、クライアントで有効化すると、コアが最終設定に基づいて新しい接続を処理します。サブスクリプションの追加、設定の有効化、システムプロキシのオンは、それぞれ異なる状態です。

混同しやすい3つの操作

• サブスクリプションを更新：登録済みのURLから内容を再取得します。更新しても、その設定に切り替わるとは限りません。
• Profileを切り替え：現在使う設定の取得元を変更します。プロキシグループ、ルール、DNSも変わる場合があります。
• ノードを切り替え：現在の設定にあるプロキシグループ内で選択先を変更します。通常、設定全体は切り替わりません。

画面上の名称はクライアントによって異なり、「サブスクリプション」「設定」「Profiles」などが使われています。この記事では設定単位をProfileと呼び、特定のクライアントのボタン名を共通メニュー名として扱いません。

リモートサブスクリプション・ローカルYAML・プロキシプロバイダーの違い

リモートサブスクリプションは取得方法、YAMLはデータ形式を指すため、両者は対立するものではありません。リモートサブスクリプションからYAMLを取得することもできます。ローカルからインポートすると、通常はクライアント内にコピーが保存されます。元のダウンロードファイルを編集してもクライアント内のコピーに反映されない場合があるため、コピーとして取り込まれたのか、ファイルを直接参照しているのか確認してください。

サブスクリプションURLなら何でもClashコアで読み込めるわけではありません。ノードURIの一覧やHTMLページ、ログイン画面、エラーメッセージは、完全なClash設定として読み込めません。インポート前に、提供元がClashまたはmihomo互換として明示している形式を選び、クライアントが使用するコアも確認してください。

proxy-providersは別の完全なProfileではない

この機能に対応するコアでは、メイン設定のproxy-providersでノードの取得元を定義し、proxy-groupsからuseでプロバイダーを参照できます。プロバイダーのノードを更新しても、メイン設定のDNS、ルール、ポートが置き換わるわけではありません。ルールプロバイダーのrule-providersはルールの集合を読み込みます。ノードプロバイダーとは区別してください。

初回インポート：形式と有効化状態を確認

1. クライアントのダウンロードページから、使用するOSに合ったクライアントを選びます。設定の互換性を後で調べられるよう、クライアントとコアのバージョンを控えておきましょう。
2. 設定管理画面を開き、リモートサブスクリプションURLを追加するか、ローカルの.yamlまたは.ymlファイルをインポートします。リモートURLは省略せずに貼り付け、空白や改行、チャットアプリが付けた句読点が混ざらないようにしてください。
3. 「日常-リモート」「仕事-ローカル」「テスト-DNS」など、用途がわかる名前を付けます。名前は管理用であり、同じ名前のプロキシグループが自動作成されるわけではありません。
4. 更新を実行し、結果を確認します。解析エラーが出た場合は、まず取得した内容と形式を確認してください。システムプロキシを何度もオン・オフしても、構文エラーは解決しません。
5. 設定を選択して有効化し、プロキシグループとルールの一覧が読み込まれたことを確認してから、システムプロキシまたはTUNを有効にします。

システムプロキシは、OSのプロキシ設定に従うアプリをローカルのプロキシポートへ接続させる機能です。TUNは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を取り込みます。どちらも設定のインポートに必須ではなく、ノードの認証エラーを自動修正する機能でもありません。TUNの利用可否はコア、OSの権限、ルーティング設定にも左右されます。

ポート番号はクライアントに表示される実際の値を確認してください。以下では混合ポートに7890を使いますが、これは設定例です。すべてのクライアントが127.0.0.1:7890で待ち受けるとは限りません。

ローカルYAMLの例：設定の範囲を理解する

以下は、設定項目の関係を理解するためのローカル設定例です。mihomo環境で基本構造を確認できますが、直接接続のみで、リモートプロキシ機能はありません。local-direct.yamlとして保存してインポートすると、ポート、プロキシグループ、ルールの関係を確認できます。

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

proxies: []

proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手動選択
  - MATCH,DIRECT

• mixed-portはHTTPとSOCKSで共用する待ち受けポートです。ほかのプロセスが使用している場合は、空いているポートに変更してください。
• allow-lan: falseは、LAN内の端末からプロキシにアクセスできないようにします。TUNの有効化とは別の設定です。
• mode: ruleはルールに基づいて通信を振り分けます。例の末尾にあるMATCH,DIRECTは、それ以前のルールに一致しなかった通信を受け取ります。
• 手動選択グループにはDIRECTしかないため、このグループに振り分けられた通信は直接接続されます。ルールから参照するグループ名は一致させてください。

YAMLのインデントにはスペースを使い、Tabと混在させないでください。falseのような真偽値は文字列と区別し、リスト項目の-も残します。解析エラーが出た場合は、ログに示された行とその直前の行を確認してください。よくある原因はインデントの深さ、コロンの書き忘れ、閉じていない引用符です。

解析に成功しても、通信できるとは限りません。構文チェック後に、ノードが存在するか、プロキシグループの参照が有効か、ルールが想定した出口に振り分けているかをそれぞれ確認してください。Clash原版、Clash Premium、Clash Meta（現mihomo）では機能範囲が異なります。拡張子だけで互換性を判断しないでください。

更新間隔：サブスクリプション更新とノードのヘルスチェックを区別

リモートProfileの自動更新は、通常クライアントが管理します。一方、メイン設定内のHTTPプロキシプロバイダーにはintervalを指定して更新間隔を設定できます。mihomoでは関連フィールドの値を秒で指定します。それぞれ異なる階層で動作するため、片方を設定すればもう片方も自動管理されるわけではありません。

更新間隔の換算例

• 3600秒は1時間です。
• 21600秒は6時間です。
• 86400秒は24時間です。

この換算は、秒単位で指定するフィールドに適用されます。クライアントの画面では分単位の入力や時間単位の選択肢が用意されている場合もあるため、入力欄の表示に従ってください。普段はサブスクリプションの提供元が推奨する間隔で更新します。特に指定がなければ、まず1日1回に設定し、ノードの更新頻度に合わせて調整しましょう。

ノードのヘルスチェックは、指定した宛先への接続可否や遅延をテストする機能であり、新しいノード一覧を取得するものではありません。使えないノードが表示されたら、「ヘルスチェックの失敗」と「サブスクリプション取得の失敗」を分けて考えます。前者では出口、テスト先、タイムアウトを、後者ではURL、ネットワーク経路、アクセス権、応答形式を確認してください。

設定の上書き：個人設定とリモートの内容を分ける

リモートサブスクリプションから取得したYAMLを直接編集すると、次回の更新で上書きされることがあります。個人用のルール、DNS、ポート設定を継続して使うには、クライアントが提供する上書き、マージ、スクリプト機能を優先してください。使える機能はクライアントによって異なり、Clashコアがすべてのクライアント独自の上書きファイル形式を認識するわけではありません。

最終的に有効な設定を確認する

読み込みの流れは「サブスクリプションの設定 → クライアントでマージ・上書き → コアの実行設定」と捉えると、問題を切り分けやすくなります。ただし、すべてのクライアントで処理順が固定されているわけではありません。画面上の設定で設定ファイルのポートを上書きするクライアントもあれば、全体の上書きとProfileごとの上書きを分けるものもあります。確認するのはサブスクリプションの原文だけでなく、最終的に実行される設定です。

1. 変更は一度に一つ：たとえば、ドメインの直接接続ルールを1つ追加するだけにし、DNS、TUN、すべてのプロキシグループを同時に変更しないでください。
2. マージ方法を確認：リストは置き換え、先頭への追加、末尾への追加など、異なる方法でマージされる場合があります。ルールは上から順に判定されるため、新しいルールをフォールバックのMATCHより後ろに追加すると、意図した動作にならないことがあります。
3. 参照先の名前を確認：カスタムルールが指定するプロキシグループが、マージ後の設定に存在している必要があります。
4. 更新後に再確認：サブスクリプションを手動で更新し、新しいルールが残っているか、並び順が正しいかを確認してください。

複数のProfileで上書きを共有する場合は、特に注意が必要です。設定Aに「手動選択」グループがあっても、設定Bにもあるとは限りません。共有ルールがその名前を参照していると、切り替え後に無効な参照が生じる可能性があります。自分で管理するグループ名を統一するか、Profileごとに上書きを分け、取得元の異なる設定へ同じ変更スクリプトを無理に適用しないようにしてください。

複数設定の切り替え：1つを有効にして、ほかは保存

一般的な単一インスタンスのクライアントでは、メインのProfileを1つ選び、対応する上書きを適用します。サブスクリプションを3つ追加しても、3つのルールが自動でマージされるわけではなく、すべてのノードが同じプロキシグループに並ぶわけでもありません。ノードを集約する場合は、設定一覧の並び順に頼らず、メイン設定とプロキシプロバイダーの構成を明確に設計してください。

用途がわかる設定を3つ用意する

• 日常用：安定した提供元を使い、自動更新を有効にして、通常の接続に使います。
• 予備：提供元と接続経路を別途確認し、定期的に手動更新します。必要になったときに使えない事態を防ぎましょう。
• 検証用：DNS、ルール、TUNの設定を試します。不要な自動更新をオフにすると、変更前後を比較しやすくなります。

切り替える前に、現在の設定名、モード、プロキシグループの選択、ポートを控えてください。切り替え後は、新しい設定がルールモードになっているか、DNS、LANアクセス、TUNに変化がないか確認します。クライアントによっては一部のグローバル設定が保持されるため、Profileを切り替えてもすべての設定が元に戻るとは限りません。

既存の接続は、切り替え後すぐに別の出口へ切り替わるとは限りません。動作はクライアントの再読み込み方法や接続の終了状況によって異なります。確認する際は新しいリクエストを実行してください。必要に応じてクライアントで既存の接続を閉じるか、対象アプリを再起動します。ダウンロード中のタスクが続いていることだけで、切り替えの成否を判断しないでください。

バックアップと復元：取得元・上書き設定・実行環境を保存

YAMLだけをバックアップしても、クライアントを完全に復元できるとは限りません。リモートURL、更新間隔、上書きファイル、画面上のグローバル設定は、クライアントのデータベースや設定フォルダーに個別に保存されていることがあります。移行前に、まずクライアントのエクスポート機能を利用し、エクスポート内容に機密情報が含まれるか確認してください。

1. 取得元を記録：サブスクリプションの管理場所、設定名、更新間隔を記録します。トークンを含むURLは、保護された場所に保管してください。
2. ローカルファイルを保存：ローカルYAML、上書きスクリプト、自分で管理するルールファイルをバックアップします。相対パスを使う設定では、フォルダー構成も維持してください。
3. 実行環境を記録：クライアントとコアのバージョン、実際の待ち受けポート、システムプロキシの状態、TUNの設定を控えておきます。
4. 復元をテスト：まず設定をインポートし、次に上書きを読み込みます。ログに解析エラーや参照エラーがないことを確認してから、新しい接続をテストしてください。

ファイル名はdaily-2026-08-27.yamlやoverride-2026-08-27.yamlのようにすると、取得元や日付がひと目でわかります。バックアップしたキャッシュを有効なサブスクリプションとして永久に使えるわけではありません。ノードの認証情報が期限切れになることもあるため、復元後にリモートの取得元から再取得し、接続を確認してください。

よくある質問：更新・切り替え・復元時のトラブル

複数のProfileを管理するときは、設定の取得元、個人設定の保存場所、現在有効な設定、コアが最終的に読み込んだ内容の4点を区別することが重要です。この4点に沿って確認すれば、更新による上書き、切り替え時の不具合、移行時の設定消失を具体的な工程まで絞り込めます。