Clashの設定ファイルとは？Profileの構造入門と複数設定の管理

Clash Profileには何が保存されるのか

ClashクライアントのProfileは、通常「設定」または「設定ファイル」と呼ばれます。単なるノード一覧ではなく、プロキシコアの待受ポート、DNSの解決、ノードの構成、プロキシグループの作成、通信ルールの振り分けを定義する構造化ドキュメントです。従来のClash、Clash Meta、後継のmihomoコアでは主にYAML形式を使用しますが、GUIクライアントによっては、選択中のポリシー、サブスクの更新日時、画面設定などをYAMLとは別に保存します。

起動可能な基本設定には通常、待受ポート、動作モード、プロキシノード、プロキシグループ、ルールが含まれます。mihomoでは、TUN、sniffer、rule-providers、proxy-providersなどの拡張フィールドが加わることもあります。クライアントはProfileを読み込むとYAMLを解析し、有効な内容をコアプロセスに渡します。インデントの誤り、フィールド型の不一致、存在しないプロキシグループの参照などがあると、読み込みが停止する場合があります。

主なフィールド	役割	代表的な内容
`mixed-port`	HTTPとSOCKSの混合プロキシ入口を提供	`7890`
`mode`	ルール、グローバルプロキシ、または直接接続のどれで通信を処理するかを決める	`rule`
`proxies`	静的なプロキシノードの定義を保存	ノード名、サーバー、ポート、プロトコルのパラメーター
`proxy-groups`	手動選択、自動速度テスト、フェイルオーバーのポリシーを構成	`select`、`url-test`、`fallback`
`rules`	ドメイン、IP、プロセス、ルールセットを上から順に照合	`DOMAIN-SUFFIX`、`IP-CIDR`、`MATCH`
`dns`	DNSの待受、上流サーバー、名前解決モードを制御	`fake-ip` または `redir-host`

次の簡略化した例では、フィールド同士の参照関係を示しています。ルールの最後の項目は、必ず存在するプロキシグループを指定してください。たとえばルール内の「ノード選択」は、proxy-groups内の名称とスペースや大文字・小文字まで完全に一致している必要があります。

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

proxies:
  - name: "ノード A"
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "ノード A"
      - DIRECT

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

サブスク設定とローカル設定の違い

サブスク設定は、リモートURLから取得します。クライアントがそのアドレスへHTTPリクエストを送り、サーバーがClash YAMLを返すと、クライアントはローカルコピーとして保存して読み込みます。サブスクURL自体がアクセス認証情報にあたるため、ログやスクリーンショット、公開リポジトリに貼り付けるとアカウント情報が漏れるおそれがあります。日常の管理ではパスワードと同じように扱ってください。

ローカル設定は、ユーザーが直接インポートまたは編集するYAMLファイルです。「サブスクを更新」をクリックしても自動では変わらないため、自作ノード、固定ルール、検証用設定、オフライン環境に適しています。どちらも最終的にはコアが読み込めるYAMLになりますが、取得元、更新方法、上書きの挙動が異なります。

比較項目	サブスク設定	ローカル設定
内容の取得元	リモートのサブスクサービスから返される内容	ローカルファイルまたは手動編集
更新方法	定期または手動でURLへ再リクエスト	ファイルを直接変更して再読み込み
リモート側による上書き	更新時にダウンロード済みコピーを置き換えるのが一般的	サブスク更新の影響を受けない
適した用途	ノードが頻繁に変わり、サービス側で一元管理される場合	固定ルール、検証用設定、自前サービス

サブスクYAMLを直接編集すると内容を失いやすい理由

多くのクライアントでは、現在のサブスクのキャッシュファイルを開いて編集できます。しかし次回の更新ではドキュメント全体が再ダウンロードされるため、手動で追加したルール、DNSパラメーター、プロキシグループが上書きされます。クライアントが旧ファイルを残していても、新しいProfileに別の内部IDが付与され、編集内容が使われなくなることがあります。

