Clashの複数デバイス間で設定を同期する方法：WebDAV・サブスクリプションURL・手動エクスポートを比較

まず、設定の同期・サブスクリプション更新・クライアントのバックアップを分けて考える

Clashの複数デバイス同期は、単独のスイッチで完結するものではありません。Windows、macOS、Android、Linuxのクライアントはmihomoカーネルを使う場合がありますが、保存されるデータは完全には同じではありません。同期対象は通常、リモートから提供されるノードとルール、手動で作成したYAML設定、クライアント固有の画面設定と動作状態の3層に分かれます。

3種類のデータを混同しない

• サブスクリプション内容：プロキシノード、プロキシグループ、ルール、プロバイダー定義などです。クライアントがURLから再ダウンロードするため、1つのリモートソースで一元管理するのに適しています。
• カーネル設定：dns、tun、sniffer、待受ポート、ルールセットのURLなどのYAMLフィールドです。フィールドの対応範囲はカーネルのバージョンによって異なる場合があります。
• クライアント状態：現在選択中のプロキシノード、テーマ、スタートアップ設定、システムプロキシ、ウィンドウサイズ、ログレベルなどです。通常はクライアントのデータベースや環境設定に保存され、YAMLファイルに含まれるとは限りません。

たとえば、PCでシステムプロキシを有効にして127.0.0.1:7890で待ち受ける設定は、PCクライアントの動作設定にすぎません。同じ設定をAndroidに読み込んでも、スマホで同じシステムプロキシ状態になるわけではなく、Android VPNインターフェース経由で通信を処理します。同様に、デスクトップのTUNインターフェース名、ルート除外、管理者権限の設定も、そのままスマホに適用すべきではありません。

同期前に4つの基準情報を記録する

1. 各デバイスで使用しているカーネル名とバージョン（例：mihomo 1.19.x）を確認し、古いカーネルが新しいフィールドを認識できない事態を避けます。
2. 混合ポート、コントロールポート、LAN待受の設定を記録します。混合ポートは7890、外部コントローラーは127.0.0.1:9090が一般的ですが、実際の値は現在の設定を確認してください。
3. WindowsのC:\Users\...やAndroidのプライベートディレクトリなど、設定内のローカル絶対パスを確認します。これらのパスは、そのまま別のプラットフォームでは使えません。
4. 正常に動作している設定のコピーを保存し、日付、デバイス、クライアントのバージョンを記録します。例：home-win-2026-08-16.yaml。

方法1：サブスクリプションURLでノードとルールを一元管理する

サブスクリプションURLは、複数デバイスで最も手間の少ない方法です。PCとスマホに同じURLを登録し、更新時はそれぞれの端末がサーバーから最新内容を取得します。デバイス間でファイルをコピーするのではなく、すべての端末が同じデータソースを参照するため、「どの端末のコピーが最新版か」という衝突も起きません。

基本的なインポート手順

一般的なクライアントでは、デスクトップ版の「サブスクリプション」→「新規作成」→「URL」からURLを入力し、自動更新間隔を設定します。Android版では通常、「設定」→「＋」→「URLからインポート」と進みます。メニュー名はバージョンによって変わりますが、URLを保存し、設定を取得し、選択してカーネルを起動するという流れは同じです。

1. 1台目のデバイスでサブスクリプションをインポートし、ダウンロードが正常に完了することを確認します。ノード数とプロキシグループ名も確認してください。
2. ルールモードに切り替え、直結するサイトとプロキシが必要なサイトを1つずつテストします。
3. 2台目のデバイスで同じURLをインポートします。1台目で生成されたキャッシュファイルを先にコピーしないでください。
4. 更新間隔はデバイスごとに設定します。通常は1440分ごとで十分です。ノードの変動が多い場合は360分まで短縮できますが、数分おきに取得する必要はありません。
5. 更新後にクライアントのログを確認し、レスポンスと設定の解析がともに成功していることを確認します。

サブスクリプション方式のメリットと制限

よくある問題は、サブスクリプションから取得したYAMLを直接編集してしまうことです。多くのクライアントでは、そのファイルをリモートキャッシュとして扱うため、「更新」を実行するとローカルの変更が上書きされます。長期的に残したいDNS、ルール、プロキシグループの変更は、クライアントが対応するオーバーライド、拡張スクリプト、またはマージ設定に記述してください。対応機能がない場合は、サブスクリプションキャッシュを主ファイルにせず、独立した設定を管理します。

