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

なぜ複数デバイスの設定は「それぞれ独立」しがちなのか

Windows PC、Android スマホ、iPad、さらには macOS ノートを同時に使ってネットにアクセスするのはもはや当たり前です。各デバイスにインストールした Clash クライアントは互いに独立していて、設定ファイル・ノードリスト・ルールセットはそれぞれローカルに保存されるため、本来お互いを感知できません。PC 側だけで振り分けルールを変更しても、スマホ側は自動では追随しませんし、スマホ側で新しいサブスクリプションを追加しても、PC 側からは見えません。時間が経つにつれ、各デバイス上のプロキシ挙動は徐々に「ずれて」いき、同じサイトが PC では開けるのにスマホでは開けない、あるいはあるデバイスだけが期限切れの古いノードにつながり続けている、といった症状が現れます。

この不整合の原因はソフトウェアの欠陥ではなく、設定データそのものの保存方式にあります。Clash 系クライアント(オリジナルの Clash コアであれ Clash Meta / mihomo コアの GUI であれ)は設定をローカルファイルとして保存し、多くの場合は YAML 形式の config.yaml にプロキシノード・ルールセット・グループ戦略などの情報がまとめられています。ファイルはローカルディスク上にあるため、本来的にはデバイスをまたぐ能力を持たず、別のデバイスへ「運ぶ」手段や、複数デバイスで同じデータソースを参照する仕組みが必要になります。

以下では「設定更新の頻度」と「操作の複雑さ」という2つの軸から、よく使われる3つの方法を整理します:サブスクリプションによる一括管理、クライアント標準の WebDAV バックアップ同期、設定ファイルの手動エクスポートです。この3つは排他的な選択肢ではなく、多くのユーザーが組み合わせて使っています——サブスクリプションで日常的なノード管理、WebDAV で全体バックアップを保険として、そして手動エクスポートでオフラインの控えを残す、といった形です。

方法1:サブスクリプションによる一括管理

サブスクリプションは現在最も主流な同期方式です。仕組みは単純で、サービス提供側がリモートアドレスを管理しており、そこに決まった形式でノードリスト(場合によってはルールも)が記述されています。Clash クライアントは定期的にこのアドレスにリクエストを送り、返ってきた内容をローカル設定として解析します。複数のデバイスで同じサブスクリプションリンクを登録していれば、理論上は同じノード集合を取得できます。

1. 各デバイスのクライアントに同じサブスクリプションリンクを追加する

   クライアントごとに画面の表記は多少異なりますが、操作の流れはほぼ同じです。「サブスクリプション管理」「プロファイル」「Profiles」などの入口を見つけ、リンクを貼り付けてダウンロードまたはインポートします。

2. 自動更新間隔を設定する

   多くのクライアントは定期的なサブスクリプション更新に対応しており、デフォルトは24時間ごとが一般的です。より短い周期に変更したり、クライアントを開くたびに手動で「更新」を押すこともできます。

3. ノード数とグループの一致を確認する

   更新後は、2台のデバイスでそれぞれノードリストを開き、数やグループ名が一致しているか確認することをおすすめします。解析の差異によって一部のノードが漏れることを防げます。

サブスクリプションの利点は「軽さ」にあります。追加のソフトが不要で、ローカルストレージも消費せず、更新はパッシブかつ自動で、ほとんど人手を要しません。一方で限界もはっきりしています——サブスクリプションが対象とするのは通常ノードと一部のルールのみで、カスタム振り分けルール、DNS 設定、TUN モードの具体パラメータといった「個人設定」の多くはサブスクリプションに含まれず、ローカルで個別に管理する必要があります。つまり、サブスクリプションが解決するのは「ノードの一致」であり、「機器全体の設定一致」とは同義ではありません。

方法2:クライアント標準の WebDAV バックアップ同期

一部の主流クライアント(例:mihomo コアベースのデスクトップクライアントである Clash Verge Rev など)には WebDAV バックアップ機能が内蔵されており、設定ファイル全体・サブスクリプションリスト・画面の環境設定をまとめて WebDAV サーバーにアップロードし、他のデバイスから同じアドレスでダウンロードして復元できます。サブスクリプションリンクと比べると、WebDAV バックアップの粒度はより粗く、実質的には「機器全体のスナップショット」であり、ノードリストよりも完全な設定状態を復元できます。

1. WebDAV サービスのアドレスを用意する

   自前で構築した WebDAV サービスでも、WebDAV プロトコルに対応したクラウドストレージでも構いません。アドレス・アカウント・パスワードを記録しておきましょう。

2. クライアントのバックアップ設定に WebDAV 情報を入力する

   「バックアップ」「同期」「WebDAV」関連の入口を見つけ、アドレスと認証情報を入力し、まず一度「バックアップをアップロード」を実行してエラーが出ないか確認します。

3. 他のデバイスで「ダウンロードして復元」を実行する

   同じアカウント情報を別のデバイスのクライアントに入力し、「WebDAV から復元」を選択、ダウンロード完了後にクライアントを再起動して設定を反映させます。