カスタム内容を長期保存したい場合は、クライアントの上書き、スクリプト、マージ機能を優先して使いましょう。クライアントによってメニュー名は異なりますが、「設定」→「上書き」、「Profiles」→「Merge」、設定カード右側の編集メニューなどが一般的です。mihomo対応クライアントでは、DNS、ルール、TUNフィールドの上書きに対応している場合もあります。利用前にマージ順を確認してください。同名のスカラー値は後から書き込まれた値で上書きされるのが一般的ですが、配列を置き換えるか追加するかはクライアントの実装によって異なります。

更新と切り替えで実際に起きていること

手動更新と自動更新

設定カードの更新ボタンをクリックすると、クライアントは通常、「サブスクURLへリクエスト、レスポンスを確認、一時ファイルへ書き込み、YAMLを解析、旧キャッシュを置き換え、コアへ再読み込みを通知」という順で処理します。HTTPリクエストが成功しても、設定が利用可能とは限りません。ログインページやエラーメッセージ、不完全なYAMLが返った場合、ステータスコードが200でも解析段階で失敗します。

自動更新は、同じ処理をスケジュール実行するだけです。一般的な間隔は6、12、24時間で、サブスクのレスポンスに含まれる更新間隔を読むクライアントもあれば、「設定」→「設定」や「Profiles」ページで指定した固定周期を使うものもあります。ノートパソコンがスリープ中は通常タスクが実行されず、復帰後すぐに更新を補うかどうかはクライアントのスケジューラー次第です。

更新前に現在のProfile名と選択中のプロキシグループを記録し、更新後の変化の原因を確認できるようにします。
システム時刻が正しいことを確認します。時刻のずれが大きいと、HTTPS証明書の検証に失敗することがあります。
更新後はノード数、プロキシグループ名、最終更新日時を確認し、「リクエスト成功」だけで判断しないでください。
コアのログを開き、yaml、parse、proxy groupなどのエラーがないことを確認します。
通常のHTTPSページでルールのマッチを確認し、次にプロキシが必要な接続先をテストします。遅延の数値だけを頼りにしないでください。

Profileの切り替えはノードだけを交換する操作ではない

設定一覧で別のProfileを選択すると、クライアントはコアに設定全体を再読み込みさせます。待受ポートが7890から7897に変わったり、DNSモードがfake-ipからredir-hostに変わったりするほか、TUN、ルーティングルール、プロキシグループも同時に変化する可能性があります。切り替え後に「ブラウザーは使えるのにターミナルはつながらない」「システムプロキシが旧ポートを指している」といった症状が出たら、まずポートと通信の取り込みモードを確認してください。

システムプロキシは、OSに設定されたプロキシアドレスにすぎません。たとえばProfileでmixed-port: 7890を使う場合、クライアントは通常、システムのHTTPおよびHTTPSプロキシを127.0.0.1:7890に設定します。新しい設定が7891に変わったのにGUIクライアントがシステムプロキシを同期更新しなければ、アプリは旧ポートへ接続し続けます。いったんシステムプロキシを無効化してから有効化し、クライアントにアドレスを書き直させてください。

TUNモードは、より広い範囲に影響します。mihomoは仮想ネットワークインターフェースを作成し、ルーティング条件に合う通信を取り込みます。DNSハイジャック、厳格ルーティング、自動ルートのパラメーターは、現在の設定またはクライアントの上書き設定に由来します。Profileを切り替えた後は、「設定」→「ネットワーク」または「設定」→「TUNモード」で状態を確認してください。macOSでは、ネットワーク拡張機能や管理者権限の再確認を求められることもあります。

複数設定を併用する際の命名と分類方法

複数のサブスクを同時に使う場合、最も起こりやすい問題は設定数ではなく、名前だけでは判別できなくなることです。「サービスA」「予備」や自動生成されたランダムなファイル名だけでは、数か月後に用途、取得元、更新方法を判断しにくくなります。名前には、その時点の一時的な状態ではなく用途を表す情報を入れましょう。

4要素の名前を使う

用途-取得元-プラットフォーム-更新方法

