Clash 設定のマルチデバイス同期:スマホとPCでサブスクリプションとルールを揃える実践方法

まず整理:マルチデバイス同期で扱うのは実は2種類の情報

マルチデバイス同期を語る前に、1台のデバイス上の Clash クライアントが実際に何を保持しているのかを分解してみましょう。設定は大きく2種類に分けられます。1つはサブスクリプションから取得するもの、もう1つは端末ローカルに保存されるものです。

サブスクリプションで配信される内容には、ノードリスト、プロキシポリシーグループ、振り分けルールが含まれます。これらはサブスクリプションリンクの提供元が管理しており、提供元が更新すれば各端末で再取得すれば同じ内容が手に入ります。一方、端末ローカルの設定は全く別物です。動作モード(ルール/グローバル/直接接続)、Mixed ポート、システムプロキシのオン/オフ、TUN モード、自動起動、UI の好み設定などは、すべて各デバイスのローカルストレージに書き込まれており、どの同期方式を使っても代わりに移動してくれません。

つまりマルチデバイス同期の本質は、サブスクリプション内容の一元配信とタイムリーな更新をどう実現するかであり、端末ローカルの設定は1台ずつ手動で設定するしかありません。以下の3方式の違いも、この「サブスクリプション内容をどう配信するか」という部分にあります。

方式1:サブスクリプションリンクによる自然同期

適用場面:すべてのノードが同一のサブスクリプション提供元から来ていて、独自ルールをほとんど、あるいは全く維持していない場合。これは最も運用コストの低い方式で、多くの人にとっての出発点でもあります。

やり方は一言で言えば「同じサブスクリプションリンクを各デバイスのクライアントにそれぞれ1回追加する」だけです。ノード、ポリシーグループ、ルールはすべてサブスクリプション内容から来るため、提供元が更新した後は各端末でそれぞれ更新ボタンを押せば一致した状態に戻ります。

1. サブスクリプション提供元の管理画面で、Clash または Clash Meta(mihomo)向けと明記されたサブスクリプションリンクをコピーします。
2. デスクトップ版(Clash Verge Rev、Clash Nyanpasu など)では設定ページで新規リモート設定を作成し、リンクを貼り付けて保存します。
3. Android 版(Clash Meta for Android、FlClash)でも同様にサブスクリプション設定を新規作成します。iOS 版クライアントも操作は同じです。
4. 各端末の自動更新間隔を24時間前後に設定しておけば、ノードとルールが提供元の更新に合わせて自動的に揃います。

この方式で陥りやすい落とし穴:

• クライアントの差異:一部のクライアントはデフォルトで汎用ノードリストを取得してローカルで変換する仕組みになっており、Clash 設定を直接配信するサブスクリプションとは挙動が異なります。できるだけ提供元が Clash または mihomo 向けと明記したサブスクリプションアドレスを使いましょう。
• 更新タイミング:各端末の自動更新のタイミングが異なるため、ノードリストが一時的に不一致になることがありますが、これは正常な現象です。手動で1回更新すれば揃います。
• UA テンプレート:一部の提供元はクライアントの識別情報によって異なる設定テンプレートを配信するため、2台のデバイスで取得したルールの細部に差が出ることがあります。詳細は提供元のドキュメントを確認してください。

方式2:プライベート設定ホスティングで独自ルールを一括配信

適用場面:大量の独自ルールや複数のポリシーグループ、DNS セクションを自分で管理していて、すべてのデバイスにバイト単位で同一の設定を届けたい場合。

やり方は、整えた完全な YAML 設定を自分だけがアクセスできる URL に置き、各端末でこれをリモートサブスクリプションとして追加するというものです。以降は設定を変更する際にこの1つのファイルだけを修正し、各端末で更新すれば反映され、ルールの順序、ポリシーグループの構造、DNS の挙動がすべて一致します。

実現可能なホスティング方法:

• プライベート Git リポジトリ:GitHub のプライベートリポジトリの raw ファイルリンクとアクセストークンを組み合わせる、あるいはプライベート Gitee リポジトリを使う方法。変更をコミットした後、各端末でサブスクリプションを更新すれば反映されます。
• 自前でのサブスクリプション変換サーバー:自分のサーバーや NAS 上で subconverter のようなバックエンドを動かし、アップストリームのサブスクリプションと独自ルールテンプレートから完全な Clash 設定を出力する方法。アドレスには専用のトークンを付与します。
• LAN 内の静的サービス:NAS や自宅サーバーで WebDAV や簡易 HTTP サービスを立てて設定ファイルを公開する方法。家庭内 LAN や暗号化トンネル経由のみでアクセス可能にします。

ホスティングした設定内で必要に応じてリモートルールセットを参照する mihomo の設定例:

mixed-port: 7890
dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
rule-providers:
  my-rules:
    type: http
    behavior: classical
    url: "https://your-hosting-address/rules/my-rules.yaml"
    path: ./providers/my-rules.yaml
    interval: 86400
