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

Profileとは？選択して使う設定プロファイル

Profileは、クライアントが設定を管理するためのプロファイル項目であり、個々のノードを指すものではありません。通常は設定内容、表示名、取得元のURL、更新日時などが記録されています。クライアントによって「設定」「設定ファイル」「Profiles」などと表示されます。項目を選択すると、対応する内容がコアに読み込まれます。

コアは接続を実際に処理するプログラムです。ClashやClash Meta（現在の名称はmihomo）はこの層に属します。一方、デスクトップのウィンドウやサブスクリプション一覧、更新ボタンはクライアントの画面にあたります。Profileの管理方法はクライアントごとに異なるため、この記事では操作の目的を軸に説明し、特定の画面でのボタン配置を共通仕様として扱いません。

YAMLはインデントで階層を表すテキスト形式です。完全な設定には通常、ポート、ノード、プロキシグループ、ルールが含まれます。一方、サブスクリプションURLから返される内容が完全な設定とは限りません。ノード一覧だけを返すURL、Base64エンコードされたデータを返すURL、Clash用の完全なYAMLを返すURLがあります。拡張子が設定ファイルと同じでも、そのまま使用できるとは限りません。

まず取得元を確認：サブスクリプション設定かローカル設定か

サブスクリプション設定：更新時にリモートから再取得

サブスクリプション設定は、プロバイダーがノードや基本ルールを管理する場合に適しています。クライアントは取得元のURLを保存し、更新操作のたびにサーバーへ再アクセスします。リモートの内容が変わると、通常はローカルのキャッシュが置き換わります。以前の内容を保持するか、設定をどのようにマージするかはクライアントの実装によって異なります。

• メリット：ノードの追加・削除や接続パラメーターの変更を、個別に編集せず更新で反映できます。
• 注意点：ダウンロードした元の設定を直接編集しても、次回の更新で変更が消えることがあります。
• 確認ポイント：項目に取得元URLと前回の更新日時が表示されるか、今回の更新が成功したかを確認します。

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

ローカル設定は、ルールの学習、固定設定の保存、トラブル時の比較に向いています。インポート後、ファイルをコピーするクライアントもあれば、指定したパスを読み込むクライアントもあります。元ファイルを編集すればすぐ反映されるとは限りません。編集後に再読み込みし、クライアントが実際にどのファイルを使っているか確認してください。

ローカル設定にproxy-providersを含めて、リモートからノードを取得することもできます。つまり、「ローカルProfile」でもリモート更新を一切使わないとは限りません。設定全体の更新、ノードプロバイダーの更新、rule-providersによるルールプロバイダーの更新は、それぞれ別のものです。

最初の設定をインポート：形式を確認してから有効化

インポートの成功と、実際に使用中であることは別です。一覧に項目が追加されても、確認できるのはクライアントにプロファイルが登録されたことだけです。構文チェックを通過したか、有効化されたか、通信がコアに届いているかは、それぞれ別に確認する必要があります。

1. クライアントの「設定 / Profiles」画面を開き、リモートからのインポートまたはURLからのインポートを選びます。プロバイダーがClashまたはmihomo形式として明記しているサブスクリプションURLを貼り付けてください。
2. 追加した項目に日常用-サブスクAと名前を付け、現在使えている設定はまだ削除しないでください。「新しい設定」のような名前よりも、用途が分かる名前のほうが見分けやすくなります。
3. 一度更新を実行し、結果を確認します。形式エラーが表示される場合は、返された内容がログイン画面や有効期限切れの通知、あるいは別形式のサブスクリプションデータではないか確認してください。
4. 項目を選択して、有効化または切り替えを実行します。ログに読み込み失敗や、プロキシグループの参照先が存在しないといったエラーがないか確認してください。
5. 「プロキシ / Proxies」画面でプロキシグループが表示されているか確認し、モードがルールに基づいて振り分けるRuleになっていることを確認します。最後に、想定される通信経路が分かっているサイトを開き、接続ログを確認してください。

ローカル設定をインポートする場合は、ファイルからのインポートを選び、.yamlまたは.ymlファイルを指定します。その後、有効化と動作確認を同じ手順で行ってください。クライアントによって「インポート」「新規作成」「追加」など名称が異なります。見つからない場合は、使い方ガイドの基本手順を確認してください。

