複数デバイスでClash設定を共有する方法：サブスクリプション・同期・バックアップ

まず同期対象を決める：ノード、ルール、それとも実行設定全体か

「複数デバイスで同じ設定を使う」といっても、Windows、macOS、スマートフォンで同じノード群を利用したいのか、各デバイスで同じルールとプロキシグループを使いたいのか、あるいは config.yaml をそのままコピーしたいのかで意味が異なります。同期する範囲もそれぞれ違います。ノードのサブスクリプションは統一しやすく、ルールとプロキシグループは一元管理に向いています。一方、実行設定全体はOS、クライアント、コアのバージョンに左右されやすい点に注意が必要です。

Clash と mihomo の設定には、プロキシサーバーだけでなく、リッスンポート、コントローラーアドレス、TUNインターフェース、DNSハイジャック、LANアクセス、GeoDataモード、ローカルファイルパスなども含まれます。Windowsで動作している設定全体をmacOSへそのまま上書きすると、インターフェース名の不一致、ポート競合、ルールセットのパス切れが起きる可能性があります。

安定性を基準に3層へ分ける

共有データ層：プロキシノード、リモートルールセット、プロキシグループの構成。この層はすべてのデバイスで統一するのに適しています。
プラットフォームパラメータ層：TUN、DNS、リッスンアドレス、ポート、プロセスマッチング、インターフェース選択。OSごとに個別管理します。
クライアント状態層：ウィンドウサイズ、テーマ、トレイ動作、ログレベル、最後に選択した設定。通常はローカルに残し、同期対象には含めません。

方法1：すべてのデバイスで同じサブスクリプションURLを使う

サブスクリプションURLを統一して更新する方法は、保守の手間が最も少ない選択肢です。各デバイスがサブスクリプション情報を個別に保存し、必要なタイミングで同じURLから設定を取得します。WindowsとmacOSのClash Verge Rev、Androidでmihomoコアを使う互換クライアントにも、同じURLをそれぞれ登録できます。デバイス間でローカルファイルを直接やり取りしないため、実行中の状態を互いに上書きすることもありません。

基本的な操作手順

デスクトップクライアントで「サブスクリプション」または「設定」ページを開きます。
「新規作成」または「インポート」を選び、HTTPSのサブスクリプションURLを貼り付けます。
ダウンロード完了後、その設定を選択して「現在の設定にする」を実行します。
自動更新の設定で間隔を指定します。例として1440分なら、1日1回の更新です。
別のデバイスでも同じ手順で登録し、最初のデバイスが生成したキャッシュファイルはコピーしません。

クライアントによってメニュー名は多少異なります。Clash Verge Rev 2.xでは、通常サブスクリプションを「サブスクリプション」ページで管理し、コア、システムプロキシ、TUNは「設定」ページにあります。トラブルシューティングでは、「サブスクリプションが更新された」ことと「現在の設定に切り替わった」ことを区別してください。前者は新しい内容をダウンロードするだけで、後者によってコアが実際に読み込む設定が決まります。

自動更新の間隔はどう設定するか

ノード情報の変化が少ない場合、12〜24時間に1回の更新で十分です。5分間隔にするとサーバーへのリクエストが増え、ネットワーク切り替え時に設定を何度も書き換える可能性もあります。一時的にノードが見つからない場合は手動で1回更新し、クライアントに表示される更新時刻が変わったか確認してください。

項目	統一するか	対応方法
ノード一覧	統一	すべてのデバイスで同じサブスクリプションURLを登録
プロキシグループ	通常は統一	サブスクリプションの内容または変換テンプレートから生成
現在のノード選択	デバイスごとに個別	ローカルネットワークの遅延に応じて選択
システムプロキシとTUN	デバイスごとに個別	各クライアントの設定ページで個別に有効化
自動更新間隔	異なっていてもよい	デスクトップは1440分、モバイルは利用頻度に合わせて設定

方法2：クラウドストレージでYAML設定を同期する

クラウドストレージによる同期は、カスタムルール、プロキシグループ、DNS設定を管理しているユーザーに向いています。よくある方法は、手作業で管理するYAMLをOneDrive、iCloud Driveなどの同期フォルダに置き、各クライアントからそのファイルを読み込むことです。重要なのは、クラウド上のファイルを「元ファイル」として扱い、クライアントが読み書きする設定ディレクトリ全体を直接同期しないことです。

