Clashの設定ファイルとは?Profile構造の基礎と複数設定の切り替え管理

Clashを使い始めたばかりのユーザーは「設定ファイル」と「サブスクリプションURL」を混同しがちで、ルールが効かない・ノードを切り替えても反応がない・設定を更新したら逆に動かなくなった、といった問題に遭遇すると手の打ち方がわからなくなります。実際には、Clash系クライアント(mihomoカーネルを使うClash Verge、Clash for Windows派生版、ClashXなど)が動く核心部分は1本のYAML形式の設定ファイルであり、業界では通常 config.yaml あるいはクライアント上での Profile と呼ばれます。その構造・出所・更新の仕組みを理解することが、ほとんどの使用上のトラブルを切り分ける前提になります。

config.yamlの3つの構成ブロック

1本の完全なClash設定ファイルは本質的に純テキストで、機能ごとに3つの部分に分けられます。基本ポートと動作パラメータ、プロキシグループ(proxy-groups)、ルール(rules)です。この3つがノード定義(proxies)と組み合わさって、トラフィックが最終的にどの経路を通るかを決定します。

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

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies: [香港01, 日本01, シンガポール01]
    url: http://www.gstatic.com/generate_204
    interval: 300

rules:
  - DOMAIN-SUFFIX,googlevideo.com,自動選択
  - GEOIP,CN,DIRECT
  - RULE-SET,reject,REJECT
  - MATCH,自動選択

1つ目はポートと動作モード:port / socks-port はそれぞれHTTPとSOCKS5のローカルプロキシポートを開放し、mixed-port は両者を統合した混合ポートで、現代の多くのクライアントはデフォルトでこれ1つだけを使います。allow-lan は同一LAN内の他の機器からこの端末のプロキシへ接続できるかどうかを決め、mode の一般的な値には rule(ルールに基づく分流)、global(全体を同じノードで通す)、direct(直接接続、プロキシを通さない)があります。

2つ目はプロキシグループで、「どのノードを選ぶか」を決めます。select タイプは手動選択で、クライアント上でクリックすれば切り替わります。url-test は設定した interval の周期で自動的に速度測定を行い、遅延が最も低いノードを選びます。fallback はメインノードが使えなくなった際に順番にフォールバックします。load-balance はリクエストをハッシュまたはラウンドロビンで複数ノードに分散させ、セッションの安定した維持が必要な場面でよく使われます。

3つ目はルールで、「どのトラフィックをどのグループに通すか」を決めます。ルールは上から下へ順に照合され、マッチした時点で処理が停止します。よく使われるルールタイプには以下があります。

• DOMAIN-SUFFIX:ドメイン接尾辞でマッチし、例えば googlevideo.com はすべてのサブドメインにマッチします。
• GEOIP:宛先IPが属する国・地域でマッチし、GEOIP,CN,DIRECT で中国本土向けトラフィックを直接接続させるのがよく使われます。
• RULE-SET:外部のルールセットファイルを参照し、大量のドメインをメイン設定に積み込まずに管理しやすくします。
• MATCH:最終的な受け皿ルールで、必ず最後の行に置き、「上記のどれにもマッチしなかった場合どうするか」を決めます。

サブスクリプションURLとローカル設定ファイルの関係

サブスクリプションURLは本質的にクライアントが直接fetchできるURLであり、サーバー側が返す内容は上記のYAMLテキスト(またはクライアント側でもう一度変換が必要な汎用サブスクリプション形式)そのものです。クライアントはこのテキストを受け取ると、毎回リクエストし直すのではなくローカルファイルとして保存します。このローカルに保存されたファイルこそが Profile です。言い換えると、サブスクリプションURLは「設定の出所」であり、Profileは「設定が端末上に落とし込まれた形」です。オフラインになっても、クライアントは前回同期したProfileでそのまま動作を続けられます。

1つのProfileは必ずしもサブスクリプションから来る必要はなく、完全に手書きしたファイルや別の場所からダウンロードしたローカルファイルでも構いません。両者はクライアント上での地位は同じで、いずれも設定リストに表示され切り替え可能です。違いは、サブスクリプションタイプのProfileにはリモートアドレスが紐づいており、設定した update-interval(通常は時間単位)に従って自動的に最新内容を再取得しローカルファイルを上書きできる点だけです。ローカルファイルタイプのProfileにはこの自動更新の動作がなく、変更があれば手動で再インポートするしかありません。

多くのサブスクリプションサービスはレスポンスヘッダーに subscription-userinfo フィールドを含め、使用済みトラフィック・総トラフィック・有効期限を返します。クライアントがこれを解析するとProfileリストの横に表示されます。これが、あるサブスクリプションはインポート後にトラフィックの進捗バーが見えるのに、別のものは単純なファイル名しか表示されない理由です——サーバー側がこの情報を提供しているかどうかの違いであり、クライアント自体とは関係ありません。

クライアントでのProfileのインポート・更新・切り替え

