Clash の Profile(設定ファイル)とは:基本概念と複数設定の管理方法

Profile とは何か:動作指示が書き込まれた一枚の指示書

まず一番多い質問に答えます。Clash でいう「設定」(Profile)とは何なのか。これは YAML 形式のプレーンテキストファイルです。Clash の起動後の挙動——どのポートで通信を受け付け、トラフィックをどんな順番で振り分け、最終的にどのノードへ渡すか——はすべてこのファイルの記述どおりに実行されます。Clash Verge、Clash for Windows、各種 mihomo 系 GUI クライアントでは、「設定」タブに並ぶ各項目がそれぞれ独立した Profile であり、クリックすることで複数の設定を切り替えて適用できます。

どの Profile を開いても構造はほぼ同じで、共通設定に加えて主に3つの要素で構成されています。

mixed-port: 7890        # ローカルプロキシのポート番号
allow-lan: false        # LAN上の他デバイスからの接続を許可するか
mode: rule              # 振り分けモード:rule / global / direct
log-level: info

proxies:                # ノード一覧
  - name: "ノードA"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:           # プロキシグループ:ノードをグループ化し、ルールから参照する
  - name: 自動選択
    type: url-test
    proxies: ["ノードA", "ノードB"]
    url: http://www.gstatic.com/generate_204
    interval: 300

rules:                  # 振り分けルール:上から順に照合
  - DOMAIN-SUFFIX,google.com,自動選択
  - GEOIP,CN,DIRECT
  - MATCH,自動選択

• proxies:ノード一覧。各ノードにはプロトコル種別、サーバー、ポート、認証情報が記載されており、設定全体の材料となります。
• proxy-groups:プロキシグループ。ノードをグループ化する仕組みで、手動選択・自動速度テスト(url-test)・フェイルオーバー(fallback)などがあります。ルールはノードを直接指定せず、グループを介してやり取りします。
• rules:振り分けルール。上から順に照合し、条件に合致した時点で指定の宛先へ振り分けます。末尾の MATCH がすべてを受け止める役割を担います。
• 共通設定:mixed-port(ローカルプロキシのポート)、allow-lan(LAN内デバイスの接続許可)、mode(rule / global / direct の3モード)、log-level など。mihomo コアの設定では dns や tun といったセクションも登場します。

一言でまとめると、proxies は材料、proxy-groups は材料をまとめる棚、rules は使う順番です。3つが揃ってはじめて設定として機能します。rules がなければすべてのトラフィックが1つのグループに集中し、proxies がなければ振り分ける材料自体がありません。

サブスクリプションリンクとローカルファイル:Profile の2つの出自

出自で分けると、Profile には2種類しかありません。サブスクリプションリンクから生成されたものと、ローカルファイルとして読み込んだものです。クライアントの設定一覧では見た目は同じですが、性質はまったく異なります。この違いを理解していないと、後々「変更が消える」というトラブルの原因になります。

サブスクリプションリンクの正体は意外とシンプルです。プロバイダーが特定の URL に YAML ファイルをホストし、クライアントがそのアドレスからダウンロードして設定ディレクトリ内にローカルコピーとして保存します。つまりサブスクリプション経由の設定も、実際にはディスク上の .yaml ファイルの一種であり、違うのは定期的に「最新版を取得しに行く」仕組みが付いている点です。これが次のセクションで説明する現象の直接的な原因になります。

なぜ「変更するとすぐ消える」のか:サブスクリプション更新は全体差し替え

症状:サブスクリプション設定にルールを追加したりポートを変更したりした直後は正常に動作するが、数日後に確認すると変更内容がすべて元に戻っている(まるで何も編集していないかのように)。

原因:サブスクリプションの更新とは、元のリンクから改めてリモートファイルをダウンロードし、ローカルコピー全体を差し替える処理です。クライアントは差分比較を行わず、手動での変更を保持する仕組みもありません。自動更新の間隔(24時間や48時間が一般的)を設定していれば、時間になれば黙って上書きされます。これは不具合ではなく、サブスクリプション機能の正常な動作です。目的そのものが「設定をプロバイダー側と常に一致させる」ことにあるためです。

手動での変更を守る3つの方法

変更量が少ない順に、次の3つの方法があります。

