同期する範囲：ルールは共有し、デバイス固有の設定は分ける

PCとスマホでClashの設定を共有するといっても、動作中のYAMLをそのまま全デバイスにコピーするわけではありません。同じノードやルールを参照しつつ、システムに関わる設定は各デバイスに保存します。サブスクはノードの取得元、設定ファイルはノードとルールの構成、クライアントはインポート・更新・コアの起動を担います。それぞれに状態があるため、ファイルを一度コピーするだけですべてを置き換えることはできません。

たとえばWindowsではシステムプロキシの接続先がローカルの 127.0.0.1:7890 でも、スマホでは通常、システムVPNインターフェースを使って通信を処理します。両方のデバイスで同じ名前のプロキシグループを使えても、TUNの設定やネットワークインターフェース名、ファイルパスまで無理にそろえる必要はありません。Androidのアプリ別プロキシ設定と、デスクトップOSのプロセスルールも、そのまま相互に使える設定ではありません。

設定レイヤー 共有に適した内容 デバイスごとに管理する内容
ノードとサブスク サブスクURL、ノード一覧、更新方法 デバイス固有の認証情報、通信量や接続数の上限
通信の振り分けルール ドメインルール、プロキシグループ名、ルールセットの参照 ローカルネットワークの例外、プロセスルール、アプリの除外リスト
実行環境 各環境で動作確認済みの共通フィールド リスニングポート、コントローラー、TUN、DNSの処理方法

方法1：各デバイスで同じURLを登録する

PCとスマホで同じノードを使うだけなら、それぞれに同じサブスクURLを登録するのが最も手軽です。まず、サービス提供元が複数デバイスでの利用を認めているか確認し、同時接続数や通信量、プランの制限もチェックしてください。設定をコピーできても、アカウントで任意の台数を同時接続できるとは限りません。

サブスクの配信内容を確認する

  • Clash YAML一式：通常は proxies、proxy-groups、rules を含み、クライアントが対応する方法でリモート設定としてインポートできます。
  • ノード一覧：プロキシプロバイダーとして使う場合、一般的なトップレベル構造は proxies です。完全な設定に必要なプロキシグループや振り分けルールは自動で補われません。
  • Base64形式のノードリンクや他のコア向け形式：インポートできるかどうかは、クライアントに解析・変換機能があるかによります。拡張子が .yaml でも、内容の互換性が保証されるわけではありません。

リモート設定の更新と proxy-providers の更新は、特に区別が必要です。前者は設定ファイル全体を置き換えることがありますが、後者が更新するのは主にプロバイダー内のノードです。ノードプロバイダーを更新しても、メイン設定の rules がサービス提供元の新しいルールに自動で置き換わるわけではありません。完全な設定URLをノードプロバイダーとしても使えるかは、対象のコアで実際に解析した結果を確認してください。

更新は即時同期ではない

対応するHTTPプロキシプロバイダーで interval: 3600 は、更新間隔が3600秒、つまり1時間であることを示します。クライアントのリモート設定にある自動更新間隔は別の設定で、このフィールドでは置き換えられません。スマホのスリープやバックグラウンド制限、クライアントの停止によって、更新が想定より遅れることもあります。

  1. 1台目のデバイスにサブスクを登録し、ノード数やプロキシグループ名、設定の読み込みログを確認します。
  2. 2台目にも同じURLを登録し、手動で一度更新して、古いローカルコピーを読み込んでいないか確認します。
  3. たとえば1時間など、更新間隔の目標をそろえます。両方のクライアントがその間隔やバックグラウンドでの更新に対応しているかも確認してください。
  4. サービス提供元がノードを変更したら、それぞれのデバイスで更新時刻を確認します。「PCは更新済みだからスマホも更新済み」とは判断しないでください。

この方法はメンテナンスの手間を最小限に抑えられますが、振り分けルールが一致するかはサブスクの内容とローカルのオーバーライド次第です。スマホへのインポート時にルールが自動で追加され、PCには追加されない場合、両者の動作は異なります。

方法2：プライベートリポジトリで設定とルールを管理する

独自のドメイン例外やルールの順序を管理したい場合、または複数デバイス向けの設定を保守する場合は、プライベートGitリポジトリを設定の管理元にする方法が適しています。変更履歴を残して以前の状態に戻せますが、クライアント間のリアルタイム同期サービスではなく、ダウンロード時の認証問題も自動では解決しません。

共有レイヤーとデバイスレイヤーに分けて管理する

clash-config/
├── shared/
│   └── rules.yaml
├── desktop/
│   └── override.yaml
├── mobile/
│   └── override.yaml
└── README.md

これはファイル構成の例であり、Clashが自動認識するディレクトリ構成ではありません。ディレクトリ名を shared にしても、クライアントが自動で統合することはありません。ルールセットはメイン設定から rule-providers で参照し、RULE-SET ルールで適用する必要があります。オーバーライドファイルには、クライアント側の対応するマージまたはインポート機能が必要です。

