同期範囲を整理する：ノード・ルール・デバイス固有の設定

Clashの設定を複数デバイスで同期することは、クライアントのフォルダー全体をコピーすることではありません。ノードの認証情報、ルーティングルール、システムプロキシの状態は、それぞれ異なる階層の設定です。デスクトップ用の設定をそのままスマホに読み込むと、未対応の項目やポートの競合、TUNの起動失敗が起きることがあります。ノードの取得元とルールの意図を共有し、ネットワークインターフェース、待ち受けポート、システム連携は各デバイスで個別に管理するのが安全です。

クライアントとコアの違いも確認しましょう。mihomoを使うデスクトップクライアントなら、同じコア設定項目に対応している場合がありますが、設定のマージ、バックグラウンド更新、スクリプト実行はクライアント側の機能です。別のコアやモバイル向けプロキシアプリが一部のClash形式を読み込めても、mihomoの設定をすべて使えるとは限りません。この記事のYAML例はmihomoを前提としています。読み込み前に、対象のコアと対応する設定項目を確認してください。

設定項目推奨する範囲理由
ノード、サブスクリプションURL同じアカウントを使うデバイス間で共有認証情報と通信量は通常、サーバー側で一元管理されるため
ルール、プロキシグループ名できるだけ統一同じドメインへの接続先がデバイスごとに異なるのを防ぐため
mixed-port、allow-lan各デバイスで個別に管理待ち受けの要件やLANへの公開範囲が異なるため
tun、コントローラーAPI各デバイスで個別に管理OSの権限、ネットワークスタック、クライアントの管理方式に依存するため

方法1：同じサブスクリプションURLを各デバイスに登録

2〜3台のデバイスで同じプロバイダーを使うなら、サブスクリプションURLを使うのが最も手軽です。各クライアントのサブスクリプションまたは設定画面に同じURLを登録し、手動で更新して有効化します。同期されるのは各デバイスがサーバーから取得する設定であり、クライアント同士が設定を直接転送するわけではありません。

設定の更新と接続状態を分けて確認する

  1. まずPCにサブスクリプションを登録し、ノード一覧、プロキシグループ、ルールが使えることを確認してから、スマホとタブレットにも登録します。
  2. 各デバイスでサブスクリプションの更新設定を確認します。クライアントが対応していれば、確認間隔を24時間に設定できます。この値は運用上の目安であり、Clash共通の初期設定ではありません。
  3. プロバイダーがノードを変更したら、各デバイスで手動更新し、現在有効な設定が対象のサブスクリプションであることを確認します。
  4. 接続画面で実際に適用されたルールと接続先を確認しましょう。設定ファイルに「更新成功」と表示されるだけでは不十分です。

サブスクリプションを更新しても、プロキシグループで選択中のノードは自動で同期されません。PCで特定の地域のノードを選んでも、スマホ側では別の選択が維持されることがあります。接続履歴やシステムプロキシ、TUNのオン・オフも通常はデバイスごとに保存されます。デバイス間で同じ選択方式にしたい場合は、設定で同じ自動選択グループを使えますが、ネットワーク環境が異なるため各デバイスの計測遅延は一致しません。

主な制約：更新タイミングはクライアントの動作に左右される

スマホアプリはバックグラウンドでOSに停止されることがあります。更新間隔を24時間に設定しても、指定した時刻に必ず取得できるとは限りません。PCのスリープやサブスクリプションサーバーへの接続障害でも、更新は遅れます。古いノードを停止する予定がある場合は、移行期間を設け、スマホではアプリを前面に表示して手動更新してください。

プロバイダーのデバイス数、同時接続数、アカウント利用規約も確認してください。サブスクリプションを共有しても、無制限に配布できるわけではありません。サブスクリプションURLにはアクセストークンが含まれることが多く、URLを知っている人がノード情報を取得できる可能性があります。アカウントの認証情報と同じように慎重に扱いましょう。

方法2：YAMLをプライベート環境で管理し、ルールを一元化

独自ルールが多い場合や、設定変更をレビューしたい場合は、プライベートリポジトリに設定のソースを保存し、認証付きHTTPS経由で各デバイスに配布できます。リポジトリはバージョン履歴を管理し、ダウンロード用URLはアクセス認証を担います。この2つは別の役割です。プライベートリポジトリのWebページは通常ログイン画面を返すため、YAMLのサブスクリプションURLとしてそのまま使うことはできません。

