Clashの設定を複数端末で同期する：共有する項目を整理

PCとスマホで設定を共有する際は、「ノードの取得元」「ルールによる振り分け」「クライアントの状態」を分けて考えましょう。同じサブスクリプションURLを使えば、両方の端末で同じノードを取得できますが、選択中のノードやシステムプロキシのオン・オフ、TUNの権限までは自動で同期されません。WebDAVやGitもファイルを転送する仕組みであり、クライアントへのインポートや有効化は行いません。

ClashのGUIクライアントは設定管理とシステムへの接続を担い、コアは設定の読み込み、ルール判定、接続の確立を担います。Clash Metaは現在mihomoの名称で開発が続いています。mihomoを利用するクライアント同士でも、コアのバージョンや設定の上書き方法、画面上の機能は異なる場合があります。そのため、同期するのは共通して使える設定項目にとどめ、アプリのデータフォルダー全体をコピーしないようにしましょう。

共有する項目と端末ごとに保持する項目

  • 共有に適した項目：ノードのサブスクリプション元、プロキシグループ名、ルールの順序、ルールセットのURL、両方の端末で対応しているDNSポリシー。
  • 端末ごとに保持する項目：システムプロキシのオン・オフ、TUNの有効化と権限、起動時の動作、ネットワークアダプター名、ログの保存先、クライアントのウィンドウ設定。
  • 個別に確認する項目：mixed-port、external-controller、secret、LAN向けリスニング設定。デスクトップ用の管理インターフェース設定を、そのままスマホに持ち込まないようにしましょう。

3つの同期方法と適した用途

まず、同期したいものに合わせて方法を選びましょう。ノードの更新だけならサブスクリプションURLが最も手軽です。設定の復元用コピーを保存するならWebDAV、ルールを継続的に管理して変更履歴も追いたいならプライベートGitが適しています。併用もできますが、どこを正本とするかは明確にしておきましょう。

方法同期する内容端末側の要件更新方法
サブスクリプションURLで管理ノードまたは設定一式リモートサブスクリプションと対象フォーマットに対応していること手動更新、またはクライアントによる定期取得
WebDAVバックアップエクスポートしたYAMLファイルWebDAV機能を内蔵、またはファイルアプリでダウンロードしてインポートアップロード、ダウンロード後に再インポートまたは再読み込み
プライベートGitリポジトリルールのソースファイルと変更履歴Gitツール、またはアクセスを制御したデプロイ手順コミット、プル、検証後に適用

「リモートサブスクリプション対応」は「WebDAVログイン対応」や「プライベートリポジトリを直接読み込み可能」という意味ではありません。クライアントが認証情報を送れない場合、保護されたファイルのURLを通常のサブスクリプションURLとして使うことはできません。導入前に、クライアント名だけで判断せず、使用中のバージョンでサブスクリプション管理、ファイルのインポート、認証に対応しているか確認しましょう。

サブスクリプションURLで管理：PCとスマホに同じ配信元を登録

インポートと更新の手順

  1. サービス提供元から、使用するコアに対応したサブスクリプションURLを取得し、返されるデータがClash設定一式、ノード一覧、または別のフォーマットのどれかを確認します。ノード情報のみの場合は、クライアントまたは設定テンプレートで実行可能な設定に組み立てる必要があります。
  2. PCとスマホそれぞれのサブスクリプション管理画面でリモート設定を追加し、同じURLを貼り付けます。画面上の名称は「サブスクリプション」「設定」「Profiles」など、バージョンによって異なります。
  3. ダウンロード後、両方の端末で対象の設定を選択して有効にします。プロキシグループ、ルール数、ノードがそろっていることを確認し、それぞれの端末で必要なシステム接続方法を有効にしましょう。
  4. 定期更新機能がある場合は、まず24時間ごとの更新を目安に設定します。ノードが一時的に使えなくなったときや、提供元から変更の連絡があったときは手動で更新し、最終更新時刻が変わったことを確認してください。

24時間という間隔は管理しやすい開始時の目安であり、すべてのクライアントの初期設定ではありません。モバイルOSではバックグラウンド処理が制限されることがあるため、自動更新を設定していても、重要な利用の前にはアプリを開いて最終更新時刻を確認しましょう。両方の端末を同時に更新していない場合、一時的にノード一覧が異なるのは正常です。

サブスクリプション全体の更新とproxy-providersの違い

GUIクライアントでリモート設定を更新すると、通常は設定ファイルを再取得します。一方、mihomoのproxy-providersは、設定ファイル内でノードの提供元を定義する機能です。HTTPタイプのプロバイダーでinterval: 3600と指定すると更新間隔は3600秒になりますが、クライアント全体のサブスクリプションが1時間ごとに再読み込みされるわけではなく、アプリの設定も同期されません。どの階層を更新するかは、設定の構成に合わせて決めましょう。

