まず設定・バックアップ・実行状態の3種類のデータを分けて考える
Clashの「同期」は、ひとつの共通スイッチで管理するものではありません。サブスクリプションURLはリモート設定の配布、WebDAVは通常クライアントのバックアップ保存、手動エクスポートは一時的なファイル移行に使います。それぞれ扱うデータ範囲が異なるため、すべてのデバイスを完全に同じ実行環境にできるとは限りません。
複数デバイスで共有しやすいのは、プロキシノード、プロキシグループ、ドメインルール、ルールセットのURL、基本的なDNSポリシーです。システムプロキシ、TUN権限、自動起動、現在選択中のノード、速度テスト結果、ログ、画面設定は端末固有の状態に近いため、各デバイスで個別に管理するのが適切です。
| データの種類 | 複数デバイスでの共有 | 推奨する管理方法 |
|---|---|---|
| ノード・プロキシグループ・ルール | 適している | サブスクリプションURLで一元配布 |
| オーバーライドスクリプト・個別ルール | クライアントの互換性による | 個別に保存し、プラットフォームごとに調整 |
| クライアント設定・過去の設定 | 同じクライアント間なら比較的適している | WebDAVまたは完全バックアップ |
| TUN権限・VPN認証 | 適していない | 各デバイスでローカルに許可 |
| 現在のノード・リアルタイム遅延 | 通常は不要 | デバイスのネットワークに合わせて再選択 |
方法1：サブスクリプションURLで設定を一元配布する
サブスクリプションURLは、維持管理の手間が最も少ない方法です。サーバー側またはサブスクリプション変換サービスに基準となる設定を置き、各デバイスには同じURLを登録して一定間隔で取得させます。設定を変更したら、配信元を一度更新し、各デバイスで再取得するだけです。
標準的なインポート手順
- デスクトップクライアントで「設定」または「Profiles」を開き、「URLからインポート」を選択します。
- サブスクリプションURLを貼り付け、「日常用ルール」などの名前を付けてからダウンロードします。
- AndroidのClash Meta系クライアントでは、「設定」→「新しい設定」→「URL」を開き、同じURLを入力します。
- 自動更新間隔は1440分に設定します。ルールを頻繁に調整する場合は360分に変更できますが、数分おきに取得する必要はありません。
- 更新後、プロキシグループ、ルール数、更新日時を確認し、その設定を現在の設定として有効にします。
クライアントによってメニュー名は多少異なりますが、必要な操作はURLの保存、YAMLの取得、ダウンロードした設定の有効化の3つだけです。「ローカル設定」と「リモート設定」の両方がある場合は、リモート設定を選びます。そうしないと、配信元の変更が自動取得されません。
サブスクリプション同期の限界
リモートサブスクリプションは通常、その設定ファイルに対するローカルの直接編集を上書きします。たとえばスマホで一時的にルールを追加しても、次回更新時に消える可能性があります。継続して使うルールはサブスクリプション元へ反映するか、クライアントのMerge、Mixin、オーバーライドスクリプトで追加してください。
オーバーライド機能はすべてのクライアントで共通して使えるわけではありません。mihomoが対応するルールプロバイダー、ルールセット形式、一部のDNS項目を、旧版のClashコアが認識できない場合があります。クライアントごとに設定を生成する際は、共通して対応する基本項目を優先し、プラットフォーム固有の項目は分離してください。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
dns:
enable: true
enhanced-mode: fake-ip
rules:
- DOMAIN-SUFFIX,example.org,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY上記の基本構成は、多くのmihomoクライアントで利用できます。ただし、ポート、LANアクセス、DNSの動作はデバイスごとに調整してください。スマホでは通常LANポートを開放する必要はありません。一方、家庭用ゲートウェイとして使うデスクトップではLANアクセスを有効にし、待ち受けアドレスとファイアウォールの範囲を追加で制限する場合があります。
方法2：WebDAVに完全バックアップを保存する
WebDAVはリアルタイム共同編集というより、「バックアップをアップロードし、必要なときに復元する」ための仕組みです。対応クライアントでは、設定、オーバーライド内容、一部の設定情報をまとめてリモートディレクトリへアップロードします。別のデバイスでバックアップをダウンロードできますが、通常は同じシリーズのクライアントで、バックアップ形式に互換性があることが前提です。
たとえばAndroidクライアントのバックアップには、アプリデータベース、設定インデックス、ローカルファイルが含まれることがあり、デスクトップクライアントでは直接解析できません。両方がmihomoコアを使っていても、アプリ側のデータ構造は大きく異なる場合があります。そのためWebDAVは、「同じクライアントを同種のデバイス間で復元する」用途が最も安全で、任意のClashクライアント同士を同期する方法ではありません。
推奨するディレクトリ構成と命名
複数のデバイスから同じファイルを継続的に上書きさせないでください。クライアントとデバイスごとにディレクトリを分け、ファイル名に日付を付けると管理しやすくなります。
clash-backups/
├── android-phone/
│ └── backup-2026-08-11.zip
├── android-tablet/
│ └── backup-2026-08-11.zip
└── desktop/
└── backup-2026-08-11.zipWebDAVを設定するときは、まずクラウド側に専用ディレクトリを作成し、クライアントで「設定」→「バックアップと復元」または「設定」→「WebDAV」を開きます。サーバーURL、アカウント、パスワード、リモートパスの順に入力します。アップロード後はすぐにリモートディレクトリを開き、ファイルの日時とサイズが変わっていることを確認してください。
復元前にローカルスナップショットを作成する
- 現在使用中の設定名と更新日時を記録します。
- リモート側の古いファイルで新しい設定を上書きしないよう、先にローカルバックアップを一度エクスポートします。
- リモートファイルがどのデバイスのものか、どのクライアントバージョンで作成されたものかを確認します。
- 復元後はクライアントを完全に終了し、再起動します。
- サブスクリプションURL、オーバーライドルール、DNSモード、TUNスイッチを確認します。ノード一覧だけを見て判断しないでください。
2台のデバイスで自動アップロードを有効にすると、最も起こりやすいのは、後から書き込んだデバイスが前のバックアップを上書きする問題です。WebDAV自体は通常、Clash設定の内容を理解せず、項目単位でマージすることもありません。スマホが21:00、タブレットが21:05にアップロードした場合、後者が前者をそのまま置き換える可能性があります。
| WebDAVの利用場面 | リスク | 対処方法 |
|---|---|---|
| 同じアカウント・同じファイル名 | デバイス同士で上書きされる | デバイスごとにディレクトリを分ける |
| 異なるクライアント間で復元 | バックアップ形式に互換性がない | 標準YAMLだけを移行する |
| リモートバックアップが長期間更新されない | 古いサブスクリプションやルールが復元される | 日付を残し、更新日時を確認する |
| アップロードが中断する | 圧縮ファイルが不完全になる | 再アップロードし、別のデバイスで読み込めるか試す |
方法3：手動でエクスポート・インポートする
手動移行は最も分かりやすく、内容も確認しやすい方法です。機種変更、安定した設定の一時的な複製、WebDAVに対応していないクライアントへの移行、インポート前に機密項目を削除したい場合に適しています。一方、変更のたびに再エクスポートが必要で、自動的に設定をそろえることはできません。
YAMLファイルを1つコピーするだけでは不十分
単純な設定ならYAMLが1つだけの場合もありますが、複雑な設定ではルールセット、スクリプト、ローカル証明書を参照することがあります。エクスポート前に次の項目を検索してください：rule-providers、proxy-providers、script、tls、path。項目がローカルの相対パスを指している場合は、対応するファイルも一緒に移行します。
profiles/
├── main.yaml
├── providers/
│ ├── proxy.yaml
│ └── direct.yaml
└── rules/
├── private.yaml
└── streaming.yaml別のデバイスへインポートした直後に、元の設定を上書きしないでください。まず「移行テスト」という名前で読み込み、クライアントが解析できることを確認します。ログに「file not found」と表示された場合は、外部ファイルが不足している可能性が高いです。「field not found」や「unsupported field」の場合は、コアのバージョンまたは設定形式の互換性が原因と考えられます。
手動移行時の確認手順
- 移行先のクライアントがmihomo互換コアを使用していることを確認し、コアのバージョンを確認します。
- YAMLをインポートしたら設定検証を実行し、インデントや項目の誤りがないことを確認します。
- プロキシグループを開き、ノード数が元のデバイスと一致することを確認します。
- モードを「ルール」に切り替え、最終的なフォールバックルールがMATCHになっていることを確認します。
- 直連サイトとプロキシ経由サイトにそれぞれ1回アクセスし、接続ログでルールのマッチ結果を確認します。
- 最後にシステムプロキシまたはTUNを有効にします。設定ミスによってネットワーク全体がすぐに乗っ取られるのを防げます。
手動エクスポートには、移行前に移行先のデバイスに不要な項目を削除できる利点もあります。たとえばデスクトップ設定の external-controller: 127.0.0.1:9090、LAN待ち受け、固定パスは、スマホでは通常必要ありません。AndroidのVPNとTUN権限もシステムから再度許可する必要があり、設定をコピーしても認証手順を省略することはできません。
複数プラットフォームで衝突しやすい5つの設定
1. ポートとシステムプロキシ
デスクトップクライアントでは、HTTP/SOCKS混合ポートに7890、コントロールポートに9090が使われることがよくありますが、実際の値はクライアントの現在の設定を確認してください。既存のプロキシソフトが動作するPCへ設定をコピーすると、7890が使用中の場合があります。その場合は競合するソフトを終了するか、混合ポートを7891、7892など空いているポートへ変更し、システムプロキシの設定も更新します。
2. TUNモード
TUNはデバイス単位の機能です。Windowsではサービスのインストールや、初回有効化時の管理者権限が必要になる場合があります。macOSではネットワーク拡張機能の許可を求められ、AndroidではシステムVPNインターフェースを使ってトンネルを構築します。同じYAMLにTUNパラメータを含めることはできますが、権限、ルーティングテーブル、除外アプリ一覧はサブスクリプションでは同期されません。
3. DNSとFake-IP
Fake-IPを使うと、コアがより早くドメイン情報を取得してルールを適用できます。ただし、一部のLAN機器の検出、印刷サービス、特殊なアプリではフィルターリストへの追加が必要になる場合があります。スマホと家庭用PCでは接続するネットワークが異なるため、すべてのフィルター項目を機械的にコピーしないでください。LANドメインを解決できない場合は、まずFake-IPを無効にした結果と比較し、その後 fake-ip-filter を調整します。
4. ローカルパス
Windowsのパスにはドライブ文字が使われることがあり、AndroidとmacOSではアプリのディレクトリ構成も異なります。設定に絶対パスが含まれると、プラットフォームをまたぐインポートで失敗しやすくなります。ルールファイルにはリモートURLを優先し、ローカルファイルが必要な場合はクライアントの設定ディレクトリからの相対パスを使います。
5. ノード選択とプロキシグループの状態
クライアントによっては、各プロキシグループで前回選択したノードを記憶しますが、その状態がYAMLではなくローカルデータベースに保存されることがあります。設定を同期した後にスマホとPCで異なるノードが選ばれていても、正常な動作です。モバイル回線と固定回線では遅延も異なるため、それぞれで速度を測定して適切なノードを選んでください。
3つの方法の選び方
| 方法 | 適した場面 | 更新方法 | 主な制約 |
|---|---|---|---|
| サブスクリプションURL | 異なる複数のデバイスを長期運用する | 定期更新または手動更新 | ローカルでの直接編集が上書きされる可能性がある |
| WebDAV | 同じクライアントのバックアップと復元 | バックアップをアップロード・ダウンロード | 異なるクライアント間では互換性に制限がある |
| 手動エクスポート | 機種変更・一度きりの移行・設定内容の確認 | 手作業でファイルをコピー | 後からの変更は自動同期されない |
デバイスが2～3台で、設定の大部分をリモートサブスクリプションから取得しているなら、同じサブスクリプションURLを使うのが最も簡単です。クライアントの設定、オーバーライドスクリプト、過去の設定を残したい場合は、サブスクリプションに加えてWebDAVバックアップを利用できます。機種変更やクライアント間の移行では、制御しやすい中間形式として手動エクスポートを使います。
より安定する組み合わせは、「サブスクリプションを中心に、バックアップを補助として使い、手動エクスポートを最後の手段にする」運用です。サブスクリプションで日常の更新を行い、WebDAVには週1回、または大きな変更の前にスナップショットを保存します。手動エクスポートは、バージョンアップ、機種変更、障害復旧に使います。リモートバックアップが上書きされても、サブスクリプションから主要設定を再取得できます。
移行後、10分で動作確認を終える
- 設定の更新日時、ノード数、プロキシグループ数が配信元と一致していることを確認します。
- クライアントのログを確認し、YAMLの解析エラーやルールセットのダウンロード失敗がないことを確認します。
- 直連ノードとプロキシノードでそれぞれ1回ずつ遅延を測定し、実際に利用できる結果を記録します。
- 本来は直接接続するサイトを開き、DIRECTまたは該当する直連グループにマッチすることを確認します。
- 本来はプロキシを使うサイトを開き、対象のルールとプロキシグループにマッチすることを確認します。
- Wi-Fiとモバイルネットワークを切り替え、DNSとTUNがどちらも再確立できることを確認します。
- クライアントを再起動し、現在の設定が選択されたままで、自動更新間隔も想定どおりであることを確認します。
- デバイスを再起動し、システムプロキシ、常時VPN、起動時実行が端末の要件どおりになっていることを確認します。
サブスクリプションを更新するとノードは正常に表示されるのに、すべてのWebページが開けない場合は、設定を何度もインポートするのではなく、まずDNS、システムプロキシのポート、TUNの競合を確認してください。一部のドメインだけ失敗する場合は、接続ログのルールマッチとDNSクエリの結果を確認し、問題が名前解決、ルール判定、ノード接続のどの段階で起きているかを切り分けます。
複数デバイス同期の要点は、より多くのファイルをコピーすることではありません。どの部分をサブスクリプションで管理し、どの部分をクライアントバックアップに含め、どの部分をデバイスごとに再設定するかを明確にすることです。境界を整理すれば、スマホ、PC、タブレットで同じルールの考え方を共有しながら、それぞれに必要なネットワーク権限と実行パラメータを維持できます。