仕事-サービスA-macOS-自動12h
個人-サービスB-全プラットフォーム-手動
テスト-ローカルルール-mihomo-固定
緊急用-サービスC-iOS-自動24h

「用途」は仕事、個人、テスト、緊急用などを区別します。「取得元」には識別しやすい略称だけを使い、完全なサブスクURLは名前に入れません。「プラットフォーム」には特定OS向けのルールを含むかどうかを示し、「更新方法」には設定が自動で変化するかどうかを記します。クライアントの表示文字数に制限がある場合はWork-A-Mac-12hのように短縮できますが、すべての設定で同じ順序を保ってください。

すべてのノードを1つのファイルに詰め込まない

複数の取得元を巨大なYAMLにまとめると便利そうに見えますが、実際には名前の重複、ルールの上書き、更新の難しさを招きます。2つのサブスクに「自動選択」「香港ノード」といった同名項目が含まれることもあります。マージツールに安定した名前変更ルールがなければ、プロキシグループが誤ったノードを参照します。ノードが数百個に達すると、速度テストのリクエストも短時間に大量の接続を発生させます。

より整理しやすい方法は、Profileを分けて管理し、取得元をまたいで選択したい場合だけproxy-providersを使うことです。mihomoのproviderは複数のリモートファイルからノードを読み込み、メイン設定からuseで参照できます。これにより、メイン設定はルールとポリシーを担当し、ノードの取得元は独立して更新できます。

proxy-providers:
  provider-a:
    type: http
    url: "https://subscription.example/provider-a.yaml"
    path: ./providers/provider-a.yaml
    interval: 43200
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "自動選択"
    type: url-test
    use:
      - provider-a
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

例のinterval: 43200はproviderを12時間ごとに更新する設定です。ヘルスチェックは600秒ごと、プロキシグループは300秒ごとに遅延を再評価します。間隔を短くしすぎるのは避けてください。ノードが多い場合、60秒ごとの全件テストは接続数とバッテリー消費を増やします。モバイル端末では、ポリシーの評価間隔を600〜1800秒に調整するとよいでしょう。

バックアップと復元で残すべきもの

設定のバックアップで重要なのは、アプリのディレクトリ全体をコピーすることではなく、動作環境を再構築できる必要な資料を保存することです。クライアントごとにディレクトリ構成やデータベース形式はバージョンによって変わるため、アプリのデータディレクトリをそのまま上書きすると、旧バージョンの状態を新バージョンへ持ち込むおそれがあります。読みやすいYAML、サブスクの取得元情報、重要な設定の記録を併せて保管する方法がより確実です。

バックアップを推奨する5種類の資料

ローカルYAML：手書きのメイン設定、上書きファイル、カスタムルール、provider定義を含めます。
サブスク一覧：サービス名、用途、更新周期を記録します。サブスクURLは、保護されたパスワード管理ツールに保存してください。
クライアント設定：システムプロキシ、TUN、起動時実行、LAN接続の許可、ポート設定を記録します。
バージョン情報：GUIクライアントとコアのバージョンを記録します。たとえばクライアント2.0.0、mihomov1.19.xのように残すと、フィールドの互換性を再現しやすくなります。
復元手順：インポート順、デフォルトProfile、よく使うプロキシグループ、必要なシステム権限の手順を記載します。

バックアップファイルはclash-profile-backup-2026-07-09のように日付で整理できます。DNS、TUN、ルールを大きく変更する前にバージョンを保存し、work-mac-before-tun-change.yamlのように用途をファイル名へ加えましょう。YAMLはGitで差分を管理するのに向いていますが、サブスクURL、認証パラメーター、非公開サーバー情報を含むファイルは、アクセス制限されたプライベートリポジトリだけに保存してください。

復元時にすべての機能を一度に有効化しない

元の環境と互換性のあるクライアントバージョンをインストールし、まずシステムプロキシとTUNを無効にしておきます。
YAMLをインポートし、コアが起動できること、ログにフィールド解析エラーがないことを確認します。
ノードを1つ手動で選択し、127.0.0.1:7890を使ってローカルプロキシポートをテストします。
システムプロキシを有効にし、システムプロキシに従うブラウザーやアプリを確認します。
最後にTUNを有効にし、DNS、LANアクセス、スリープから復帰した後のネットワーク状態を確認します。

