Clashのマルチデバイス設定同期を比較：サブスクリプションURL・WebDAV・手動エクスポート

まず同期するデータの層を整理する

Clashの「設定」は、単一のファイルだけを指すものではありません。PCとスマートフォンにはノード、ルール、プロキシグループが表示されますが、これらはリモートサブスクリプションから取得される場合もあれば、クライアント独自のデータベースに保存される場合もあります。同期を始める前に、データを3つの層に分けておくと、方式を選びやすくなります。

基本設定：ノード、プロキシグループ、ルール、DNS

基本設定は通常 YAML ファイルで、proxies、proxy-groups、rules、dns などのフィールドを含みます。mihomo カーネルは rule-providers、proxy-providers、sniffer や、より詳細な TUN パラメータにも対応しています。この層はサブスクリプションURLで一元配信するのが適しています。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - 自動選択
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

クライアント設定：システムプロキシ、TUN、起動動作

「起動時に接続」「スタートアップ起動」「システムプロキシ」「LAN接続を許可」などのスイッチは、通常クライアントのローカル設定です。同じ YAML を2台の端末に読み込んでも、これらの設定まで同期されるとは限りません。Windows でシステムプロキシを有効にしても、Android や iOS が自動的に VPN を確立するわけではありません。macOS の TUN 権限も、設定ファイルを別の端末にコピーして引き継ぐことはできません。

実行状態：現在のノードと遅延履歴

現在選択中のノード、直近の速度テスト結果、ログ、通信量の統計は、実行状態として扱われることが多いデータです。クライアントのデータベースに保存される場合もあれば、再起動時にリセットされる場合もあります。これらを同期対象にすると、「設定は同じなのに画面表示が違う」という状態になりがちです。より安定した方法は、プロキシグループの構成だけを同期し、各端末で速度テストとノード選択を行うことです。

方式1：サブスクリプションURLで一元配信する

サブスクリプションURLは、2台以上の端末で長期的に使う場合に適しており、ルールの保守も最も簡単です。サーバーにマスター設定を1つ保存し、PC、スマートフォン、タブレットで同じURLを追加します。ルールを変更したら配信元だけを編集し、各端末で更新を実行します。

基本的な操作手順

信頼できるサブスクリプション管理環境でマスター設定を用意し、対象カーネルで YAML を読み込めることを確認します。
デスクトップクライアントで「設定」→「サブスクリプション」または「Profiles」→「New Profile」を開き、HTTPS アドレスを貼り付けます。
モバイル端末で「設定」→「URLからインポート」を開き、同じURLを入力して保存します。
自動更新間隔を設定します。通常の利用なら 1440 分、ルールを頻繁に変更する場合は 360 分が目安です。
初回更新が完了したら、プロキシグループ数、ルール数、DNS モード、最終更新日時を確認します。

クライアントによってメニュー名は異なります。たとえば一部のデスクトップ版では「設定」→「新規作成」→「URL」、一部のモバイル版では「設定」右上のプラスボタンから追加します。「更新完了」と表示されるだけで成功と判断せず、設定の詳細を開いてファイルサイズが 0 KB ではないこと、YAML の解析エラーがないことを確認してください。

端末ごとの差異はローカルに残す

同じサブスクリプションに、すべての端末向けのローカルパラメータを無理に記述する必要はありません。デスクトップ版では mixed-port: 7890 が必要な場合がありますが、モバイル版はシステム VPN インターフェースで通信を制御するため、このポートを使いません。TUN のインターフェース名、ルーティング権限、DNS ハイジャック方式にもプラットフォームごとの差があります。

安定しやすい構成は、リモートサブスクリプションにノード、プロキシグループ、ルールセット、共通 DNS ポリシーを任せ、システムプロキシ、TUN、LANアクセス、起動動作は各端末に保存する方法です。クライアントがオーバーライドや Mixin に対応している場合は、完全なマスター設定を複製せず、ローカルに必要なパラメータだけを追加します。

# マスター設定が共通ロジックを担当
mode: rule
log-level: info

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

サブスクリプション方式の注意点