providerで変動する内容を分離する

YAMLに慣れている場合は、メイン設定を安定させ、ノードやルールだけをリモートproviderに分ける方法があります。以下は基本的な関係を示す構成例です。URLとパスは、実際にアクセスできるものへ置き換えてください。

mixed-port: 7890
mode: rule
allow-lan: false

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.net/profile/nodes.yaml"
    path: "./providers/remote-nodes.yaml"
    interval: 21600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

rule-providers:
  private-rules:
    type: http
    behavior: classical
    format: yaml
    url: "https://example.net/rules/private.yaml"
    path: "./rules/private.yaml"
    interval: 86400

interval: 21600はノードproviderを6時間ごとに確認する設定で、ルールの86400は1日ごとを意味します。providerのローカルpathはキャッシュ保存先であり、特定デバイスの絶対パスに依存させないでください。mihomoのバージョンによって、format、ルールの動作、providerフィールドの対応状況が異なる場合があります。インポート後はまず解析ログを確認しましょう。

方法2：WebDAVでバックアップと復元を行う

WebDAVは、「クライアントのデータをまとめてリモートに保存し、別のデバイスで復元する」方法に近い仕組みです。複数の設定、オーバーライドスクリプト、ルールファイル、一部のクライアント設定を保存するのに向いていますが、両方のクライアントが互換性のあるWebDAVバックアップ形式に対応していることが前提です。WebDAVが定めるのはファイルへのアクセス方法であり、Clashクライアントが同じバックアップ構造を採用することまでは定めていません。

WebDAVに適したケース

• 同じクライアントを2台のデスクトップ間で移行する場合。たとえば、古いPCから新しいPCへ乗り換えるときです。
• ノードのサブスクリプションだけでなく、複数の設定ファイル、スクリプト、クライアント設定もまとめて保存したい場合。
• 定期的に復元ポイントを残し、設定を壊したときに昨日や先週の状態へ戻したい場合。
• リモートサービスがHTTPS、独立したアカウント、ファイルのバージョン履歴に対応している場合。

対応クライアントでは、通常「設定」→「バックアップと復元」→「WebDAV」または「設定」→「データ」→「WebDAV」に入口があります。サーバーアドレス、ユーザー名、パスワード、リモートディレクトリを入力したら、まず「接続テスト」を実行してから最初のバックアップを作成します。アドレスはサービスのルートパスの場合も、https://dav.example.net/remote.php/dav/files/user/clash/のような完全なディレクトリの場合もあります。具体的な形式はサーバーの説明に従ってください。

安全な初回同期の手順

1. メインデバイスで自動復元を無効にし、日時を付けたリモートバックアップを手動で作成します。
2. WebDAVサービスにログインしてファイルが生成されたことを確認し、ファイルサイズを記録します。正常なバックアップが2.8 MB程度なのに数十バイトしかない場合は、エラーページをアップロードしていないか確認してください。
3. 2台目のデバイスに同じメジャーバージョンのクライアントをインストールし、WebDAV接続を設定します。
4. まずバックアップ一覧を取得し、すぐに双方向の自動同期を有効にしないでください。
5. 日時が明確なバックアップを選んで復元し、クライアントを再起動します。その後、サブスクリプション、ルールモード、DNS、TUNのオン・オフを順番に確認してください。
6. 2台目のデバイスが正常に動作することを確認してから、定期バックアップを有効にするか判断します。

接続に失敗した場合は、HTTPステータスで原因を絞り込みます。401は通常、認証情報が受け付けられていないことを示します。403はディレクトリ権限不足、404はパスの入力ミス、409は上位ディレクトリが未作成、507はリモート容量不足であることが多いです。クライアントに「バックアップに失敗しました」としか表示されない場合は、WebDAVサーバー側のログも確認してください。

WebDAVはリアルタイムの双方向マージではない

PCとスマホで同じ設定を別々に編集し、同じファイル名でアップロードすると、後からアップロードした側が先のファイルを上書きする可能性があります。多くのクライアントは共同編集ツールのようにYAMLをフィールド単位でマージできず、プロキシグループの変更とDNSの変更を両方残すべきか判断することもできません。

