Clashの設定ファイル（Profile）入門｜複数のサブスクリプション切り替えとローカル設定管理

1. Profile・サブスクリプション・実行設定の関係

ClashクライアントにおけるProfileとは、保存して選択し、コアに読み込ませる設定データのことです。サブスクリプションURLから取得する場合も、ローカルのYAMLファイルから読み込む場合もあります。設定カードが3枚あっても、3つのプロキシが同時に有効になるわけではありません。一般的なデスクトップクライアントでは、通常、一度に選択できるメイン設定は1つです。クライアント設定やオーバーライドを加えたものが、コアに渡される実行設定になります。

この記事では、mihomoコアを使用するClash Verge Revなどのデスクトップクライアントを例に操作方法を説明します。クライアントによってメニュー名は「サブスクリプション」「設定」「Profiles」など異なりますが、該当する機能の探し方もあわせて紹介します。旧Clashコアとmihomoでは対応する設定項目が完全には一致しません。拡張子が.yamlであるだけで、どの環境でも使えると判断しないでください。

種類	保存される内容	更新方法
リモートProfile	サブスクリプションURL、取得した設定、クライアント上の記録	手動更新または定期更新
ローカルProfile	手動で作成・インポートしたYAML	手動で編集。外部ファイルとの同期はクライアントによって異なる
オーバーライド設定	ベース設定に追加・変更する項目やルール	クライアントのマージ機能またはスクリプトで処理
実行設定	コアに渡される最終的な設定	設定の選択、適用、再読み込み時に生成

サブスクリプションには、返されるデータの種類もあります。完全な設定を返すものもあれば、ノード情報だけを返すものもあります。完全な設定には通常、プロキシ、プロキシグループ、ルールが含まれます。ノード情報だけの場合は、クライアントが対応する変換機能やproxy-providersを使って取り込む必要があり、そのまま完全なProfileとしては使えません。トークンを含むサブスクリプションURLを、信頼できないオンライン変換サービスに入力しないでください。

2. サブスクリプションを2つ追加し、名前を付けてから有効化

複数の設定を管理するうえで、まず重要なのは見分けやすくすることです。「サブスクリプション1」「サブスクリプション2」のような名前では、しばらくすると編集できるものやリモート更新されるものが分からなくなります。用途・提供元の識別名・設定の種類を分けて記録しましょう。表示名にはアクセストークン、メールアドレス、サブスクリプションURL全体を含めないでください。

見分けやすい設定名を付ける

左側の「サブスクリプション」または「Profiles」を開き、URL入力欄にサービス提供元から案内されたClash対応URLを貼り付けて「インポート」をクリックします。設定カードが表示されるまで待ちましょう。URLを貼り付けられたことと、設定の取得に成功したことは別です。
カードの右クリックメニューまたはその他のメニューを開き、「情報を編集」などの項目から名前を「日常用-A-リモート」に変更します。記録されているリモートURLが正しいことを確認して保存してください。
同じ手順で2つ目をインポートし、「予備-B-リモート」と名付けます。形式エラーが出た場合は、取得した内容がYAMLではなく、ログインページや期限切れの案内になっていないか確認してください。
「日常用-A-リモート」のカードをクリックします。選択済みの表示を確認したら、「プロキシ」画面を開き、この設定に定義されたプロキシグループとノードが表示されることを確認してください。

ここで変更した名前はクライアント上の表示名であり、YAML内のプロキシグループのnameは自動では変わりません。ルールがPROXYという名前のプロキシグループを参照している場合、参照元を変更せずにグループ名だけを「日常用プロキシ」に変えると、設定の読み込みに失敗することがあります。整理を始めたばかりの段階ではカード名だけを変更し、内部のグループ名はそのままにしておきましょう。

3. サブスクリプション切り替え後は4項目を確認

AからBに切り替えると、ノード一覧だけでなく、DNS、ルール、プロキシグループ名、待ち受けポート、TUN関連の設定も変わる場合があります。一方、クライアントの共通設定がその一部を上書きすることもあります。そのため、「ノード名が変わった」だけでは、設定全体が想定どおりに動作しているとは判断できません。

読み込み結果を確認：Bを選んだら「ログ」を開き、設定の解析エラーやプロキシグループの参照エラーがないか確認します。新しい設定の読み込みに失敗した場合、クライアントの処理によっては以前の設定が引き続き使われることも、サービスが停止することもあります。
プロキシモードを確認：ホーム画面で、現在のモードがRule、Global、Directのどれかを確認します。ルールによる振り分けを確認する場合はRuleを選びます。Globalでは全通信がグローバルポリシーに従うため、ルールの順序が正しいことの確認には使えません。
実際の接続先を確認：「プロキシ」を開き、Bの主要なプロキシグループで利用可能なノードを選んでから、テスト用のWebページを開きます。Bのグループ名がAと異なる場合、以前保存したノード選択が引き継がれないことがあります。
新しい接続の記録を確認：「接続」を開き、新しいリクエストに適用されたルールとプロキシ経路を確認します。長時間接続は以前の出口を使い続ける場合があります。テスト用Webページをいったん閉じて開き直し、必要なら該当するテスト接続だけを切断してください。