1. マージ/オーバーライド機能(推奨)。Clash Verge の「マージ(Merge)」機能や Clash for Windows の Mixin は考え方が同じで、サブスクリプション本体は一切変更せず、別途小さな YAML パッチを用意し、クライアントが設定を読み込む際にそのパッチを重ねて適用します。サブスクリプションが更新されても本体だけが差し替わり、パッチはそのまま有効です。dns セクションの変更、ルールの追加・削除、ポート調整といった小規模な変更に向いています。注意点は2つ:パッチ内のフィールド名を誤ると何のエラーも出さずに無効化されるため、編集後は必ず設定を再読み込みしてログを確認すること。パッチと本体の内容が競合した場合の優先順位は、各クライアントの公式ドキュメントに従ってください。
2. ローカル設定として複製してから編集する。サブスクリプションでダウンロードしたファイルを別名で保存し、ローカルファイルとして読み込み直します。これ以降は自由に編集でき、更新による上書きの影響を受けません。代わりにサブスクリプションとの連携は切れるため、ノードの追加・削除やルールの更新は自分で手動反映する必要があります。変更量が多く、かつサブスクリプション側の更新頻度が低い場合に向いています。
3. proxy-providers / rule-providers による分離参照(mihomo コア)。自分専用のローカルなメイン設定を用意し、ノード一覧は proxy-providers でサブスクリプションのアドレスを参照させ、ルールセットは rule-providers で外部リンクを参照させます。メイン設定は完全に自分の管理下にあり、サブスクリプションは単に参照される材料の供給元となるため、両者の更新は互いに干渉しません。

proxy-providers:
  マイサブスクリプション:
    type: http
    url: "https://example.com/subscribe.yaml"
    interval: 86400
    path: ./providers/subscribe.yaml
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 300

3つ目の方法はハードルが最も高い分、最も恒久的な解決策です。メイン設定にはプロキシグループとルールの骨格だけを記述し、ノードはサブスクリプションの更新に合わせて自動で最新化されるため、「上書きされる」という問題自体がそもそも発生しません。

複数設定の併存:命名・切り替え・バックアップ

同時に2〜3つの設定を使い分けるのは珍しいことではありません。プロバイダーごとに1つずつ、メイン線と予備線を分けて、あるいは仕事用と自宅用を分けるといった運用が典型例です。複数設定の日常的な管理では、次の点を押さえておきましょう。

• 読み込み後は必ず名前を変更。デフォルトの名前は意味不明な文字列になっていることが多いため、「取得元+用途」の形式に変更しておけば、数ヶ月後でも見分けがつきます。
• ポート番号は統一する。各設定の mixed-port を揃えておきましょう(例:すべて 7890)。揃えていないと設定を切り替えた際に、システムプロキシや他のソフトに固定で書かれたポート番号と一致せず、「切り替えたらネットに繋がらない」という症状が出ます。
• 更新間隔は短くしすぎない。サブスクリプション設定は24時間おき程度で十分です。頻繁に取得しても得られるメリットはなく、変更内容が上書きされる回数が増えるだけです。
• 切り替え後は3点を確認。現在のモードが rule のままか、システムプロキシが正しく設定されているか、海外サイトにアクセスして通信できるか。設定を切り替えるとコアが再起動されるため、進行中の接続が一時的に切れるのは正常な動作です。
• バックアップは2種類とる。設定ディレクトリ全体をコピーして保管しておくこと、そしてサブスクリプションリンク自体を別途メモしておくこと。リンクさえ手元にあれば、設定はいつでも再構築できます。これが最も確実な保険になります。

よくある症状チェックリスト

• サブスクリプション更新後に独自ルールが消える → マージ/オーバーライドまたはローカル複製に切り替える。方法は第4節を参照。
• サブスクリプションの読み込みで解析失敗と表示される → リンクが返している内容が YAML 形式でない可能性が高いです。サブスクリプションによってはクライアント識別が必要な場合や、事前に変換処理が必要な場合があります。ファイルの文字コードが原因でこのエラーが出ることもあります。
• 設定切り替え時にポート使用中と表示される → 2つの設定の mixed-port が重複しているか、前のコアプロセスが正しく終了していません。残っているプロセスを終了してから切り替えてください。
• 設定を変更しても反映されない → 変更後はコアの再読み込みまたは再起動が必要です。クライアントによっては保存と同時に自動反映される場合と、手動でクリックする必要がある場合があるので、この手順を忘れないようにしてください。

Profile についての基本はここまでです。1つの YAML ファイル、2つの出自、絶対に覚えておくべき上書きの原則、そして変更を守る3つの方法。あとは実践するだけです。クライアント自体の入手方法と、初回のサブスクリプション読み込みについては、以下から確認できます。