複数デバイスで Clash 設定を同期する方法比較:サブスクリプションリンク・クラウド同期・手動エクスポート

なぜ設定の同期を考える必要があるのか

Clash系クライアント(オリジナルコア、Clash Meta / mihomo を含む)は、いずれもノード情報・プロキシグループ・振り分けルールを1つのYAML設定ファイルで記述します。デスクトップ版とモバイル版は通常それぞれ個別にインストール・管理されるため、あるデバイスでルールを調整したりノードを追加したりしても、他のデバイスは自動的にその変更を認識しません。1台のデバイスだけを長期間使う場合はこの問題は目立ちませんが、「パソコン + スマートフォン」や「個人利用 + 家庭用ルーター」といった複数デバイスをまたぐ場面になると、設定の不同期は2つの直接的な問題を引き起こします。1つはデバイスごとに利用可能なノードリストが一致しなくなり、あるデバイスでは既に無効になった機場(プロキシ提供元)ノードに接続できないまま気づかないこと。もう1つは振り分けルールにズレが生じることで、例えばパソコンでカスタムルールを追加しても、スマートフォン側は古いルールでマッチングを続けるため、同じサイトでも2台のデバイスで挙動が異なってしまうことです。

さらに厄介なのは維持コストです。サブスクリプション提供元がノードリストを更新したりサーバーアドレスを変更した場合、理論上はすべてのデバイスで再取得が必要になります。3〜5台程度なら手動操作でも許容範囲ですが、ルーター・タブレット・サブ機のスマートフォンまで同時に管理するとなると、繰り返し作業がすぐに煩雑になり、「1台だけ更新を忘れる」といったミスも起きやすくなります。適切な同期方式を選ぶことは、自動化の度合い・プライバシー管理・操作の複雑さの間でバランスを取ることに他なりません。

方法1:サブスクリプションリンクによる自動更新

現在最も広く使われている同期方法です。仕組みはシンプルで、クライアントはノードリストを直接保存せず、サブスクリプションリンク(URL)を保存しておき、更新のたびにそのアドレスにリクエストを送って最新の設定内容を取得し、ローカルのキャッシュを上書きします。すべてのデバイスに同じサブスクリプションリンクを入力しておけば、理論上どのデバイスも更新後に同じデータを取得できます。

• 自動更新周期:多くのクライアントはサブスクリプションの自動更新間隔(例えば24時間ごと)を設定でき、いつでも手動で「サブスクリプションを更新」をタップして即座に最新内容を取得することもできます。
• ノードとルールの同期:サブスクリプション提供元がリンクの背後でノードリストと振り分けルールを一括管理していれば、ルールの変更は次回の更新時に自動的にすべてのデバイスへ反映され、手動操作は不要です。
• 通信量と有効期限の情報:一部のサブスクリプションリンクは残り通信量や有効期限などのメタ情報を返すことができ、クライアントがそれを解析して画面に表示するため、使用量を一元的に把握できます。

この方式の利点は「一度設定すれば長期間メンテナンス不要」であることで、ノード情報自体が頻繁に変化する場面に特に向いています。一方で欠点も明確です。振り分けルールは完全にサブスクリプション提供元が決定するため、あるデバイスで手動でカスタムルールを追加していても、次回のサブスクリプション更新時に上書きされて消えてしまう可能性が高いです。そのため、サブスクリプションリンクによる同期を計画している場合は、カスタムルールをルールセット(rule-provider)として個別に管理し、参照する形にすることをお勧めします。サブスクリプション本体が返すメイン設定に直接書き込まないことで、ルールの変更がサブスクリプション更新によって失われることを防げます。

方法2:クラウドストレージでの設定ファイル同期

設定ファイルを手動で管理する習慣がある場合や、サブスクリプション提供元が自動更新可能なリンクを提供していない場合は、Clashの設定ファイルディレクトリをクラウドストレージの同期対象に含める方法があります。よくあるやり方は、設定ファイルをクラウドストレージクライアントが同期を担当するフォルダに置くか、シンボリックリンク(symlink)でClashの設定ディレクトリをクラウドフォルダ内の実際のパスに向ける方法です。この方法なら、1台のデバイスでファイルを編集すると、同じアカウントにログインしている他のデバイスへクラウドストレージが自動的に変更を反映します。

1. Clashクライアントが実際に設定ファイルを読み込むパスを確認します(クライアントごとにデフォルトディレクトリが異なるため、クライアントの設定内で「設定ファイルの場所」などの項目を確認してください)。
2. そのディレクトリ内の設定ファイルをクラウド同期用フォルダにコピーするか、逆にクラウドフォルダを指すシンボリックリンクを作成します。
3. 複数デバイスでクラウドストレージクライアントが正しくログイン・同期されていることを確認し、一方で設定を変更した後、他のデバイスが想定した時間内に更新を受け取るかチェックします。
4. クライアントが実行中に設定ファイルをロックしていてクラウドストレージが書き込めない、または競合コピーが発生する場合は、先にクライアントを終了してから編集し、編集完了後にクライアントを再起動して読み込ませます。