YAML形式のドメインルールセットを使う場合、以下は形式の例として利用できます。example.com はドキュメント用のサンプルドメインであり、特定のサービスのアドレスを直接接続するよう推奨するものではありません。

payload:
  - "+.example.com"

この形式の内容は、behavior: domain と format: yaml を指定したルールプロバイダーで利用できます。メイン設定には、プロバイダー名や取得方法、マッチ時のポリシーも定義してください。ルールセット自体には接続先の選択が含まれないため、完全な rules リストの代わりにはなりません。

プライベートリポジトリの認証情報は別途管理する

  • ブラウザーで開けても、クライアントが取得できるとは限らない：ブラウザーにはログイン済みのセッションがありますが、コアからのリクエストには通常、そのCookieは引き継がれません。
  • ダウンロードURLには有効期限がある場合がある：一時的な認証パラメーター付きのファイルURLは、期限切れになるとログインページやエラーページを返すことがあります。
  • 認証への対応状況はクライアントごとに異なる：独自のリクエストヘッダーや専用の認証フローが必要なURLは、各クライアントで動作確認してください。
  • サブスクの認証情報をコミット履歴に含めない：リポジトリを非公開にしてもアクセス範囲が狭まるだけで、履歴やクローン、バックアップから漏えいするリスクはなくなりません。

Gitには、サブスクのトークンを含まないルールのソースファイルを保存するのが適しています。非公開URLはローカル設定から渡してください。合成した設定を公開する必要がある場合は、取得権限を制限し、公開処理のログに内容全体が出力されないことを確認します。スマホから取得しやすくするために、プライベート設定を公開ファイルに変更してはいけません。

変更の取り消しと反映を分けて行う

デスクトップの管理環境では、次のコマンドで変更を確認し、誤ってコミットした内容を取り消せます。取り消し用のコミットを作成した後も、各クライアントで設定を再取得して読み込む必要があります。Gitの操作が成功しても、スマホの設定に反映されたとは限りません。

git diff -- shared/rules.yaml
git add shared/rules.yaml
git commit -m "共有ドメインルールを調整"
git log --oneline -5
git revert HEAD

方法3：サブスクとローカルオーバーライド／スクリプトを併用する

ノードの更新はサブスクに任せ、個別の設定はローカルオーバーライドで保持する方法は、複数デバイスで使う際の現実的な折衷案です。更新のたびに置き換わるサブスクのキャッシュファイルを直接編集せず、クライアントが用意する独立したレイヤーにオーバーライドを保存することが重要です。

ファイルの中身だけでなく、マージ方法も確認する

クライアントによって、浅いマージ、深いマージ、リストの置き換え、専用の先頭追加方式など、動作が異なります。同じYAML断片でも、あるクライアントではルールが追加され、別のクライアントではリスト全体が置き換わることがあります。以下は最終設定に反映させたいフィールドの例であり、すべてのクライアントで使える共通のインポート形式ではありません。

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

mixed-port は、HTTPとSOCKSの通信を受け付ける混合リスニングポートです。異なるデバイスがそれぞれ7890を使っても、通常は互いに競合しません。同じデバイス上で、同じアドレスとポートを使うプロセスを2つ起動すると、バインドの競合が起きる可能性があります。スマホ向けクライアントでユーザーがこのポートを変更できるかは、画面や実行設定で確認してください。

ルールリストは特に注意して確認してください。たとえばローカルドメインのルールをフォールバックルールより前に置きたい場合、必要なのは順序の変更であり、ファイルの末尾に1行追加することではありません。MATCH が残りの通信すべてにマッチした後では、その下に追加したルールは実行されません。共有ルールが参照するプロキシグループ名も、最終設定に存在する必要があります。

スクリプトはクライアント固有の機能であり、共通のコア設定ではない

一部のデスクトップクライアントには、サブスクの読み込み後に設定オブジェクトを変更するJavaScriptの処理機能があります。スクリプトのエントリーポイントや実行タイミング、利用できるAPIはクライアントごとに異なります。同じスクリプトをすべてのAndroid・iOSクライアントで使えるとは限らず、過去のClash設定にあったスクリプト機能とも混同しないでください。

  1. 実行環境への依存を減らすため、固定フィールドの設定にはまず静的オーバーライドを使います。
  2. ノードやプロキシグループに応じた動的な生成が必要な場合に限り、クライアントのスクリプト機能を使います。
  3. スクリプトには対象クライアント、対応バージョン、テスト日を記録します。クライアントを更新した後は、出力を再確認してください。
  4. スクリプトを保存できたかだけでなく、最終的な実行設定を確認します。

環境による違い：DNS、TUN、コアの機能

Clashの設定環境には、複数のコアやGUIクライアントがあります。mihomoを使うクライアント同士でも、コアのバージョンやクライアント側の設定生成方法、OSの権限によって動作が異なる場合があります。互換性は実際に使うコアとバージョンで判断し、アプリ名にClashが含まれているだけで、すべてのフィールドが共通だと考えないでください。

