Clash のマルチデバイス設定同期方法比較:サブスクリプションリンク・WebDAV バックアップ・手動エクスポートはそれぞれ誰向けか

スマホ、パソコン、タブレットにそれぞれクライアントを入れた後、設定をどう一致させるか?本記事ではサブスクリプションリンクによる一元配信、WebDAV クラウドバックアップ、手動エクスポート/インポートの3つの方法について、適用場面・運用コスト・よくある落とし穴を比較します。

なぜマルチデバイスの設定は「それぞれ別物」になりやすいのか

パソコンには Clash Verge Rev、スマホには FlClash や Clash Meta for Android、タブレットにはさらに ClashX Meta を入れる——これが多くのユーザーの実際の使い方です。問題は、Clash 系クライアントの中心的な設定(プロキシノード、ルールセット、DNS 部分)は通常、1つのローカル YAML ファイルとして保存され、3台のデバイスがそれぞれ個別に管理することになる点です。時間が経つと、ノード情報が古くなったり、ルールのバージョンが不一致になったり、どこかのデバイスだけ更新漏れが起きたりします。さらに厄介なのは、あなたが手動でルールを編集する習慣がある場合(例えば特定のドメインに DIRECT を1行追加するなど)、その変更は編集した当のデバイスにしか残らず、別のデバイスに移ると見つからなくなることです。

解決の方向性は大きく3つに分けられます。設定を「自動的に更新させる」(サブスクリプションリンク)、設定を「クラウドに保存する」(WebDAV バックアップ)、設定を「人手で運ぶ」(手動エクスポート/インポート)。この3つは排他的なものではなく、実際には組み合わせて使うことが多いのですが、重視するポイントと運用コストはかなり異なるため、選択を誤ると後から何度も手直しすることになります。

方法1:サブスクリプションリンクによる一元配信

これが最も一般的で、主軸として推奨される方式です。プロバイダー(機場)や自前で構築したノードサービスから、サブスクリプションリンク(Subscription URL)が発行されます。クライアントは定期的にこのリンクにリクエストを送り、最新のノードリストを取得して、クライアント側で設定したルールテンプレートに従って完全な設定を再構築します。複数のデバイスに同じサブスクリプションリンクを登録しておけば、理論上はノード情報の同期が保たれます——全員が同じ「ソース」から取得しているからです。

# 一般的なサブスクリプションリンクの構造例
https://sub.example-provider.com/link/abcdef123456?clash=1

# クライアントは内部でこのリンクに定期的にリクエストを送り、proxies と proxy-groups フィールドを更新する

サブスクリプションリンクによる同期の範囲は正しく理解しておく必要があります。同期されるのはノードとプロバイダー側が用意したグループテンプレートだけで、クライアント側でローカルに追加した独自ルールや DNS の上書き、UI の設定などは含まれません。パソコン上で手動で rules にいくつかルールを追加した場合、スマホに乗り換えてサブスクリプションを更新しても、これらの手動ルールは自動的には反映されません——クライアントが「オーバーライド(Override)」機能をサポートしていて、独自のスニペットを別ファイルとして保存し、サブスクリプションと併用する場合を除きます。

• 向いている人:ノードをサブスクリプションサービスから取得していて、手動でルールを変更することがほとんどないユーザー。
• メリット:一度設定すれば、以降のノード更新は全自動で、複数デバイスで自然にノード情報が一致する。
• 限界:独自ルール、グループ名、UI 設定は同期されない。

方法2:WebDAV によるクラウドバックアップ

一部の主要なクライアント(例えば Clash Verge Rev)には、設定ファイルの WebDAV バックアップ・復元機能が内蔵されています。考え方としては、完全な設定ファイル(ノード、ルール、グループ、一部のローカル設定を含む)を自分の WebDAV サービス(自前で構築した Nextcloud でも、WebDAV プロトコルをサポートするクラウドストレージでもよい)にアップロードし、他のデバイスは同じ WebDAV ディレクトリから取得して復元する、という流れです。この方式の利点は「全量同期」であることです——サブスクリプションリンクがノードだけを同期するのに対し、WebDAV バックアップは手動で調整したルールやグループの順序まで一緒に運んでくれます。