リモートサブスクリプションにルールが含まれている場合、ダウンロードしたYAMLを直接編集しても、次回の更新で変更が上書きされることがあります。独自の振り分けルールを使う場合は、クライアントが正式に対応しているローカル上書き、マージ、スクリプト機能を利用し、どの項目に適用されるか確認してください。PCとスマホで同じ上書き方法が使えない場合は、管理下のサーバーで両方が読み込める最終設定を生成する方法もあります。

WebDAVバックアップ：設定ファイルを転送して復元

WebDAVはリモートファイルの読み書きに対応しており、整理済みの設定を個人用ストレージに保存して別の端末で復元する用途に向いています。転送するのはファイルです。クライアントに自動復元機能が明示的に用意されていない限り、アップロード後にダウンロード、インポート、有効化の操作が必要です。

双方向の上書きより、片方向の配信がトラブルの切り分けに有効

  1. ストレージサービスにclash-config/などの専用フォルダーを作成します。HTTPSと専用のアプリパスワードを使い、配信元の端末には書き込み権限を付与し、受信側の端末はできるだけ読み取り専用にしましょう。
  2. PCから共有するYAMLをエクスポートし、ノードのパスワード、サブスクリプショントークン、コントローラーのシークレットなどの機密情報が含まれていないか確認します。バックアップの用途に応じて、残す項目を判断してください。
  3. まずshared-2026-08-14.yamlのように日付入りのファイルをアップロードし、直前に使えたコピーも残しておきます。ファイルが完全にアップロードされたことを確認した後、ストレージサービスの対応方法に沿って固定名のファイルを更新しましょう。
  4. スマホのクライアントがWebDAVからの復元に対応している場合は、該当する画面から操作します。対応していない場合は、WebDAV対応のファイルアプリでダウンロードし、プロキシクライアントのローカルファイル読み込み画面からインポートしてください。
  5. 有効化後、ルールと接続ログを確認します。復元に失敗した場合は、すぐにバックアップを削除せず、直前に使えた設定を再インポートしてください。

両方の端末からshared.yamlに書き込むと、後からアップロードしたファイルで先の変更が上書きされることがあります。条件付き書き込み、ロック、競合処理はサーバーとクライアントの実装によって異なるため、YAMLが自動でマージされるとは限りません。PCから配信し、スマホは読み取り専用にするのがおすすめです。スマホで一時的に選んだノードは端末内に保持しましょう。

設定ファイルのバックアップとアプリデータのバックアップは分けて考える

クライアント全体のバックアップには、データベース、内部設定ID、システム上のパスなどが含まれる場合があり、通常は同じクライアントでの復元に適しています。Windows、macOS、Android間で移行する場合は、内容を確認できる設定ファイルをエクスポートしましょう。iOSでは、利用するプロキシクライアントが実際に対応するフォーマットとインポート方法を確認してください。任意のmihomo設定を直接読み込めるとは限りません。

認証情報を含むバックアップをリモートストレージに保存する必要がある場合は、暗号化アーカイブにしてからWebDAVへアップロードします。暗号化ファイルは復元用です。信頼できる端末で復号してからクライアントにインポートしてください。通常のYAMLサブスクリプションとして取得することはできません。

プライベートGitリポジトリ：ルールのバージョンと端末ごとの差分を管理

Gitは、ルールを変更した理由や元に戻せるバージョン、デスクトップとスマホで異なる設定を記録するのに適しています。認証情報を含まないルールのソースファイルをリポジトリに保存し、サブスクリプションURLやノードのパスワードはローカルまたはアクセスを制御したデプロイ環境で管理しましょう。リポジトリを非公開にしても、コミット履歴に残った秘密情報が自動で消えるわけではありません。

ノードの認証情報を含まないルールファイルから始める

以下は共有設定の構造を示す最小構成です。example.comはドキュメント用の例示ドメインです。プロキシノードは含まれず、すべての接続が最終的にDIRECTとなるため、サービス提供元のサブスクリプションの代わりにはなりません。実際のノードを追加する場合は、クライアントのマージ機能または設定生成の手順で、必要なプロキシグループとノード定義が保持されるようにしてください。

mode: rule
mixed-port: 7890
allow-lan: false
log-level: info

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

7890はローカルの混合プロキシポートの例で、HTTPとSOCKSの接続を受け付けます。ポートがすでに使用されている場合は、PC側で利用可能なポートに変更し、システムプロキシの設定も合わせてください。スマホのクライアントはリスニングポートやVPN接続を独自に管理する場合があるため、この項目が端末側の設定を上書きするかは実装によります。

ローカルでバージョン履歴を作成する

Gitをインストールしてコミット時のユーザー情報を設定したら、policy.yamlを保存したフォルダーで次のコマンドを実行します。ここで作成するのはローカルの履歴です。プライベートなリモートリポジトリと同期する際は、リポジトリサービスの案内に従ってSSHまたはアクセストークンを設定してください。

git init
git add policy.yaml
git commit -m "共有ルール設定を記録"