クライアントのディレクトリ全体を同期しない理由

クライアントのディレクトリには、SQLiteデータベース、ウィンドウ状態、ログ、キャッシュ、ロックファイルなど、頻繁に変化するデータが含まれる場合があります。
2台のデバイスを同時に動かすと、クラウドストレージが「競合コピー」を作成し、コアが古いファイルを読み続けることがあります。
OSによってパスの区切り文字が異なり、Windowsのドライブ付きパスはmacOSやLinuxでそのまま使えません。
クライアントのアップデート後にディレクトリ構成が移行される場合があり、古いディレクトリを直接同期すると、過去の状態が再び書き戻されることがあります。

より安全な手順は、クラウドストレージに shared-base.yaml を保存し、各デバイスへダウンロードまたはコピーしてから、クライアントの「設定」→「ローカルファイルをインポート」で読み込む方法です。ルールを変更するときは元ファイルだけを編集し、YAMLを読み込めることを確認してから他のデバイスへ反映します。クライアントが上書き、マージ、スクリプトに対応している場合は、共有ファイルをルールとプロキシグループだけにし、TUNやポートはローカルの上書き設定で管理することもできます。

設定ディレクトリはクライアントの案内を基準にする

設定ディレクトリはClashエコシステム共通の標準ではありません。mihomoをコマンドラインで起動する場合、Linuxでは ~/.config/mihomo/config.yaml が主設定ファイルとしてよく使われます。旧版Clashでは ~/.config/clash/ が一般的です。GUIクライアントには独自のアプリデータディレクトリやサブスクリプションデータベースがあり、場所はアプリ識別子やバージョンによって変わります。

そのため、ディレクトリを探すときは、Clash Verge Rev 2.xの「設定」→「設定ディレクトリ」→「ディレクトリを開く」のように、まずクライアントが用意したボタンを使います。画面に入口がない場合は、ログ冒頭に表示される作業ディレクトリや起動引数を確認してください。ディレクトリ内に config.yaml があるからといって、すぐに上書きしてはいけません。ログに記録された実際の読み込みパスを先に確認します。

クラウドストレージを安全に同期する手順

設定を変更するクライアントを終了し、同じファイルへ同時に書き込まれないようにします。
クラウドストレージの状態が同期完了になるまで待ってから、YAMLを開きます。
保存後、shared-base-conflicted-copy.yaml のような競合コピーが作成されていないか確認します。
1台のデバイスで設定をインポートして再読み込みし、プロキシグループ、ルール、DNSがすべて正しく解釈されることを確認します。
他のデバイスにもそのバージョンを反映し、直前の利用可能なコピーを残します。

方法3：自前の設定ホスティングとリモートルールセット

デバイスが多く、ルールを継続的に管理する必要がある場合は、設定をメイン設定、プロキシプロバイダー、ルールプロバイダーに分け、HTTPSで一元ホスティングできます。各デバイスには短い入口設定だけを保存し、ノードとルールはmihomoが定期的に取得します。YAMLを手作業でコピーするよりも、デスクトップ、ノートPC、ホームサーバー、モバイルデバイスを併用する環境に適しています。

proxy-providersでノードを一元管理する

proxy-providers:
  shared:
    type: http
    url: "https://config.example.net/proxies.yaml"
    path: ./providers/shared.yaml
    interval: 86400
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

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

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

interval: 86400 は86400秒ごと、つまり24時間ごとに更新する設定です。ヘルスチェックは600秒ごとに実行され、指定したテストリクエストをノードが完了できるかを判定するだけで、実際のダウンロード速度を示すものではありません。リモートファイルはダウンロード後に ./providers/shared.yaml へ保存されます。この相対パスはコアの作業ディレクトリを基準とするため、クライアントに書き込み権限があることを確認してください。

rule-providersでルールを統一する

rule-providers:
  private:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/private.yaml
    url: "https://config.example.net/rules/private.yaml"
    interval: 86400

rules:
  - RULE-SET,private,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

