Profileとサブスクリプションの関係

ClashクライアントのProfileとは、選択して読み込める設定ファイルのことです。リモートのサブスクリプションから取得する場合も、PC上のYAMLファイルを読み込む場合もあります。設定内容に加えて、取得元のURL、更新日時、更新間隔などのクライアント情報が記録されることもあります。実際にコアが読み込むのはクライアントが処理した後の設定であり、画面上の設定カードそのものではありません。

この違いを理解すると、混同しやすい3つの操作を区別できます。「インポート」は設定を一覧に追加すること、「更新」は設定内容を再取得すること、「有効化」は設定をコアに渡して実行することです。インポートに成功しても有効化されたとは限らず、ダウンロードに成功してもコアが新しい内容を受け付けたとは限りません。

対象保存される内容注意点
サブスクリプションURLリモートの設定を取得するためのURL。アクセストークンを含むことが多い機密情報にあたるため、公開しない
ローカル設定ノード、グループ、ルールなどを記述したYAMLファイル通常は自分でメンテナンスが必要
プロキシプロバイダー設定から参照する独立したノードリソースProfile全体の更新とは別のレイヤー
実行時設定上書きや統合を経て、実際にコアへ渡される設定内容元のサブスクリプションファイルと異なる場合がある

サブスクリプション全体とproxy-providersは区別が必要です。前者にはポート、DNS、グループ、ルールなどがまとめて定義される場合があります。後者は主にノードを提供し、メイン設定のポリシーグループからuseで参照します。rule-providersはルールセットを提供するもので、プロキシノードは提供しません。

サブスクリプションURLをインポートする方法

まず取得される形式を確認する

同じサービスから複数のサブスクリプション形式が提供される場合があります。他のプロキシソフト向けのノードリストを、Clash用の完全なYAML設定としてそのまま使えるとは限りません。サービス側でClashまたはmihomo形式と明記されたものを選びましょう。VLESSやHysteria2などのプロトコルが含まれる場合は、アプリ名にClashとあるかだけで判断せず、実際に使用するコアが対応していることも確認してください。

  1. クライアントの「設定」または「Profiles」画面を開き、サブスクリプションURLのインポート機能を使います。ボタン名はクライアントによって「新規作成」「インポート」「追加」など異なるため、現在の画面に合わせてください。
  2. URL全体を貼り付けます。前後の空白や引用符、チャットアプリが付け加えた句読点は含めないでください。「自宅用」「出張用」など、用途が分かる名前を付けます。
  3. インポート後、更新日時を確認してから、その設定を選択します。ログに解析エラー、未対応の項目、ポリシーグループの参照エラーがないか確認してください。
  4. プロキシグループを開き、ノード一覧が表示されることを確認したうえで、そのグループを通る新しい接続をテストします。この段階ではDNSやTUNを同時に変更せず、問題の原因を切り分けやすくしてください。

インポートに失敗したら応答内容を確認

YAMLに関するエラーが表示され、応答の先頭が<html>なら、ダウンロードされたのはログインページやエラーページかもしれません。HTTP 401や403は認証切れやアクセス制限、429はリクエスト頻度の制限が原因であることが多いです。まずサブスクリプションの取得元を確認してください。エラーを回避するために、TLS証明書の検証を安易に無効化しないでください。

ローカル設定と最小構成の例

ローカルProfileは、ルールを固定したい場合や、オフラインでも設定を保持したい場合、設定項目の意味を学びたい場合に適しています。UTF-8でprofile-local.yamlを作成し、インデントにはスペースを使います。Tabは使わないでください。以下は構造を確認するための最小構成です。ローカルの7890番ポートで待ち受け、選択肢はDIRECTのみで、リモートのプロキシノードは含みません。

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

proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選択
  • mixed-port: 7890はHTTPとSOCKSのプロキシ接続口を提供します。ポート番号はこの例での設定であり、すべてのクライアントが7890を使うわけではありません。
  • allow-lan: falseは、同じLAN内の他のデバイスからの利用を許可しません。初めて設定する場合は、この値のままにしてネットワークへの不要な公開を避けましょう。
  • mode: ruleはルールモードを指定します。最後のMATCHが、それまでのルールに一致しなかった接続を処理します。
  • 手動選択はポリシーグループ名です。ルールから参照する場合は、表記を完全に一致させる必要があります。この例では最終的にDIRECTが選ばれるため、通信はプロキシを経由せず直接接続されます。

