Clashの複数デバイス設定同期ガイド：サブスクリプションの共有、オーバーライドファイル、プライベートストレージ

まず設定を同期可能な部分とデバイス固有の部分に分ける

Clashの複数デバイス同期は、1つの完全なYAMLファイルをすべての端末にコピーすることではありません。デスクトップOS、モバイルOS、クライアントごとに、設定ディレクトリ、ネットワークインターフェース、システムプロキシ、TUN権限の扱いは異なります。実行中の設定全体をそのまま上書きすると、ノードは読み込めても、ポートが競合したり、TUNの起動に失敗したり、モバイル端末がデスクトップにしか存在しないファイルパスを参照したりすることがあります。

安定した運用には、まず設定を3つの層に分けます。リモートサブスクリプションはノードとサービス提供元が配布するポリシー情報を担当し、共有オーバーライドはカスタムルール、ポリシーグループ名、共通DNSロジックを担当します。デバイス固有の層には、リッスンアドレス、ポート、コントローラー、TUN、ネットワークインターフェース、クライアント状態を置きます。同期するのは前の2層だけにし、デバイス固有の層は各クライアントで個別に保存します。

方法1：各デバイスで同じサブスクリプションを共有する

サブスクリプションの共有は、最も手軽な複数デバイス運用です。各デバイスに同じサブスクリプションURLを保存し、それぞれのクライアントが定期的に取得してローカル設定を生成します。ノードの追加・削除、名称変更、サービス提供元のルール更新はサブスクリプションの更新時に反映されます。一方、ポート、TUN、システムプロキシの状態はローカルクライアントが管理します。

デバイス数が少なく、ノード一覧を揃えることが主な目的のケースに適しています。デバイス同士が互いに見える必要も、パソコンを常時起動しておく必要もありません。あるデバイスで更新に失敗しても、他のデバイスはそれぞれの更新間隔で動作を続けられます。

サブスクリプション共有の注意点

サブスクリプションURLには通常、アカウントを識別するパラメーターが含まれているため、一般的なWebリンクではなくアクセス認証情報として扱う必要があります。公開コードリポジトリ、スクリーンショット、サポートチケット、公開共有ドキュメントに記載しないでください。デバイスを譲渡・紛失した場合や使用を終了する場合は、クライアントからサブスクリプションを削除し、サービス提供元が対応していれば認証情報も更新します。

サービス規約にある同時接続数とデバイス数の制限にも注意が必要です。同じサブスクリプションを複数のクライアントに追加できるからといって、サービス側がそれらのデバイスによる大量の同時接続を許可するとは限りません。ノードは表示されるのに接続を拒否される場合は、アカウントの状態、同時接続上限、ノードの利用可能性を併せて確認してください。

更新間隔と失敗時の対処

1. まず普段使うデバイスで手動更新し、Clashまたはmihomoが解析できる設定内容がサブスクリプションから返されることを確認します。
2. その後、他のデバイスは一定の間隔で更新し、短時間にリクエストを繰り返さないようにします。
3. 更新後はポリシーグループにメンバーが残っているか確認し、ノード名の変更によって手書きのポリシー参照が無効になっていないか確認します。
4. クライアントで直前に使えていた設定を1つ保存しておきます。新しい設定の解析に失敗した場合は、まず以前の設定に戻し、その後レスポンス内容とフィールドの互換性を確認します。

サブスクリプションの共有で揃えられるのは「ノードの取得元」であり、手動追加したルール、ポリシーグループの選択結果、各デバイスのクライアント設定まで自動的に同期されるわけではありません。これらも統一したい場合は、サブスクリプションから生成されたメイン設定を何度も編集するのではなく、オーバーライド層を追加します。

方法2：オーバーライドファイルでルールとポリシー構成を統一する

オーバーライドファイルを使うと、個人で管理する設定ロジックをサブスクリプションの結果に重ねられます。オーバーライド、マージ、スクリプト処理に対応したクライアントでは、サブスクリプション更新後にルールを自動追加したり、ポリシーグループを変更したり、一部のDNSフィールドを置き換えたりできます。リモートのノード更新を維持しながら、更新のたびに生成ファイルを編集し直す手間を省けます。

クライアントによって「オーバーライド」の定義は異なります。YAMLキー単位でマージするもの、JavaScriptで設定オブジェクトを処理するもの、単純な前置・後置ルールだけを提供するものもあります。導入前に、クライアントが実際に対応している処理順を確認してください。特に、配列が追加、置換、名前によるマージのどれで処理されるかが重要です。rules、proxies、proxy-groupsでは、配列の処理方法が最終結果を直接左右します。