違いが出る項目 デバイスごとの設定方針 確認箇所
TUNによる通信の処理 各デバイスで権限、ルート、除外項目を設定する 起動ログ、システムVPNの状態、接続一覧
DNSリスナー デスクトップ専用のバインドアドレスやポートをコピーしない 最終的なDNS設定とポートのバインドログ
プロセス・アプリのルール デスクトップのプロセス名とモバイルアプリの選択は別々に管理する 実際のアプリ通信に適用されたルール
ファイルパス 各クライアントで使用可能な作業ディレクトリを使う プロバイダーの取得結果とファイル読み込みエラー

DNSの fake-ip モードでは、合成アドレスを使ってコアが接続を処理します。デバイス上で実行中に生成されたDNSキャッシュを、同期が必要な設定とみなさないでください。スマホがWi-Fiからモバイル回線に切り替わると、上流DNSへの接続状況も変わることがあります。設定が同じでも、それぞれのネットワーク環境でテストが必要です。

iOSでプロキシ機能を提供するアプリが、必ずmihomoを使っているとは限らず、Clash YAML一式をそのまま受け付けるとも限りません。アプリを選ぶ際は、サブスクのインポート形式やルールの解釈、ローカルオーバーライドへの対応を先に確認し、共有するソースファイルを決めてください。異なるコア向けに変換した設定を使う場合は、ノード名が表示されるかだけでなく、プロトコルのパラメーターやルールの動作も確認する必要があります。

更新後の確認：両方のデバイスで同じ設定が読み込まれているか

設定同期には、繰り返し実施できる確認手順が必要です。以下は推奨チェック項目であり、特定クライアントの実測性能を示すものではありません。メニュー名はクライアントによって異なるため、リモート設定の更新、実行設定、接続一覧、ログなどに該当する画面を探してください。

  1. 設定の出所を記録：設定名、サブスクの更新時刻、共有ルールのGitコミットの短縮IDを記録します。記録にサブスクの認証トークン全体を含めないでください。
  2. 手動で更新：両方のデバイスでリモート設定を更新します。プロバイダーを使う場合は、ノードとルールのプロバイダーの更新時刻も確認してください。
  3. 読み込み成功を確認：ログにYAMLの解析エラー、未定義のプロキシグループ、プロバイダーの取得失敗、ポートのバインド失敗がないことを確認します。
  4. 最終設定を確認：実行モードが rule になっていること、オーバーライドが維持されていること、フォールバックルールが末尾にあることを確認します。
  5. 実際の通信を確認：各デバイスから、直接接続される想定のアドレスとプロキシ経由の想定アドレスにアクセスし、接続一覧で適用ルールと出口を確認します。レイテンシテストの成功は、テスト先に到達できたことを示すだけです。
  6. ネットワーク切り替えも確認：スマホではWi-Fiとモバイル回線の両方で動作を確認し、デスクトップではLAN内のサービスに想定どおりアクセスできるかをチェックします。

PCでは正常でスマホでは失敗する場合、まずスマホで実際に読み込んでいる設定とプロバイダーの更新時刻を確認し、その後VPNの権限やバックグラウンド更新、DNS、プロトコル対応を調べてください。最初からすべてのルールをグローバルプロキシに変更すると、振り分けの問題を一時的に回避できても、原因を特定する手がかりが失われることがあります。

おすすめの構成と認証情報の管理

  • ノードだけを共有：各デバイスで同じURLを登録し、デバイス固有の設定は個別に保存します。アカウントの制限と更新状況の確認がポイントです。
  • ノードと少数の例外ルールを共有：サブスクと独立したオーバーライドを併用します。各デバイスで表現できる静的ルールを優先し、リストのマージ方法をそれぞれ確認してください。
  • 複数デバイスを継続的に管理：プライベートリポジトリにルールのソースファイルと変更履歴を保存し、サブスクの認証情報は各デバイスに保持します。そのうえで、環境ごとに設定を生成するかインポートします。
  • プロキシグループを動的に生成：対応機能のある管理環境で処理し、他のデバイスには互換性のある結果を渡します。スマホでもデスクトップ用スクリプトが動くと想定しないでください。

サブスクURLには通常、認証情報が含まれます。QRコードや設定のエクスポートファイル、ログのスクリーンショットにも、同じアクセス権限が含まれる場合があります。問題のスクリーンショットを共有する前に、クエリパラメーターやノードのパスワード、コントローラーのキーを隠してください。URLを第三者に知られた場合は、サービス提供元の管理画面でサブスクのトークンを再発行し、すべてのデバイスで更新します。チャットからメッセージを削除したり、リポジトリを再び非公開にしたりしても、コピー済みのURLは無効になりません。

コントローラーも、スマホと共有する公開用の接続口ではありません。リモート管理のために external-controller をインターネットに直接公開しないでください。複数デバイスで共有するのは設定とルールであり、各デバイスの管理権限ではありません。共有する範囲を先に決め、デバイス固有の違いは残すほうが、すべてのYAMLを完全一致させるより管理しやすくなります。