ローカルの比較用設定を作成：構文の問題とネットワークの問題を切り分ける

シンプルなローカル設定を用意すると、クライアントがYAMLを正常に読み込めるか確認できます。以下はmihomo向けの例で、設定階層とプロキシグループの参照方法を示すものです。リモートのプロキシノードは含まれておらず、プロキシ接続も提供しません。

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

proxies: []

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

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

• mixed-port: 7890は、HTTPとSOCKSの両方のリクエストを受け付けるローカルプロキシポートを定義します。これはサンプル値であり、すべてのクライアントが7890を使うわけではありません。
• allow-lan: falseは、LAN内の端末からこのプロキシへのアクセスを許可しません。まずローカル環境で確認する場合に適しています。
• 手動選択はプロキシグループ名です。ルールの最後の要素を、この名前と完全に一致させる必要があります。
• DIRECTは直接接続、REJECTは通信拒否を意味します。どちらも組み込みの出力先であり、リモートノードではありません。
• MATCH,DIRECTはフォールバックルールです。それより前のルールに一致しない通信は、直接接続されます。

ファイルをlocal-baseline.yamlとして保存し、インポート後に確認用-ローカル直結という名前を付けます。この設定を読み込めても、基本的な構造が受け付けられたことしか確認できず、サブスクリプションのノードが使える証明にはなりません。クライアントで全体設定の上書きが有効な場合、実際のポートやモードがファイルの記述と異なることもあります。

YAMLを編集するときはスペースでインデントし、Tabは使わないでください。各フィールドを詳しく確認する場合は、YAMLマニュアルを参照してください。mihomo向けの新しいフィールドを、旧バージョンを含むすべてのClashコアにそのまま適用しないでください。未対応のフィールドはエラーになるか、無視されることがあります。

複数設定の命名と切り替え：用途と確認手順を固定する

多くのクライアントで、同時に有効化できるメイン設定は1つです。Profileが3つ登録されていても、3つのサブスクリプションが自動でマージされたり、通信が同時に振り分けられたりするわけではありません。複数の取得元を1つの設定にまとめるには、通常、プロバイダー機能またはクライアントが対応するマージ機能が必要です。

切り替え後に4項目を確認

1. 有効化された項目：編集画面を開いただけではなく、選択マークが切り替え先の設定に付いていることを確認します。
2. 動作モード：Ruleはルールに基づく振り分け、Globalはグローバル設定、Directは直接接続です。画面に保存されたモードが、ファイル内のmodeを上書きする場合があります。
3. プロキシグループの選択：ルールから実際に参照されているグループを開き、現在の選択先を確認します。新しい設定でグループ名が変わると、以前の選択内容を引き継げない場合があります。
4. 新しい接続のログ：リクエストを再度実行し、適用されたルール、プロキシグループ、最終的な出力先を確認します。ブラウザーで確立済みの長時間接続は、切り替え前の経路を一時的に使い続けることがあります。

切り替え後すぐに結果が変わらない場合は、テスト中のページを閉じてから開き直し、必要に応じて関連する古い接続だけを終了してください。最初からクライアントの再インストール、全設定の削除、DNSの変更を同時に行うのは避けましょう。変更が多すぎると原因を特定できなくなります。

定期更新とカスタムルール：変更をどこで管理するか確認

更新間隔は運用上の設定であり、短いほどよいわけではありません。たとえば、一般的なサブスクリプションなら、まず更新間隔を24時間に設定できます。プロバイダーから指定がある場合は、その案内に従ってください。入力欄の単位が分なら24時間は1440分、秒なら86400秒です。保存前に単位を確認しましょう。

定期更新は通常クライアントが行うため、PCがスリープ中だったりアプリが終了していたりすると実行されない場合があります。一方、proxy-providers内のintervalはコアのプロバイダーフィールドで、通常は秒単位です。クライアントによるProfile全体の更新スケジュールの代わりにはなりません。

長期間保持するルールは、独立した変更レイヤーに置く