WebDAV 方式の利点は「まるごと移行」がしやすいことで、特に新しいデバイスへの買い替えや OS の再インストール後に、以前の環境を項目ごとに再設定せず素早く復元できる点で有用です。ただし本質的な制約もあります。通常はこの機能に対応したデスクトップクライアント同士でのみ機能し、モバイル端末(Android や iOS)のクライアントが同じ WebDAV バックアップ形式に対応しているとは限らないため、プラットフォームをまたいで復元する際は事前にターゲットクライアントがバックアップファイル構造に対応しているか確認が必要です。また、バックアップは手動または定期実行されるスナップショットであり、リアルタイム同期ではないため、変更後に再バックアップを忘れると復元されるのは古いバージョンのままです。

方法3:設定ファイルの手動エクスポート・インポート

最も原始的だが最も直接的な方法は、config.yaml やクライアントがエクスポートした設定パッケージをそのまま別のデバイスへコピーすることです。多くのクライアントには「設定をエクスポート」「設定フォルダを開く」といった入口が用意されており、ローカルに保存された YAML ファイルを見つけ、USB メモリ・LAN 経由の転送・クラウドストレージの同期フォルダなどを使ってターゲットデバイスに移し、対応クライアントの「設定をインポート」機能で読み込みます。

1. 設定ファイルの場所を特定する

   クライアントの設定内で「設定フォルダを開く」またはそれに類する入口を見つけると、現在有効な YAML ファイルとサブスクリプションのキャッシュファイルが確認できます。

2. ファイルをターゲットデバイスにコピーする

   任意の転送手段(LAN 共有、クラウドストレージ、データケーブル)でファイルをターゲットデバイスがアクセスできる場所に置きます。

3. ターゲットクライアントでインポートする

   「ファイルから設定をインポート」機能でそのファイルを選択し、クライアントの解析完了を待って、ノードとルールが正常に読み込まれているか確認します。

この方法はネットワークサービスに依存せず、オフラインでも完結するため、設定を大量に手作業で調整していてサードパーティの WebDAV サービスに依存したくない場面に向いており、一回限りの「設定移行」やオフラインアーカイブとしてもよく使われます。欠点も明確で、すべて手作業に依存するため、変更が他のデバイスに自動で伝播せず、デバイスが増えるほど更新漏れが起きやすくなります。さらに、クライアントによって YAML フィールドの対応状況にわずかな差があり、たとえば一部デスクトップ版特有のグループ戦略フィールドをモバイル版クライアントが正しく解析できないこともあるため、インポート後は項目ごとの確認が必要です。

3つの方法をどう選ぶか:シーン別比較

実際の運用では、3つを単独で選ぶのではなく組み合わせるケースが多いです。比較的堅実な組み合わせは、日常はサブスクリプションでノードの更新を保ち、定期的に WebDAV で機器全体をバックアップして不意の設定消失を防ぎ、大きな変更を行う前に手動で YAML をエクスポートして控えを残す、という三層構成です。どれか一層に問題が起きても、他の手段が退路として残ります。

同期後によくあるトラブルシューティングの考え方

方式を選んでも、同期後に「設定が反映されない」といった状況に遭遇することはあります。よくある確認方向をいくつか挙げます。

• クライアントが設定を再読み込みしているか確認する。一部のクライアントは設定のインポートや更新後、手動で「適用」をクリックするかコアを再起動しないと反映されず、すべてのフィールドが自動でホットリロードされるわけではありません。
• サブスクリプションの解析が途中で切れていないか確認する。サブスクリプションリンクの返す内容が大きすぎる、あるいはクライアントが対応していないフィールドを含む場合、解析が途中で失敗しノードリストが「一部欠けている」ように見えることがあります。この場合はクライアントのログや更新ログでエラー原因を確認することをおすすめします。
• TUN モードなどシステムレベルの設定が移行されているか確認する。TUN モードは仮想ネットワークカードとシステムのルーティングテーブルに関わるため、一部のクライアントはこの種の設定を YAML 設定ファイルではなくアプリ層の環境設定に置いています。単に設定ファイルを同期しただけでは TUN のオン・オフ状態は引き継がれないため、新しいデバイスで個別に確認する必要があります。
• モバイル版とデスクトップ版のルール構文の差異。ルールセット内でリモートのルールセットアドレスではなくローカルファイルパスを参照している場合、別のデバイスに移すとパスが無効になる可能性が高いです。可能な限りローカルファイル参照ではなくリモートルールセットを使い、移行時のパス依存を減らすことをおすすめします。

まとめ

複数デバイスでの設定不一致という問題は、本質的には「ローカルファイル」と「デバイス間の共有」の間にある避けがたい矛盾です。サブスクリプションはノードレベルの自動同期を解決し、WebDAV バックアップは機器全体のスナップショット式の移行能力を提供し、手動エクスポートは最も基本的ながら最もコントロールしやすいオフライン方式です。どれも万能ではなく、自分の利用頻度・デバイス数・カスタムルールへの依存度に応じて組み合わせることで、複数デバイス間のプロキシ挙動を本当に一致させることができます。