ネットワーク到達性が必要：新しい端末に初回インポートする際は、サブスクリプションURLへアクセスできなければ設定を取得できません。
更新でローカル編集が上書きされる場合がある：ダウンロード済みのサブスクリプションファイルを直接編集しても、次回の更新で通常はリモート版に戻ります。
URL自体を保護する必要がある：サブスクリプションURLにはアクセストークンが含まれる場合があるため、公開リポジトリ、スクリーンショット、グループチャットの履歴に載せないでください。
クライアントごとに変換動作が異なる：フィールドを自動変換するクライアントもあれば、元の YAML を厳密に解析するクライアントもあります。

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

WebDAV は、同じ YAML をリアルタイム編集する仕組みというより、「クライアントのスナップショットを保存する」方法です。WebDAV に対応したクライアントでは、設定、環境設定、バックアップパッケージなどをリモートディレクトリへアップロードし、別の端末でダウンロードして復元できます。端末の買い替えや、同じクライアント間の移行に適していますが、マルチデバイス互換性はバックアップ内容に左右されます。

クライアントが何をバックアップするか確認する

サブスクリプション一覧だけをアップロードするクライアントもあれば、ローカル設定、プロキシグループの選択、アプリ設定まで保存するクライアントもあります。手動インポート・エクスポートだけに対応し、WebDAV 機能を備えていないものもあります。操作前に「設定」→「バックアップと復元」または「設定」→「WebDAV」を開き、説明にサブスクリプション、オーバーライド、ルール、ローカル設定が含まれているか確認してください。

バックアップパッケージにクライアントのデータベースが含まれる場合、通常は同じアプリ、または互換性のあるバージョンにしか復元できません。たとえばバージョン 2.1.0 で作成したデータベースを、別の mihomo GUI クライアントが読み込めるとは限りません。両方が mihomo カーネルを使っていても、GUI 層のデータ構造が異なる場合があります。

WebDAV の推奨操作手順

1台目の端末で「設定」→「バックアップと復元」→「WebDAV」を開きます。
HTTPS サーバーアドレス、ユーザー名、アプリ専用パスワード、リモートディレクトリを入力します。
「接続テスト」をクリックし、成功したことを確認してから手動バックアップを1回実行します。
バックアップ日時とファイルサイズを記録します。たとえば通常のバックアップが 428 KB なのに、新しいファイルが 2 KB しかない場合は、まず内容が完全か確認してください。
2台目の端末に同じクライアントをインストールし、システムプロキシや VPN はまだ有効にしないでください。
同じ WebDAV ディレクトリに接続し、作成したばかりのバックアップを選んで復元します。
復元後、VPN、TUN、システムプロキシを再認証し、ルールのマッチングをテストします。

WebDAV のURLには、サーバーのルートパスだけを入力する場合と、完全なディレクトリを入力する場合があります。たとえばサーバーの入口が https://dav.example.net/remote.php/dav/files/user/ で、クライアントがユーザー名を自動追加すると、パスが重複して HTTP 404 が返されることがあります。HTTP 401 は通常、アカウントまたはアプリパスワードの誤りを示します。HTTP 403 は、ディレクトリへの書き込み権限がない場合によく発生します。

2台の端末による上書きを防ぐ

WebDAV が設定の競合を自動的に統合してくれるとは限りません。PCが 10:20 にアップロードし、スマートフォンが 10:23 に古い設定を再度アップロードすると、サーバー上の最新ファイルから直前に追加したルールが失われる可能性があります。安全策として、アップロード担当のメイン端末を1台に決め、ほかの端末は原則として復元だけにするか、端末名ごとにディレクトリを分けてください。

/ClashBackup/
  desktop-main/
    backup-2026-06-20.zip
  macbook/
    backup-2026-06-20.zip
  phone/
    backup-2026-06-20.zip

クライアントが履歴バージョンの保持に対応している場合は、少なくとも直近3世代を残すことをおすすめします。誤って上書きしても、すべてのバックアップが一度に失われることを防げます。復元前には現在の設定もエクスポートしてください。特にスマートフォン側にローカルオーバーライドがある場合は必須です。

方式3：YAMLまたはバックアップファイルを手動エクスポートする