共有オーバーライドは小さく明確に保つ

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - MATCH,ノード選択

上の例はルールの順序だけを示しており、ポート、コントローラー、TUNは扱いません。実際に使う際は、ノード選択が最終設定のポリシーグループ名と完全に一致している必要があります。ルールは上から順に照合され、フォールバックルールは末尾に置きます。オーバーライドツールがルールの挿入位置を誤ると、追加した項目が一度もマッチしない可能性があります。

実行状態を設定同期と混同しない

ポリシーグループで現在選択されているノードは、クライアントがローカルデータベースやキャッシュに書き込んでいる場合があり、YAMLに存在するとは限りません。同じ設定を読み込んだ2台のデバイスでも、Aのデバイスが「香港ノード」を選択している一方、Bのデバイスは「自動選択」のままということがあります。これは通常、妥当な動作です。モバイル回線、家庭用ブロードバンド、会社のネットワークでは遅延が異なるためです。統一すべきなのはポリシーグループの構成であり、一時的な選択状態を無理にコピーすることではありません。

方法3：LAN経由で設定ファイルを転送する

LAN転送は、一時的な移行、初回セットアップ、少数の管理対象デバイスに適しています。たとえば、パソコンで設定を整理した後、OSのファイル共有、AirDrop、ケーブル接続によるファイル転送、ローカルファイルサーバーを使ってスマートフォンやタブレットに渡します。公開共有ページを経由する必要はなく、転送後に共有サービスを停止することもできます。

この方法は手順が分かりやすく、完全なYAML、ルールセット、説明ファイルの受け渡しに向いています。一方、以後の更新は手作業になります。デバイスが増えると、同じファイル名で内容が異なる、古い設定が新しい設定を上書きする、特定のデバイスだけ更新し忘れるといった問題が起こりやすくなります。そのためLAN転送は「配布作業」としては適していますが、長期的な自動同期の仕組みには向きません。

LAN転送のチェックリスト

1. 送信前に設定エディターの自動保存による競合を無効にし、ファイルの内容が完全に書き込まれていることを確認します。
2. ファイル名または同じフォルダー内の説明ファイルに日付とバージョンを記録し、複数のバージョンを config.yaml だけで区別しないようにします。
3. インポート後、まず設定の構文チェックを実行し、その後にシステムプロキシまたはTUNを起動します。
4. 受信側のデバイスが、送信側のLANリッスンアドレス、コントローラーアドレス、プラットフォーム専用パスを引き継いでいないことを確認します。
5. 転送が終わったら一時共有フォルダーを閉じ、受信側デバイスのダウンロードフォルダーにある重複コピーを削除します。

LAN内でHTTPを使ってファイルを提供する場合は、信頼できるネットワークからアクセスできるアドレスだけにバインドし、共有時間も制限します。公衆無線LANでは他の端末も同じネットワークセグメントにいる可能性があるため、「LAN内のみ」だからといってアクセス範囲が自動的に制御されるわけではありません。

方法4：プライベートストレージで共有設定を管理する

ルールやオーバーライドファイルを継続的に管理する場合は、共有層を自分で管理するGitリポジトリ、WebDAV、家庭用ストレージデバイス、アクセス制御付きのオブジェクトストレージに置く方法があります。各デバイスは、クライアント対応のリモート設定機能、ファイル同期ツール、または手動ダウンロードで最新版を取得します。デバイス数が多く、設定の変更履歴を明確に管理したい場合に適しています。

プライベートストレージで重要なのは、単にファイルをリモートに置くことではなく、アクセス認証情報、バージョンのロールバック、競合処理の方法を決めることです。ファイルの書き込み途中で同期ツールがクライアントの再読み込みを発生させると、一時的な解析エラーが起こる可能性があります。より安全な手順は、まず一時ファイルにダウンロードし、構文チェックを完了してから正式な設定を置き換えることです。クライアント内蔵のリモートサブスクリプションを使う場合は、ダウンロードと切り替えをクライアントに任せ、別の同期ツールで同じファイルを同時に書き換えないでください。

機密情報と共有ロジックを分離する

共有リポジトリには、ルール、ポリシーグループのテンプレート、公開ルールセットへの参照を保存するのが適しています。サブスクリプションの認証情報、コントローラーのパスワード、非公開ノードの認証情報は、より厳格に権限管理された場所に置くか、各デバイスで個別に入力します。ストレージサービスへのログインが必要な場合でも、最小限のアクセス範囲でアカウントを割り当て、複数の家族やデバイスで管理権限を共有しないようにします。