完全な設定ファイルと独立したルールセットの違い

完全な設定ファイルをホストする場合、デバイスが取得するファイルにはプロキシ、プロキシグループ、ルールが含まれ、すぐに使える状態である必要があります。ルールセットだけをホストする場合は、メイン設定でrule-providersから参照し、さらにrulesで呼び出します。ルールセット単体のファイルは、完全なサブスクリプションとして有効化できません。

ルールセットの構成をローカルファイルで説明します。まず、コアの作業ディレクトリにあるrules/shared-direct.yamlへルールファイルを置き、次の内容を記述します。example.comはルール形式を確認するための予約済みサンプルドメインです。本番環境では実際に使うドメインに置き換えてください。

payload:
  - DOMAIN-SUFFIX,example.com

メイン設定に次のスニペットを追加し、既存のノードとプロキシグループは残します。この例では、既存のプロキシグループ名が「ノード選択」であることを前提としています。名前が異なる場合は、最終行を実際の設定にある名前に変更してください。

rule-providers:
  shared-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/shared-direct.yaml

rules:
  - RULE-SET,shared-direct,DIRECT
  - MATCH,ノード選択

rulesは上から順に評価され、末尾のMATCHがどのルールにも一致しない場合のフォールバックになります。上記のリストは順序を示す例であり、サブスクリプションに含まれる既存ルールをすべて置き換えるためのものではありません。HTTPルールプロバイダーにする場合は、type: httpを指定し、実際のダウンロードURL、キャッシュパス、intervalも設定します。たとえばinterval: 86400は更新間隔が86400秒、つまり24時間であることを示します。これはルールプロバイダーの更新間隔であり、サブスクリプション全体の更新間隔ではありません。

アクセス権限とローカルのバックアップ

  • 利用する各クライアントでダウンロードURLを試し、ログイン画面やリダイレクト先、エラーメッセージではなくYAMLが返ることを確認します。
  • 独自の認証ヘッダーが必要な場合は、クライアントと該当するダウンロード方式が対応しているか確認してください。ブラウザーでログイン済みでも、クライアントからアクセスできるとは限りません。
  • リポジトリには、できるだけルールと生成ロジックだけを保存します。ノードのパスワード、サブスクリプションのトークン、コントローラーAPIのキーは別に管理してください。
  • リリースごとに検証済みの旧バージョンを残し、設定の解析に失敗した場合はローカルのバックアップへ戻せるようにします。

プライベートリポジトリに保存すれば秘密が漏れない、というわけではありません。認証情報を一度コミットすると、後からファイルを削除しても履歴から自動的に消えることはありません。誤って登録した場合は、まず認証情報を失効またはローテーションし、その後で履歴を整理してください。トークン付きのダウンロードURLを公開の問い合わせ欄やスクリーンショットに載せないでください。

方法3：サブスクリプション更新後にローカルオーバーライドを適用

ローカルオーバーライドは、「ノードは上流に追従させ、デバイス設定は維持したい」場合に適しています。通常、クライアントはサブスクリプションを取得した後、設定マージやスクリプトを使って最終的な実行設定を生成します。ただし、「オーバーライド」はすべてのClashクライアントに共通する仕様ではありません。ファイル形式、マージ順、スクリプト対応状況は、実際に使うクライアントで確認してください。

デスクトップでは、クライアントの設定マージまたはオーバーライド機能で、以下のデバイス固有の設定を管理できます。この例では、混合プロキシポートをローカルホストだけで待ち受け、システムプロキシもTUNも有効にしません。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

クライアントが待ち受けポートを一元管理している場合は、設定画面から変更してください。画面の設定とオーバーライドファイルが互いに上書きし合うのを防げます。スマホのVPNによる通信の取り込みはデスクトップのシステムプロキシとは仕組みが異なります。「同期」のためにデスクトップのポート設定を無理にコピーする必要はありません。

リストのマージは特に間違いやすい