手動エクスポートは最も分かりやすく、変更範囲も管理しやすい方法です。リモートサービスに依存しないため、端末が2台だけの場合、設定変更が少ない場合、オフラインで移行したい場合に適しています。一般的な入口は「設定」→「設定ディレクトリを開く」、「設定」→「エクスポート」、または設定項目右側の共有メニューです。

YAMLのエクスポートと完全バックアップは別物

YAML のエクスポートで持ち出せるのは、通常、基本設定だけです。システムプロキシのスイッチ、現在のノード、クライアントテーマ、ショートカット、TUN 権限は新しい端末で再設定する必要があります。完全バックアップにはより多くのアプリ状態が含まれる場合がありますが、クライアント間の移植性は低くなります。

Windows から macOS へ移行する場合は、標準 YAML を優先してエクスポートしてください。同じスマートフォンアプリ間で端末を買い替える場合は、アプリが提供するバックアップパッケージを優先できます。実行ディレクトリ全体を直接コピーするのは避けてください。キャッシュ、ログ、データベースのロックファイル、プラットフォーム固有のパスが混在している可能性があります。

インポート前に確認する4項目

ポートの競合：mixed-port: 7890 が別のプログラムで使用されている場合は、7891 に変更してから再読み込みします。
絶対パス：C:\Users\name\rules\local.yaml は macOS や Android ではそのまま使用できません。
ルールファイル：rule-providers が参照するローカルファイルも一緒にコピーされているか確認します。
カーネルのフィールド：対象クライアントが geodata-mode、sniffer、tun などのオプションに対応しているか確認します。

インポート後、すぐにグローバル TUN を有効にしないでください。まずカーネルを起動し、ログで設定の読み込み結果を確認してから、システムプロキシで基本的な動作をテストします。デスクトップ版では HTTP と SOCKS の混合ポートに 7890、コントローラーのポートに 9090 がよく使われますが、実際の値は設定に従ってください。

ファイル名でバージョンを把握できるようにする

手動コピーでよくある問題は、ファイルが消えることではなく、どれが最新か分からなくなることです。ファイル名に日付、端末の用途、改訂番号を含めることをおすすめします。例：clash-main-2026-06-20-r03.yaml。変更は毎回1つのテーマに絞り、同じディレクトリに簡単な記録も保存しましょう。

2026-06-20 r03
- DIRECT の LAN ルールを追加
- 自動選択のテスト間隔を 300 秒に変更
- Fake-IP モードを維持
- デスクトップ版では TUN をローカルで有効化し、モバイル版ではマスター設定に記述しない

2台の端末でそれぞれファイルを変更した場合、ファイルサイズだけで新旧を判断しないでください。proxy-groups、rule-providers、rules を部分ごとに比較し、特にルールは上から順に評価されるため、順序の変更が接続先を直接変える可能性がある点に注意します。

3つの同期方式を選ぶ基準

3つの方式は排他的ではありません。サブスクリプションは継続的な配信、WebDAV はクライアント状態の復元、手動エクスポートはオフライン保管を担わせる組み合わせが、実際の運用に近い方法です。以下では、保守コストと互換性の範囲を比較します。

方式	適した端末数	主な同期内容	クライアント間の互換性	代表的な用途
サブスクリプションURL	2台以上	ノード、プロキシグループ、ルール、共通 DNS	比較的高いが、カーネルのフィールドに左右される	長期的な一元管理
WebDAV	1～3台	サブスクリプション一覧、クライアント設定、バックアップパッケージ	普通。通常は同じクライアントが必要	端末の買い替えと復元
手動エクスポート	1～2台	単一の YAML または完全バックアップ	YAML は比較的高く、バックアップパッケージは低い	オフライン移行と保管

個人で使う2台の端末

PCとスマートフォンを使う頻度が低く、ルール変更も月に1～2回程度なら、YAML を手動エクスポートすれば十分です。変更のたびに日付と改訂番号を更新し、システムのファイル共有機能で別の端末へインポートします。ノードがサービスのサブスクリプション由来なら、オーバーライドとカスタムルールだけを手動で管理します。