クライアントが変数置換や外部キーファイルに対応していない場合、自動化を優先してすべての情報を1つの長期同期YAMLにまとめないでください。デバイスの認証情報を含まない基礎テンプレートを用意し、端末にインポートした後でローカルフィールドを追加します。手順は1つ増えますが、問題の切り分けが明確になり、デバイスの利用停止時にもアクセスを個別に取り消せます。

Git、WebDAV、家庭用ストレージの選び方

おすすめの運用フロー：サブスクリプション、共有層、ローカル層を分けて管理する

多くの個人ユーザーにとって、バランスのよい構成は次のとおりです。各デバイスでサブスクリプションURLを個別に保存し、ルールとポリシーテンプレートは管理された1つの場所に置き、ポート、TUN、コントローラー、システムプロキシの設定はローカルに残します。これにより、ノード一覧はサブスクリプションで更新され、共有ルールの管理元は1つに集約され、プラットフォームの違いがリモートファイルで繰り返し上書きされることもありません。

1. 基準デバイスを用意：まずデスクトップデバイスを1台選び、サブスクリプション、ルールの順序、DNS解決、ポリシーグループの参照を検証します。現在のコアですべての設定を正常に読み込めることを確認してください。
2. 共有層を抽出：プラットフォームをまたいで使うフィールドだけを残し、リッスンポート、TUNインターフェース、コントローラー、ローカルパスを共有ファイルから外します。
3. 小規模に検証：まず2台目のデバイスにインポートし、クライアントのオーバーライドの意味、配列のマージ方法、対応フィールドを確認します。
4. 設定バージョンを記録：変更のたびに、ポリシーグループ名の変更やルールセットの追加など、1つのテーマだけを扱います。複数の変更を同時にすべてのデバイスへ反映しないようにしてください。
5. ロールバック手段を残す：更新前に、読み込み可能な直前の設定を保存します。解析エラー、DNSの異常、ルールの不一致が起きた場合は、まず動作を復旧してから変更内容を比較します。
6. デバイスを定期的に整理：使用しなくなったサブスクリプション、リモートストレージの認証情報、古い設定のコピーを削除し、停止したデバイスが以後の更新を取得し続けないようにします。

同期後に必ず確認する項目

• 設定チェックに合格しているか、ログに未知のフィールド、重複したポリシー名、ルールセットの読み込みエラーがないか。
• ポリシーグループに有効なノードが含まれているか、手書きルールが参照するポリシー名が残っているか。
• DIRECT、プロキシポリシー、REJECTが想定どおりにマッチし、すべてが末尾のルールに流れていないか。
• DNSリクエストが想定したリゾルバーで処理されているか、Fake-IPまたはRedir-Hostモードがクライアントの対応範囲に合っているか。
• デスクトップのシステムプロキシとモバイル端末のVPN権限が、引き続きローカル状態によって制御されているか。
• TUNの起動後にルーティングループ、LANアクセスの中断、他のVPNソフトとの競合が発生していないか。

デバイス数と運用目的に合わせて方法を選ぶ

デバイスが2～3台で、主にノードを揃えたい場合は、まずサブスクリプション共有を採用します。分流ルールも統一したい場合は、小規模なオーバーライドファイルを追加します。デスクトップの設定をスマートフォンへ一時的に移行するならLAN転送を使えますが、プラットフォーム固有のフィールドを手動で確認してください。デバイスが多い、ルールを継続的に更新する、変更レビューが必要といった場合は、プライベートGitリポジトリやアクセス制御されたファイルストレージが適しています。

実行状態をすべて同期すべき方法はありません。Clashとmihomoの設定には、プロキシロジックを記述する部分と、OSのネットワークスタックに直接関係する部分があります。前者は一元管理できますが、後者ではデバイスごとの差異を尊重する必要があります。すべての端末を覆う1つのファイルを探すより、同期する範囲を明確に分けるほうが信頼性は高くなります。

最終的な構成は、サブスクリプションがノードの取得元、オーバーライドが共通ルール、プライベートストレージがバージョン管理と配布、ローカル設定がシステムインターフェースを担当すると整理できます。この4項目に沿って切り分ければ、問題がリモート更新、マージ処理、ファイル転送、デバイス権限のどこにあるかをすばやく判断でき、複数の完全な設定コピーを何度も比較する必要がありません。