段階的に復元すれば、問題がProfile、ノード、システムプロキシ、TUNのどこにあるかを特定できます。インポート直後にすべての機能を有効にすると、通信が途切れた際にDNS、ルーティング、接続のエラーが同時にログへ出力され、最初の失敗箇所を判断しにくくなります。

よくあるProfileの問題と切り分け方

設定を更新したのにノード一覧が変わらない

まず、名前が似た別の設定ではなく、現在有効なProfileを更新していることを確認します。次に更新日時とサブスクのレスポンス内容を確認してください。リモートから新しいノードが返っているのに画面が古い一覧のままなら、別のProfileへ切り替えてから戻すか、コアを再起動して再読み込みさせます。それでも変わらない場合は、固定の上書き設定やproviderキャッシュが有効になっていないか確認します。

YAMLをインポートすると解析エラーになる

YAMLではスペースで階層を表し、Tabインデントには依存できません。リスト項目の先頭にあるハイフン、コロンの後のスペース、特殊文字を含むノード名、重複フィールドを重点的に確認します。エラーログに行番号がある場合は、その行から上へ1つのまとまったブロックを確認してください。インデントの本当の原因は数行前にあることがよくあります。

# 正しい例：proxies は配列
proxies:
  - name: "ノード A"
    type: socks5

# 誤った例：リスト項目とフィールドの階層が一致していない
proxies:
 - name: "ノード A"
    type: socks5

設定を切り替えると、すべてのWebサイトが直接接続になる

modeがdirectになっていないか、ルールの末尾がMATCH,DIRECTになっていないか、接続先ドメインが直接接続ルールにマッチしていないかを確認します。mihomoのログには接続先、マッチしたルール、最終ポリシーが表示されます。ログに新しい接続がまったくない場合、問題は通常ルールではなく、システムプロキシ、アプリのプロキシ設定、またはTUNによる取り込みにあります。

再起動するたびにプロキシグループの選択が元に戻る

従来の設定フィールドprofile.store-selected: trueを使うと、対応するコアでプロキシグループの選択を保存できます。mihomoにもProfileの永続化に関する設定があります。ただし、GUIクライアントがこの状態を管理していたり、更新のたびに新しい設定IDを生成したりする場合があります。永続化を有効にするだけでなく、プロキシグループ名を安定させ、サブスク変換時に日付やノード数が自動追加されないようにすることも重要です。

profile:
  store-selected: true
  store-fake-ip: true

初心者向け管理手順：まずは1つの設定から

使い始めたばかりなら、複数のサブスクをすぐに統合したり、複雑なルールを書いたりする必要はありません。まずメインで使うサブスクを1つだけ残し、更新、ノード切り替え、システムプロキシ、ログ確認が正常に動くことを確かめます。2つ目の設定は緊急用として、分かりやすい名前を付けて区別しましょう。取得元をまたいでノードを選ぶ必要が出てから、providerや上書き機能を導入すれば十分です。

日常の操作は、短い手順に固定できます。週に1度サブスクの更新日時を確認する、設定更新後にノード数とプロキシグループを確認する、ルール変更前にローカルYAMLをコピーする、Profile切り替え後にポートと取り込みモードを確認する、クライアント更新後にコアのバージョンを記録する、という流れです。こうすれば「突然つながらない」という問題を、何度も削除して再インポートするのではなく、検証可能ないくつかの段階に分けられます。

Profile管理の要点は、3層の内容を分けることです。リモートで管理されるサブスク、端末に長期保存するルール、クライアントが記録する実行状態です。サブスクは変化するノードを提供し、ローカル設定は安定したルーティング方針を表し、クライアントの状態は現在の選択を記憶します。3つを分けて管理すれば、複数設定の併用、自動更新、端末移行をより簡単に制御できます。