Profileは単なるプロキシノード一覧ではない

ClashクライアントにおけるProfileとは、通常、コアが読み込める設定ファイルを指します。サブスクリプションURLから取得する場合もあれば、ローカルの config.yaml を手動でインポートする場合もあります。使用可能な設定には、サーバーアドレスだけでなく、待受ポート、DNSの動作、プロキシノード、プロキシグループ、ルール、TUNパラメータも含まれます。Profileの切り替えとは、本質的にはクライアントにこの一連の実行状態を再読み込みさせる操作です。

サブスクリプションサービスから返される内容が、完全なClash YAMLとは限りません。Base64形式のノード一覧を返し、サブスクリプション変換サービスでClash形式に変換する必要があるURLもあれば、proxies、proxy-groups、rulesを含むYAMLを直接返すURLもあります。インポートに成功したことは、テキストがクライアントに受け入れられたことを示すだけです。正常に通信できるかどうかは、項目の互換性、ノードの有効性、ルール間の参照関係にも左右されます。

設定の読み込み時に起きること

  1. クライアントはYAMLを読み込み、インデント、項目の型、必須パラメータを確認します。
  2. Clashまたはmihomoコアがローカルの待受ポートを作成します。たとえば、HTTPとSOCKSを受け付ける混合ポート 7890 です。
  3. コアがノードとプロキシグループを作成し、各グループが参照するメンバーを解決します。
  4. ルールは上から順にマッチング処理へ入り、ルールセットプロバイダーは必要に応じてリモート内容をダウンロードします。
  5. TUNを有効にすると、AndroidクライアントはシステムにVPN権限を要求し、仮想ネットワークインターフェースを作成します。

どの段階で失敗しても、「設定はインポートできたのに起動できない」という状態になる可能性があります。たとえば、YAMLのインデントミスは解析段階で処理を停止させます。存在しないノード名をプロキシグループが参照していると、設定の検証段階でエラーになります。リモートのルールセットに到達できない場合は、そのルールセットに依存する振り分けだけに影響することもあります。

config.yamlの主要項目を階層ごとに解説

YAMLではインデントで階層を表現します。通常は半角スペース2つを使い、タブは使用しません。以下は構造を理解するための簡略化した例です。サーバーアドレス、認証情報、プロトコルパラメータは項目の位置を示すためだけのもので、接続可能な設定としてそのまま使用しないでください。

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

proxies:
  - name: HK-A
    type: ss
    server: example.net
    port: 443
    cipher: aes-128-gcm
    password: example-password

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - HK-A
      - DIRECT

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

基本的な待受設定と動作モード

mixed-port: 7890 は、同じポートでHTTPとSOCKS5プロキシ接続を受け付ける設定です。デスクトップアプリでは、システムプロキシを 127.0.0.1:7890 に指定することがよくあります。AndroidクライアントはVpnServiceやTUNで通信を取り込むことが多いものの、混合ポートはLAN内のデバッグや、特定アプリの手動設定にも利用できます。

  • mode: rule：rules を上から順に照合します。日常利用では最も一般的なモードです。
  • mode: global：通信の大部分をグローバルプロキシグループへ送り、通常の振り分けルールを順番に判定しません。
  • mode: direct：通信を直接接続します。障害の原因がプロキシ経路にあるかを一時的に切り分けるのに適しています。
  • allow-lan: false：ローカルプロキシポートをLAN内のデバイスに公開しません。共有する場合は、待受アドレスとシステムファイアウォールも同時に確認してください。
  • log-level: info：通常の動作ログを記録します。短時間のトラブル対応では debug に変更し、完了後に戻してください。

proxies：接続先ノード

proxies 配下の各項目は、一つのノードを表します。プロトコルごとに必要な項目は異なります。たとえばShadowsocksでは cipher と password を使用し、Trojanでは通常 password やTLSサーバー名などを指定します。mihomoはさらに多くのプロトコルや拡張項目に対応していますが、すべての旧版Clashコアが認識できるとは限りません。

