Profileとconfig.yaml：設定項目と実行時設定の違い

Profileとは、通常、クライアントに保存される設定項目を指します。サブスクリプションURLから追加することも、ローカルのYAMLファイルをインポートすることもできます。設定本文に加え、項目名、取得元のURL、更新日時、更新間隔、ローカルでの処理ルールなどが保存される場合もあります。Profileはクライアント側の管理上の概念であり、YAMLのトップレベルに必ず記述する項目ではありません。

一方、config.yamlは一般的な設定ファイル名です。カーネルが実際に読み込むのは設定内容と起動時に指定されたファイルパスであり、すべての設定ファイルをこの名前にする必要はありません。クライアントには複数のProfileを保存できますが、通常、1つのカーネル実行インスタンスが読み込む最終設定は1つです。別のProfileを選ぶと、クライアントは新しい実行時設定を生成するか、読み込みます。

対象保存される内容変更した場合の影響
リモートProfileサブスクリプションURL、ダウンロードしたYAML、更新設定次回の更新でダウンロード内容が置き換わる場合がある
ローカルProfileローカルからインポート、または作成した設定本文通常、ノードやルールは手動で管理する
実行時設定元の設定とクライアント側の上書き設定を合成したもの直接編集しても、再読み込み後に反映されなくなる場合がある
クライアント設定システムプロキシ、画面設定、一部のTUNスイッチなどProfileを切り替えても維持される場合がある

そのため、「ファイルを編集したのにポートが変わらない」からといって、保存に失敗したとは限りません。クライアント設定がmixed-portを上書きしているか、別のProfileが使用されている可能性があります。原因を調べる際は、まず現在選択中の項目を確認し、クライアントが表示する最終設定または起動ログを確認してください。

ローカルファイルとサブスクリプション設定：管理元で分類する

リモートProfile：サブスクリプションの更新を維持する

サブスクリプションURLから取得する内容は、使用するカーネルが対応する形式である必要があります。Clash YAMLに対応したサブスクリプションには、通常、ノード、プロキシグループ、ルールが含まれます。ノード一覧だけのサブスクリプションは、完全な設定の代わりとしてそのまま使えません。URLは設定を取得するための入口であり、返される内容がそのまま読み込めるYAMLだとは限りません。

リモートProfileは、ノードの変更を継続して取り込む用途に向いています。ダウンロードしたコピーにルールを追加しても、変更されるのは現在のローカルファイルだけです。次回のサブスクリプション更新でファイル全体が再書き込みされることがあります。編集結果を別途保存するクライアントもありますが、実際の動作は一度更新して確認してください。ファイル名だけで判断することはできません。

ローカルProfile：固定コピーで個別に検証する

リモート設定をローカルファイルにエクスポートし、新しい項目としてインポートすれば、独立したコピーを作成できます。ルールの調査やDNSのテスト、問題発生前の状態の保存に便利です。一方、元のサブスクリプションでノード名やアドレス、認証情報が変更されても、ローカルコピーには通常、自動で反映されません。

日常の管理では、「普段使いのリモート項目」と「調査用のローカルコピー」を両方用意しておくのがおすすめです。前者で更新を受け取り、後者は問題の確認や変更のテスト時だけ使うようにすれば、1つの設定に異なる管理方法を混在させずに済みます。

複数設定の名前付けと切り替え：一度に変えるのは1つだけ

名前には取得元・用途・日付を含める

ファイル名は取得元の識別に使い、サブスクリプションキーは含めないようにしましょう。次のように名前を付けると、リモート項目と固定コピーを区別できます。日付はバックアップの作成日であり、サブスクリプションの有効期限ではありません。

  • remote-main：メインのサブスクリプション。普段使いし、定期的な更新を有効にする。
  • remote-backup：予備のサブスクリプション。使用前に有効かどうかを手動で確認する。
  • local-main-2026-09-30.yaml：その日付時点のメイン設定のローカルコピー。
  • local-dns-test-2026-09-30.yaml：DNS設定の比較に使う検証用設定。

切り替え前後に確認する6項目