behavior: domain はドメイン形式のルールに適しています。ファイルにCIDRネットワークが含まれる場合は、内容に合ったbehaviorタイプを指定します。複数のClashルール構文が混在する場合は、mihomoの対応状況に応じて classical を使用できます。behaviorタイプとファイル内容が一致しないとルールの読み込みに失敗し、通常はログにprovider名と解析エラーの位置が表示されます。

リモートホスティングで確認すべき点

サーバーはHTTPSを提供し、正しいYAMLテキストを返す必要があります。
非公開URLでアクセストークンが必要な場合は、トークンの権限と有効期限を管理します。
メイン設定を更新する前に前のバージョンを保存し、1か所の構文エラーがすべてのデバイスに影響しないようにします。
ルールセットには安定したURLを使い、コミットのたびにファイルアドレスが変わらないようにします。
リモートファイルの更新後、プロキシグループの新しい構成を適用するために、クライアントで「再読み込み」が必要になる場合があります。

クロスプラットフォームの差異：ローカルに残すべき設定

共有設定が複数のOSで動作するかどうかは、システム依存の項目を含むかで決まります。ルール構文、プロキシグループ、リモートプロバイダーは再利用しやすい一方、インターフェース、プロセス、ポート、ローカルパスはデバイスごとに確認が必要です。mihomoコアを使っていても、すべてのGUIクライアントが同じ画面項目に対応するとは限りません。クライアントが上書きファイルから最終設定を生成する場合もあります。

TUNモードとインターフェース設定

TUNは仮想ネットワークインターフェースを作成し、ルーティングを引き受けます。Windows、macOS、Linux、Androidでは権限モデルが異なるため、GUIクライアントでは通常、各デバイス上での許可が必要です。共有ファイルには基本構造だけを残し、interface-name、device、route-address-set など、ローカル環境に依存する項目は固定値にしないほうが安全です。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-detect-interface: true にすると固定インターフェース名による問題を減らせますが、複数のNIC、仮想マシン、社内VPNを同時に使う場合はデフォルトルートの確認が必要です。あるデバイスでTUNを有効にした後に通信できなくなったら、まず「設定」→「TUNモード」で機能を無効にし、ログのルーティングエラーと権限エラーを確認します。すぐに共有ルールを変更しないでください。

リッスンポートとLANアクセス

mixed-port: 7890
allow-lan: false
bind-address: "*"
external-controller: 127.0.0.1:9090

mixed-port: 7890 はHTTPとSOCKSのプロキシ接続を同時に受け付けます。特定のデバイスでポートが他のプログラムに使われている場合は、そのデバイスだけ7891へ変更できます。external-controller をローカルクライアントからのみ接続する場合は、127.0.0.1:9090 で待ち受けることを推奨します。LAN共有が必要な場合は、実際の用途に応じて allow-lan を有効にし、システムのファイアウォールとWi-Fiネットワークの種類も確認してください。

ローカルパスとルールリソース

Windowsのパスは C:\Users\Public\Clash\rules のように記述できますが、macOSとLinuxでは / から始まるパスを使います。クロスプラットフォーム対応のため、ルールプロバイダーには ./rules/private.yaml のような相対パスをできるだけ使います。クライアントの作業ディレクトリが保護された場所にある場合は、現在のユーザーが rules と providers のサブディレクトリを作成できることも確認してください。

プロセスルールのOS差異

PROCESS-NAME はOSが報告するプロセス名に依存します。Windowsでは example.exe に一致させる場合があり、macOSのアプリでは実行ファイル名が Example になることがあります。Androidではパッケージ名で一致させる場合があります。プロセス単位で正確に分流する必要がある場合は、プラットフォームごとにルールセットを分け、ローカル設定から参照します。

推奨構成：共有ベース設定とローカル上書き

Windows、macOS、Linuxを併用する環境では、共有ベース設定を1つ管理し、各プラットフォーム用に短い上書き設定を用意します。ベース設定にはプロキシプロバイダー、ルールプロバイダー、プロキシグループ、共通DNSロジックを記述し、上書きファイルではポート、TUN、プロセスルール、コントローラーアドレスだけを扱います。

ファイル構成の例

clash-config/
├── shared-base.yaml
├── overlays/
│   ├── windows.yaml
│   ├── macos.yaml
│   └── linux.yaml
├── rules/
│   ├── direct.yaml
│   └── reject.yaml
└── backups/
    └── shared-base-2026-08-04.yaml