• クライアントに「上書き」「マージ」やスクリプト処理機能がある場合は、まず関連ドキュメントを読み、カスタム設定を独立したレイヤーに追加してください。マージの順序はクライアントごとに異なります。
• 元ファイルの編集機能しかない場合は、先にコピーをエクスポートしてから編集し、その後は手動で管理する必要があることを理解しておきましょう。
• ルールを追加するときは順序に注意してください。一般的なルールは上から順に評価されるため、新しいルールをMATCHの後に追加しても、通常は期待どおりに動作しません。
• 更新後はサブスクリプションの元ファイルだけでなく、最終的に適用されている設定も確認してください。クライアントがポート、DNS、TUNの設定をさらに上書きしている場合があります。

切り替え後にルールがおかしい場合：ノードをむやみに変えず、症状から確認

プロキシグループが消えた、またはルールが存在しない名前を参照している

まず読み込みログを確認してください。たとえば、ルールが日常用プロキシを参照しているのに、新しい設定には手動選択しか定義されていない場合、参照先が一致しません。スペル、大文字・小文字、空白を確認し、上書きルールが以前の設定のグループ名を参照したままになっていないかも確認してください。グループ名を変更した場合は、カスタムルールも合わせて変更します。

切り替えは成功したが、一部のアプリだけプロキシを経由する

まず通信がコアに届いているか確認してください。システムプロキシはOSが提供するプロキシ設定であり、すべてのアプリが従うとは限りません。TUNモードは仮想ネットワークインターフェースで通信を処理しますが、適切な権限、ルーティング、DNS設定も必要です。Profileを切り替えても、こうした通信経路の問題が自動で解決するわけではありません。

アプリの接続先が127.0.0.1:7890のままなのに、実際の待ち受けポートが7897に変わっている場合、古いポートに接続しているか、接続エラーになっている可能性があります。この2つの数字は確認用の例です。実際の待ち受けポートはクライアントの表示に従ってください。切り替えに合わせてシステムプロキシも更新されているか、別途確認が必要です。

ページは開くが、想定と異なる経路から接続される

まず接続ログにドメイン名が記録されているか確認し、次に適用されたルールを確認します。アプリ独自のDNS、暗号化DNS、IPへの直接接続、既存接続の再利用などが確認結果に影響することがあります。1つのサイトに表示された出口情報だけで、設定全体が有効かどうかを判断しないでください。ドメイン名が分かるサイトを選び、新しい接続を作成して、該当するログと照合します。

更新後に使えなくなったが、以前の設定なら正常に動く

エラー情報を保存し、直近で正常に使えたコピーに戻してから、ノード、グループ名、ルールの変更点を比較します。サブスクリプションの応答に問題がある場合は、形式と有効期限をプロバイダーに確認してください。更新ボタンを短時間に何度も押しても、同じリクエストが繰り返されるだけで、リモート側のデータ不備は解決しません。通信経路に関する問題はよくある質問も参考に、項目ごとに確認してください。

バックアップとロールバック：動作確認済みの設定を最低1つ残す

バックアップには設定内容だけでなく、使用状態も記録してください。サブスクリプションURLだけでは当時のルールを復元できません。また、YAMLだけではクライアントのモード、TUNの有効状態、上書き設定が含まれない場合があります。

1. 大きく変更する前に、現在使えている設定をエクスポートしてください。ファイル名はdaily-before-edit-2026-08-03.yamlのようにすると、日付で識別できます。
2. コアの種類、実際の待ち受けポート、モード、プロキシグループの選択先、有効な上書き項目を記録します。スクリーンショットを撮る際は、サブスクリプションURLとノードの認証情報を隠してください。
3. 変更内容は新しい項目に追加してテストします。読み込みが正常で、ルールの適用結果も想定どおりであることを確認してから、日常用の設定を置き換えるか判断してください。
4. ロールバックする場合はバックアップ項目を選択し、対応するクライアント設定も復元してから、新しい接続で動作を確認してください。「ファイルのインポートに成功した」だけでは復元完了とはいえません。

普段の管理はシンプルにできます。日常用のサブスクリプション、予備設定、ローカルの確認用設定を1つずつ用意します。取得元を区別し、名前を決め、切り替え後は同じ順序で確認してください。問題が起きたときに、設定内容、更新処理、システムプロキシやTUNなどの通信経路のどこに原因があるか判断しやすくなります。