rules、proxies、proxy-groupsはいずれもリストです。クライアントによってリスト全体を置き換える場合や、先頭・末尾への追加、スクリプト処理に対応する場合があります。ローカルルールを2つ追加しても、既存の数千件のルールが残るとは限りません。変更後は最終的な実行設定を確認し、既存リストが意図せず消えていないことを確かめてください。

  • 独自のDIRECTルールは、適用したい通信に一致する位置へ追加します。通常は末尾のMATCHより前に置く必要があります。
  • 追加するルールが参照するプロキシグループは、あらかじめ存在している必要があります。グループ名のスペースや大文字・小文字も一致させてください。
  • DNS設定は全体を確認してください。enhanced-modeだけを変更しても、各プラットフォームで同じ方法でDNS通信が取り込まれるとは限りません。
  • TUNのデバイス名、ルート除外、権限設定は各デバイスで管理し、異なるOS間でそのまま使い回さないでください。

3つの方法を更新の反映速度と運用負荷で比較

方法反映条件主な管理項目
共通のサブスクリプションURL各デバイスで設定を正常に取得し、有効化できている更新間隔、アカウント制限、上流設定の変更
YAMLのプライベートホスティング公開が完了し、クライアントからダウンロードできる認証、バージョンの切り戻し、設定の互換性
ローカルオーバーライドによるマージサブスクリプション更新後、マージ処理が正しく適用されるデバイスごとのマージ仕様とルールの順序

PC1台、スマホ1台、タブレット1台を使う場合は、まず共通のサブスクリプションでノードを更新し、PCにはデバイス固有の待ち受け設定を残します。共有ルールを頻繁に変更する必要が出てから、ルールセットのホスティングを導入しましょう。必要な管理手順だけを追加でき、最初から設定生成サービスを構築する必要はありません。

3台すべてが前面で動作しているなら、定期更新を待つより手動で更新したほうが結果を確認しやすいことがあります。ただし、これを根拠に同期時間を秒単位で保証することはできません。実際の反映時間には、公開処理、クライアントの更新スケジュール、ネットワークからのダウンロード、設定の再読み込みが関わります。設定した確認間隔だけで判断せず、実際の更新時刻を記録してください。

導入とトラブル対処：同じ接続先で検証する

初回公開時に確認する5項目

  1. 環境を記録。クライアント名とバージョン、コアの名称とバージョンをそれぞれ記録し、「最新版」とだけ書くのは避けます。
  2. 旧設定を保存。正常に動作している設定をエクスポートし、現在選択中のプロキシグループも記録します。バックアップファイルは認証情報を含むデータとして管理してください。
  3. 1台ずつ更新。まずPC、次にスマホの順で更新し、各デバイスの取得時刻と有効な設定を確認します。すべてのデバイスを同時に変更しないでください。
  4. 実行設定を確認。mode、ルールの順序、参照先のグループ名を確認し、オーバーライドが最終設定に反映されていることを確かめます。
  5. 実際の接続をテスト。同じドメインにアクセスし、接続ログで適用ルール、プロキシグループ、最終的なノードを比較します。その後、DIRECTになるはずのサイトもテストしてください。

同じ設定なのに、振り分け結果が違うのはなぜ？

まず、すべてのデバイスがルールモードになっているか確認してください。グローバルモードでは、同じルール一覧による振り分けは行われません。次に、アプリの通信がコアを経由しているかを確認します。デスクトップではブラウザーだけがシステムプロキシを使い、ほかのアプリは使っていない場合があります。スマホではVPN経由で通信が取り込まれることがあります。最後に、DNSの結果、ルールプロバイダーのキャッシュ、プロキシグループの選択状態を比較してください。

更新に成功したのに、古いルールが残るのはなぜ？

「ダウンロードしたファイル → 現在有効な設定 → マージ結果 → コアの実行設定」の順に確認します。よくあるのは、無効なサブスクリプションを更新しているケースや、最後の処理でローカルオーバーライドが古いルールを書き戻すケースです。完全なサブスクリプションとHTTPルールセットでキャッシュが別々の場合もあるため、サブスクリプション更新後にルールプロバイダーの状態も確認してください。

調査に必要な情報を残して設定を戻すには？

エラーメッセージと失敗したバージョンを保存してから、直前の正常な設定に戻します。TUNやシステムプロキシを変更していた場合は、該当デバイスのスイッチも元に戻してください。クライアント終了後も、システムが使えない待ち受けポートを参照し続けるのを防げます。その後は一度に1つの階層だけを変更します。まずノードの取得元、次に共有ルール、最後にローカルオーバーライドを検証します。複数デバイスで同期する目的は、振り分け方を追跡でき、デバイスごとの差を説明できるようにすることです。すべてのファイルを一字一句同じにすることではありません。