name は設定内部で参照するキーです。プロキシグループに記述する名前は、空白、大文字・小文字、記号を含め、ノード名と完全に一致させる必要があります。同名ノードがある場合、一部のクライアントは読み込みを拒否し、別の実装では先に定義した項目が上書きされることがあります。そのため、サブスクリプション生成時は名前が重複しないようにしてください。

proxy-groups：選択と自動テスト

プロキシグループは、複数のノードや他のプロキシグループを、ルールから参照できる一つの出口としてまとめます。よく使われるタイプには、手動選択の select、テスト結果で選ぶ url-test、障害時に切り替える fallback、負荷を分散する load-balance があります。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - HK-A
      - SG-A
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

この設定では 600 秒ごとにテストを実行します。tolerance: 80 は、遅延差が 80 ms を超えない限り、現在のノードを頻繁に切り替えないことを示します。30 秒に短縮すると、ネットワーク要求とバックグラウンドの起動回数が増えます。モバイル端末で高頻度のテストを常時実行する必要は通常ありません。

rules：上から順に最初の一致を適用

Clashのルールは、すべての判定を各接続に実行するのではなく、順番に確認して最初に一致した項目を適用します。より具体的なドメインルールを、範囲の広いルールより前に置いてください。末尾には通常、残りの通信を処理する MATCH を置きます。MATCH,DIRECT を1行目に置くと、後続のプロキシルールは適用されません。

  • DOMAIN,api.example.com,ノード選択：完全一致するドメイン名だけを対象にします。
  • DOMAIN-SUFFIX,example.com,ノード選択：メインドメインとサブドメインを対象にします。
  • IP-CIDR,192.168.0.0/16,DIRECT：指定したIPv4ネットワークを対象にします。
  • GEOIP,CN,DIRECT：IP位置情報データベースに基づいて判定します。
  • MATCH,ノード選択：それまでのルールに一致しなかった接続を受け取ります。

DNS、Fake-IP、TUNパラメータの関係

DNS項目はドメイン名の解決方法を決めますが、通信の出口を単独で決めるものではありません。DNSモジュールで処理された後も、接続はルールシステムへ進む必要があります。fake-ip を有効にすると、ローカルDNSがマッピングアドレスを返し、コアがその対応関係からドメイン名を復元してルールを照合します。これにより、アプリが独自に名前解決してドメインルールを回避する問題を抑えられます。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
  dns-hijack:
    - any:53

198.18.0.0/16 は、Fake-IPのマッピング範囲としてよく使われます。アプリがこのネットワークへ接続していても、インターネット上の同名アドレスへアクセスしているとは限りません。mihomoコアはドメイン名とマッピングアドレスの対応を管理し、接続をルールと対象ノードへ渡します。

Fake-IPの除外が必要なケース

LAN内のデバイス検出、一部のゲームプラットフォーム、実際のLANアドレスを必要とするアプリは、Fake-IPに適さない場合があります。その場合は fake-ip-filter に完全一致のドメイン名やワイルドカードルールを追加してください。除外範囲をすべての主要ドメインへ広げるのは避けましょう。ドメインルールの網羅性が低下し、アプリがプロキシを迂回して独自のDNSを使う問題が再発する可能性があります。

TUN設定とAndroidの権限状態は別物

設定内の tun.enable は、あくまでコアのパラメータです。AndroidがVPNインターフェースの作成を許可するかどうかは、システムのVpnService権限によって決まります。初回起動時は通常、システムの接続リクエストで確認が必要です。同時に別のVPNアプリが動作していると、新しいインターフェースを作成できない場合があります。

Androidクライアントによってメニュー名や配置は完全には統一されていません。よくある操作経路は「設定」→「パラメータ設定」→「TUNモード」、またはホーム画面のサービスカードから直接有効にする方法です。stack、ルート除外項目、DNSハイジャックを変更した後は、サービスを停止してから再起動し、古い接続とルーティングテーブルを再構築してください。

サブスクリプション更新で上書きされる内容