クライアントによって、操作画面の名称は「設定」「Profiles」「サブスクリプション」など異なります。特定のクライアントやバージョンのメニュー名に限定せず、操作対象ごとに説明します。

  1. 現在の状態を記録する。有効なProfile、ルールモード、選択中のノード、システムプロキシ、TUNのオン・オフを控えておきます。問題を再現する際には、ファイル名よりもこれらの情報が重要です。
  2. 現在使えている設定をバックアップする。項目のエクスポート機能またはコピー機能でYAMLを保存し、使用中のカーネル名とバージョンも記録します。
  3. 先にインポートし、その後で有効にする。新しいファイルを設定一覧に追加し、まずクライアントの設定チェックを実行します。不明なフィールドが報告された場合は、カーネルとの互換性を確認してください。
  4. 切り替え先のProfileを選ぶ。読み込みが終わるまで待ち、ログに解析エラー、プロキシグループの参照エラー、ポートのバインド失敗がないか確認します。
  5. 実際の動作を確認する。想定したルールモードになっていること、プロキシグループが意図しないデフォルトノードに戻っていないこと、システムプロキシのポートが実行時設定と一致していることを確認します。
  6. 新しい接続でテストする。対象のページを開き直し、接続一覧で適用されたルールと接続先を確認します。既存のダウンロードだけを見ても、切り替え結果は判断できません。

設定切り替え時に既存の接続がどう扱われるかは、クライアントとカーネルによって異なります。以前の接続先を使い続ける場合もあれば、再読み込みによって切断される場合もあります。新しいルールを確認するときは、新たにリクエストを発生させてください。重要な通信中は、完了を待ってから設定を切り替えましょう。

サブスクリプションの自動更新：クライアントとリソースの更新間隔を分けて考える

完全なProfileのサブスクリプション更新は、通常クライアントが管理します。更新設定は、対象項目の編集画面または全体のサブスクリプション設定にあります。まず手動で更新し、ダウンロードと解析が成功することを確認してから自動更新を有効にすると、ネットワークの問題と更新スケジュールの問題を切り分けやすくなります。

更新間隔を設定するときは単位を確認する

画面の単位が分の場合、360は6時間、1440は24時間です。単位が時間なら、それぞれ6または24を入力します。これは間隔の換算例であり、すべてのクライアントに共通する初期値ではありません。他のクライアントの画面に表示された数値を、そのまま入力しないでください。

  • サブスクリプションの提供元が更新頻度を指定している場合は、その内容を確認し、短時間に何度もリクエストしないようにしてください。
  • PCのスリープ、アプリの終了、モバイルOSによるバックグラウンド動作の制限などで、定期処理が遅れることがあります。「6時間ごと」に設定しても、毎回時間どおりに実行されるとは限りません。
  • 更新に成功したら、現在のProfileが自動で再読み込みされるか確認します。キャッシュを更新するだけのクライアントもあり、その場合は項目を選び直すか、再読み込みが必要です。
  • 更新に失敗した場合は、発生時刻とエラーの種類を記録し、ネットワーク、サブスクリプションの有効期限、サーバーの応答、返された内容を確認します。

providerのintervalと混同しない

該当フィールドに対応するClashまたはClash Meta（mihomo）カーネルでは、HTTP形式のproxy-providersやrule-providersにintervalを設定できます。単位は通常、秒です。たとえばinterval: 86400は、対象リソースを24時間ごとに更新する設定です。これはリソース単位の更新間隔であり、ProfileのサブスクリプションURL全体を自動更新するものではありません。

同様に、profile.store-selectedはプロキシグループの選択状態を保存する設定で、サブスクリプションの更新スケジューラーではありません。このオプションに対応するカーネルでのprofile.store-fake-ipは、Fake-IPのマッピング保存に関する設定であり、複数の設定を管理するリストではありません。クライアントのProfile一覧と、YAMLのprofileフィールドは別の階層に属します。

ローカルルールを維持する：オーバーライド、リソース分割、独立コピー

サブスクリプションを自動更新しながらカスタムルールを維持するには、クライアントが明示的に提供するオーバーライド、マージ、スクリプト処理機能を優先して使いましょう。これらは、サブスクリプションの更新後にローカルの変更を適用するための機能です。名称や実行順序、構文はクライアントによって異なります。オーバーライド用ファイルを、汎用のClash設定としてそのままインポートしないでください。

ルールの挿入位置でマッチ結果が変わる

rulesは上から順に判定されます。カスタムルールをMATCHの後ろに置くと、通常は処理されません。一方、ルール一覧全体を置き換えると、サブスクリプションにもともと含まれていた振り分けルールが失われることがあります。操作前に、ツールが「先頭に挿入」「末尾に追加」「全体を置換」のどれを実行するか確認し、最終的な実行時設定で結果を確かめてください。

以下は、Profileの切り替え、ポート、ルールの順序を確認するための独立した最小構成のローカル設定例です。DIRECTとREJECTのルールのみを含み、リモートのプロキシノードはありません。サブスクリプション設定の代わりには使えません。

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

proxy-groups:
  - name: LocalChoice
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,LocalChoice

