ClashのProfile設定ファイル入門：インポート・切り替え・複数設定の管理

PROFILE / 01

Profileには何が保存されるのか

ClashのGUIクライアントにおけるProfileとは、通常、コアが読み込める設定一式を指します。リモートのサブスクリプションURLから取得する場合もあれば、手動でインポートしたローカルのYAMLファイルの場合もあります。クライアントはProfileのダウンロード、保存、切り替え、更新を担当し、Clashまたはmihomoコアは有効な設定に従ってリスニングポートを作成し、プロキシノードを読み込み、プロキシグループを生成して、ルールに基づき通信を処理します。

Profileの日本語表示はクライアントによって完全には統一されておらず、「設定」「設定ファイル」「サブスクリプション」「Profiles」などの表記が使われます。画面上の名称は異なっても、基本的な関係は共通しています。設定一覧には複数のファイルを保存できますが、通常、コアに渡して実行できるメイン設定は同時に1つだけです。項目の切り替えは単なるノード変更ではなく、ポート、DNS、プロキシグループ、ルール、TUNパラメーターまで置き換わる可能性があります。

簡略化した設定にすると、これらの構成要素の関係を確認できます。実際のサブスクリプションには通常、より多くのノードやルールが含まれ、利用できるフィールドの範囲は使用するコアのバージョンにも左右されます。

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

proxies:
  - name: example-node
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - example-node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,ノード選択
  - MATCH,DIRECT

SOURCE / 02

サブスクリプション設定とローカル設定の違い

リモートのサブスクリプションProfileは、サブスクリプションURLから提供されます。クライアントにURLを保存すると、必要に応じて、または定期的に設定を再ダウンロードできます。更新後の内容は通常、クライアントにキャッシュされた旧バージョンを置き換えるため、ノードの増減、プロキシグループの調整、ルールの変更は次回の読み込み時に反映されます。サブスクリプションURLにはアクセス認証情報が含まれることが多いため、パスワードと同じように扱い、公開スクリーンショット、ログ、質問文などに貼り付けないでください。

ローカルProfileは、端末上のYAMLファイルから読み込まれます。手動ルール、固定ポート、実験的なDNS設定、トラブル対処用の最小構成を保存するのに適しています。ローカルファイルにはリモートの提供元がないため、クライアントが自動更新することは通常ありません。変更を反映するには、ファイルを再編集するか、修正版のコピーをもう一度インポートする必要があります。

もう一つ混同しやすいケースとして、一部のクライアントではリモート設定をコピーしてローカルの複製を作成できます。複製は作成時点のサブスクリプション内容を引き継ぎますが、その後は元のサブスクリプションと自動同期されないのが一般的です。設定の出所を確認するには、項目にサブスクリプションURL、更新日時、更新間隔、更新ボタンが表示されているかを確認します。ファイルパスと変更日時だけが表示される場合は、ローカルファイルである可能性が高いでしょう。

サブスクリプションの更新を受けつつカスタムルールも長期保存したい場合は、クライアントが提供する上書き、マージ、拡張機能を優先して使いましょう。機能名は Override、Mixin、Merge、上書き設定などの場合があります。これらの機能はサブスクリプションのダウンロード後に指定フィールドを追加または変更し、キャッシュファイルを直接編集した際に起きる上書き問題を減らせます。クライアントによってマージ構文は異なるため、移行前に対応するフィールドの説明を確認してください。

IMPORT / 03

設定のインポートと初回チェック

リモートサブスクリプションをインポートする場合は、クライアントのProfile画面で「URLからインポート」などの入口を使い、ノード名、ルールエディター、ブラウザーのプロキシ設定にサブスクリプションURLを貼り付けないでください。インポートに成功しても、それはクライアントがレスポンスを取得できたことを示すだけです。返された内容を現在のコアが解析できるかも確認する必要があります。サーバーがログインページ、案内文、形式の不完全なYAMLを返した場合、クライアントが項目を作成できても、コアの読み込み時にエラーが発生することがあります。