PC、スマートフォン、タブレットを長期的に共用する

サブスクリプションURLを中心に運用するのがおすすめです。プロキシグループ名は「ノード選択」「自動選択」「トラブル対処」などに統一すると、各端末の画面を照合しやすくなります。WebDAV はクライアントのバックアップ保存だけに使い、日常のルール編集には関与させません。

再インストールや複数クライアントのテストを頻繁に行う

できるだけ標準的な mihomo YAML を基準として1つ保管し、特定の GUI クライアントのデータベースを唯一の情報源にしないでください。クライアント固有の機能はローカルオーバーライドで追加します。アップグレード前には毎回手動エクスポートを行い、WebDAV には復元可能な直近3回分のスナップショットを保存します。

複数のプラットフォームでルールを揃える実践方法

プロキシグループ名を統一し、ルールの参照切れを防ぐ

ルール末尾のポリシー名は、プロキシグループ名と完全に一致していなければなりません。マスター設定に DOMAIN-SUFFIX,example.com,ノード選択 と記述していても、モバイル版でプロキシグループを「手動選択」に変更すると、読み込み時にエラーが出たり、意図した振り分けにならなかったりします。名称を決めたら、1台の端末だけで個別に変更しないようにしましょう。

プラットフォーム差分はオーバーライド層に集約する

共通設定にはノード、ルール、DNS の基本ロジックを残し、プラットフォーム固有のパラメータはローカルオーバーライドに置きます。Windows では 7890 の混合ポートとシステムプロキシを維持し、macOS ではクライアントの権限に応じて TUN を設定します。Android と iOS ではアプリが VPN インターフェースを確立します。これにより、サブスクリプション更新のたびにプラットフォーム設定が上書きされることを防げます。

テスト項目を固定する

同期するたびに同じ手順で確認すれば、通常3分ほどで大半の問題を見つけられます。

設定の更新日時が想定どおりか確認します。
プロキシグループ数とデフォルトの選択肢が一致しているか確認します。
自動選択グループで遅延テストを1回実行し、利用可能なノード数を記録します。
ログを開き、yaml、provider、dns に関するエラーがないことを確認します。
DIRECT で接続されるはずのサイトと、プロキシ経由になるはずのサイトにアクセスし、ルールのマッチ結果を確認します。
システムプロキシまたは VPN をいったん無効にしてから再度有効にし、設定を再読み込みしても正常に動作することを確認します。

差異が出たら、まず更新経路を確認する

一方の端末ではルールが正常なのに、もう一方では古い内容が使われている場合、まずサブスクリプションの更新日時を比較し、次にリモートファイルがキャッシュされていないか確認します。自動更新間隔が 1440 分の場合、変更内容はすぐに反映されないため、「更新」を手動でクリックする必要があります。更新後も一致しない場合は、古いローカル設定が有効になっていないか、オーバーライドがルールを変更していないか、対象カーネルが未対応フィールドを無視していないかを確認してください。

長期運用できる組み合わせ

多くのマルチデバイス利用者には、「サブスクリプションをマスター設定にする + プラットフォーム別のローカル設定 + 定期的な手動バックアップ」という構成がおすすめです。HTTPS サブスクリプションでノード、プロキシグループ、ルール、共通 DNS を統一し、システムプロキシ、TUN、VPN 権限、起動動作は端末ごとに管理します。大きな変更の前には、日付入りの YAML を1つエクスポートします。

クライアントが WebDAV に対応している場合は、復元用の層を追加できます。毎週、またはアップグレード前にバックアップを1回アップロードし、直近3～5世代だけを残します。WebDAV はルールを統合するものでも、サブスクリプションの代替でもありません。サブスクリプションの内容に問題があっても、手動ファイルや履歴バックアップから復元できるようになります。

同期の目的は、すべての端末の画面を完全に同じにすることではありません。同じドメインが同じポリシーに一致し、同じプロキシグループが同じ用途を持ち、プラットフォーム固有のパラメータが各端末に残っていることが重要です。マスター設定とローカル状態を分ければ、マルチデバイス管理は「部屋全体をコピーする」作業から「必要な引き出しだけを移す」作業に変わります。