リモートProfileには通常、サブスクリプションURLが保存されています。クライアントが更新を実行すると、そのURLから内容を再ダウンロードし、対象設定のリモートスナップショットを置き換えます。ノードの追加・削除、プロキシグループのメンバー、ルールの順序は新しい内容に合わせて変わる可能性があります。ダウンロード後のYAMLを直接編集しても、次回の更新で通常は上書きされます。

リモート内容、ローカル上書き、実行時設定

「変更したのに反映されない」という問題を避けるには、3つの状態を理解すると役立ちます。第1層はサブスクリプションサーバーが返す元の設定、第2層はクライアントが保存するローカルProfile、第3層は上書き、スクリプト、互換変換を経てコアに渡される最終設定です。画面に表示される内容は第2層でも、ログに出る実際のパラメータは第3層のものかもしれません。

  1. 現在のProfile名と更新時刻を記録します。例：2026-07-30 09:40。
  2. サブスクリプションを手動更新し、応答状態が正常であることを確認して、ノード数に変化があるか調べます。
  3. 設定プレビューを開き、proxy-groups と rules が有効な名前を参照しているか確認します。
  4. 「設定」→「パラメータ設定」で、DNS、ルーティング、上書き項目を確認します。
  5. 設定を再読み込みするかサービスを再起動し、接続ログで実際に一致したルールとプロキシグループを確認します。

自動更新の間隔は、サブスクリプションの変更頻度に合わせて設定してください。ノード情報の更新が1日1回だけなら、15 分ごとに取得する必要はありません。一般的には 1440 分から設定を始め、急ぎで変更を反映したいときだけ手動更新します。短すぎる間隔は、バックグラウンド要求と失敗時の再試行を増やすだけです。

ローカルに保持するのに適した変更

固定のLAN直通ルール、個人用ドメインルール、端末専用のDNSパラメータは、リモートファイルを直接編集せず、上書きレイヤーとして管理するのが適しています。クライアントがMerge、Mixin、上書き機能に対応していれば、追加項目をサブスクリプションの結果へ統合できます。統合前に配列の処理方法を確認してください。rules を追加する実装もあれば、全体を置き換える実装もあります。

ルールの順序は特に重要です。個人用の直通ルールを末尾の MATCH より後ろに追加すると、決して一致しません。範囲の広いルールと最終ルールの前に挿入し、ログで DOMAIN-SUFFIX や IP-CIDR などの一致記録を確認してください。

複数Profileの併用と切り替え管理

仕事用ネットワーク、家庭用ネットワーク、テスト環境は、それぞれ別のProfileとして保存できます。複数Profileの価値は、ルールとパラメータを分離できる点にあり、すべてのノードを一つのファイルへ詰め込むことではありません。各Profileには Daily-Meta、Office-Direct、Lab-TUN のように識別しやすい名前を付け、入手元と用途も記録してください。

切り替え前に確認したい4種類の違い

  • コアの互換性：設定でmihomo専用の項目を使用していないか確認します。旧版Clashコアでは、未知のプロトコルやルールセット形式を読み込めない場合があります。
  • ポートの競合：2つのローカルサービスが同時に 7890 やDNSポート 1053 を待ち受けると、後から起動したサービスでバインドエラーが発生します。
  • モードの状態：一部のクライアントでは rule、global、direct が画面全体の状態として扱われ、Profileと一緒に切り替わるとは限りません。
  • 上書きの範囲：グローバル上書きはすべてのProfileに適用される場合があります。一方、Profile専用の上書きは現在の項目だけに作用します。

設定を切り替えた後も、既存のTCP接続が切断されるまで古い出口を使い続ける場合があります。確認時はアプリを再度開くかテスト接続を切断してから、新しいログを確認してください。Webページを更新するだけでは、新しい接続が作られるとは限りません。HTTP/2やQUICが既存のセッションを再利用する可能性があるためです。

バックアップ時に保存するもの

