複数端末で Clash 設定を同期する方法:サブスクリプションリンク・WebDAV・手動エクスポート

「複数端末で設定がバラバラになる」のは季節性のよくある悩みのようなもので、命に関わるほどではないものの、確実に気力を削ってきます。ノードが繋がったり繋がらなかったり、ルールが効いたり効かなかったり。まずノードを疑う前に、原因を切り分けてから対処法を選びましょう。

症状:複数端末の設定はなぜどんどんズレていくのか

まずは症状から。PC・スマホ・タブレットで Clash を同時に使っている人の相談内容は、だいたい次の3つに集約されます。

• ノードが同期されない:メイン端末でサブスクリプションを更新したのに、新しく追加されたノードが別の端末には見当たらず、古いノードだけがすでに使えなくなっている。
• ルールが一致しない:ある端末で特定サイトを直接接続に設定したのに、別の端末に切り替えると同じサイトがプロキシ経由になっている。原因は「その変更が他の端末に伝わっていなかった」だけと後で気づく。
• 接続断が一気に発生する:サブスクリプションの更新やプラン変更を1台の端末でしか行わず、残りの端末が次々と接続できなくなり、「ノードが全滅した」と誤解してしまう。

原因は一言で説明できます。Clash の設定(プロファイル)は各端末のローカルディレクトリにファイルとして保存されており、クライアント同士はお互いの状態を把握していません。更新ボタンを押した端末だけが最新化され、押していない端末は古い設定のまま使い続け、ノードが失効して初めて問題が発覚します。根本的な解決策は2つしかありません。設定の出どころを1つに絞るか、各端末を定期的に揃えるか。以下の3つの対処法は、症状の重さに応じたものです。

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

向いている症状:ノードやルールがほぼサブスクリプション由来で、独自の変更が少なく、端末が3台以上ある場合。最も手間がかからず、多くの人にとっての最適解です。

やり方は、同一のサブスクリプションリンクを各端末にそれぞれ登録し、あとは各端末で個別に定期更新をかけるだけです。設定内容はサブスクリプションサーバー側で管理されており、各端末が取得するのは同じ内容なので、「誰かが同期を忘れる」という問題自体が発生しません。

手順は次の通りです。

1. 各端末のクライアントで、同一のサブスクリプション URL を使ってリモート設定(プロファイル)を新規作成し、名前も揃えておくと後で見分けやすくなります。
2. 自動更新を有効にします。Clash Verge Rev ではサブスクリプション項目ごとに更新間隔を設定でき、mihomo 系のモバイルクライアントも定期更新に対応しているものが多いです。間隔は24時間程度が目安で、短すぎるとリクエストが増えるだけ、長すぎるとノードの変化に追いつけません。
3. サブスクリプションの内容そのままでは使いにくい場合(独自ルールを常に追加したい、グループを調整したいなど)は、サブスクリプション変換の段階で一度処理し、各端末では変換後の同じリンクを登録します。以後の変更は変換部分だけ直せば済みます。

禁忌:独自の変更をサブスクリプションが生成した設定ファイルに直接書き込むのは避けましょう。次回の更新で上書きされてしまいます。変更はクライアント側の上書き機構で行うのが基本で、Clash Verge Rev ならグローバル拡張設定(Merge / Script)、mihomo 系の設定なら独自部分とサブスクリプション部分を分けて管理します。これならサブスクリプションは通常通り更新され、独自の変更も維持されます。

対処法2:WebDAV 同期

向いている症状:独自の変更が多い(自作ルール、複数のローカル設定を並行運用など)場合で、1箇所を直せば全端末に反映されてほしいというケース。

FlClash をはじめとするマルチプラットフォーム対応クライアントには WebDAV 同期が組み込まれており、一部のデスクトップクライアントにも WebDAV バックアップ機能があります。仕組みは同じで、設定フォルダをまとめて同一の WebDAV アカウントにアップロードし、他の端末は同じアカウントから取得して復元します。Nutstore(ナットストア)、Nextcloud、Synology NAS の WebDAV サービスがこの「保管庫」として使えます。

手順は次の通りです。

1. WebDAV アカウントを用意します。Nutstore ならセキュリティ設定でサードパーティアプリ用パスワードを有効にし、自前で構築した Nextcloud ならサーバーアドレス・アカウント・パスワードの3つを控えておきます。
2. メイン端末のクライアントに WebDAV 情報を入力し、一度バックアップアップロードを実行します。
3. 残りの端末には同じアカウント情報を入力し、復元ダウンロードを実行します。以後は大きな変更をしたたびにアップロードし、自動同期に対応しているクライアントなら定期実行を設定しておきましょう。

