Profile、config.yaml、実行時設定

Profileは、クライアントが管理する設定一式です。ローカルのYAMLファイルから追加することも、リモートのサブスクリプションURLから取得することもできます。設定内容に加えて、名前や取得元、更新日時などの管理情報が含まれるのが一般的です。Profileの切り替えは、設定の取得元や内容を切り替える操作であり、クライアントの再インストールやOSのネットワーク設定変更ではありません。

config.yamlはよく使われる設定ファイル名ですが、すべてのProfileに共通する固定の識別名ではありません。Clashやmihomoのコアを直接起動する場合は、読み込む設定ファイルを指定できます。Clash Nyanpasuでは、サブスクリプションの内容、クライアントの設定、オーバーライド処理を組み合わせて、コアに渡す実行時設定を生成する場合があります。そのため、設定一覧に表示される元の内容と、コアが最終的に読み込む内容は一致するとは限りません。

対象主な内容確認場所
Profile名前、取得元、設定本文、管理情報クライアントの「プロファイル」画面
元のYAMLプロキシ、プロキシグループ、ルールなどの設定項目設定エディターまたはエクスポートした元ファイル
実行時設定クライアントで処理され、コアに渡される設定項目実行時設定の確認画面とコアのログ
クライアント設定システムプロキシの切り替え、画面オプション、クライアントの管理用設定クライアントの「設定」画面

トラブルシューティングでは、まずどの層を変更したのかを確認します。元のYAMLを変更しても反映されない場合、再読み込みされていないか、同名の項目がクライアント設定やオーバーライドで置き換えられている可能性があります。一時生成された実行ファイルを編集してその場では反映されても、次回の切り替え・更新・再起動時に再生成されることがあります。

ローカル設定、リモートサブスクリプション、オーバーライドの役割

ローカル設定：内容を固定して再現しやすくする

ローカル設定は、ルールの検証、問題の再現、オフラインでの保存に適しています。インポート後に、クライアントがファイルの内容をコピーしているのか、元ファイルへの参照を保持しているのか確認しましょう。デスクトップ上の元ファイルを編集すればクライアントにも反映されるとは限りません。名前を変えて再インポートし、内容を比較すると、クライアントの管理方法を確認できます。

リモートサブスクリプション：定期的に取得する設定

リモートProfileには通常、サブスクリプションURLが保存され、手動または定期的な更新時に設定を再取得します。サブスクリプションから完全なClash YAMLが返される場合は、proxies、proxy-groups、rulesなどが含まれることがあります。ノードURIだけのテキストは、完全なClash設定ファイルとは異なります。拡張子を.yamlに変えるだけでは変換できません。

リモートProfile内のノードやルールを直接編集する場合は、次回の更新に注意が必要です。更新時に取得元の内容で置き換えられると、手動で加えた変更も失われます。個人用ルールを長く維持するには、独立して管理するオーバーライド層に追加するか、サブスクリプションをローカルProfileとして保存して編集します。後者では、元のサブスクリプションの変更が自動反映されなくなります。

オーバーライド：個別の変更を維持する

オーバーライドを使うと、入力設定に項目を追加したり、既存の項目を調整したりできます。たとえば、LAN向けの直接接続ルールを追加したり、ログレベルを統一したりできます。利用できるマージ方法、スクリプトのインターフェース、処理順序、適用範囲はクライアントのバージョンによって異なります。他のクライアント用スクリプトがClash Nyanpasuでも使えるとは限らず、リスト形式の項目が必ず追加マージされるとも限りません。

動作を確認できるローカルProfileを作成する

以下のYAMLは、インポート、切り替え、ルールの読み込みを確認するためのものです。プロキシサーバーは含まれていません。UTF-8でlocal-check.yamlとして保存し、「プロファイル」画面からローカルファイルをインポートして追加します。そのProfileを選択し、読み込み状態を確認してください。インポート項目の名称はバージョンによって異なる場合があるため、現在の画面にあるファイルのインポート操作を利用してください。

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

proxy-groups:
  - name: Local-Choice
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN,example.com,DIRECT
  - MATCH,Local-Choice
  • mixed-port: 7890は、この例でHTTPとSOCKSに共用するポートを指定しています。すべてのクライアントバージョンにおけるデフォルトポートではありません。
  • allow-lan: falseはLANからの接続を制限します。この例をLANで共有するプロキシ設定として使わないでください。
  • mode: ruleはルールモードを指定します。モードをクライアント側で管理している場合は、画面上の現在値と最終的な実行時の値を確認してください。
  • Local-Choiceには、組み込みの接続先としてDIRECTとREJECTのみが含まれます。インポートに成功しても、リモートプロキシが利用できるわけではありません。

