Clash設定ファイル Profileとは？複数設定の切り替えと管理方法

まずProfile、購読URL、config.yamlを区別する

結論から言うと、Profileはクライアントが1つのプロキシ設定を管理するための論理単位です。購読URLはその設定のリモートソースで、YAMLファイルはクライアントがダウンロードまたは読み込んだ後にローカルへ保存する実体です。3者には関係がありますが、同じものではありません。

Clash Verge RevやClash NyanpasuなどのGUIクライアントでは、Profileは「購読」「設定」「設定ファイル」などと表示されることがあります。通常、1つのProfileには名前、ソースURL、ローカルファイルのパス、更新日時、現在の有効状態が含まれます。項目を選択すると、クライアントが対応するYAMLを読み込み、構文を確認したうえで、処理済みの設定をMihomoコアに渡して実行します。

対象	主な役割	一般的な形式	更新方法
Profile	クライアント内で設定を整理・選択・管理する	設定一覧の1項目	切り替え、名前変更、再取得
購読URL	リモート設定の内容を提供する	HTTPSで始まるURL	クライアントがURLへリクエストして取得
YAMLファイル	ポート、ノード、プロキシグループ、ルールを保存する	config.yamlなどのファイル名	リモートから上書き、またはローカルで編集
実行時設定	Mihomoコアが実際に適用する	クライアントがマージ・上書きした後の結果	Profileの切り替え、またはコアの再読み込み

config.yamlは一般的なファイル名にすぎない

config.yamlはClashエコシステムでよく使われるデフォルト名であり、すべてのProfileがこの名前である必要はありません。GUIクライアントでは重複を避けるため、7f2c8a.yamlのようなランダムな識別子で保存されたり、購読名ごとに専用フォルダーが作られたりします。そのため、一覧には「オフィス回線」と表示されていても、ディスク上のファイル名はまったく異なる場合があります。

実行可能な基本YAMLには通常、リッスンポート、プロキシノード、プロキシグループ、ルールが含まれます。次の構成はProfile内の各要素の関係だけを示したもので、実際のノード認証情報は含みません。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: "サンプルノード"
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "サンプルノード"
      - DIRECT

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

複数のProfileを作成する：先に名前を付けてから読み込む

複数の設定を併用する場合、実用的なのは「設定1」「新しい購読」のような初期名を残すことではなく、読み込んだ日に用途を明確にすることです。名前には少なくとも、どの用途か、どの回線グループが提供元か、自動更新を許可するかの3点を含めましょう。

「用途・提供元・更新方法」で名前を付ける

日常・メイン購読・自動更新：普段使い用で、クライアントによる定期取得を許可します。
仕事・社内ルール・手動更新：社内ドメインの振り分けを含むため、更新前にルールの変更を確認します。
モバイル回線・低通信量：プロキシグループでは、安定性が高く通信コストの低いノードを優先します。
テスト・ローカルYAML・上書き禁止：ルール、DNS、TUNパラメーターの検証に使用します。
フォールバック・2026-08-27：動作確認済みの静的なコピーを保管します。

Clash Verge Rev 2.xの一般的な画面を例にすると、「購読」→「新規作成」の順に進み、購読URLを貼り付けて名前を入力し、保存した後にダウンロードまたは更新ボタンをクリックします。ローカルファイルを読み込む場合は、「購読」→「新規作成」→「ローカルファイル」を選び、拡張子が.yamlまたは.ymlのファイルを指定します。バージョンによってボタン名は「インポート」「新しい設定」「購読を追加」など異なりますが、基本手順は同じです。

現在使用中のProfile名を先に記録します。
リモート購読を新規作成するか、ローカルYAMLを読み込みます。
初期名を用途が分かるシーン名に変更します。
手動更新を1回実行し、更新日時が変わったことを確認します。
設定の詳細を開き、ノード数、プロキシグループ、ルールが揃っているか確認します。
最後に新しいProfileへ切り替え、読み込みに失敗しても現在の接続が途切れないようにします。

Profileを切り替える：選択状態だけでなく有効な設定を確認する

Profileをクリックすると、通常はYAMLの解析、上書きの適用、Mihomoへの設定引き渡し、プロキシグループ状態の更新という4つの処理が行われます。一覧に選択マークが表示されても、切り替え処理を開始したことしか分かりません。本当に有効になったかは、コアの状態、現在のプロキシグループ、接続履歴も確認してください。

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

