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

Profile・サブスクリプションURL・実行時の設定

Clash系クライアントでいうProfileとは、保存・更新・有効化できる設定一式を指します。画面上では「設定」「サブスクリプション」「Profiles」など、クライアントによって表記が異なります。単一のノードや独立したプロキシプロトコルではありません。mihomoコアが実際に使うのは、ノード、プロキシグループ、ルール、DNS、待ち受けポートなどを含む、クライアントから渡された最終的な設定です。

サブスクリプションURLは、リモートの設定を取得するためのアドレスです。クライアントがURLにアクセスして応答をローカルに保存し、内容を検証して読み込みます。そのため、URL、ダウンロード済みファイル、コアが現在使っている設定は、それぞれ別のものです。画面にサブスクリプションを追加しただけでは有効になったとは限りません。また、ファイルを取得できても、現在のコアがすべての項目を受け付けるとは限りません。

項目	保存される内容	主な用途
サブスクリプションURL	認証情報を含むことが多いリモートアドレス	サーバーで公開された設定を再取得する
リモートProfile	ダウンロードした設定と更新情報	取得元を保持し、必要に応じて、または定期的に更新する
ローカルProfile	手動で作成、またはインポートしたYAMLファイル	ノード、ルール、設定構造を自分で管理する
実行時設定	クライアントが処理してコアに渡す設定	現在の接続の名前解決と通信経路を決める

完全な設定ファイルとノードサブスクリプションの違い

「サブスクリプション」と表示されていても、すべての応答をそのまま完全なProfileとして使えるわけではありません。完全なmihomo設定にはproxies、proxy-groups、rulesなどを含められます。一方、ノードだけを含むリソースはproxy-providers向けの場合があります。別形式のノード一覧を使うには、クライアントがインポートや変換に対応している必要があります。ファイルの拡張子だけで互換性を判断しないでください。

リモート設定とローカルYAMLの管理範囲

リモート設定：設定の本体は提供元が管理

リモートProfileは、ノードの変更やサーバー側のルール更新を継続的に反映したい場合に適しています。一般的な操作は「設定」→「新規作成」または「インポート」→「URL」の順に進み、提供元の互換URLを貼り付けてダウンロードし、内容を確認してから有効化します。メニュー名はクライアントごとに異なるため、実際のバージョンの画面で確認してください。特に、項目の取得元と有効状態を確認しましょう。

リモート設定をダウンロードしたファイルを直接編集すると、更新時に変更が上書きされるおそれがあります。次回の更新でノード、プロキシグループ、ルールが再生成され、手動で追加したドメインルールが消えることがあります。変更を継続して使う場合は、クライアントのオーバーライド、マージ、スクリプト機能を優先してください。これらはクライアント側の機能であり、すべてのmihomoクライアントで同じように利用できるわけではありません。

ローカル設定：ファイル自体を自分で管理

ローカルYAMLは、ルールの検証、オフラインでの保管、特定用途向けの設定に適しています。元がサブスクリプションであっても、自動更新されるわけではありません。ファイル内でリモートproviderを利用している場合、そのリソースは個別の設定に従って更新できます。ローカルProfile全体がリモート設定で置き換わることとは別の仕組みです。

以下は設定の構造を確認するための、直接接続用サンプルです。リモートノードを含まないため、プロキシサービスとしては利用できません。サンプルでは混合ポート7890でHTTPとSOCKSクライアントからの接続を受け付け、ルールに従ってトラフィックを選択可能なプロキシグループに振り分けます。

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

proxies: []

proxy-groups:
  - name: 日常の通信
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,日常の通信

proxiesにはインラインノードを記述します。サンプルは空のリストなので、利用できるプロキシノードはありません。
proxy-groupsには通信先をまとめるプロキシグループを定義します。ルールが参照するグループ名は実在し、完全に一致している必要があります。
rulesは上から順に照合されます。先に記述したドメインルールが優先され、最後のMATCHが残りの通信を処理します。
mode: ruleはルールモードを使う設定です。OSのシステムプロキシやTUNを自動で有効にするものではありません。

元ファイルと有効な設定を区別する

クライアントによっては、画面上の設定でポート、DNS、TUNを管理し、その値をProfileにマージします。その場合、元ファイルにmixed-port: 7890と書かれていても、実際には画面で指定した別のポートが使われることがあります。設定の食い違いがある場合は、元ファイルを何度も編集するのではなく、クライアントの「実行時設定」「有効な設定」や関連ログを確認してください。