有効にすると、example.comとそのサブドメインへの新しい接続は、まずDIRECTルールに一致します。それ以外の接続はLocalChoiceに送られます。同じPC上の別プロセスがすでに7890を待ち受けている場合、ポートをバインドできないことがあります。クライアントでポートの全体上書きが有効なら、実際のポートは画面とログで確認してください。

ルールは自分で管理し、ノードだけを更新したい場合は、固定のメイン設定とノードプロバイダーを組み合わせる方法もあります。ただし、使用するカーネルがその機能に対応し、リモートの応答がprovider形式に準拠し、プロキシグループが対象リソースを正しく参照していることが前提です。完全なサブスクリプションをインポートするより複雑なため、設定の参照関係を理解しているユーザー向けです。

バックアップとロールバック：元の設定と実行環境を一緒に保存する

バックアップに含める項目

  • 設定本文：使用可能なYAMLを保存し、サブスクリプションの元データと合成後の実行時設定を区別します。
  • ローカルオーバーライド：オーバーライド、マージ、スクリプトの各ファイルを個別に保存し、どのProfileに適用するかも記録します。
  • 実行環境：クライアントとカーネルのバージョン、ポート、モード、TUNの状態を記録します。
  • 参照リソース：オフラインで復元する場合は、外部ルールセット、ノードプロバイダー、Geoデータベースを利用できるかも確認します。

大きな変更を加える前に、日付入りのスナップショットを保存し、動作確認済みの設定を最低1つ残してください。クライアントが一時生成した実行ファイルだけをバックアップするのは避けましょう。マシン固有のパスが含まれていたり、次回起動時に再生成されたりすることがあります。クライアントの管理データをエクスポートする際は、ローカルオーバーライドやサブスクリプションURLが含まれるかも確認してください。

「設定・オーバーライド・状態」の順に戻す

  1. 問題のある項目の自動更新を一時停止し、後で比較できるようエラーが出た設定を残します。
  2. 動作確認済みのローカルスナップショットをインポートし、構文をチェックしてから有効にします。
  3. 追加したオーバーライドレイヤーを一時停止し、復元した古いスナップショットに同じ誤ったルールが再適用されないようにします。
  4. 元のルールモード、プロキシグループの選択、プロキシの適用方法を戻し、新しい接続でテストします。
  5. 復元後の動作を確認したら、変更を1つずつ追加します。リモートの内容に問題がないことを確認してから、自動更新を再開してください。

よくある質問：切り替えが反映されない・ノードが変わる・更新で上書きされる

Profileを切り替えても、システムプロキシが変わらないのはなぜ？

Profileの切り替えで変わるのは、通常カーネルの設定であり、OSのシステムプロキシ設定が必ず書き換わるわけではありません。たとえば、システムプロキシが127.0.0.1:7890を参照したまま、新しい設定が実際には7891で待ち受けていると、アプリが接続できないことがあります。システムプロキシのポートをクライアントの実際の待ち受けポートに合わせ、対象アプリがシステムプロキシを使う設定になっているか確認してください。

切り替え後にノード選択がデフォルトに戻るのはなぜ？

選択状態は、カーネルまたはクライアントのキャッシュで管理される場合があります。新しい設定でプロキシグループ名やノード名が変わったり、選択中のノードが削除されたりすると、以前の選択を引き継げません。選択状態の保存を有効にしていても、サブスクリプション更新後は主要なプロキシグループを確認してください。名前の変更をノードの接続障害と混同しないようにしましょう。

サブスクリプションの更新に成功したのに、カスタムルールが消えたのはなぜ？

まず、変更をリモートからダウンロードしたコピーに直接書き込んでいなかったか確認してください。該当する場合、更新で上書きされるのはリモート項目では一般的な動作です。長期的に維持する変更は、対応するローカルオーバーライドに移し、手動で更新して最終的なルールの順序を確認しましょう。クライアントにオーバーライド機能がなければ、独立したローカルコピーを使い、手動で管理してください。

2つの設定を同時に有効にできますか？

同じカーネル実行インスタンスでは、通常のProfile切り替えは現在使う設定を選ぶ操作であり、2つのファイルを自動で重ね合わせるものではありません。ノードやルールを組み合わせる必要がある場合は、明示的なマージ処理またはprovider参照を使ってください。設定の適用順、同名のプロキシグループの扱い、ポート設定を確認する必要があります。2つのファイルにチェックを入れるだけでマージされると考えないでください。

日常の管理は3つの役割に分けられます。リモート項目で更新を受け取り、ローカルオーバーライドで長期的な変更を維持し、日付入りのスナップショットでロールバックに備えます。一度に変更するレイヤーを1つに絞り、新しい接続で結果を確認すると、設定変更の原因を特定しやすくなります。フィールドと参照関係は上級設定、初回インポートの手順は入門ガイドをご覧ください。