# WebDAV 設定項目の例(クライアントの設定画面で入力するもので、設定ファイルに手書きするものではない)
WebDAV アドレス: https://dav.example.com/remote.php/dav/files/username/
ユーザー名: your-account
パスワード: アプリ専用パスワード(ログイン用のメインパスワードは使わない)

WebDAV 同期を使う際に見落としやすい点があります。それは「バックアップ / 復元」モデルであり、ドキュメント共同編集ソフトのようなリアルタイムの双方向マージではないということです。つまり、パソコンでルールを変更してバックアップをアップロードした後、スマホで別の箇所を変更したものの最新バックアップを先に取得していなかった場合、両者の変更は統合されずに互いを上書きしてしまいます。正しい運用手順は、設定を変更する前に必ず現在のデバイスで「最新バックアップを取得」し、変更後に「バックアップをアップロード」することです。この順序を習慣にすれば、ほとんどの競合を避けられます。

• 向いている人:頻繁に手動でルールを微調整し、複数デバイスの設定を(ノードだけでなく)完全に一致させたいユーザー。
• メリット:独自ルールやグループ構成を含めた全量同期が可能。
• 限界:自前の WebDAV サービスが必要で、自動マージには対応しないため、操作順序を誤ると互いを上書きしてしまう。

方法3:手動エクスポート/インポート

最も原始的だが、最も自分でコントロールしやすい方法です。1台のデバイスで設定ファイル(通常は .yaml や .yml)をエクスポートし、任意の手段(メール、チャットツール、ローカルネットワーク転送、USB メモリ)で別のデバイスに渡し、目的のクライアントで手動インポートします。この方法はクラウドサービスやサブスクリプション機構に依存しないため、一時的な問題調査、自分で調整した分流ルールを誰かに共有する場合、あるいはデバイス数が少なくたまにしか更新しない場合に向いています。

# 多くのクライアントの設定ファイルのローカル保存先(一般的な例)
Windows:  %USERPROFILE%\.config\clash\profiles\
macOS:    ~/Library/Application Support/clash/profiles/
Linux:    ~/.config/clash/profiles/

手動エクスポート/インポートの最大の欠点は、自動更新されないことです——今日渡したファイルのノード情報は、エクスポートしたその瞬間のまま止まり、プロバイダー側のバックエンドでノードアドレスが変更されても、手動でインポートした設定は追随しません。したがってこの方式は「一度きりの受け渡し」や「緊急時のバックアップ」として使うのが適しており、長期的なマルチデバイス同期の主軸としてはおすすめしません。逆に、パソコンで調整したルールの断片をスマホ側に参考として渡したいだけであれば、この方法が最も直接的で、追加のクラウドサービスアカウントを設定する必要もありません。

• 向いている人:たまにデバイスを乗り換える人、特定の1つの設定を厳密に管理したい人。
• メリット:サードパーティのサービスに依存せず、プロセスを完全にコントロールできる。
• 限界:自動更新機能がなく、長期使用すると同期を忘れてノード情報が古くなりやすい。

3つの方法をどう選ぶか

実際の場面では、多くのユーザーは3つのうち1つだけを選ぶのではなく、用途に応じて組み合わせて使います。以下の比較表で主力の方式を素早く判断できます。

比較的安定した組み合わせとしては、主力のノードはサブスクリプションリンクで自動更新させ、独自ルールの断片は別のオーバーライドファイルとして書いてサブスクリプションと併用する、というものです。クライアントが WebDAV に対応しているなら、それを唯一の同期手段ではなく「ルールとグループ構成」の定期バックアップ手段として使うとよいでしょう。こうすればある日 WebDAV サービスが使えなくなっても、サブスクリプションリンクによってノードの利用は保証され、両方が同時に止まることはありません。

よくある質問のトラブルシューティング