上書き設定を直接マージできるかどうかは、クライアントの機能によります。Merge、Mixin、上書き、スクリプトの入口を備えるクライアントもあれば、最終YAMLしかインポートできないクライアントもあります。自動マージできない場合は、PC上で windows-final.yaml のような最終ファイルを生成し、対象デバイスにインポートします。マージ後は同名キーの上書き結果を必ず確認してください。特に rules、dns、proxy-groups のようなリストやネストしたオブジェクトが重要です。

現在のノード選択まで統一しない

自宅のブロードバンド、オフィスネットワーク、モバイル回線ではルーティング条件が異なります。同じノードでも、Windowsのデスクトップでは遅延42ms、スマートフォンのモバイル回線では180msになることがあります。各デバイスでプロキシグループの選択を個別に保持するか、url-test、fallback などの自動方式を使います。共有するのは候補ノードとテストルールであり、最後に選んだノードまで強制的に共有する必要はありません。

バックアップ、ロールバック、競合への対処

設定の同期はバックアップの代わりにはなりません。同期すると、削除、インデントミス、誤ったルールまで他のデバイスへ伝播します。バックアップは過去の状態へ復元できる版を残すためのものです。少なくとも、現在利用できる設定、直前の変更前設定、長期間検証済みの安定版を保管してください。

変更するたびに行う4つの確認

現在のファイルをコピーし、config-2026-08-04.yaml のように日付を付けて保存します。
YAMLのインデントにスペースを使い、Tab文字が混入していないことを確認します。
プロキシグループが参照するprovider、ノード名、他のプロキシグループが存在することを確認します。
再読み込み後にログを確認し、rules、proxy-providers、rule-providersがすべて正常に読み込まれたことを確認します。

更新後にすべてのデバイスで同時に問題が起きた場合は、まずクラウド同期またはリモート公開を一時停止し、誤ったバージョンが広がらないようにします。次に安定版ファイルを復元し、自動更新を一度無効にしてからコアを再読み込みします。基本接続が戻ったことを確認した後、今回の変更を少しずつ追加し、DNS、ルール、プロキシグループ、リモートリソースのどれが原因かを切り分けます。

よくある競合への対処順序

同名のコピーが2つできた：更新日時と内容を比較し、ファイル名だけで新旧を判断しません。
クライアントがYAMLエラーを表示する：ログに示された行番号から上へ向かって、インデントと引用符を確認します。
ルールを更新しても動作が変わらない：現在の設定を再読み込みしたことを確認し、ルールのマッチング順序を確認します。
1台だけ通信できない：そのデバイスのTUNとシステムプロキシを先に無効にし、共有設定そのものを検証します。
リモートproviderのダウンロードに失敗する：HTTPSアドレス、アクセス権、DNS、ローカルキャッシュのパスを確認します。

3つの方法をどう選ぶか

利用シーン	推奨方法	主な管理ポイント
個人用デバイスが2〜3台で、同じノードだけ使いたい	同じサブスクリプションURL	各デバイスで個別に更新し、ノードを選択
カスタムルールがあり、変更頻度は低い	クラウドストレージ上のYAMLを同期	クライアントのデータベースとキャッシュは同期しない
デバイスが多く、ルールを長期運用する	自前のHTTPSホスティング	バージョン管理、権限、ロールバック
Windows、macOS、Linuxをまたいで使う	共有ベース設定とプラットフォーム別上書き	TUN、ポート、パス、プロセスルール

個人利用の多くは、まずサブスクリプションURLから始めれば十分です。ルール、DNS、プロキシグループを自分で管理する必要が出てきたら、クラウド上の元ファイルを導入します。デバイスが増えたら、ノードとルールをproviderに分け、HTTPSで定期更新できます。どの方法でも、システム依存の設定はローカルに残し、すぐにロールバックできる安定版を保管してください。

同期後は、各デバイスで4つの結果を個別に確認できます。サブスクリプションの更新時刻が正しいこと、現在の設定に切り替わっていること、ルールの適用結果が想定どおりであること、TUNまたはシステムプロキシを正常に無効化・復元できることです。この4項目を分けて検証すると、「Webページを開けるか」だけで判断するより設定差異を見つけやすくなります。