ファイルをローカル設定としてインポートしても、クライアントが待ち受けポート、実行モード、DNSなどを上書きする場合があります。問題を調べる際はYAMLだけでなく、クライアントの設定と実行時設定も確認してください。コアの設定項目や互換性については、コア設定リファレンスも参照してください。

システムに実行可能なmihomoがインストールされている場合は、ファイルがあるディレクトリで以下の構文チェックを実行できます。成功しても、そのコアで設定を読み込めたことを示すだけです。ノードへの接続や、デスクトップ環境のシステムプロキシが有効になっていることまでは保証しません。

mihomo -t -f ./profile-local.yaml

自動更新の間隔を設定する

ノードの変更が少ない普段使いの設定なら、Profileの自動更新はまず24時間ごとに設定します。ノードが頻繁に調整されるサービスでは、サービス提供元の案内に従い6時間ごとに変更できます。これは設定の目安であり、性能を実測した結果ではありません。更新頻度を上げても既存ノードの遅延は改善せず、サーバー側でアクセス制限を受ける可能性があります。

単位を確認してから数値を入力

  • クライアントの画面で単位が「分」の場合、24時間は1440と入力します。「時間」の場合は24です。
  • mihomoのHTTPプロキシプロバイダーでは、interval: 86400は86400秒、つまり24時間を表します。この項目はGUIのProfile更新間隔ではありません。
  • プロバイダーのヘルスチェック間隔health-check.intervalは、ノードの状態を確認する頻度です。サブスクリプションを再取得する頻度とは異なります。
  • 0が必ず無効を意味するとは限りません。クライアントによって仕様が異なるため、自動更新のオン・オフが明示された設定を優先してください。

PCがスリープ中、クライアントが終了中、またはネットワークに接続できない場合、更新タスクは予定どおり実行されないことがあります。ネットワーク復旧後に「最終更新成功」の時刻を確認し、サブスクリプションURLを変更した場合は手動で一度更新して結果を確かめてください。自動更新がオンというだけで、ファイルが最新だと判断しないようにしましょう。

複数設定を切り替えるときの確認順

多くのデスクトップクライアントでは、一度に有効化できるメインProfileは1つです。設定を3つ保存していても、3つのサービスのノードがすべて同じポリシーグループに読み込まれるわけではありません。Profileを切り替えると、新しいルール、DNS、ポリシーグループがまとめて適用される場合があります。一方、システムプロキシやTUNの権限などはクライアント側で管理され、Profileと連動して切り替わるとは限りません。

  1. 切り替え前の状態を記録：現在の設定名、実行モード、選択中のノード、システムプロキシとTUNのオン・オフを控えます。
  2. 新しいProfileを選択：画面上で有効な設定になっていることを確認し、コアのログに読み込みエラーがないか調べます。読み込みに失敗すると、クライアントが古い設定を使い続ける場合があります。
  3. ポリシーグループを確認：同じ名前のグループでは選択内容がクライアントに記憶されることがありますが、切り替え先に以前のノードが存在するとは限りません。元と同じノードが選択されていると決めつけないでください。
  4. 接続ポートを確認：アプリで127.0.0.1:7890を手動設定している一方、新しい実行時設定が7897番ポートで待ち受けている場合は、両方の設定をそろえます。
  5. 新しい接続を確立：テスト用のページやアプリの接続をいったん閉じて開き直し、接続ログで適用されたルールと出口を確認します。既存のTCP長時間接続は、切り替え後すぐに再確立されるとは限りません。

「切り替え後、ブラウザーは使えるのにターミナルでは使えない」場合は、サブスクリプションをすぐ変更するのではなく、まずターミナルの環境変数を確認してください。Linuxでは以下のコマンドで一般的なプロキシ変数を確認できます。出力に内部アドレスが含まれることがあるため、ログを共有する前に機密情報を取り除いてください。

printenv http_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY

システムプロキシは、その設定に従うアプリに主に影響します。TUNは仮想ネットワークインターフェースを使ってより多くの接続を取り込み、対応するサービスや権限が必要です。Profileを切り替えてもTUNの権限は付与されません。それぞれの利用範囲はTUNモードの説明と照らし合わせて確認してください。