コアの状態を確認：「設定」→「コア設定」または「システム設定」→「コア」を開き、Mihomoが実行中になっていることを確認します。
ポートを確認：現在のProfileのmixed-portがシステムプロキシのポートと一致しているか確認します。一般的な値は7890ですが、実際には現在の設定を優先してください。
プロキシグループを確認：「プロキシ」ページを開き、「ノード選択」「自動選択」などのグループが新しい設定のものか、前のProfileの名前ではないかを確認します。
接続を確認：「接続」または「ログ」を開き、テストページへアクセスして、新しい接続がどのルールとプロキシグループにマッチしたか確認します。

2つのProfileがどちらもmixed-port: 7890を使用している場合、リッスンアドレスとポートが変わらないため、通常はシステムプロキシを変更する必要はありません。新しい設定がmixed-port: 7897に変わった場合は、システムプロキシも127.0.0.1:7897へ変更します。YAMLだけ変更して古いシステムプロキシのポートを残すと、ブラウザーがプロキシに接続できなくなります。

TUNモードの切り替えでは、もう一段階確認する

TUNモードは仮想ネットワークインターフェースを通じて通信を取り込むため、通常のシステムプロキシより適用範囲が広くなります。Profileの切り替え後にtun、DNS、ルート除外項目、ネットワークスタックを変更した場合、TUNの再起動が必要になることがあります。一般的な操作手順は「設定」→「システム設定」→「TUNモード」と進み、いったん無効にして2～3秒待ってから再度有効にすることです。

TUNを有効にしたら、ログにインターフェースの作成、ルートの書き込み、DNSリスニングに関する情報が出ているか確認します。設定がdns.listen: 0.0.0.0:1053を使用している場合は、1053番ポートが別の実行中プロキシに占有されていないことも確認してください。複数のクライアントで同時にTUNを有効にすると、デフォルトルートが繰り返し書き換えられることがあります。切り替えをテストする際は、1つのコアだけを実行してください。

Profileを更新する：リモート更新、上書き、実行時再読み込みを区別する

「購読を更新」は通常、リモートYAMLを再ダウンロードするだけです。「設定を再読み込み」はコアにローカルの内容を再読込させます。クライアントによっては両方を連続して実行しますが、Profileを一度手動で切り替える必要がある場合もあります。更新後もノード数が変わらなくても、必ずしも失敗ではありません。サーバー側でノードのパラメーターやルールだけが変更されることもあります。

更新日時とログで更新結果を判断する

更新前に、Profileに表示されている時刻、たとえば2026-08-27 09:30を控えます。更新後に時刻が変わったことを確認し、ログのHTTPステータスも確認してください。成功時によく見られるステータスは200です。401や403は購読権限やトークンの期限切れ、404はリモートパスが存在しないことを示す場合が多く、接続タイムアウトでは現在のネットワークと直接接続ルールを確認します。

症状	優先して確認する点	対処方法
更新日時は変わったが、ノード名が古いまま	実行中の設定を再読み込みしたか	Profileを再選択し、必要ならコアを再起動する
更新後にカスタムルールが消えた	購読キャッシュを直接編集していないか	フォールバック用コピーから復元し、上書き機能を使う
更新時にYAML解析エラーが表示される	エラー行付近のインデント	元のファイルに戻し、スペースで階層を統一する
新しいノードはあるがプロキシグループに表示されない	プロキシグループのproxiesまたはprovider参照	ノードが該当グループに追加されているか確認する

YAMLはインデントに敏感です。リスト項目の前には通常2つのスペースを使い、タブを混在させないでください。編集後はまずクライアントの構文チェック結果を確認してから、コアに読み込ませます。エラーが86行目を示していても、実際にコロンが抜けていたりインデントがずれていたりする位置は85行目のことがあります。前の行も合わせて確認しましょう。

ローカル設定を編集する：まずファイルの対応関係を確認する

複数のProfileを使う環境で最も多い操作ミスは、config.yamlという名前のファイルを編集したのに、クライアント画面へ変化が反映されないことです。クライアントが別のキャッシュファイルを実行しているか、実行設定に上書き内容が重ねられていることが主な原因です。編集前はディスク上のファイル名で推測せず、Profileの詳細メニューから対象ファイルを開いてください。

安全に編集する手順

設定一覧で現在有効な項目を確認します。
その項目の「ファイルを開く」「設定を編集」「フォルダーを開く」から進みます。
元のファイルをコピーし、複製名に日付と用途を加えます。
毎回1つの範囲だけ変更します。たとえば先にmixed-portを変更し、確認後にDNSを変更します。
保存後、構文チェックと設定の再読み込みを実行します。
ログでコアが想定したファイルを読み込んだことを確認します。

