Clash設定ファイル（Profile）とは：構造を分解して複数設定を切り替える方法

ProfileはサブスクリプションURLではなく、コアが実際に読み込む実行設定

Clash、Clash Meta、mihomoのクライアントでは、Profileは通常「設定」または「設定ファイル」と呼ばれます。最終的にはYAMLドキュメントで、ノードだけでなく、待ち受けポート、DNS、プロキシグループ、ルール、TUNパラメーター、コントロールインターフェースも定義します。コアの起動時に読み込まれるのはこの設定ファイルであり、ブラウザーに表示されるサブスクリプションURLではありません。

サブスクリプションURLは、設定の取得元と考えると分かりやすいでしょう。クライアントがURLへリクエストを送り、サーバーの応答をダウンロードして、結果をローカルProfileとして保存します。その後、一時的にネットワークが切れても、ローカルファイルが残っていてノードの認証情報が有効なら、通常はその設定を読み込めます。「サブスクリプションを更新」を実行すると、クライアントは再度ダウンロードし、対応するローカルデータを上書きまたは再生成します。

完全な設定ファイルに含まれる主な項目

最小限の実行構成はコアのバージョンやクライアントの実装によって異なりますが、一般的な項目は6つの層に分けられます。

• port、socks-port、mixed-port：ローカルプロキシの待ち受けポート。
• proxies または proxy-providers：個別のノードまたはリモートノードの集合。
• proxy-groups：手動選択、速度テスト、自動切り替えなどのポリシーグループ。
• rules または rule-providers：ドメイン、IP、プロセス、ルールセットの照合順序。
• dns：DNSの待ち受け、上流サーバー、Fake-IPまたはRedir-Hostの動作。
• tun、sniffer、external-controller：システム通信の取り込み、ドメインスニッフィング、制御インターフェース。

以下は階層を理解するための簡略化した例です。ポート 7890 はHTTPとSOCKSの混合入口、9090 は外部コントロールインターフェースとして使用します。実際の認証情報は省略しているため、そのまま接続用の設定として使わないでください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

proxies:
  - name: Tokyo-A
    type: ss
    server: 203.0.113.10
    port: 443
    cipher: aes-128-gcm
    password: example-password

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - Tokyo-A
      - DIRECT

  - name: AUTO
    type: url-test
    proxies:
      - Tokyo-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

3つの中核セクション：proxies、proxy-groups、rules

Profileを理解する際は、最初から何百行もあるDNSやルールセットを読む必要はありません。3つの中核セクションを押さえれば十分です。proxiesが出口を提供し、proxy-groupsが出口をまとめ、rulesが各接続をどのグループへ渡すかを決めます。3者は下位層から上位層へつながる参照チェーンです。

proxies：ノード本体と接続パラメーター

proxiesは静的なノード配列です。各項目には少なくとも名前、プロトコル、サーバーアドレス、ポート、認証情報を指定します。プロトコルによって追加項目も異なり、たとえばShadowsocksでは暗号化方式、TrojanではパスワードとTLSパラメーター、VMessではUUID、VLESSではフロー制御やトランスポート設定を記述します。

ノード名は、現在の設定内で一意に識別できなければなりません。プロキシグループは名前でノードを参照するため、ノード名を変更したらproxy-groupsも確認してください。グループに古い名前が残っていると、設定の検証に失敗したり、画面上で空のグループや利用できないメンバーが表示されたりします。

proxies:
  - name: HK-01
    type: trojan
    server: hk01.example.net
    port: 443
    password: change-me
    sni: hk01.example.net
    udp: true

大規模なサブスクリプションでは、すべてのノードをメインファイルへ手作業で書き込まず、proxy-providersを使うのが一般的です。Providerはリモートからノード一覧を取得し、指定した間隔で更新できます。ただし、Providerが担当するのは「ノードの取得元」であり、どのサイトに使うかまでは自動で決めません。

proxy-groups：ノードを実行可能なポリシーにまとめる

proxy-groupsは、クライアントの「プロキシ」画面でユーザーが実際に操作する対象です。代表的なタイプは4つあります。

グループはノードだけでなく、別のグループも参照できます。よくある構成は、総合入口としてPROXYを作り、HK-AUTO、JP-AUTO、Fallback、DIRECTを追加する方法です。ルールからは総合グループまたは用途別グループだけを参照すれば、下位ノードを更新するたびにルールを1行ずつ修正する必要がありません。