rules:
  - RULE-SET,my-rules,Proxy
  - MATCH,DIRECT

この方式で陥りやすい落とし穴:

• カーネルの差異:Clash Meta(mihomo)は rule-providers や tun といったフィールドをサポートしていますが、開発が終了した旧来の Clash はこれらのキーを認識しません。共有設定は各端末のカーネルに共通する部分のみで書くか、カーネルごとに2種類の設定を別々に管理する必要があります。
• 資格情報の保護:設定にはノードのサーバーアドレスとパスワードが含まれているため、ホスティングするアドレスには推測不可能なアクセス資格情報を必ず付与してください。漏洩した場合の影響はサブスクリプション漏洩と同等です。
• キャッシュの問題:Git プラットフォームの raw リンクにはキャッシュがあり、変更直後に更新すると古いバージョンが取得されることがあります。数分待つか、URL にバージョンパラメータを付加してください。
• パスの問題:設定内でローカルルールファイルを参照するパスはプラットフォームごとに異なります。できるだけ rule-providers によるリモートルールセットに切り替え、相対パスの使用は避けましょう。

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

適用場面:デバイスが2〜3台しかなく、設定の変更頻度が低い場合、あるいはいかなるデータも第三者を経由させたくない場合。

デスクトップ版クライアントは通常、現在の設定を YAML ファイルまたは完全なバックアップとしてエクスポートする機能をサポートしており、スマホ版クライアントはファイルからのインポートに対応しています。転送は LAN 経由のファイル共有、USB メモリ、暗号化した圧縮ファイルなどで行います。

1. メインで使っているデバイスで現在有効な設定ファイルをエクスポートします。
2. LAN 経由または暗号化した圧縮ファイルでファイルを対象デバイスに送ります。
3. 対象デバイスのクライアントで「ファイルからインポート」を選択し、保存して有効化します。
4. ポート、DNS、TUN の設定が期待どおりに反映されているか、項目ごとに確認します。

この方式で陥りやすい落とし穴:

• バージョンのズレ:片方の端末だけ変更してもう一方を忘れると、数週間後には2つの設定が食い違ってしまいます。トラブルシューティング時はまず両方のファイルの更新日時を確認しましょう。
• プラットフォームの差異:Android クライアントの設定フィールド対応状況はデスクトップ版の mihomo と完全には一致していません。インポート後は DNS と TUN のセクションが実際に反映されているか確認しましょう。
• 認可情報は持ち運べない:HTTPS 復号証明書や TUN に必要な管理者権限・VpnService の許可は各デバイスに紐づいており、設定ファイルとともに移動することはできません。デバイスごとに再度許可する必要があります。

3方式の比較と選び方のポイント

方式	同期される内容	一致性	資格情報のリスク	運用コスト	向いている人
サブスクリプションリンクによる自然同期	提供元から配信されるノードとルール	高い(同一ソースから取得)	サブスクリプションリンクを秘匿する必要あり	最低	ノードが単一のサブスクリプションから来ており、ルールをあまり触らない人
プライベート設定ホスティング	独自の完全な設定	最も高い(同一ファイル)	ホスティング方法による	中	独自ルールとポリシーグループを本格的に管理する人
手動エクスポート/インポート	エクスポート時点のスナップショット	時間とともにズレる	第三者を経由しない	低いが毎回手動対応	デバイスが少なく変更頻度も低い、プライバシー重視の人

多くの人にとっての最適解は方式1をベースにすることです。サブスクリプションリンクでノードとルールを解決し、端末ローカルの設定は1台ずつ一度設定しておけば十分です。独自ルールが本格的な規模になってきたら方式2が検討に値します。方式3は出張時の応急対応やプライバシー要件が非常に高い場面向けと言えます。

同期以外に各端末で個別対応が必要なこと

• 動作モード、Mixed ポート、システムプロキシ、自動起動はすべて端末ローカルの設定であり、3つの方式のいずれでも同期されません。1台ずつ一度設定すれば十分です。
• TUN モードはデバイスごとに個別にオン/オフします。デスクトップ版では管理者権限または root 権限が必要で、Android では VpnService の許可ダイアログを経由します。許可結果は端末間で共有されません。
• 各端末のカーネルバージョンはできるだけ近づけておきましょう。メジャーバージョンをまたぐ場合、新しいフィールドはまず mihomo のドキュメントを確認したうえで共有設定に書き込んでください。
• システム時刻は正確でなければなりません。サブスクリプションの更新とノードの TLS ハンドシェイクはいずれも正しい時刻に依存しており、ズレが大きいと直接失敗します。サブスクリプションが取得できない、あるいはノードが全滅でタイムアウトするといった症状として現れます。
• 設定を変更した後の効果確認は、感覚に頼るよりクライアントのログと接続パネルで各コネクションがどのルールにヒットしたかを見るのが確実です。