手書きのローカル設定は独立したコピーを残し、変更日も記録してください。リモートサブスクリプションでは、取得元、上書きルール、クライアント設定を保存することが重要です。毎回ダウンロードされる一時コピーをすべてメインファイルとして保管する必要はありません。サブスクリプションURLにはアクセス情報が含まれることが多いため、バックアップは管理された場所に保管し、公開ログ、スクリーンショット、問い合わせ内容に貼り付けないでください。

旧クライアントからClash Metaまたはmihomoクライアントへ移行する場合は、まずProfileを1つインポートして検証し、その後に残りの設定を移行します。proxy-providers、rule-providers、プロキシグループのフィルター式、TUN項目を重点的に確認してください。YAMLとして解析できても、リモートプロバイダーをダウンロードできるとは限らず、現在のコアがすべてのノードプロトコルに対応しているとも限りません。

設定の読み込みに失敗したときの切り分け順序

設定の問題は、階層ごとに切り分けるのが効果的です。まずファイルを解析できるか、次にノードが接続を確立できるか、最後にルールが通信を想定した出口へ送っているかを確認します。解析エラーを飛ばしてノードのテストを繰り返しても、通常は有効な結論にたどり着けません。

第1層：YAMLと項目の検証

  • コロンの後に空白があるか確認します。例：mode: rule。
  • リスト項目 - と親項目のインデントを確認します。
  • コロン、シャープ記号、その他の特殊記号を含む名前は、引用符で囲んでください。
  • プロキシグループ、ルール、プロバイダーが参照する名前が存在するか確認します。
  • クライアントログで行番号を確認し、最初に発生した解析エラーから修正します。

第2層：ノードとネットワーク接続

単一ノードを選んで遅延テストを実行しても、分かるのはテストURLへの接続結果だけで、すべてのWebサイトへアクセスできることを示すものではありません。まずモードを global に切り替えて短時間確認し、その後 rule に戻す方法があります。グローバルモードでは使えるのにルールモードで使えない場合は、ルールの一致結果とプロキシグループの現在の選択を確認してください。どちらのモードでも使えない場合は、ノードパラメータ、システム時刻、DNS、ネットワーク制限を引き続き確認します。

第3層：ルールと最終出口

ログで対象ドメインの一致記録を探し、どのルールに一致し、どのプロキシグループへ入り、最終的にどのノードが選択されたかを確認します。ログにドメイン名ではなくIPアドレスしか表示されない場合は、DNSをClashが処理しているか、アプリが独自の暗号化DNSを使用していないかを確認してください。トラブル対応中はログレベルを debug に変更し、記録が終わったら info に戻します。

保守しやすいProfile運用の習慣

設定管理の基本は、入手元と役割を分けることです。サブスクリプションはノードと基本ポリシーを提供し、ローカル上書きは個人ルールを担い、クライアント設定はシステムインターフェースとアプリの動作を制御します。3つを同じリモートファイルに混在させると、更新後に何が原因で変わったのか判断しにくくなります。

  1. 各Profileに用途が分かる名前を付け、入手元の説明を残します。
  2. 更新前に現在使用できるノードとプロキシグループの選択を記録し、更新後に主要項目を比較します。
  3. 個人ルールは繰り返し適用できる上書きレイヤーに置き、挿入位置を確認します。
  4. 高頻度の自動速度テストやサブスクリプション更新を減らし、モバイル端末ではバックグラウンドの起動を優先的に抑えます。
  5. Profileを切り替えた後はテスト接続を作り直し、ステータスアイコンだけでなくログでルールを検証します。
  6. コアをアップグレードする前に設定の互換性を確認します。特にプロトコル拡張、ルールプロバイダー、TUNパラメータに注意してください。

Profileを「ノード、プロキシグループ、ルール、DNS、システム取り込み用パラメータをまとめた完全なスナップショット」と捉えると、サブスクリプション更新と複数設定の切り替えを理解しやすくなります。障害が発生した場合も、設定解析、ノード接続、DNS処理、ルール一致、システムルーティングの順に切り分けられ、同じファイルを何度も削除して再インポートする必要がなくなります。