proxy-groups:
  - name: Streaming
    type: select
    proxies:
      - HK-AUTO
      - JP-AUTO
      - PROXY

  - name: HK-AUTO
    type: url-test
    use:
      - provider-main
    filter: "(?i)港|HK|Hong Kong"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 100

rules：上から順に評価し、最初に一致した時点で終了

rulesは順序を持つ照合リストです。リクエストは先頭から確認され、一致すると指定されたポリシーへ接続を渡し、それより下のルールは評価されません。具体的なルールを広範なルールより前に置き、最後はMATCHで受けます。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - PROCESS-NAME,git.exe,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Fallback

この例では、api.example.comは直接接続されます。その他のexample.comのサブドメインはプロキシを通ります。Windows上でgit.exeが確立し、コアが識別できる接続はPROXYへ渡されます。ローカルネットワークのアドレスは直接接続し、残りの中国本土IPも直接接続します。最後に、どのルールにも一致しない通信をFallbackへ渡します。

Profileとサブスクリプションの更新：上書きされる内容

サブスクリプションから生成されたYAMLを直接編集すれば、短期的には反映されます。しかし次回の更新で変更がすべて消えることがあります。理由は単純で、クライアントがリモートの応答をそのProfileの正式版として扱い、更新時にノード、ポリシーグループ、ルールを書き直すためです。手動で追加したPROCESS-NAME、DNSの上流サーバー、カスタムグループなどは、個別の上書き機能がなければリモート側の内容に置き換えられます。

3種類の取得元による違い

1. ローカルファイルからインポート：ディスク上のYAMLを読み込み、通常はリモートへ自動アクセスしません。自分で完全に管理する設定に適しています。
2. サブスクリプションURLからインポート：クライアントが設定した間隔でリモートへリクエストします。一般的な更新間隔は24時間で、手動更新も可能です。
3. Providerによる分離：メイン設定にはDNS、グループ、ルールだけを残し、proxy-providersでノードのみを更新します。ルール構造を長期的に管理したい場合に適しています。

一般的なGUIクライアントでは、通常「設定」→「新規作成」→「URLからインポート」の順に進みます。更新は対象設定カードの「更新」ボタンから実行します。ポートは「設定」→「パラメーター設定」→「混合ポート」で変更することが多いでしょう。クライアントによってProfileを「設定」「サブスクリプション」「設定管理」と呼ぶなど、ボタンの位置は異なりますが、基本的な関係は変わりません。

mihomoのProvider構造を使うと、リモートのノードをローカルファイルへキャッシュできます。次のinterval: 86400は86400秒、つまり24時間ごとに確認するという意味です。ヘルスチェックは600秒ごとに実行されます。

proxy-providers:
  provider-main:
    type: http
    url: https://subscription.example.net/clash
    path: ./providers/provider-main.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

クライアントが上書き、拡張スクリプト、Merge設定に対応している場合は、ローカルのDNS、ルール、ポリシーグループを上書き層へ移すのがおすすめです。リモート側にはノードだけを任せ、個人用のロジックはローカルに残します。こうすれば80個のノードを更新しても、開発環境用に追加した直接接続ルールまで一緒に消えることはありません。

複数のプロバイダー・用途別設定を命名して併用する方法

設定が増えると、最初に手に負えなくなるのはYAMLではなく命名です。リストに「新しい設定」「サブスクリプション2」「テストコピー最終版」などが並ぶと、数週間後にはどれを使っていて、どれを削除できるのか分からなくなります。名前には取得元、用途、更新日を直接表す情報を入れましょう。

おすすめの命名形式

[取得元]-[用途]-[更新方式]-[日付]

Aサイト-日常-自動-20260625
Bサイト-ストリーミング-自動-20260625
ローカル-開発用振り分け-手動-20260625
緊急用-基本直接接続-手動-20260625

日付はノードを更新するたびに変更する必要はありません。設定構造を最後に手動で変更した日を記録する用途に向いています。自動サブスクリプションの更新日時はクライアントに任せましょう。毎日名前を変えるだけではノイズが増えるだけです。

取得元ごとに分けるか、用途ごとに分けるか

使い始めたばかりなら、取得元ごとに1つのProfileを残すのが最も簡単です。ルールの要件が固まったら、「1つのメイン設定と複数のProvider」へ移行するとよいでしょう。最初からすべての取得元、数十個の用途別グループ、数万件のルールを1つのファイルへ詰め込むのはおすすめしません。インデントの誤り1つで、トラブルシューティングの範囲が大きく広がります。