サブスクリプションの更新間隔とリソースの更新

リモートProfile全体の定期ダウンロードは、通常クライアントが管理します。一方、proxy-providersやrule-providersのリソース更新は、mihomoがそれぞれのintervalに従って実行できます。両者は別々のタイマーで動くため、片方を更新しても、もう片方が同時に更新されるとは限りません。

更新対象	設定場所	間隔の意味
リモートProfile	クライアントのサブスクリプション設定	画面上では分または時間で指定する場合があります。単位を確認してください。
HTTPプロキシprovider	該当するproxy-providersの項目	intervalの単位は通常秒です。3600は1時間です。
HTTPルールprovider	該当するrule-providersの項目	intervalの単位は秒です。86400は24時間です。

提供元の更新頻度に合わせて設定する

まず「設定」→対象のサブスクリプション→「編集」または「設定」で、更新の有効・無効と時間の単位を確認します。
提供元から特別な指定がなければ、リモートProfileの更新はまず24時間間隔を目安にし、ノードの変更頻度に応じて調整できます。これは管理上の推奨であり、コアのデフォルト値ではありません。
手動で一度更新し、完了時刻とエラーメッセージを確認してから、設定が再読み込みされたか確かめます。
デバイスがスリープ中も定期処理が実行されるとは限りません。ネットワーク復帰後に最終更新時刻を確認し、必要に応じて手動で更新してください。

接続障害への対処として、毎分更新する設定にしないでください。頻繁なリクエストは提供元で制限されるおそれがあり、誤ったパスワード、DNS障害、ルールの誤マッチも解決できません。更新で確認するのは「設定内容が古くなっていないか」、接続ログで確認するのは「今回のリクエストがどの経路を通ったか」です。

更新に成功してもノードが変わらない

まず、一覧にある似た名前の別設定ではなく、現在有効な項目を更新したか確認します。次に、ノードがインラインリストとproviderのどちらにあるかを確認してください。ノードがprovider内にある場合、Profileを再ダウンロードしても、同じprovider定義が取得されるだけのことがあります。また、ファイルのダウンロード成功とコアの再読み込み成功は別です。クライアントが古い設定のまま動作を続けていると、通信は正常でも新しい内容は反映されていません。

オーバーライドルールとサブスクリプション更新の併用

リモートノードの管理は提供元に任せ、ローカルの通信振り分け要件はオーバーライドに残す方法が、長期的に管理しやすくなります。たとえば、業務サービスのドメインは直接接続し、それ以外はサブスクリプションのルールを使う場合、該当ルールだけを管理すればよく、リモートのノード一覧全体をコピーする必要はありません。

クライアントがProfileごとのマージ設定に対応しているか、それともすべてのProfileでグローバルオーバーライドを共有するか確認します。
ルールの挿入位置を確認してください。既存のMATCHより後ろに追加したルールは照合されません。
マージ方法を確認します。リスト全体を置き換えるのか、先頭または末尾に追加するのかはクライアントの実装によって異なり、YAMLのマージでルールが自動的に連結されるとは限りません。
再読み込み後に有効な設定を確認し、ルールの順序と参照先のプロキシグループ名を確かめます。

たとえばDOMAIN-SUFFIX,example.com,DIRECTは、該当ドメインとそのサブドメインを直接接続する指定です。サブスクリプション内のプロキシグループに通信を振り分ける場合は、実際に存在するグループ名を指定してください。提供元がグループ名を変更した場合、オーバーライド内の古い名前も更新しないと、設定の検証に失敗することがあります。

複数Profileの保存と用途別の切り替え

Profileを複数保存しても、複数の設定が同時に有効になるわけではありません。多くのデスクトップクライアントでは、1つのコアインスタンスが読み込む最終設定は1つです。Profileの切り替えでは通常、ルール、ノード、プロキシグループが再読み込みされますが、確立済みの接続が直ちに切り替わるとは限りません。具体的な動作はクライアントとコアの仕様によって異なります。

ノード数ではなく用途で名前を付ける

日常用－リモート：安定した利用向け。提供元の更新方針に従って管理します。
仕事用－ローカルルール：社内サービスへのアクセス要件を明確にし、必要なDNSやルーティング条件を記録します。
テスト用－ローカルコピー：ルールの編集や新しい項目の検証に使い、日常用の設定は上書きしません。