Mihomoでよく使われるコアフィールドには、mixed-port、allow-lan、mode、dns、tun、proxies、proxy-groups、rulesがあります。フィールドを変更する前に、クライアントに個別の切り替え項目がないか確認してください。たとえば画面上のTUNスイッチは、実行時の上書きによって制御されることがあります。YAMLにenable: falseと記述していても、クライアントがコア起動前に独自設定をマージする場合があります。

最終的な設定を確認する必要がある場合は、クライアントの「実行設定」「現在の設定」「デバッグ用エクスポート」などの機能を利用します。これはリモート購読、ローカルの上書き、クライアント設定をマージした結果であり、購読キャッシュだけを見るよりもMihomoが実際に受け取る内容に近いものです。

古いProfileを整理する：無効化してから削除する

設定一覧に項目が増えすぎると、重複した名前や期限切れの購読によって誤操作が起きやすくなります。整理するときは、現在有効な項目から削除しないでください。まず動作確認済みのメインProfileへ切り替え、ウェブページとログを確認してから古い項目を処理します。

削除前に必要な情報を残す

Profileの表示名、ソースの種類、最終更新日時を記録します。
ローカルでカスタマイズした設定は、先にYAMLとしてエクスポートしてから一覧項目を削除します。
古いProfileにしかないルール、プロキシグループ、DNSパラメーターがないことを確認します。
リモート購読は現在も使っている入口だけを残し、同じURLを指す項目を複数作らないようにします。
削除後にキャッシュフォルダーを確認し、クライアントが自動管理するファイルと手動バックアップを区別します。

設定は「現在使用中」「テスト中」「ロールバック用」の3種類に分けるのがおすすめです。現在使用中は1～2個に絞り、テスト設定は検証後に統合または削除し、ロールバック用は直近の安定版を1つ残せば十分です。日付付きのコピーも数か月以上経つと、ルールやノード情報が古くなっている可能性があるため、長期間メイン設定として使わないでください。

複数設定の管理でよくある質問

Profileを切り替えたら、以前選んだノードが変わったのはなぜ？

ノード選択は通常、プロキシグループ名とノード名を基準に保存されます。新しいProfileに同名ノードがない場合、クライアントはプロキシグループのデフォルト項目、または一覧の最初にある利用可能な項目へ戻ります。切り替え後は「ノード選択」「自動選択」など主要なプロキシグループを再確認してください。

複数のProfileを同時に実行できますか？

ほとんどのデスクトップクライアントでは、同時に1つのメインProfileだけを同じMihomoコアへ渡します。複数のコアを手動で起動する場合は、mixed-port、コントロールポート、DNSリッスンポートをそれぞれ別に割り当て、システムプロキシやデフォルトルートを同時に制御しないようにする必要があります。一般的な利用では、1つのクライアント内で切り替える方法が適しています。

購読を更新すると、プロキシグループで手動選択した項目は上書きされますか？

リモートYAMLによってプロキシグループの定義は更新されますが、クライアントが前回の選択状態を別途保存していることもあります。元のノードが残っていれば、通常はそのまま使えます。ノード名が変わったり削除されたりした場合、プロキシグループは利用可能なデフォルト項目へ戻ります。更新後は遅延と現在の選択項目を確認してください。

config.yamlを変更したのに反映されないのはなぜ？

まず、現在のProfileに対応するファイルを編集しているか確認してから、再読み込みを実行します。クライアントのMerge、Mixin、上書き設定が同名フィールドを上書きしていないかも確認してください。ポート設定を変更した場合は、システムプロキシも合わせて変更します。

Profileの更新頻度はどのくらいが適切？

日常的に使う購読は6～24時間ごとの更新で十分です。ルールの変更が少ないローカル設定は手動更新で問題ありません。更新間隔を短くしてもリクエストが増えるだけで、ノード状態をより早く確認できるとは限りません。ノードの遅延確認は、プロキシグループのヘルスチェックで別途行います。

再現性のあるProfile管理フロー

Clash設定を複数安定して管理するには、「ソース、ファイル、実行状態」を対応付けることが重要です。読み込み時に名前を明確にし、切り替え後はポートとプロキシグループを確認し、更新前にはロールバック用コピーを保存します。ローカル編集は上書き機能または独立したProfileで保持しましょう。設定が増えても、現在のコアがどの内容を読み込んでいるかをすぐ判断できます。

名前に用途、提供元、更新方法を含める。
リモート購読とローカルのテスト設定を分けて保存する。
切り替え後にコア、ポート、プロキシグループ、接続ログを確認する。
自動更新される購読キャッシュを長期的なカスタマイズの直接編集先にしない。
大きな変更の前に、日付付きの動作確認済みコピーを保存する。
整理するときは先にメイン設定へ切り替え、その後で古い項目を削除する。