緊急用の設定を1つ残す

緊急用の設定は複雑でなくて構いません。利用可能なノード1つ、selectグループ1つ、基本ルールを数本だけ用意し、不要なTUNや複雑なDNSは無効にします。メイン設定の更新に失敗したとき、ルールセットのURLへ到達できないとき、TUNドライバーに問題があるときは、緊急用設定へ切り替えて基本的な接続を復旧してから原因を調べられます。

緊急用設定はローカルYAMLを使い、起動のたびにリモートのルールセットをダウンロードする構成は避けます。月に1回手動で読み込み、設定の検証に通ること、ノードへ接続できること、7890ポートが他のプログラムに占有されていないことを確認してください。

Profileを切り替えると、クライアント内部で何が起きるのか

Profileの切り替えは、単にノード一覧を入れ替える操作ではありません。クライアントは通常、現在のコアを停止または再読み込みし、新しいYAMLをコアで検証してから、待ち受けポート、DNS、TUNインターフェース、ポリシー状態を再構築します。設定が複雑になるほど、再読み込みに関わるシステムコンポーネントも増えます。

既存の接続は自動的に引き継がれるとは限らない

切り替え前に確立されたTCP接続は切断されることもあれば、タイムアウトまで維持されることもあります。具体的な動作はクライアントの再読み込み方式によって異なります。新しい接続は新設定のルールで処理されます。大容量ファイルのダウンロード、Git push、SSHセッションの維持中は、Profileを不用意に切り替えないでください。

再現可能な切り替え確認は、次のように行えます。まず接続パネルでアクティブな接続数を確認します（例：23件）。ダウンロードを停止し、設定を切り替え、コアの状態が「実行中」に戻るまで待ちます。その後、テスト用ドメインを開き、新しい接続でどのルールに一致したかを確認します。一般的なデスクトップ環境では、簡単な設定なら再読み込みは1～3秒で完了しますが、TUN、リモートルールセット、多数のProviderを有効にしている場合はさらに時間がかかることがあります。

ポリシーの選択は記憶される場合とリセットされる場合がある

クライアントによっては、ポリシーグループ名ごとに前回の選択を保存します。たとえば2つのProfileにPROXYという同名グループがある場合、切り替え後に前回選択したノードの復元を試みることがあります。ただし、新しい設定に同名ノードがなければ、そのグループの先頭にある利用可能なメンバーへ戻ります。

そのため、複数の設定で同じポリシーの意味を共有する場合は、PROXY、Streaming、Fallbackなどのグループ名を統一できます。意味が異なるものに無理やり同じ名前を付けるのは避けてください。画面上では選択が保持されているように見えても、実際の出口の動作が変わってしまいます。

TUN設定の切り替え後は追加確認が必要

TUNモードは、より多くのシステム通信を取り込みます。2つのProfileで異なるstack、DNS hijack、ルート除外項目を設定している場合、切り替え時に仮想ネットワークアダプターやルーティングテーブルの再構築が必要になることがあります。切り替え後は次を確認してください。

• TUNが再び有効になっているか。システムプロキシだけが残っていないか。
• 192.168.1.1などのローカルネットワークアドレスへ、引き続き直接接続できるか。
• DNSリクエストが新しい設定の待ち受けポート（例：0.0.0.0:1053）へ渡っているか。
• 除外対象のプロセスやネットワーク帯域が、引き続きroute-exclude-addressに含まれているか。
• ブラウザー、コマンドライン、システムプロキシを参照しないアプリが、すべて想定どおりに振り分けられているか。

実践的な設定管理の手順

Profileの管理に複雑なツールは必要ありません。重要なのは、インポート、検証、切り替え、ロールバックを分けて行い、現在唯一使える設定で直接試行錯誤しないことです。

手順1：コピーしてから変更する

DNS、TUN、ルールを変更する前に、現在の設定をコピーして日付を付けます。元の設定はそのまま残してください。クライアントにコピー機能がなければ、YAMLをエクスポートして別のディレクトリに保存します。変更版にはまず「テスト」と名前を付け、検証が終わってからメイン設定と入れ替えます。

手順2：先に構文を検証する