クライアントをまたいだ復元には特に注意が必要です。クライアントAはYAMLとJSONインデックスで設定を保存し、クライアントBはデータベースで設定IDを管理している場合があります。両方がmihomoを使っていても、WebDAVバックアップが相互利用できるとは限りません。クライアントを変更するときは、別クライアントの完全なデータパッケージを直接復元するのではなく、標準YAMLをエクスポートするか、サブスクリプションを再インポートするのが安全です。

方法3：YAMLを手動でエクスポート・インポートする

手動エクスポートは最も分かりやすく、頻度の低い移行に適しています。現在のクライアントから設定ファイルをエクスポートし、LAN経由のファイル転送、USBケーブル、個人用ストレージなどで別のデバイスへ送り、ファイルからインポートします。自動更新はされませんが、毎回渡す内容が明確で、保存や比較がしやすい方法です。

基本的な手順

1. クライアントの「設定」または「サブスクリプション」を開き、現在有効な項目から「エクスポート」または「設定フォルダーを開く」を選びます。
2. メインのYAMLファイルをコピーします。設定がローカルのprovider、スクリプト、ルールファイルを参照している場合は、対応するディレクトリも一緒にコピーしてください。
3. テキストエディターで絶対パス、LANアドレス、デバイス固有のネットワークインターフェース名を検索します。
4. 用途と日付を含む名前を付けます。例：travel-phone-2026-08-16.yaml。
5. 移行先のデバイスで「設定」→「＋」→「ファイルからインポート」と進みます。完了後は解析エラーを確認してからプロキシを起動してください。

クロスプラットフォームで重点的に確認するフィールド

• external-controller：0.0.0.0:9090と記述すると、コントロールインターフェースがLANに公開される可能性があります。通常のローカル利用では127.0.0.1:9090に変更できます。
• secret：コントロールインターフェースのトークンはデバイスごとに設定し直してください。同じ値をすべてのデバイスへ長期間コピーするのは避けます。
• allow-lan：PCを他のデバイスのプロキシとして使う場合にのみ有効化します。スマホへインポートした後は、通常あらためて必要性を判断してください。
• interface-name：ネットワークインターフェース名はプラットフォームによって異なるため、Windows、Linux、Androidでそのまま共有できません。
• tun：デスクトップのルーティング、DNSハイジャック、自動インターフェース検出の設定がモバイル端末に適しているとは限りません。
• path：provider、ルールセット、スクリプトが移行先に存在しない絶対パスを使っていないか確認します。

external-controller: 127.0.0.1:9090
secret: "replace-with-device-specific-secret"
allow-lan: false

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

この設定は確認用の例であり、すべてのプラットフォームでそのまま有効化できるわけではありません。Androidクライアントは通常、システムVPN権限で動作します。一方、デスクトップではTUNインターフェースの作成に管理者権限が必要な場合があります。インポート後に「設定は有効だがインターネットに接続できない」場合は、まずTUNを無効にし、システムプロキシまたはアプリ内VPNだけで確認します。基本的なノードが使えることを確認してから、設定を1つずつ戻してください。

手動移行で特に漏れやすいファイル

メイン設定のproxy-providersとrule-providersがHTTP形式なら、移行先でキャッシュを再ダウンロードできることが多いです。type: fileを使っている場合は、ローカルファイルも一緒に移行する必要があります。設定が参照するスクリプト、カスタムGEOデータ、証明書ファイルもYAMLに自動で埋め込まれることはありません。

もう1つのよくある誤解は、動作キャッシュを元の設定と取り違えることです。cache.db、profiles.json、stateのような名前のファイルは、現在のクライアントでしか使えない場合があります。プラットフォーム間で移行する際は、プログラムのデータディレクトリ全体をコピーするのではなく、クライアントが明示的に提供する「設定のエクスポート」機能を優先してください。

3つの同期方法の選び方

おすすめの組み合わせ

多くのユーザーは3つから1つだけ選ぶ必要はありません。安定しやすい構成は、サブスクリプションURLでノードと共通ルールを管理し、クライアントのオーバーライドで各デバイスのDNS、TUN、LAN設定を管理し、WebDAVまたは手動エクスポートで復元ポイントを残す方法です。あるデバイスの設定が壊れても、サブスクリプションを再インポートして、デバイス固有のパラメーターだけを復元できます。