ローカルファイルをインポートする前に、拡張子と文字コードを確認しましょう。YAMLの拡張子は通常 .yaml または .yml で、UTF-8で保存することをおすすめします。YAMLはインデントで階層を表すため、スペースを使い、同じ階層にタブを混在させないでください。プロキシグループが参照するノード名はノード定義と一致している必要があり、ルールが指定するプロキシ名も実際に存在しなければなりません。

1. 現在使える設定を残す。新しいProfileを初めてインポートする前に、元の設定をすぐ削除しないでください。読み込みに失敗した場合、すぐに元へ戻せます。
2. インポート完了と更新日時を確認する。リモート項目には直近の取得日時が表示され、ローカル項目ではファイル名を認識できることを確認します。
3. 設定を有効化し、コアの状態を確認する。解析失敗、起動失敗、ポート競合が継続的に表示されていないことを確認してください。
4. プロキシグループを確認する。グループ内に選択可能なノードがあり、自動テストグループが遅延測定を完了できるか確認します。
5. 通信の引き受け方式を確認する。システムプロキシモードではリスニングポートを、TUNモードでは仮想ネットワークアダプターの状態と権限を確認します。
6. 直結先とプロキシ経由先を分けてテストする。1つのWebページが開けるだけでは、ルール、DNS、すべてのプロキシ方針が正しいとは限りません。

mihomo設定では、特定のコアだけが対応するフィールドにも注意が必要です。あるProfileがmihomoクライアントで正常に動作しても、古いオリジナルClashコアへそのまま渡せるとは限りません。「未知のフィールド」や解析失敗が発生した場合は、サブスクリプションURLを何度も変更するのではなく、コアの種類とバージョンを比較してください。

SWITCH / 04

複数のProfileを正しく切り替える

設定を切り替える前に、現在の動作モードと使用中のプロキシグループを記録します。Profileごとにプロキシ選択を保存するクライアントもあれば、新しい設定で同名グループの選択を復元しようとするクライアントもあります。2つの設定にどちらも「ノード選択」が含まれていても、グループ内のノードがまったく違えば、画面が最初の利用可能な選択肢に戻ることがあります。切り替え後は、以前の結果をそのまま引き継ぐのではなく、重要なプロキシ方針を再確認してください。

ポートも確認が必要なフィールドです。設定Aが mixed-port: 7890、設定Bが mixed-port: 7893 の場合、システムプロキシが7890を指したままだと、設定Bへの切り替え後にブラウザーだけ接続できず、コア自体は正常に見えることがあります。デスクトップクライアントによってはシステムプロキシのポートを自動同期しますが、設定の読み込みだけを行うものもあります。そのため、設定を切り替えるたびに、クライアントに表示される実際のリスニングアドレスを確認してください。

TUNモードでは切り替えの影響範囲がさらに広くなります。ProfileによってDNSモード、ルート除外項目、自動ルート設定、インターフェース検出パラメーターが異なる場合があります。切り替え時に仮想ネットワークアダプターが一時的に再作成され、既存の接続が閉じるまで古い経路を使い続けることもあります。新しい設定を検証する際はテスト対象のアプリを再起動し、必要に応じて古い接続を切断してからルールのヒット状況を確認しましょう。

日常利用に適した切り替え手順

1. 対象Profileの直近の更新が成功していることを確認し、読み込みエラーがないか確認する。
2. 現在のプロキシグループの選択を記録する。特に手動選択グループとグローバルモードの出口を確認する。
3. 対象Profileへ切り替え、コアの再読み込みが完了するまで待つ。
4. 動作モードがRule、Global、Directのどれかを確認し、別の設定に書き換えられていないか確認する。
5. システムプロキシまたはTUNの状態を確認し、実際のリスニングポートを照合する。
6. 接続ログを開き、直結ルールとプロキシルールを1件ずつテストする。

切り替え後に出口だけを変更し、ルールやDNSを置き換える必要がない場合は、現在のProfileのプロキシグループでノードを選ぶ方が適しています。不要な設定切り替えを減らすことで、ポート、ルール、TUNパラメーターが同時に変わることによる切り分けの負担も抑えられます。

CATALOG / 05

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