バックアップファイルにはdaily-2026-09-09.yamlのような名前を付けられます。日付があれば以前の状態に戻しやすくなりますが、サブスクリプショントークンをファイル名に含めないでください。各設定には取得元、更新方法、オーバーライドの適用範囲も記録しておきましょう。「一覧の3番目」と覚えておくより確実です。

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

有効状態を確認：対象のProfileを選択し、読み込みが完了するまで待って、設定エラーがないか確認します。
プロキシグループの選択を確認：同じ名前のプロキシグループでは以前の選択が復元される場合があります。profile.store-selectedなどの永続化設定を使っている場合は、特に確認してください。
待ち受けポートを確認：アプリで127.0.0.1:7890を手動指定している場合、新しい設定にも同じ接続先が必要です。ない場合は、アプリ側の設定も変更してください。
通信の取り込み方式を確認：システムプロキシ、TUN、DNSの状態を確認します。Profileを切り替えても、OSのネットワーク設定まで必ず連動するわけではありません。
新しい接続をテスト：対象へのリクエストを再実行し、接続履歴で適用されたルールと通信経路を確認します。必要に応じて、関連する既存の接続を切断してから検証してください。

業務ネットワークで専用VPNを使っている場合は、TUNのルートと社内DNSの競合も確認してください。「インターネットに接続できる」だけで切り替え成功と判断せず、社内ドメインを正しく名前解決できるか、ファイルサーバーに直接アクセスできるかも用途に応じて確認しましょう。

よくあるトラブルと復旧手順

インポート後にYAMLの解析エラーが発生する

インデントにスペースを使っているか、Tabが混在していないか、コロンの後に必要なスペースがあるかを確認します。ダウンロード内容の先頭も確認してください。<html>、ログイン画面、期限切れの案内が表示される場合、URLから想定した設定を取得できていません。Webページのエラー内容をYAMLとして編集し続けないでください。

プロキシグループまたはノードが見つからないと表示される

proxy-groups、proxies、providerの参照関係を確認します。ルールの振り分け先は、実在する出力先として解決できなければなりません。まず最近追加したオーバーライドを戻して元の設定を読み込み、原因がサブスクリプションにあるのか、ローカル変更にあるのか切り分けてください。

更新後に読み込めないが、以前の設定は使える

以前の設定は残し、すべてのProfileを先に削除しないでください。ログで読み込み失敗に関係する最初のエラーを確認し、現在のクライアントとmihomoコアのバージョンを記録します。GUIのバージョンとコアのバージョンは別です。新しい設定項目に未対応の場合は、メンテナンス情報を確認して互換性のあるコアに更新するか、以前使えていた設定に戻してください。

更新がタイムアウトする、またはアクセスエラーが返る

HTTPの401や403では、認証情報、権限、サーバー側の制限を確認します。429はリクエスト頻度が制限されていることを示します。タイムアウトの場合は、ネットワークやDNSに加えて、クライアントがサブスクリプションを取得するときに直接接続とプロキシのどちらを使うか確認してください。更新リクエストが必ず現在選択中のノードを経由するとは限りません。

使用中のノードが無効になり、サブスクリプションの取得にもそのノードが必要な場合、更新が循環依存に陥ることがあります。クライアントで許可される範囲で、提供元にアクセスできる別の更新方法を一時的に使い、新しい設定を取得してから元の設定に戻してください。作業中にサブスクリプション一覧を何度も空にする必要はありません。

バックアップと日常管理のチェックリスト

直近で動作を確認した設定を少なくとも1つと、それに対応するオーバーライドを保存します。
リモートProfileとローカルの検証用ファイルは別の名前で管理し、更新時に手動ルールを上書きしないようにします。
エクスポートしたファイルにはノードのパスワード、サブスクリプションURL、コントロールインターフェースの認証情報が含まれることがあります。機密ファイルとして保管してください。
別のデバイスへ移行する際は、YAMLをコピーするだけでなく、ポートの競合、ファイルパス、TUNの権限、システムプロキシの設定も確認します。
大きな変更を行うたびに、有効なProfile、プロキシグループの選択、確認対象を記録しておくと、再現やロールバックが容易になります。

Profile管理の基本は、取得元、変更内容、実行状態を分けて考えることです。サブスクリプションはリモート設定を提供し、ローカルファイルやオーバーライドは用途ごとの要件を保持します。有効な設定と接続履歴を確認すれば、実際の動作を検証できます。この3つの境界を明確にしておけば、更新やProfileの切り替えを決まった手順で確認でき、問題のたびに再インストールする必要はありません。