1. 共通層：ノード、プロキシグループ、共通ルールをサブスクリプションまたはproviderから取得します。
2. デバイス層：ポート、TUN、システムプロキシ、LANアクセス、コントロールインターフェースは各デバイスで設定します。
3. バックアップ層：大きな変更を加える前に、日時を付けたWebDAVバックアップまたはYAMLエクスポートを作成します。
4. 検証層：更新後に設定の解析、DNSクエリ、ルールのヒット状況、実際の接続性を確認します。

たとえば、Windowsのデスクトップでは混合ポート7890とシステムプロキシを使い、AndroidではVPNモードで動作させます。両方でノードとルールは共有しますが、動作状態まで揃える必要はありません。選択中のノードも別々で構いません。PCでは低遅延のノード、スマホではモバイル回線の安定性を優先した別のノードを選べます。

同期後に使えない場合の切り分け手順

ステップ1：設定が正常に解析されたか確認する

まずクライアントのログを確認し、すぐにノードが原因だと決めつけないでください。field not found、yaml unmarshal、重複キーの警告が出る場合、カーネルのバージョンがフィールドに対応していない、YAMLのインデントが誤っている、マージ設定が衝突しているといった原因が考えられます。YAMLのインデントにはスペースを使い、Tabは避けます。同じ階層のフィールドを2回定義しないでください。

ステップ2：リモートリソースを確認する

• サブスクリプションを手動更新し、URLにアクセスでき、設定内容が返されることを確認します。
• providerのダウンロード状態を確認し、キャッシュファイルが空でないことを確認します。
• デバイスのシステム時刻を確認します。時刻のずれがHTTPS接続に影響する場合があります。
• サブスクリプションの更新でローカルオーバーライドが上書きされていないか確認し、プロキシグループに想定したノードが残っていることを確認します。

ステップ3：DNS、ルール、TUNを分けてテストする

1. 一時的にTUNを無効にし、クライアントが対応する基本的なプロキシ方式だけでノードの接続性をテストします。
2. モードを一時的にグローバルへ切り替え、問題がノードにあるのか、ルールマッチングにあるのかを判断します。
3. ルールモードに戻し、ログでリクエストがどのルールとポリシーグループに一致したか確認します。
4. DNSの待受とハイジャックを確認します。ローカルで53、7890、9090がすでに使用されている場合は、ポートを変更するか競合プロセスを停止してください。
5. 最後にTUNを再度有効にし、システム権限、デフォルトルート、ネットワークインターフェースの自動検出が正常であることを確認します。

複数デバイスを長期運用する方法

デバイスが増えるほど、各端末での直接編集を減らすことが重要です。共通ルールの管理元は1つにまとめ、デバイス固有の設定は明確にローカルへ残します。PC、タブレット、スマホに、バージョン表示のない少しずつ異なる完全設定を3つ保存するのは避けてください。数か月後には、どれが最新の変更を含むのか判断しにくくなります。

シンプルなバージョン記録を作る

• ファイル名に日付と用途を入れ、「最終版」「最新版」のように並べ替えられない名前は使いません。
• 変更するたびに具体的なフィールドを記録します。例：「fallback-filterを調整」「Androidでallow-lanを無効化」。
• 大きな変更の前に旧設定を残し、24時間正常に動作することを確認してから古いバージョンを整理します。
• サブスクリプション、WebDAV、コントロールインターフェースの認証情報は分けて管理し、デバイス紛失時に個別で無効化できるようにします。
• 月に1度は復元テストを行い、バックアップファイルがアップロードに成功するだけでなく、実際にインポートできることを確認します。

最終的な選択はシンプルです。複数デバイスで同じノード群を使いたいだけならサブスクリプションURL、同じクライアントを完全に移行したいならWebDAV、一時的なコピーやクライアント間の移行なら手動エクスポートを選びます。ルールを頻繁に変更する上級ユーザーは、「リモートの共通設定＋ローカルのデバイス別オーバーライド＋定期バックアップ」という階層構成が適しています。保守の手間が少なく、同期後の異常も切り分けやすくなります。