git diff -- policy.yaml
git log --oneline -- policy.yaml
  • サブスクリプションの認証情報は、ローカルの専用ファイルに保存し、.gitignoreで追跡対象から除外します。除外ルールを追加しても、すでに追跡されているファイルは自動で除外されません。
  • 公開前にgit diffを確認し、意図したルールだけが変更されていることを確認します。デスクトップとスマホで異なるTUN設定は、共有ルールファイルに含めないでください。
  • 同期する側の端末には、読み取り専用のデプロイ認証情報を使い、各スマホにリポジトリへの書き込み権限を付与しないようにしましょう。
  • 共有済みの変更を取り消す場合は、git revertで取り消し用のコミットを作成し、設定を再生成してインポートします。変更履歴も保持できます。

通常、プロキシクライアントはgit pullを実行できません。また、プライベートリポジトリのWebページURLはYAMLの生データURLではありません。スマホには手動でダウンロードしてインポートするか、管理されたデプロイ手順でルールとサブスクリプションを組み合わせ、認証付きのHTTPS設定URLを用意します。後者では、クライアントが必要な認証方式に対応しているか確認し、ビルドログにトークンが表示されないようにしてください。

更新後の確認：設定が同じでも端末への接続方法は異なる

まず1台の端末で検証し、その後もう一方へ配信しましょう。一度に変更する階層は1つにします。ファイルを取得できるか、設定を読み込めるか、システムへ接続できるか、通信が期待どおりかの順に確認すれば、同期の失敗、コアの互換性、端末側の権限の問題を切り分けやすくなります。

  1. 元ファイルを確認：ダウンロード結果がログイン画面ではなくYAMLであることを確認します。HTTP 401は認証失敗、403はアクセス拒否、404はリソースが見つからないことを示す場合が一般的です。ストレージまたは配信サービス側でURLと権限を確認してください。
  2. 設定の解析を確認：クライアントのエラーログを見て、インデントの誤り、重複フィールド、未対応のプロトコルパラメーターがないか確認します。プロキシグループが参照する名前が存在すること、ルールが上から順に評価されることも確認してください。
  3. 有効化状態を確認：設定をダウンロードしただけでは不十分です。現在選択されているファイルが再読み込み済みか確認してください。ノードの選択状態が復元されるかどうかは、クライアントのキャッシュやプロキシグループ名が維持されているかによって異なります。
  4. システムへの接続を確認：PCでシステムプロキシを有効にすると、システムプロキシに対応するアプリがその設定を使って接続します。Androidなどのモバイルプラットフォームでは通常VPNインターフェースを使うため、必要な許可を端末上で設定してください。
  5. 実際の接続を確認：両方の端末で同じテスト先に接続し、接続ログの適用ルールとプロキシグループを確認します。ページが開けても、それだけで想定したプロキシを経由したとは判断できません。

ノードとルールが完全に同じでも、Wi-Fi、モバイル回線、DNS環境、IPv6の経路が異なれば、PCとスマホで結果が変わることがあります。「PCでは動くのにスマホでは失敗する」場合は、まず同じWi-Fiで再テストし、モバイル端末の権限、ノードのプロトコル対応、ログのエラーを確認してください。共有設定を何度も上書きするのは避けましょう。

複数端末でのおすすめ構成とメンテナンス

2台で使う場合：同じサブスクリプション、接続設定は端末ごと

PCとスマホのそれぞれに同じサブスクリプションをインポートし、更新状況を定期的に確認します。システムプロキシ、TUN、起動時の設定は端末ごとに保持しましょう。ルールの変更が少ない場合は、更新や大きな変更の前に日付入りのYAMLバックアップを1つ保存すれば十分です。リポジトリや配信手順を追加する必要はありません。

ルールを長期管理する場合：Gitで履歴管理、サブスクリプションでノード更新、WebDAVにバックアップ

認証情報を含まないルールをプライベートGitリポジトリに保存し、ノードは引き続きサブスクリプションから取得します。検証済みの設定はアクセスを制御した方法で配信し、復元用のコピーをWebDAVに保存します。ルール変更後はすぐに検証・配信し、サブスクリプションはクライアントの周期に従って更新、バックアップは新しい設定が使えることを確認してから作成します。3種類の更新を一度に行う必要はありません。

  • 更新のたびに：設定の取得元、更新時刻、現在の有効状態を記録し、DIRECTになるルールとプロキシ経由を想定したルールを1つずつ確認します。
  • クライアントまたはコアを変更する場合：テスト用のコピーを先にインポートし、プロトコル、ルールセット、DNS、TUN関連の項目が対応しているか確認してから、普段使う設定を切り替えます。
  • 端末を紛失した、または使わなくなった場合：その端末に付与したWebDAVとリポジトリの認証情報を失効させます。サブスクリプションURLが漏えいした可能性がある場合は、提供元の手順に従って再発行してください。

基本操作を確認する場合は、まずサブスクリプションのインポート方法をご覧ください。ルールの順序やコアの違いについては、ルールの技術リファレンスとコアの説明を参照してください。複数端末で同期する際は、ノードとルールの取得元を明確にし、ポート、権限、システムへの接続は各端末で個別に管理することが重要です。