設定を統合するときに確認すべき競合

複数の取得元を1つの設定で使う必要がある場合は、メイン設定とproxy-providersの組み合わせか、クライアントが正式にサポートする統合機能を使います。完全なYAMLファイルを2つ単純につなげないでください。トップレベルのキーが重複すると、パーサーに拒否されたり、一方の値が上書きされたりすることがあります。ノードやルールが自動的に追加されるわけではありません。

競合する項目対処方法
ノード名・ポリシーグループ名取得元ごとに接頭辞を付け、参照箇所もすべて合わせて変更する
ルール一覧適用順を明確にし、最後にフォールバックのMATCHを置く
DNS・待ち受けポートメイン設定で一元管理し、2つの設定値を単純につなげない
プロバイダーのキャッシュパスリソースごとに別のパスを使い、互いに上書きされないようにする

ルールは件数より順序が重要

ルールは通常、上から順に照合されます。独自ルールをMATCH,DIRECTの後ろに追加すると、それ以前のルールに一致しなかった接続はフォールバックルールで処理されるため、後続のルールは想定どおりに適用されません。クライアントに「前に追加」「後ろに追加」の両方がある場合は、エディターで保存できたかだけでなく、最終的な設定のどこに生成されたかを確認してください。

また、通常の完全なサブスクリプションをそのままproxy-providersのリソースとして使えるとは限りません。プロバイダーには、コアが対応するノードリソース形式が必要です。統合ツールによっては配列全体を置き換え、末尾に追加しない場合もあります。取得元を一つずつ追加し、読み込みテストの後に実行時設定のノード数、ポリシーグループの参照、ルールの末尾を確認しましょう。複数の設定を一度に貼り付けるより、問題を特定しやすくなります。

バックアップ・復元とよくある質問

サブスクリプションURLだけでは不十分

サブスクリプションURLがあればリモートの設定を再取得できますが、独自ルール、クライアントの上書き設定、ポリシーの選択状態までは復元できません。初めて正常に使えたときと、大きなルール変更を行う前にバックアップを作成し、日付を付けて区別しましょう。正常に動作するローカル設定も1つ保管しておくと、復元時に安心です。

  • 設定ファイル：ローカルYAML、リモート設定の正常に動作した時点のコピー、取得元の名前、更新日時を保存します。
  • カスタムレイヤー：上書きファイル、統合スクリプト、自分で管理するルールリソースを保存します。実行時に生成されるファイルだけをコピーしないでください。
  • クライアント設定：待ち受けポート、システムプロキシ、TUN、自動更新間隔を記録します。クライアントに正式なエクスポート機能がある場合は、そちらを優先してください。
  • プライバシー保護：バックアップにはノードのパスワード、サブスクリプショントークン、コントロールAPIのキーが含まれる場合があります。アクセス制限のあるディレクトリに保存し、他のデバイスと同期する場合も保護されたストレージを使ってください。

更新後にルールが元に戻るのはなぜ？

最も多い原因は、リモートファイル自体を編集していることです。変更をクライアントの独立した上書きレイヤーに移し、生成された設定にルールが反映されているか確認してください。一時的な実行ファイルを編集し続けるのは避けましょう。再起動、切り替え、更新時に再生成されることがあります。

ローカル設定が自動更新されないのはなぜ？

ローカルからインポートした設定には、通常ファイルの内容だけがあり、リモートの取得元はありません。クライアントによってはファイルをコピーして読み込むため、ディスク上の元ファイルを編集してもすぐに反映されないことがあります。ファイルとの連携に対応しているか確認してください。非対応の場合は、再インポートするかクライアントの編集機能を使い、設定を再読み込みします。

古い設定に戻しても接続できない場合は？

まず、コアが古いProfileを正常に読み込んでいるか確認し、次にサブスクリプションの期限、システム時刻、ポートの競合を調べます。設定を復元しても、サーバー側で削除済みのノードは戻らず、システム権限が自動で補われることもありません。「設定の読み込み → 接続ポート → ルールの一致 → ノードへの接続」の順で確認すると、複数のスイッチを一度に切り替えるより効率的です。サブスクリプションに関する詳しい情報はサブスクリプションに関するよくある質問をご覧ください。