禁忌は3点あります。

• WebDAV が同期するのは設定ファイルであり、実行中の状態ではありません。復元後は有効な設定の再選択、遅延の再テスト、プロキシモードの再確認が必要です。
• 多くの実装は「後から書いた方が先の内容を上書きする」方式です。2台の端末で相次いで変更してから同期すると、先に変更した内容が消えてしまいます。「変更したらすぐアップロード、使う前には必ずダウンロード」という順序を習慣化しましょう。
• 設定にはサブスクリプションアドレスやノードの認証情報が含まれるため、WebDAV アカウントの保護レベルはプロキシアカウント本体と同等にすべきです。専用の強固なパスワードを設定し、二段階認証が使えるなら必ず有効にしましょう。

復元が完了したら、まずコマンドで通信できるか確認してから本格的に使い始めましょう。

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

向いている症状:端末が少ない(1〜2台)、変更頻度が低い、あるいは機種変更やOS再インストール時に一度だけ移行したいケース。手間が最も少なく、誰でもすぐ試せます。

やり方は、設定ファイルを1台の端末から別の端末にコピーするだけです。デスクトップクライアントは設定管理画面にエクスポート機能があるか、設定フォルダから直接 YAML ファイルを取り出せます。モバイル端末は共有機能やエクスポート機能を使い、ローカルネットワーク転送、クラウドストレージ、ケーブル接続などの手段で送れます。

手順は次の通りです。

1. 元の端末で設定をエクスポートします。Clash Verge Rev の設定フォルダは通常、システムのアプリデータディレクトリ内の profiles フォルダにあり、サブスクリプションごとに1つの YAML ファイルが対応しています。FlClash などのクライアントは設定画面にエクスポート機能が直接用意されています。
2. YAML ファイルを移行先の端末に送り、クライアントで「ローカルファイルをインポート」を選択します。
3. インポート後はポート設定を確認しましょう。両端末の mixed-port や外部制御ポートが競合または異なる場合は、移行先の端末の運用に合わせて修正します。
4. サブスクリプションの更新アドレスも確認しましょう。YAML がサブスクリプション更新後の生成物である場合、移行先の端末ではあくまで静的な1つのファイルにすぎません。以後の更新には移行先の端末で改めてサブスクリプションリンクを登録するか、この手順を定期的に繰り返す必要があります。

ヒント

手動エクスポートで得られるのは、ある時点のスナップショットです。機種変更などの移行には向いていますが、長期的に設定を揃え続けるには不向きで、時間が経てば再び端末間でズレが生じます。

処方の比較:3つの方式をどう選ぶか

3つの方式は特性が異なります。端末数、変更頻度、サブスクリプションへの依存度という3つの観点で選びましょう。

複数の方式を組み合わせるケースもよくあります。サブスクリプションリンクでノードの新鮮さを保ちつつ、WebDAV や手動エクスポートで独自ルールやローカル設定を運びます。両者は競合せず、それぞれ役割分担できます。

注意点:同期後に気をつけること

処方が決まったら、あと少し注意点を押さえておきましょう。せっかく整えた設定が、同期のたびにまた乱れてしまわないように。

• ポートを揃える:各端末の mixed-port(デフォルト 7890)はできるだけ統一しておきましょう。ブラウザのプロキシ設定やコマンドラインツールの設定を1セットで共通利用できます。
• モードを合わせる:ルール・グローバル・直接接続の3モードは各端末のローカルな状態であり、設定の同期対象には含まれません。端末を切り替えたら、まずモードを確認してから他の項目を見ましょう。
• 内核バージョンを大きく離さない:新しい mihomo の設定項目(sniffing 関連の書き方など)は、古い内核では読み込みエラーになることがあります。複数端末で同じ YAML を共有する場合は、最も古いバージョンのクライアントの文法に合わせましょう。
• TUN とシステムプロキシは端末ごとの設定:設定ファイルには含まれず、各端末で個別に必要に応じて有効化する必要があります。1台で有効にしたからといって、他の端末にも反映されているわけではありません。
• 変更前に控えを残す:ルールを大きく変更する前に、変更前の設定を一度エクスポートして保管しておきましょう。同期の仕組みは、誤りもそのまま忠実に全端末へ配信してしまいます。

複数端末の運用は、本質的には技術的な難題ではなく「仕組みづくり」の問題です。設定の出どころを1つに決め、更新のルールを決めてしまえば、あとはクライアントが決まった時間に実行してくれます。出どころが乱れてしまうと、どれだけツールを増やしても取り返せません。