読み込み後、プロキシグループ画面にLocal-Choiceが表示されることを確認し、DIRECTを選択します。ローカルのHTTPプロキシポートを確認する場合は、次のコマンドを実行できます。このテストはシステムプロキシの設定に依存せず、ブラウザーの全通信がプロキシ経由になることを示すものでもありません。

curl --proxy http://127.0.0.1:7890 --head https://example.com

コマンドの結果とあわせて接続ログも確認してください。example.comにはドメインの直接接続ルールが適用されるはずです。ポートへの接続が拒否された場合は、サブスクリプションを疑う前に、コアの起動状態と実際の待ち受けポートを確認してください。

複数Profileの命名と切り替え手順

取得元・用途・状態でProfileを見分ける

名前から設定の範囲が分かるようにします。「取得元－用途－状態」の形式がおすすめです。例：サブスクA－普段使い－安定、ローカル－ルール検証－テスト、サブスクB－予備－要確認。サブスクリプションURL全体やアカウントのトークンは名前に含めないでください。日付はバックアップファイル名に付けると、設定一覧に似た名前が毎日増えるのを防げます。

  1. 現在の状態を記録します。使用中のProfile、プロキシグループで選択中のノード、ルールモード、実際のポート、システムプロキシとTUNの状態を控えます。たとえばポートが7890の場合、切り替え後に別のポートで待ち受けていれば、プロキシを手動設定しているアプリも変更が必要です。
  2. 切り替え先のProfileを確認します。リモートProfileは一度更新し、設定を正常に取得できたことを確認します。ローカルProfileでは、YAMLのインデントとルールの接続先を確認し、参照先のプロキシグループが存在することを確かめてください。
  3. Profileを切り替えます。「プロファイル」画面で切り替え先を選び、クライアントの読み込みが完了するまで待ちます。コアのログに構文エラー、未対応項目、ポートの競合が出ていないか確認してください。
  4. プロキシグループを選び直します。2つのProfileに「プロキシ」という名前のグループがあっても、含まれるメンバーは異なる場合があります。グループ名だけで判断せず、現在選択されているノードを確認してください。
  5. 新しい接続で動作を確認します。新たにWebページへアクセスし、接続ログに表示されるルール、プロキシの経路、接続先を確認します。Profileのカードが選択状態になっているだけでは、通信経路が正しいとは判断できません。

Profileの切り替えは通常、その後に作成される接続に適用されます。確立済みの接続がすぐに切り替わるとは限りません。厳密に確認するには、テスト対象のアプリを終了して再起動するか、クライアントに接続を終了する機能があれば利用してください。接続を終了するとダウンロード、会議、長時間接続が中断されるため、先に作業を保存してください。

複数Profile、複数ノード、TUNの違い

1つのProfileに複数のノードを含め、selectやurl-testなどのプロキシグループで管理できます。ノードAからノードBに切り替えるだけなら、通常は新しいProfileを作る必要はありません。ルール一式、DNS設定、サブスクリプションの取得元を変える場合は、Profileの切り替えを検討してください。

一般的なデスクトップクライアントの1つのインスタンスは、通常、現在のコアに1つの実行時設定を渡します。リストにProfileが3つ並んでいても、3つのルールが自動で同時に適用されるわけではありません。複数の取得元を組み合わせる場合は、対応が明示されている設定の合成機能を使い、ノード名、プロキシグループ名、ルールの接続先が競合しないか確認してください。

通信の取り込みと設定の選択は別の機能

  • システムプロキシ：OSのプロキシ設定に従うアプリに影響します。独自のプロキシ設定を使うアプリや、システムプロキシを参照しないアプリもあります。
  • TUNモード：仮想ネットワークインターフェースと関連するルーティングを使って通信を取り込みます。OSの権限に加え、DNSとルートの適切な設定が必要です。
  • Profile：コアが接続を処理するためのノード、ルール、関連パラメーターを指定します。前述の通信取り込み機能とは別のものです。

Profileを切り替えても特定のアプリが直接接続する場合は、まずそのアプリの通信がコアの接続ログに記録されているか確認してください。記録がなければ通信の取り込み方法を優先して確認します。記録があるのに接続先が誤っている場合は、モード、ルールの順序、プロキシグループの選択を確認してください。ルールの適用問題を解決するためだけにTUNを何度もオン・オフしないでください。

