Profileは切り替えて使う実行設定
ClashクライアントにおけるProfileとは、通常、カーネルが読み込める設定ファイルを指します。一般的にはYAML形式で、待ち受けポート、プロキシノード、プロキシグループ、ルール、DNS設定、プロキシプロバイダー、ルールプロバイダーなどを含みます。クライアントでProfileを選択すると、そのファイルを解析し、有効な設定をClashまたはmihomoカーネルに渡します。
Profileは単一のノードと同じ意味ではありません。ノードは設定内の接続項目であり、プロキシグループは複数のノードや内蔵ポリシーをまとめます。ルールはドメイン、IP、プロセスなどの条件に応じて、リクエストを適切なプロキシグループへ振り分けます。ノードの切り替えでは通常、あるプロキシグループで選択中のメンバーだけが変わります。一方、Profileを切り替えると、ノード一覧、ルールの順序、DNSモード、ポート、TUNパラメーターまで同時に変わる場合があり、影響範囲はより大きくなります。
クライアントによってProfileの呼び方は異なり、「設定」「サブスクリプション」「設定ファイル」「Profiles」などと表示されます。画面上の名称が違っても、基本的な関係は共通しています。クライアントが設定の入手元を保存し、カーネルが現在の設定を読み込み、ユーザーがプロキシグループで具体的な出口を調整します。
| 対象 | 主な内容 | よく使う操作 |
|---|---|---|
| Profile | ポート、DNS、ノード、プロキシグループ、ルール | インポート、更新、切り替え、コピー |
| プロキシグループ | 複数のプロキシノードまたは内蔵ポリシー | 手動選択、自動テスト、フェイルオーバー |
| ノード | サーバーアドレス、ポート、プロトコルパラメーター | 遅延テスト、出口の選択 |
| ルール | リクエストのマッチ条件と適用先ポリシー | 順序の調整、ドメインやルールセットの追加 |
設定の入手元で更新方法が決まる
Profileの入手元には、サブスクリプションURLからのインポート、ローカルYAMLファイルからのインポート、クライアント上で作成またはコピーして自分で管理する方法の3種類があります。入手元によって、その後の更新動作も変わります。複数設定を構成する前に、それぞれがリモート管理かローカル管理かを確認しましょう。
サブスクリプションURLからインポート
サブスクリプションURLからは、リモート設定の内容が返されます。クライアントは通常、このURLを保存し、手動更新または設定した間隔での自動更新を可能にします。更新時にはリモートへ再度リクエストを送り、新しい内容で対応するキャッシュ版を置き換えます。ローカル変更を保持できるかはクライアントの実装によるため、更新で上書きされるリモート設定にルールを恒久的に直接書き込むのは避けてください。
サブスクリプションURLにはアカウント識別情報が含まれる場合があるため、機密情報として扱いましょう。公開スクリーンショット、公開コードリポジトリ、共有ドキュメント、障害ログなどにURLを記載しないでください。別のデバイスへインポートする場合は、信頼できる経路で共有し、使わなくなったデバイスから該当設定を削除します。
ローカルYAMLファイルをインポート
ローカルファイルは、テスト、自作ルール、オフラインバックアップに適しています。クライアントによってはファイル内容を自身の設定ディレクトリへコピーするため、元ファイルを編集しても自動同期されません。一方、指定パスを直接参照するクライアントもあります。インポート後に識別しやすい説明フィールドやルールを変更して再読み込みし、実際に読み込まれているのがコピーなのか元のパスなのかを確認しましょう。
設定を手動作成またはコピー
既存のProfileをコピーして調整する方法は、安定版を残しながら新しいルールを試すのに適しています。例えば「日常・安定版」をコピーして「DNSテスト」を作り、DNSと関連ルールだけを変更します。テストに成功してから、その変更を長期利用する設定へ統合するか判断します。これにより、唯一の利用可能な設定を何度も直接編集する事態を避けられます。
Profile切り替え後は階層ごとに反映を確認
画面上でProfileを選択しても、クライアントがその設定を使う準備をしただけです。本当に反映されたかは、設定解析、カーネルの稼働、システムトラフィックの入口という3つの階層で確認する必要があります。安全な切り替え手順は、現在の作業を保存し、対象Profileを選択し、解析完了を待ち、プロキシグループの状態を確認してから、システムプロキシまたはTUNを確認することです。
- 対象設定を選択：Profile一覧で使用する項目を選び、現在のマークが対象設定へ移動したことを確認します。
- 読み込み結果を確認：YAML構文、フィールドの互換性、ポート競合、プロキシプロバイダーのダウンロード失敗に関する表示がないか確認します。
- プロキシグループを確認：必要なプロキシグループが存在し、現在のノードが利用可能か確認します。異なる設定に同名のプロキシグループがあっても、含まれるノードはまったく異なる場合があります。
- 実行モードを確認：Rule、Global、Directのいずれかを確認します。日常的な振り分けには通常Ruleを使います。Globalでは大部分のリクエストがグローバルポリシーへ送られ、Directでは直接接続します。
- トラフィックの入口を確認：ブラウザーなどシステムプロキシに従うプログラムでは、システムプロキシが正しく有効になっている必要があります。システムプロキシを参照しないプログラムでは、通常TUNまたはアプリ自身のプロキシ設定が必要です。
- 接続を確認：直接接続する宛先、プロキシ経由の宛先、DNS解決を個別にテストし、ノードの遅延だけで設定全体の反映を判断しないようにします。
待ち受けポートが異なるProfileへ切り替える場合は、システムプロキシに保存されたポートも一致させる必要があります。例えば、旧設定が mixed-port: 7890、新設定が mixed-port: 7897 なのに、システム側が旧ポートを指していると、アプリは接続できないように見えることがあります。クライアントによってはシステムプロキシのポートを自動同期しますが、切り替え後に一度確認することをおすすめします。
mixed-port: 7890
mode: rule
allow-lan: false
dns:
enable: true
ipv6: false
nameserver:
- 1.1.1.1
- 8.8.8.8この例は設定の階層だけを示したもので、完全なProfileではありません。実際の設定は、使用するカーネルのバージョン、ノードのプロトコル、ルール構成、ローカルネットワークの条件に合わせる必要があります。YAMLではスペースで階層を表すため、Tab文字、インデントのずれ、重複フィールドが読み込み失敗の原因になることがあります。
複数設定は用途・入手元・状態で命名する
設定が増えた後に起きやすい問題は、ファイルがないことではなく、どれを使用中でどれを更新できるのか分からなくなることです。「設定1」「新設定」「最終版」のような名前だけでは、障害時にすぐ切り戻せません。少なくとも用途と入手元を名前に含め、必要に応じて状態や日付も付けましょう。
| 命名例 | 用途 | 管理方法 |
|---|---|---|
| 日常・リモートサブスクリプション | 通常のブラウジングとルール振り分け | 定期的に更新 |
| 日常・安定バックアップ | リモート更新時の切り戻し | ローカル保存、自動更新なし |
| 開発・TUN | コマンドラインとシステムプロキシを参照しないアプリ | TUNパラメーターをローカル管理 |
| ルールテスト・一時用 | 新しいルールとDNS変更の検証 | テスト完了後にアーカイブまたは削除 |
日常利用では、大量の重複コピーを保存する必要は通常ありません。メインで使うリモート設定、検証済みのローカル安定バックアップ、用途別に少数のテスト設定を残せば、ほとんどの切り替えと切り戻しに対応できます。コピーが多すぎると、プロキシグループの選択、更新日時、サブスクリプションの入手元が分かりにくくなります。
システムプロキシ設定とTUN設定を分ける
システムプロキシは、OSのプロキシ設定に従うアプリへ主に影響し、構成も比較的シンプルです。TUNモードでは仮想ネットワークインターフェースを作成して、より広い範囲のトラフィックを引き受けます。ルーティング、DNSリダイレクト、インターフェースの自動検出、権限なども関係します。2つのモードを頻繁に切り替える場合は、Profileを分けて管理し、毎回複数のパラメーターを手動変更するのを避けましょう。
mihomoカーネルを使用する場合、TUN設定には stack、auto-route、auto-detect-interface、DNSリダイレクトなどのフィールドが含まれることがあります。対応状況はカーネルのバージョン、OS、クライアントの権限によって異なります。あるプラットフォーム向けのTUN部分を別のプラットフォームへそのままコピーすると、インターフェース選択の誤り、LANアクセスの異常、DNS経路の変化が起きる可能性があります。
検証済みの切り戻しポイントを1つ残す
安定バックアップは、実際に正常動作した設定から作成してください。ダウンロードしただけで未使用のファイルをバックアップにするのは避けます。バックアップ時には作成日、カーネルの種類、適用する用途を記録します。サブスクリプションの内容に異常がある場合、ルールプロバイダーへ接続できない場合、新バージョンのフィールドに互換性がない場合は、まず安定設定へ切り替えて接続を復旧し、その後で更新内容を個別に確認できます。
サブスクリプション更新とローカル変更を分けて扱う
リモートサブスクリプションでは、ノード、プロキシグループ、ルールを提供元が一括更新できる一方、更新によってProfileへ直接書き込んだ変更が上書きされることがあります。更新とカスタマイズを両立させるには、「リモートで生成される内容」と「ローカル固有の内容」を分離して管理します。
方法1：クライアントのオーバーライド機能を使う
一部のクライアントは、オーバーライド、ミックスイン、スクリプト処理に対応しています。リモート設定をダウンロードした後で、指定したフィールドを追加・変更できます。例えば、ポートの統一、LANアクセスの有効化、ルールの追加、DNS設定の置き換えなどです。オーバーライドの構文はすべてのClashクライアントに共通する標準ではないため、クライアントを移行する前にエクスポートして形式を確認してください。
方法2：proxy-providersとrule-providersを使う
mihomoでは、プロキシプロバイダーとルールプロバイダーを使って外部コンテンツを分けて管理できます。メイン設定ではポート、DNS、プロキシグループ、ルールの順序を管理し、プロバイダーではURLまたはファイルパスからノードやルールセットを読み込みます。これにより、メイン設定全体を置き換えずに外部データだけを更新できます。
proxy-providers:
remote-nodes:
type: http
url: "https://example.invalid/subscription"
path: ./providers/remote-nodes.yaml
interval: 3600
health-check:
enable: true
url: "https://www.gstatic.com/generate_204"
interval: 600
proxy-groups:
- name: PROXY
type: select
use:
- remote-nodes例のアドレスには名前解決できない予約ドメインを使用しており、構造の説明だけを目的としています。実際に使う場合は、有効な入手元を入力し、返される内容がプロキシプロバイダー形式に適合することを確認してください。完全なサブスクリプション設定とproviderファイルの構造は必ずしも同じではありません。任意のサブスクリプションURLを proxy-providers に入れれば解析できるとは限りません。
方法3：完全なローカル設定を管理する
ルールの順序、DNS経路、TUNの動作を細かく制御したい場合は、完全なローカルYAMLを管理し、ノード部分を手動で更新できます。この方法は管理範囲が明確になる一方、保守の負担も増えます。変更するたびにまず設定を検証してから現在のProfileへ切り替え、未検証のファイルで安定版を直接置き換えないでください。
インポート失敗と切り替え異常の確認手順
Profileの問題は、「入手元へのアクセス—ファイル解析—カーネルの稼働—システムによる引き受け—ルールのマッチ」という順番で確認できます。階層ごとに切り分けるほうが、何度も削除して再インポートするより効果的で、エラー発生時の状態も残せます。
サブスクリプションをインポートしても一覧が空
- サブスクリプションURLが有効か確認し、クライアントにHTTPステータスやタイムアウト情報が表示されていないか確認します。
- 返された内容がClashで読み込めるYAMLであり、ログインページ、エラーメッセージ、別クライアント専用形式ではないことを確認します。
- システム時刻を確認します。時刻が大きくずれていると、証明書の検証、サブスクリプションの有効期限、リモートリクエストに影響する場合があります。
- 現在のネットワークからサブスクリプションの入手元へアクセスできない場合は、まず既存の安定Profileで接続を確立してから更新します。
設定はインポートできるが切り替えられない
- ログに表示される具体的なフィールドと行番号を確認し、YAMLのインデント、配列形式、重複キーを重点的に調べます。
- 設定で使用しているフィールドが、現在のカーネルでサポートされているか確認します。mihomo向けに記述された拡張フィールドは、古いClashカーネルでは受け付けられない場合があります。
- 待ち受けポートが別のプログラムや、別のカーネルインスタンスに使用されていないか確認します。
- ルールが参照するプロキシグループが存在し、名前の大文字・小文字や文字が完全に一致しているか確認します。
- 外部providerファイルのダウンロードが成功しているか、パスに書き込み可能か、内容形式が対応する種類に適合しているか確認します。
切り替えは成功したがアクセス経路が変わらない
- クライアント画面で現在のProfileのマークが変わっていることを確認し、カーネルの再読み込みが完了しているか確認します。
- システムプロキシのアドレスが新しいProfileの待ち受けポートと一致しているか確認します。
- 現在の実行モードがDirectになっていないことを確認し、対象リクエストが最終的にどのルールへマッチしたかを調べます。
- TUN使用時は、仮想インターフェース、ルーティング、権限の状態を確認します。TUNを無効にした後も、残ったシステムプロキシを個別に確認してください。
- ブラウザーやアプリが既存の接続を再利用している可能性があります。切り替え後に関連する接続を閉じるかアプリを再起動してからテストします。
再現可能な日常設定の手順を作る
管理しやすい手順は、インポート、命名、確認、有効化、テスト、バックアップの6段階にまとめられます。初回インポート時に入手元と用途を記録し、読み込み前に構文と互換性を確認します。有効化後は、プロキシグループ、DNS、ルールのマッチ、トラフィックの入口を個別に検証し、安定したことを確認してからローカルの切り戻し版を作成します。
リモート設定を更新するときは、ノード数の変化だけを確認してはいけません。主要なプロキシグループ名、ルールの順序、DNSモード、待ち受けポートも確認してください。これらはクライアントの既存の選択やシステム設定に直接影響します。更新後に異常が出た場合は、まず検証済みのProfileへ戻し、2つの設定の構造差分を比較します。
在宅勤務やネットワーク環境の切り替えが多いデバイスでは、「家庭・システムプロキシ」「モバイル回線・TUN」「開発環境・ローカルルール」のように用途別の設定を残すと便利です。各設定の役割を明確にし、できるだけ統一した命名規則を使います。ネットワークが変わっても、大量のフィールドを一時的に編集するのではなく、検証済みの用途別設定へ切り替えられます。
Profile管理で重要なのは、ファイルを増やすことではありません。それぞれの設定について、入手元、更新方法、適用場面、切り戻し先を判断できる状態にすることです。リモートサブスクリプションとローカル変更を分離し、ノード選択と設定一式の切り替えを区別したうえで、決めた順序で反映状態を確認すれば、複数設定でも分かりやすく運用できます。