設定が増えると、問題はインポートよりも識別にあります。複数の項目がすべて config.yaml という名前では、出所、用途、更新方法を判断しにくくなります。名前には少なくとも「出所の種類」と「利用シーン」を含めるとよいでしょう。たとえば「サブスク-A-日常」「ローカル-ルールテスト」「バックアップ-移行前」などです。名前にサブスクリプションの認証情報、完全なURL、ノードサーバーのアドレスを含める必要はありません。

日付は「バックアップ-2026-05-18」のような一時スナップショットに向いています。一方、継続的に更新されるサブスクリプションは、更新のたびに名前を変えると区別しにくい重複項目が大量に生まれるため、毎回の改名は避けましょう。長期利用する設定については、コアの要件、ポート、DNSモード、カスタム内容を別の記録に保存し、記憶だけに頼らないようにします。

記録しておきたい情報

• 出所：リモートサブスクリプション、ローカルファイル、またはサブスクリプションから作成したローカル複製か。
• 用途：日常利用、ルールのデバッグ、TUNテスト、移行用バックアップ。
• コア要件：オリジナルClash向けか、mihomoの拡張フィールドに依存するか。
• 通信の引き受け方式：システムプロキシ、TUN、またはLAN内の端末だけにプロキシポートを提供する方式か。
• 変更箇所：DNS、ポート、ルール、プロキシグループを変更したか。
• 更新日時：サブスクリプションの最終更新日時、またはローカルファイルの最終修正日。

設定を削除する前に、それが現在使用中かどうかを確認してください。現在のProfileの削除を拒否するクライアントもあれば、一覧内の別項目へ自動的に切り替えるクライアントもあります。安全策として、まず動作確認済みの設定を有効化してから、重複項目を削除します。重要な手動ルールを含むローカルファイルは、先に明確なバックアップフォルダーへ書き出してください。

REVISION / 06

更新・編集・上書きの関係

リモートProfileの核心は、「ローカルキャッシュがリモートの内容によって管理される」ことです。クライアントのキャッシュ内でノード、ルール、DNSフィールドを直接編集すると短期的には反映されますが、次回のサブスクリプション更新時に新しいファイルへ置き換えられるのが一般的です。カスタムルールが更新後にいつも消える場合は、更新失敗をコアの問題と決めつける前に、編集した場所を確認してください。

長期的な変更には3つの方法があります。1つ目は、クライアントの上書きまたはマージ機能を使い、変更するフィールドだけを保存する方法です。2つ目は、サブスクリプションをローカル設定としてコピーし、すべて自分で管理する方法です。3つ目は、proxy-providers と rule-providers を使い、ノード集合やルール集合をメイン設定から分離する方法です。3つ目はYAMLとmihomoの設定構造に慣れたユーザー向けで、リモートリソースの形式が対応するproviderの要件を満たすことも確認する必要があります。

proxy-providers:
  remote-set:
    type: http
    url: "https://example.invalid/provider.yaml"
    path: ./providers/remote-set.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: "https://www.example.com/generate_204"

proxy-providers はクライアントのProfileと同じものではありません。Profileはコアに渡すメイン設定であり、providerはメイン設定が参照する外部リソースです。1つのProfileで複数のproviderを参照することも、providerをまったく使わないこともできます。両者を区別すれば、クライアントのサブスクリプションを更新すべきか、providerを更新すべきか、メイン設定を再読み込みすべきかを判断できます。

YAMLを編集する際は、リストの上書きにも注意してください。新しい rules で古いリスト全体を置き換えるマージツールもあれば、先頭または末尾への挿入に対応するものもあります。ルールは上から順に照合されます。カスタムルールが MATCH の後ろに追加されると、ファイルを正常に読み込めても、そのルールがヒットすることはありません。マージ後は上書き部分だけでなく、最終的に生成された設定を確認してください。

PROOF / 07

複数Profileでよくあるトラブルの切り分け

切り替え後、すべてのアプリがインターネットに接続できない

まずコアが動作しているかを確認し、次にシステムプロキシのポートと現在のProfileのリスニングポートが一致しているかを確認します。TUNを使用している場合は、仮想ネットワークアダプターが正常に作成され、クライアントに必要な権限があるか確認してください。一時的に通信の引き受け機能を無効にして、基礎的なネットワーク自体が正常か検証する方法もあります。最初から設定を削除しないでください。ポートの不一致やTUNの再作成失敗の方がよくある原因です。

