Clashの設定ファイルとは:Profileの基礎概念とマルチ設定切替管理
Profileはノード・ルール・プロキシグループを決めるClashの中核データです。本稿では設定ファイルの構造と取得方法を解説し、複数のサブスクリプションを併用する際の命名・更新・切替方法を示して、互いの上書き事故を防ぎます。
NT-05.1Profileとは何か
Clashクライアントを起動すると画面に表示されるノード一覧、プロキシグループ、振り分けルールは、すべて同じひとつのファイル——通称Profile(設定ファイル)から読み込まれています。実体はYAML形式のテキストで、「どのノードがあるか」「ノードをどうグループ化するか」「どの通信をどのプロキシグループに振り分けるか」という3点を記述したものです。クライアント自体はあくまで実行エンジンであり、ノード情報を自前で保持しません。すべての挙動は現在読み込まれているProfileに依存します。同じクライアントでも設定ファイルを差し替えれば、画面上のノード・グループ・ルールがまったく別物になるのはこのためです。
Profileを理解しておく意味は、「ノードが消えた」「ルールが効かない」「グループ名が変わった」といった現象に遭遇したとき、まずクライアント本体の不具合を疑うのではなく、現在読み込まれている設定ファイルの種類と、直近に更新が入ったかどうかを確認することにあります。使用中の困りごとの大半は、クライアント本体ではなく設定ファイル側に原因があります。
NT-05.2設定ファイルの構造
標準的なClash/mihomoの設定ファイルは、いくつかのトップレベルフィールドで構成されています。主なフィールドと役割は次の表の通りです。フィールド名は大文字・小文字を区別するため、仕様どおりに正確に記述する必要があります。
| フィールド | 役割 |
|---|---|
| proxies | ノード一覧。プロトコル種別・アドレス・ポート・認証情報を1件ずつ宣言する |
| proxy-groups | プロキシグループ。複数ノードをまとめ、選択方式(手動/自動テスト/負荷分散)を指定する |
| rules | 振り分けルール。ドメイン・IP・プロセスなどの条件で通信を特定のプロキシグループへ振る |
| rule-providers | 外部ルールセットの参照。ルール数が多い場合にrulesへの直書きを避けるために使う |
| dns | DNS解決の挙動。nameserver、enhanced-mode、fake-ipの範囲などを含む |
| tun | 仮想ネットワークアダプタ関連のスイッチ。システムプロキシで捕捉できない通信を処理する |
最小構成の例は以下の通りです。実際の設定ではフィールドはもっと増えますが、骨格は変わりません。
proxies:
- name: "サンプルノード"
type: vmess
server: example.example
port: 443
uuid: 00000000-0000-0000-0000-000000000000
proxy-groups:
- name: "自動選択"
type: url-test
proxies: ["サンプルノード"]
url: "http://www.gstatic.com/generate_204"
interval: 300
rules:
- DOMAIN-SUFFIX,example.com,自動選択
- MATCH,DIRECT
この3つの区分には明確な依存関係があります。proxy-groupsはproxiesで宣言したノード名を参照し、rulesはさらにproxy-groups内のグループ名を参照します。どこか一箇所の名称を変更して他の2箇所と同期させなければ、「プロキシグループがノードを見つけられない」「ルールが存在しないグループを指している」といったエラーが発生します。これは手書き設定で最もよく起きるミスです。
NT-05.3設定ファイルの取得方法:ローカルファイルとサブスクリプションURL
設定ファイルの取得方法は主に2種類あり、その後の運用コストが大きく変わります。
- ローカルファイル:自作または他所から入手したYAMLファイル。クライアントに読み込ませた後は自動で変化せず、ノードが失効したらファイル全体を手動で差し替える必要があります。
- サブスクリプションURL:HTTP/HTTPSのアドレス。クライアントが定期的にこのURLへリクエストを送り、最新の内容を取得してローカルキャッシュを上書きします。ノードプールの更新、期限のお知らせ、通信量情報などは通常このURLのレスポンスヘッダーに含まれます。
多くのクライアントはサブスクリプションに自動更新間隔を設定できます。一般的には1日1回、あるいは数時間おきに設定します。間隔を短くしすぎるとサブスクリプション元のサーバーに負荷がかかり、リクエスト頻度が高すぎるクライアントに対してレート制限やブロックを行う事業者もあります。更新間隔は事業者が推奨する値より短くする必要はありません。
NT-05.4複数設定の併用:命名・更新・切替のルール
普段用・バックアップ用・特定アプリの検証用など、複数のサブスクリプションを同時に使うのはよくあるケースです。複数の設定を併用すると最も起きやすいのが相互の上書き事故です。2つのサブスクリプションがクライアント上で同じデフォルト名で表示され、更新対象を間違えたり、切替後にどちらが有効になっているかを確認し忘れたりします。以下の点を守るとミスを減らせます。
- サブスクリプションを取り込んだらすぐにリネームし、用途や取得元がわかる表記を加える(例:「普段用」と「バックアップ用」を区別)。クライアントが自動生成したデフォルト名のまま残さない。
- 更新前に現在選択中の設定対象を確認してから更新操作を行う。別の設定に切り替えた後、元の設定の更新ボタンを誤って押してしまう事故を避ける。
- 用途ごとに自動更新間隔を分けて設定する。長期間使わないバックアップ用サブスクリプションは自動更新を無効化し、バックグラウンドのリクエストを減らす。
- 設定を切り替えたらプロキシグループの選択状態を再確認する。サブスクリプションごとにグループ構成や命名が異なる場合があり、切替後は以前手動で選んでいたノードが存在しないことがある。
- ルール数が多くカスタマイズ度が高い設定は、ローカルバックアップを1件残しておくことを推奨する。サブスクリプション元の変更でカスタムルールがまとめて上書きされる事態を防ぐ。
サブスクリプションの更新はファイル全体の上書きであり、差分の統合ではありません。クライアント画面上でノードのグループを手動調整したり、カスタムルールを追加していた場合、次回の更新でその変更はまとめて消去されます。クライアント側に独立した「ユーザールール」重ね合わせ機能がない限り、この点は避けられません。
NT-05.5よくあるトラブルの確認手順
「ノード数が合わない」「ルールが効かない」「プロキシグループが消えた」といった現象が起きた場合、以下の順序で確認すると、多くのケースは設定ファイル側に原因が見つかり、クライアントの再インストールは不要です。
- 現在有効になっているのがどの設定ファイルか、直前に自動更新が発生していないかを確認する。
- 設定ファイルの内容を直接開き、proxy-groupsが参照しているノード名がすべてproxies内に存在するか照合する。
- rulesが参照しているプロキシグループ名が、proxy-groups内の名称と完全に一致しているか確認する。大文字小文字や全角・半角の違いも含めてチェックする。
- rule-providersを使用している場合は、外部ルールセットのURLにアクセスできるか、フォーマットがクライアントの要件に合っているかを確認する。
- 設定ファイル側の問題を除外したうえで、ノードのサーバー側や自分のネットワーク環境の要因を検討する。
設定ファイルを丸ごと差し替えるしかないブラックボックスとしてではなく、読んで照合できるテキストとして扱う姿勢が、Clash系クライアントを長期的に安定運用する基本です。複数設定を併用する場合、わかりやすい命名と更新の規律は、どのクライアント機能のオン・オフよりもミスを減らします。