クライアントによってUI上の言葉遣いは多少異なりますが、設定のインポート方法は基本的に2種類に分かれます。サブスクリプションURLを貼り付けるか、ローカルファイルを選択するかです。以下は一般的な操作フローで、実際のメニュー位置は各クライアントの画面に従ってください。

1. クライアントの「設定」「Profiles」または「サブスクリプション管理」ページを開く。
2. 追加ボタンをクリックし、「URLからインポート」を選んでサブスクリプションURLを貼り付けて確定すると、クライアントが自動的にダウンロードし新しいProfileとして解析する。
3. ローカル設定ファイルの場合は「ファイルからインポート」を選び、ダウンロード済みの .yaml ファイルを指定する。
4. インポートが完了したら、リスト内でその項目を選択して現在有効な設定に設定する。多くのクライアントはチェックマークやハイライト枠で「使用中」の項目を示す。
5. 更新したい場合は、その項目の横にある更新アイコンをクリックすればリモート内容を再取得できる。削除して作り直す必要はない。

自動更新については、間隔は12〜24時間程度に設定するのがおすすめで、短くしすぎないことです。サブスクリプションのエンドポイントに頻繁にリクエストを送ることは必要性が低い(ノードリストは通常1日に何度も変わらない)上、一部のサービス提供者は高頻度のリクエストに対して速度制限や一時的なブロックを行うこともあります。

強調しておきたいのは、クライアント内に複数のProfileを保存しても互いに干渉しないという点です——同じ瞬間に有効なのは選択中の1つだけで、選ばれていない他の設定は単に静的に保存されているだけで、稼働中のポートを占有したり余分なリソースを消費したりはしません。これが「複数設定管理」がニーズとして存在する理由でもあります。出張中は低遅延の中国本土向け中継設定に切り替え、普段はメインのサブスクリプションに戻し、新しいルールをテストする際には一時的な草案設定に切り替える、といった使い分けが互いに影響し合わずに可能です。

複数設定管理でよくある誤解

インポートと切り替えを把握したら、次に実際の運用で最も踏みやすい誤解をいくつか見ていきます。

手動での変更はサブスクリプション更新で上書きされる

サブスクリプションタイプのProfileのローカルファイルに直接追加ルールを手書きした場合、次回の自動更新でリモートから返された新しい内容が丸ごと上書きされ、手動で加えた部分は消えてしまいます。長期的に自定義ルールを保ちながらサブスクリプション内容も失いたくない場合は、クライアントが提供する「オーバーライド」「Override」または「パッチ設定」機能を使うべきです。これはサブスクリプション本来の内容の上に独立して保存されるカスタムルール・プロキシグループを重ねる仕組みで、サブスクリプションを更新しても基礎部分だけが置き換わり、重ねた層は影響を受けません。

複数サブスクリプション間のプロキシグループ名の衝突

異なるサービス提供者のサブスクリプションでは「香港ノード」「自動選択」のような汎用的な命名が使われがちです。2つのサブスクリプション内容を手動で1つの設定にマージしようとすると、ルールが参照するプロキシグループ名が対応しなくなりやすく、ルールにマッチしたのに該当グループが見つからず、想定していたノードではなく受け皿のMATCH分岐にトラフィックが流れてしまうことがあります。サブスクリプションをまたいで設定をマージする前に、まずプロキシグループの命名が一意かどうかを確認することをおすすめします。

Profileの切り替え=ノードの切り替えだと誤解する

Profileの切り替えは、ポート・ルール・プロキシグループ定義を含む設定全体の切り替えです。一方、日常的な「ノード回線を変える」は通常、現在のProfile内のあるプロキシグループでノードを選び直すだけで済み、設定全体を切り替える必要はありません。この2つの操作を混同すると、ルールと分流ロジックも一緒に変わってしまい、問題を調査するときに本当の原因を特定できなくなります。

更新間隔を短すぎに設定する

前述の通り、自動更新間隔を数分おきに設定すると「より即時的」に見えますが、実際には大半のサブスクリプションのノードリストは短時間で頻繁に変わることはなく、過度に高頻度なリクエストは逆に速度制限を受けるリスクを高めます。妥当な範囲は12〜24時間で、重要な変更の前には手動で1回更新すれば十分です。

よくある質問

ProfileとサブスクリプションURLは複数保存できますか?互いに衝突しますか?

任意の数のProfileを同時に保存できます。これらはリスト内の独立した項目であり、互いに衝突することはありません。衝突が起きるのは複数の内容を手動で1つの設定ファイルにマージしたときだけで、命名やルールの順序処理が不適切な場合に問題が発生します。

サブスクリプションを更新したら急にルールが効かなくなったのはなぜですか?

多くの場合、サブスクリプション側でルールセットやプロキシグループ構造が更新され、既存の手動カスタム内容が丸ごと上書きされたためです。オーバーライド/パッチ機能でカスタム部分を保存しておくことで、この問題の再発を避けられます。

ローカルファイルタイプのProfileに自動更新を設定できますか?

できません。自動更新はリクエスト可能なリモートアドレスに依存しますが、純粋なローカルファイルにはそのアドレスがなく、内容の変更は再度手動でインポートすることでしか同期できません。