YAMLはスペースで階層を表現します。Tab、ずれたインデント、引用符の不足は、読み込み失敗の原因になります。特にコロンを含む名前、正規表現、URLを確認してください。コアのエラーに行番号が表示された場合は、まずその行より上のリストのインデントを確認します。エラー位置はパーサーが処理を続けられなくなった場所であり、問題の発生源とは限りません。

# エラーになりやすい：グループ名にコロンがあるのに引用符がない
- name: Work: Git

# より安全な書き方
- name: "Work: Git"

手順3：固定サンプルで振り分けを検証する

4種類の固定サンプルを用意します。中国本土のドメイン1つ、プロキシが必要なドメイン1つ、ローカルネットワークアドレス1つ、指定プロセス1つです。クライアントの接続ログを開き、ルールタイプ、適用されたポリシー、最終的なノードを順番に確認します。ブラウザーでIPを調べるだけでは不十分です。ブラウザーキャッシュ、HTTP/3、既存の接続が判断に影響する可能性があります。

1. 中国本土のドメインはDIRECT、または想定した中国国内向けポリシーに一致するはずです。
2. プロキシ対象のドメインは用途別グループに一致し、末尾のMATCHへ直接落ちてはいけません。
3. 192.168.0.0/16などのプライベートネットワーク帯域は、直接接続のままにします。
4. 指定プロセスのルールは、対象プログラムが新しい接続を作成した後に表示されます。
5. DNSログにタイムアウトやループする問い合わせが継続的に発生していないことを確認します。

手順4：ロールバックポイントを記録する

現在安定している設定のファイル名、混合ポート、TUNのオン・オフ、メインポリシーの選択を記録します。テスト設定に問題があれば、「設定」→「安定版設定」で切り替え、「設定」→「パラメーター設定」で7890などのポートが戻っていることを確認します。コアが自動再起動しない場合は、「停止」を実行してから「起動」を1回行います。

よくある問題：インポートは成功したのに設定が使えない

設定は一覧にあるのに、プロキシグループが空になる

まずproxiesにノードがあるか、またはproxy-providersのダウンロードが成功しているか確認します。次に、グループ内のproxies名とProviderのuse名が完全に一致しているか確認してください。名前は大文字・小文字を区別し、余分なスペースも参照失敗の原因になります。

更新後にカスタムルールが消える

これはサブスクリプションから生成された設定を直接編集した場合によく起きます。カスタム内容をクライアントの上書き層へ移すか、ローカルのメイン設定を作ってProvider経由でリモートノードを取り込みます。クライアントが上書きに対応していない場合は、ローカルコピーを残して手動で統合し、サブスクリプションのキャッシュファイルを長期的な編集場所として使い続けないでください。

設定を切り替えた後も、ブラウザーが古いノードを使い続ける

まず新しいシークレットウィンドウを開くか、ブラウザーを完全に終了して、接続の再利用を除外します。次に接続パネルで新しい接続が生成されているか確認します。それでも古いノードを使う場合は、同名のポリシーグループが過去の選択を復元していないか、ルールが実際には別のグループを参照していないかを確認してください。TUNを有効にしている場合は、仮想ネットワークアダプターが新しい設定で再読み込みされていることも確認します。

ルールを追加したのに、常にMATCHに一致する

ルールの順序、ドメインタイプ、DNSの動作を確認します。DOMAINは完全なドメイン名だけに一致し、DOMAIN-SUFFIXはサブドメインも対象にします。IPルールでは、接続先から対応するIPを取得できなければなりません。no-resolveを付けると、照合のためにDNSを能動的に実行しません。プロセスルールは、プラットフォームとコアがプロセス情報を取得できるかどうかにも左右されます。

まとめ：Profileをバージョン管理できる実行設定として扱う

Profileの本質は「ノードをいくつ入れたか」ではありません。入口、出口、ポリシー、照合順序を、コアが実行できる1つの設定にまとめることです。proxiesが出口を提供し、proxy-groupsがポリシーを組み合わせ、rulesが接続を振り分けます。DNSとTUNは、ドメインやシステム通信をこの経路へどのように取り込むかを決めます。

複数の設定を併用する場合は、読みやすい名前を付け、自動サブスクリプションとローカル設定を分け、緊急用Profileを1つ残します。更新後はノード、ポリシーグループ、ルールの一致を確認し、切り替え前には重要な接続を停止、切り替え後にはポート、DNS、TUNを検証します。サブスクリプションやルールに変更があっても、すぐに動作する状態へ戻せるようになります。