オーバーライドの最小限の変更と互換性チェック

長期間使うオーバーライドは、適用範囲を狭くし、対象を明確にします。たとえば、サブスクリプション全体を複製して項目ごとに置き換えるのではなく、LAN向けの直接接続ルールを1つだけ追加します。ルールの接続先には、存在を確認したプロキシグループ名を指定してください。Profileごとにグループ名が異なる場合は個別に設定するか、処理時に接続先の存在を明示的に確認します。

# rulesリストの先頭に追加し、MATCHの後ろには置かない
- IP-CIDR,192.168.50.0/24,DIRECT,no-resolve

これはルールの一部であり、単独でインポートできる完全なProfileではありません。例のネットワーク範囲192.168.50.0/24だけに適用されます。実際のLANが192.168.1.0/24の場合は、ルーティングテーブルに合わせて変更してください。no-resolveは、このIPルールの判定時にドメイン名の解決を明示的に行わない指定です。すべてのDNS問い合わせを無効にするものではありません。

  1. 安定版Profileのコピーで先にテストし、元のProfileは切り戻し用に残します。
  2. 一度に変更する項目の種類は1つにします。たとえば、まずルールを変更し、次にDNSを変更します。ポートとTUNを同時に変更しないでください。
  3. 最終的な実行時設定を確認し、各項目の値、リストの順序、ルールの接続先が想定どおりであることを確かめます。
  4. サブスクリプションを更新した後にも確認し、個人用の変更がオーバーライドによって安定して反映されることを確かめます。

Clash、Clash Meta（mihomo）および各バージョンでは、対応する設定項目が完全には一致しません。「不明な項目」や未対応のルール形式が表示されたら、まずコアの名称とバージョンを記録し、YAMLリファレンスで互換性を確認してください。Profileのファイル名を変えるだけでは、コアの機能差は解決できません。

設定のバックアップと復元の手順

バックアップするのはYAMLだけではない

復元できるバックアップには、設定本文、オーバーライドの内容、必要なクライアント設定の記録を含めます。リモートURLも保存しますが、別途暗号化して保管してください。サブスクリプションURLだけでは、提供元が後から削除したノードを保持できません。元のYAMLだけを保存した場合は、実際に適用されている個人用オーバーライドが抜けることもあります。

  • 元の設定：安定版Profileを、たとえばlocal-check-2026-09-27.yamlとしてエクスポートします。
  • オーバーライドと適用先：スクリプトやルールの断片と、それぞれを適用するProfileの説明を保存します。
  • 環境情報：クライアントとコアのバージョン、待ち受けポート、システムプロキシとTUNの状態を記録します。
  • 機密情報：サブスクリプションのトークン、ノードのパスワード、コントロール用APIのキー、証明書などを確認し、公開リポジトリにアップロードしないようにします。

復元時は、まず元の設定をインポートして正常に解析できることを確認します。次にオーバーライドを戻し、最終的な項目を確認します。最後に必要に応じてシステムプロキシまたはTUNを有効にしてください。別のマシンに復元する場合、以前のマシンのネットワークインターフェース名、絶対パス、LANアドレスをそのまま流用しないでください。ルールセットやプロキシプロバイダーがリモート取得に依存する場合は、新しいマシンから関連データを取得できることも確認します。

よくある問題の確認手順

症状まず確認する項目対処方法
切り替え後も以前の設定のように見える読み込みログ、現在の実行ルール、既存の接続読み込みの成功を確認してから、新しい接続でテストする
サブスクリプション更新後にルールが消えるリモートの設定を直接編集していないか個人用の変更をオーバーライドまたはローカルProfileに移す
プロキシグループが見つからないと表示されるルールの接続先とグループ名が完全に一致しているか大文字・小文字、空白、更新後のグループ名を確認する
コアが起動しない最初の解析エラー、項目の互換性、ポートの競合安定版Profileに戻し、変更を1つずつ再適用する
一部のアプリだけ反映されない通信がコアに届いているか、アプリ独自のプロキシ設定まず通信経路を特定し、その後にルールの判定を確認する

安定した管理の基本は、切り戻せるProfileを残し、サブスクリプションの設定と個人の変更を分け、切り替え後に実行状態を確認することです。設定ファイルは通信の処理方法を定義し、クライアントは設定を整理して読み込み、システムプロキシやTUNは通信をコアへ送ります。この3つの層に分けて確認すると、サブスクリプションを何度も再インポートするより問題を特定しやすくなります。