設定の更新は成功したが、ノードが変わらない

現在有効なのが本当に更新直後の項目か確認してください。名前が似た重複Profileは、誤判定を招きやすいものです。続いて更新日時、プロキシグループの内容、コアのログを確認します。メイン設定がproviderを参照している場合は、Profileとproviderそれぞれの更新状態も確認してください。片方だけを更新しても、ノード一覧がすぐに変わるとは限りません。

保存したローカルルールが消える

これは通常、サブスクリプションのキャッシュを編集し、その後の更新で変更が上書きされたことを示します。ルールをクライアント対応の上書き機能へ移すか、独立したローカルProfileを作成してください。移行時には、ルールが参照するプロキシグループ名も同時にコピーし、ルールは存在するのに対象プロキシがない状態を避けます。

古いクライアントでは動作する設定が、新しいクライアントでは読み込みに失敗する

クライアント名だけでなく、双方が実際に使用しているコアを比較してください。mihomoが対応する拡張フィールドはバージョンによって進化し、オリジナルClashと各派生版でも対応フィールドに違いがあります。エラーメッセージに示されたフィールドを確認し、構文やインデントの問題なのか、フィールド型の問題なのか、コアが未対応なのかを切り分けます。ブール値、数値、文字列についても正しい型を維持し、エラーを回避するために一律で引用符を付けないでください。

切り替え後にプロキシグループの選択がリセットされる

まず新旧の設定に完全に同じ名前のプロキシグループが存在するか、また新しいグループに以前選択していたノードが含まれているか確認します。対象が存在しない場合、クライアントは利用可能な選択肢へ戻るしかありません。自動テストグループは遅延に応じてノードを再選択することもあります。これはグループの正常な動作であり、Profileの切り替え失敗を意味しません。

一部のドメインだけアクセスできない

接続ログを開き、リクエストにヒットしたルールとプロキシ方針を確認します。ドメインの名前解決に失敗する場合は、DNS設定、fake-ipの除外項目、上流サーバーへの到達性をさらに確認してください。誤ったプロキシ方針にヒットしている場合は、ルールの順序を確認します。複数設定の環境では、現在表示しているルールエディターが実行中のProfileに属しているかも確認し、未有効化の項目を何度も編集しないようにしましょう。

有効なトラブル対処の記録には、現在のProfile名、出所の種類、コア名とバージョン、動作モード、リスニングポート、通信の引き受け方式、具体的なエラー1件を含めます。サブスクリプションURLとノードの認証情報は、共有前に隠してください。これらの情報があれば、問題を「設定解析」「コア起動」「ポートの引き受け」「DNS名前解決」「ルール照合」のいずれかにすばやく分類でき、目的のない再インポートを減らせます。

FINAL CHECK / 08

複数設定の管理チェックリスト

• 設定名から出所と用途を判別でき、デフォルトのファイル名に依存していない。
• リモートサブスクリプションとローカルファイルを分けて管理し、更新で上書きされる内容を明確にしている。
• 切り替え後に動作モード、プロキシグループ、リスニングポート、システムプロキシまたはTUNの状態を確認している。
• 重要なカスタムルールを上書き設定またはローカルファイルに保存し、復元可能なバックアップがある。
• クライアントまたはコアをアップグレードする前に、Profileが特定ブランチの拡張フィールドを使用しているか確認している。
• トラブル対処では、まず現在有効な項目を確認し、実行されていない設定を編集しない。
• 重複設定を削除する前に、動作確認済みのProfileへ切り替えている。

Profile管理で重要なのは、できるだけ多くの設定を保存することではなく、それぞれの出所、用途、更新範囲を明確にすることです。日常設定は安定した状態に保ち、テスト内容は独立した項目に分け、リモートサブスクリプションのキャッシュを直接編集せず、切り替え後はポート、モード、プロキシ方針、DNSの順に確認することで、複数設定を併用する際の切り分けコストを大幅に抑えられます。