ポート変更で「切り替え後にネットにつながらない」理由

たとえば、アプリにローカルHTTPプロキシ127.0.0.1:7890を手動で設定していて、Bの実際の待ち受けポートが7897に変わった場合、アプリが古いポートにリクエストを送ると接続に失敗します。この数値はトラブルシューティング用の例であり、すべてのクライアントの初期値ではありません。クライアントの「設定」で現在のポートを確認し、アプリのプロキシ設定と項目ごとに照合してください。

システムプロキシ、TUN、Profileはそれぞれ異なる設定です。Profileはコアの実行に必要な設定を提供し、システムプロキシはシステムのプロキシ設定に従うアプリに影響します。TUNはルーティング条件に合う通信を取り込みます。Profileを選択しただけで、システムプロキシやTUNが自動で有効になるわけではありません。

4. 自動更新間隔を設定：サブスクリプション更新とヘルスチェックを区別

リモートProfileの定期更新はクライアントが管理します。通常は設定カードの「情報を編集」にある「更新間隔」または「自動更新」から設定できます。まず入力欄の単位を確認してから数値を入力してください。単位が分の場合は720で12時間ごと、秒の場合は12時間に43200を入力します。他のクライアントの画面を見て、そのまま設定しないでください。

普段使いの設定：まずは24時間ごとの更新に設定できます。画面の単位が分なら1440を入力します。サービス提供元から更新頻度の指定がある場合は、その案内に従ってください。
予備の設定：実際に切り替えるときにURLの期限切れに気付くことがないよう、こちらも定期的に更新してください。更新後はノード数と接続状況を一度確認しましょう。
ローカル設定：リモートの取得元がない場合、サブスクリプションの更新間隔を設定する必要はありません。自動更新ボタンを表示させるために、適当なURLを入力しないでください。

クライアントを終了すると、通常は内部の定期タスクも実行されません。PCがスリープ中に予定どおり更新されることも期待できません。クライアントの再起動後すぐに更新されるかどうかは、実装によって異なります。外出先で予備の設定を使う予定がある場合は、事前にカードのメニューから「更新」をクリックし、更新成功時刻を確認してから接続テストを行うと確実です。

3種類のintervalを混同しない

Profileの更新間隔はクライアント上の設定です。YAMLのproxy-providersにあるintervalは該当するリモートノード情報の更新を制御し、health-check.intervalはヘルスチェックの頻度を制御します。mihomoのこれらのprovider項目では、間隔の単位は秒です。ヘルスチェックを300秒に変更しても、メインのサブスクリプションが5分ごとに再取得されるわけではありません。

5. ローカルYAML：設定のスナップショットに便利。サブスクリプションには自動追従しない

ローカルProfileは、ルールのテスト、問題発生前の設定の保存、自分で管理する完全な設定の運用に適しています。一般的なインポート手順は「サブスクリプション」→「新規作成」または「ファイルをインポート」を選び、ローカルYAMLを読み込んで「テスト用-ルール-ローカル」などの名前で保存する方法です。クライアントによってはファイルを独自のデータフォルダーにコピーし、元のファイルを継続して読み込まないことがあります。インポート後に外部で元ファイルを編集しても、カードの内容に反映されるとは限りません。

ローカルコピーを作成する手順

リモートカードのメニューから「ファイルを編集」や「ファイルを開く」を探し、取得済みのベース設定をコピーします。クライアントのエクスポート機能を使う方法もあります。
コピーを保護されたローカルフォルダーに保存し、ファイルのインポート機能から新しいカードとして追加します。既存のリモート設定は上書きしないでください。
変更する項目は一度に1つに絞ります。保存してローカルカードを選択し、ログを確認してください。問題なく読み込めたら次の項目を変更します。
元に戻せるよう、リモートカードを残しておきます。実験に失敗した場合はそちらに切り替え、プロキシモード、プロキシグループの選択、新しい接続の記録を確認してください。

以下は項目を確認するための基本的な断片であり、サブスクリプションを置き換えられる完全なプロキシ設定ではありません。最後のルールは、それ以外のすべてのリクエストを直接接続に送ります。プロキシノードは定義されていません。ルールのテストではこの動作を理解したうえで使用してください。接続を修復するための設定として使うことはできません。

mixed-port: 7890
mode: rule
log-level: info

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

YAMLのインデントにはスペースを使い、Tabは使用しないでください。同じ階層の項目は同じ幅でインデントします。既存ファイルを編集するときに、トップレベルのrulesやdnsキーを重複して追加しないでください。重複キーは拒否されたり、内容が上書きされたりする場合があります。保存前に、まずクライアントの設定チェック機能を使ってください。

ローカルコピーに保存したノードの認証情報も、いずれ使えなくなることがあります。一度コピーすれば更新不要というわけではありません。ノード情報は自動更新しつつ個人ルールを維持したい場合は、更新が止まったサブスクリプションのコピーを使い続けるのではなく、オーバーライドやproviderの仕組みを利用してください。