この方式の利点は、カスタムルール・プロキシグループの分類ロジック・DNS設定などすべての詳細を完全に保持でき、サブスクリプションリンクのように上書きされることがない点です。ルールが比較的固定的で、たまにノードやルールを調整するだけのユーザーに向いています。注意すべきリスクは同時編集です。2台のデバイスがほぼ同時に同じ設定ファイルを変更すると、クラウドストレージサービスは通常「競合コピー」を生成するため、この場合は手動で2つのファイルを比較し正しいバージョンにマージする必要があります。そうしないと、一方のデバイスが不完全または古い内容を読み込んでしまう可能性があります。また、設定ファイルにノードのパスワードなど機密情報が含まれる場合は、クラウドストレージに保存することのプライバシー上の許容度を評価し、必要に応じて同期ディレクトリを暗号化処理してください。

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

最も基本的で管理しやすい方法は、設定ファイルを手動でエクスポートし、デバイスごとにインポートすることです。多くのClash系クライアントは「現在の設定をエクスポート」または「設定ファイルのパスをコピー」といった機能を提供しており、エクスポートしたYAMLファイルはUSBメモリ、ローカルネットワーク経由の転送、チャットツールなどで他のデバイスに送信し、対応するクライアントで「設定ファイルをインポート」を選んで読み込みを完了させます。

手動エクスポート・インポートは次のようなケースに向いています:デバイス数が少ない(パソコン1台とスマートフォン1台のみなど)、更新頻度が非常に低い(設定が固まってから長期間調整しない)、または自動同期のプライバシー面での懸念が強く、設定内容をいかなる第三者サービスも経由させたくない場合です。欠点はこれらの前提と直結しており、デバイス数が増えたり更新頻度が上がったりすると、手作業の繰り返しがすぐに積み重なり、「あるデバイスの更新を忘れる」というミスも起きやすくなります。問題を調査する際には、まず各デバイスが現在使っている設定のバージョンを確認する作業が必要になります。

手動方式を選ぶ場合は、エクスポートするファイルに日付を付けて命名し(例:config-20260513.yaml)、直近数バージョンをローカルに保存しておくことをお勧めします。新しい設定にルールエラーやフォーマットの問題が見つかった場合、すぐに直前の動作確認済みバージョンへ戻せるため、最初から書き直す必要がなくなります。

# 設定ファイルの文法を手動で確認する一般的な方法:
# 多くのクライアントはインポート時に基本的な検証を行い、フォーマットエラーは
# インポート時に直接通知されることが多い
# テキストエディタのYAML構文ハイライト機能を使って、インデントやコロンの
# 記法が正しいか事前に確認することもできる
proxies:
  - name: "node-a"
    type: ss
    server: example.your-node.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"

3つの方法の適用シーン比較

3つの方式は互いに排他的なものではなく、実際の運用では組み合わせて使われることも多いです。ノード情報はサブスクリプションリンクで自動更新し、カスタムルールはクラウド同期または手動で独立したファイルとして管理して参照する、といった形です。選択の際は以下の観点を参考にしてください。

サブスクリプション提供元がノード情報とルール管理を同時に提供し、ルール更新の頻度が高い場合は、サブスクリプションリンクを優先して重複作業を減らしましょう。カスタムルールが比較的複雑で、サブスクリプション更新のたびに上書きされることを避けたい場合は、ルールを独立したルールセットファイルに切り分け、クラウドまたは手動で各デバイスに配布し、メイン設定にはルールセットのアドレスのみを参照させることを検討してください。1〜2台のデバイスしかなく更新もほとんどない場合は、手動エクスポート・インポートだけで十分であり、クラウドやサブスクリプションの仕組みをわざわざ導入して複雑さを増す必要はありません。

同期後の確認手順

どの方式で同期したとしても、設定更新後には簡単な確認を行うことをお勧めします。「同期できたつもりだが実際には反映されていない」という事態を避けられます。

• クライアント画面に表示されているノードの数と名称が想定通りか確認し、古いキャッシュが読み込まれていないことを確かめる。
• 設定ファイルの最終更新日時、またはサブスクリプションの最終更新時刻を確認し、実際に更新が行われたことを確かめる。
• ヒットすることが分かっているカスタムルールを1つ選び、実際に対応するサイトへアクセスして、想定通りの振り分け結果になっているか(デフォルトのポリシーグループに流れていないか)を確認する。
• TUNモードを有効にしている場合は、同期後にTUN関連の設定項目(仮想ネットワークカードのアドレス範囲、DNSハイジャック設定など)がデフォルト値に上書きされていないか確認する。これらの項目はサブスクリプション上書き型の同期で意図せずリセットされやすい。

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

同期作業でよく遭遇する問題は大きく2種類に分かれます。1つは「同期したように見えるが内容が変わっていない」、もう1つは「同期後にクライアントがエラーになり起動できない」です。前者はキャッシュや更新間隔の設定に問題があることが多く、まずクライアント内のサブスクリプション自動更新周期を確認するか、手動で1回更新を実行し、更新時刻のタイムスタンプを比較してみてください。後者はファイル形式の問題であることが多く、例えば手動編集時のインデントミス、クラウド同期中に不完全な半端なファイルが生成された、あるいはクライアントごとに同じ設定内の項目への対応状況が異なる(例えば一部のプロキシタイプのパラメータが旧バージョンのクライアントでは未対応)といったケースが考えられます。起動失敗に遭遇したら、まずクライアントのログに表示される具体的なエラー行番号を確認し、そのあたりのYAML構造をインデントやフィールド名のスペルミスも含めて1つずつ点検すると、問題を素早く特定できることが多いです。