6. サブスクリプション更新後もオーバーライドを維持：取得元と個人設定を分ける

リモートサブスクリプションから取得したYAMLを直接編集すると、次回の更新で新しい内容に置き換わる可能性があります。リモートProfileにはサービス提供元の設定を残し、個人ルールはクライアントのオーバーライド、マージ設定、スクリプトに保存する方法がより安全です。クライアントは実行設定を生成する際に、独自の処理順序で変更内容を重ね合わせます。

この機能に対応したクライアントでは、「サブスクリプション」画面にある「グローバル拡張設定」「グローバル拡張スクリプト」や、個別カードのメニューにある「拡張設定」を探します。名称や適用範囲はバージョンによって異なります。グローバル設定はすべてのProfileに影響する場合があり、個別設定は該当する記録にだけ適用されるのが一般的です。普段使いの設定に適用する前に、テスト用コピーで適用範囲を確認してください。

マージの動作を確認してからルールを追加

マップ項目：DNSの子項目を変更する場合は、クライアントが再帰的にマージするのか、項目全体を置き換えるのかを確認し、既存の名前解決設定が失われないようにします。
リスト項目：rules、proxies、proxy-groupsはいずれもリストです。通常のYAML断片に自動的な「追加」の意味があるわけではなく、具体的な動作はクライアントによって異なります。
ルールの順序：Clashのルールは上から順に照合されます。個人ルールは通常、フォールバック用のMATCHより前に配置する必要があります。MATCHの後に追加しても、ほとんどの場合そのルールには到達しません。
ポリシーの参照先：グローバルオーバーライドがAにしかないプロキシグループを参照していると、Bへの切り替え時に読み込みエラーになることがあります。複数設定で共用する場合はグループ名を統一するか、拡張設定をProfileごとに分けてください。

たとえば、example.comとそのサブドメインを直接接続する場合、ルールはDOMAIN-SUFFIX,example.com,DIRECTと記述できます。これはルールの書式を示す例です。現在のクライアントが明示的に対応している「前置ルール」の設定画面を使うか、拡張スクリプトのAPIに従って挿入してください。すべてのクライアントが同じprepend-rules項目に対応しているとは限りません。

更新して設定が維持されることを確認

オーバーライドを保存して設定を適用します。最終的な実行設定で対象ドメインを検索し、想定した回数だけ存在し、フォールバックルールより前にあることを確認してください。
対象ドメインに再度アクセスし、「接続」で該当ルールとDIRECTポリシーが適用されていることを確認します。
リモートProfileを手動で更新し、設定が再読み込みされるのを待ってから、最初の2項目をもう一度確認します。
予備のProfileに切り替え、グローバルオーバーライドが存在しないプロキシグループを参照していないことを確認します。エラーが出る場合は、該当するProfileだけに適用する設定へ変更してください。

「更新後も設定が残る」「リクエストに正しく適用される」「Profile切り替え後にエラーが出ない」の3点がすべて確認できて、はじめて設定が維持できたといえます。ベースとなるサブスクリプションのファイルに個人ルールが見当たらなくても、消えたとは限りません。最終的な実行設定にだけ含まれている場合があります。

7. バックアップと復元：再び有効化するために必要な最小限を保存

バックアップはプロキシ画面のスクリーンショットだけでは不十分です。設定の表示名、リモートURL、個人用オーバーライド、必要なローカルYAML、現在のポートとモードを保存しておきましょう。proxy-providers、rule-providers、相対パスを使っている場合は、依存ファイルを再取得できるか確認し、必要に応じてファイルも一緒に保存してください。

症状	まず確認する項目	復元方法
更新後にカスタムルールが消えた	リモートファイルを直接編集していないか	バックアップからルールを復元し、独立したオーバーライドへ移行する
切り替え後にプロキシグループが存在しないと表示される	グローバルオーバーライドで指定しているポリシー名	該当するオーバーライドを無効にし、Profileごとの拡張設定に切り替える
設定を選択したのにアプリがインターネットに接続できない	待ち受けポート、システムプロキシ、TUNの状態	実際に有効なポートに合わせてアプリのプロキシを設定し直し、新しい接続でテストする
ローカルファイルを編集しても反映されない	インポート時にファイルがコピーされていないか	クライアントが実際に使用しているコピーを編集し、設定を再適用する

サブスクリプションURLや設定ファイルには、そのまま使用できる認証情報が含まれている場合があります。公開リポジトリに置かないでください。他の人にトラブル対応を依頼する際は、サブスクリプショントークン、ノードのパスワード、秘密鍵を削除し、スクリーンショットでもURL全体を隠してください。新しい端末へ移行するときは、まず動作確認済みの設定をインポートして接続し、次にオーバーライドを戻し、最後に定期更新を有効にすると、各段階の問題を切り分けやすくなります。

サブスクリプションのインポート、ルール、TUNの関係を詳しく確認したい場合はClash 設定ガイドをご覧ください。初回インストール後の操作手順は使い方ガイドで確認できます。