同期する範囲：ルールは共有し、端末固有の設定は分ける
「設定を共有する」とは、3台すべてでまったく同じ最終YAMLを読み込むことではなく、設定の共通ソースを使うことだと考えるのが適切です。プロキシノード、プロキシグループ名、振り分けルールはできるだけ共通化できます。一方、ローカルの待ち受けポート、TUNの設定、コントローラーの接続先、クライアント固有の設定は端末ごとに管理しましょう。こうすれば、ノードの更新時に別の端末のネットワーク設定まで上書きされるのを防げます。
まず、コアとGUIクライアントを区別しましょう。mihomoは対応する設定の解析、ルール判定、プロキシ接続を担い、クライアントはサブスクリプションの更新、設定の選択、上書き、システム連携を担当します。これらの機能や保存方法はクライアントごとに異なります。iPhone向けクライアントも、必ずしもmihomoを使用しているとは限りません。ノードのサブスクリプションをインポートできても、Clash YAMLのルール、DNS、プロキシグループをすべて適用できるとは限りません。
- 共有に向いているもの：ノードの取得元、安定したプロキシグループ名、ドメインルール、各端末が対応するルールセット。
- 端末ごとに設定するもの：
mixed-port、external-controller、コントローラーのシークレット、TUNやネットワークインターフェース関連の設定。 - 要確認：プロトコルの対応状況、
proxy-providers、rule-providers、DNS関連の項目、クライアント独自の拡張。
3つの同期方法を比較
サブスクリプションURLは、配信元のノードを継続的に更新したい場合に適しています。iCloud Driveは、少数の端末間で手動管理のファイルを受け渡す用途に向いています。プライベートGitリポジトリは、ルールの変更をレビューしたり、以前の状態に戻したりしたい場合に便利です。いずれも設定ファイルを端末に届ける方法であり、現在の接続状態、選択中のノード、システムプロキシのオン・オフを自動で同期するものではありません。
| 方法 | 向いている内容 | 更新方法 | 主な制約 |
|---|---|---|---|
| サブスクリプションURL | ノード、配信元の完全な設定 | 各端末で個別に更新 | レスポンス形式や対応項目が異なる場合がある |
| iCloud Drive | 手動管理のYAMLファイル | ファイル同期後に再インポートまたは再読み込み | クライアントが元ファイルを継続して読み込むとは限らない |
| プライベートGitリポジトリ | ルール、テンプレート、ローカル上書きの例 | 取得、確認、適用 | 認証情報と配布手順を別途管理する必要がある |
「Macとスマートフォンで同じノードを使いたい」なら、まずサブスクリプションを試しましょう。「ルールを1つ変更したら全端末に反映したい」なら、共通のルールソースを用意してから、ファイル同期かGit配布かを選びます。ノードを共有するために、各端末のクライアントデータフォルダ全体をコピーするのは避けてください。
サブスクリプションURL：各端末で同じ配信元を登録・更新
インポートと更新の手順
- 提供元に確認し、サブスクリプションの出力形式が完全なClash設定、ノード一覧、または他のクライアント専用形式のどれかを把握します。
- Macクライアントの設定管理画面でURLをインポートし、手動で一度更新します。プロキシグループとルールが存在することを確認してから、その設定を有効にしてください。
- Windowsクライアントにも同じ配信元を登録し、実際のレスポンスが同じか確認します。サービスによってはリクエストパラメーターやクライアント識別情報に応じて異なる形式を返します。
- iPhoneクライアントで対応するサブスクリプション形式を選び、インポート結果を確認します。ノードだけがインポートされた場合は、ルールとDNSを別途設定してください。
サブスクリプションの更新は、3つのクライアントそれぞれで行います。Macで更新してもiPhoneの更新は実行されません。モバイル端末ではバックグラウンド処理が制限される場合もあります。まずは自動更新の間隔を24時間に設定し、ノードに変更があったときに手動で更新する方法がおすすめです。これは初期設定の目安であり、選べる間隔やバックグラウンドでの動作はクライアントによって異なります。
サブスクリプション更新による上書きを防ぐ
サブスクリプションから取得したファイルを直接編集すると、次回の更新で変更が失われることがあります。上書きに対応するクライアントでは、ローカルポート、DNSの調整、独自ルールを専用の上書き設定に記述しましょう。非対応の場合は、ローカル設定を別に保存し、ノードを今後どう更新するかも決めておきます。各端末が対応していれば、プロキシプロバイダーを使ってノードの更新とメイン設定を分離する方法もあります。
サブスクリプションURLには通常アクセストークンが含まれるため、パスワードと同様に管理してください。URL全体を公開スクリーンショットやログ、公開リポジトリに載せないでください。また、形式変換のために見知らぬオンラインサービスへ安易に渡すのも避けましょう。URLが漏れた場合は提供元でトークンを再発行し、各端末の登録先を更新してください。
iCloud Drive：ファイルを同期して再インポート
Macの「Finder」→「iCloud Drive」で専用フォルダ（例：ClashConfig）を作成し、共有する設定ファイルだけを保存します。iPhoneでは「ファイル」→「ブラウズ」→「iCloud Drive」から確認できます。WindowsではiCloudをインストールしてサインインし、iCloud Driveを有効にしてから該当フォルダにアクセスします。
- 1台をメインの編集端末に決め、
shared.yamlを保存してアップロードが完了するまで待ちます。 - 受信側の端末で、クラウド上のファイル表示だけではなく、ファイルがローカルにダウンロードされていることを確認します。
- クライアントのファイルインポート機能から対象ファイルを選び、解析結果を確認してから現在の設定に切り替えます。
- 変更後はまず1台で動作を確認し、他の端末では再インポートするか、クライアントが対応する再読み込み機能を使います。
重要なのは、「元ファイルを読み込む」のか「コピーをインポートする」のかを見分けることです。YAMLをクライアントのデータフォルダにコピーするクライアントでは、iCloud上のファイルが更新されても、クライアントは古いコピーを使い続けます。確認するには、一時的に見分けやすいプロキシグループ名に変更し、再インポート後に画面へ反映されるかを確認します。
同じYAMLを複数の端末で同時に編集しないでください。ファイル同期で競合コピーが作成されたり、手動で統合する際にインデントやルールの順序を壊したりするおそれがあります。一度に編集する端末は1台にし、動作確認済みのファイルを残しておきましょう。受信側で反映を確認してから次の変更に進みます。
プライベートGit：ルールのレビューと設定のロールバック
Gitは、自分で管理するルールや設定の構成を保存する用途に向いており、アカウントの認証情報の保管には適していません。次のようにディレクトリを分けられます。ファイル名はプロジェクト内の取り決めであり、Clashやmihomoが自動認識するものではありません。クライアントから明示的にインポートするか、独自の生成手順で組み立ててください。
clash-config/
├── shared.yaml
├── rules/
│ └── direct.yaml
├── local/
│ ├── mac.yaml
│ └── windows.yaml
└── .gitignoreshared.yamlには共通のプロキシグループとルールを、local/には端末ごとの差分を保存します。実際のサブスクリプションURLやシークレットを含むファイルはコミット対象から除外してください。一度履歴に追加された秘密情報は、後から除外設定を追加しても自動では消えないため、認証情報の再発行も必要です。プライベートリポジトリはアクセス制御の一手段にすぎず、あらゆる秘密を長期保管する場所として使うべきではありません。
コミット、取得、動作確認
git diff -- shared.yaml rules/
git add shared.yaml rules/
git commit -m "DIRECTルールの順序を調整"
# 他のデスクトップ端末で作業コピーを更新
git pull --ff-onlygit pull --ff-onlyはブランチが分岐している場合に停止するため、意図しないマージを作成せず、先にローカルの変更を処理できます。取得に成功した後も、クライアントで設定を再読み込みする必要があります。iPhoneで適切なGit運用ができない場合は、信頼できるファイルインポート方法で配布ファイルを受け取れば十分です。スマートフォンでデスクトップ開発環境一式を再現する必要はありません。
mihomoベースのデスクトップ環境では、適用前に生成後のファイルをテストできます。ここでのeffective.yamlは、共有設定と端末ごとの差分を統合したファイルです。このコマンドを実行するには、ローカル環境からmihomoの実行ファイルを呼び出せる必要があります。
mihomo -t -f effective.yaml設定テストに合格すれば、コアが設定を受け付けたことは確認できます。ただし、リモートノードに接続できることや、システムプロキシが有効になっていることまでは保証されません。問題が起きた場合は、Gitから前のファイルを取得して再インポートまたは再読み込みします。ファイルを戻してもシステムのネットワーク設定は復元されないため、別途確認してください。
ローカル上書き：ポート、TUN、ルールの順序
MacとWindowsでルールの考え方は共有できますが、入口となる設定は端末ごとに分けてください。以下はmihomoベースのデスクトップ向けローカル設定項目の一例で、プロキシ設定全体ではありません。例では混合ポートに7890を使用し、コントローラーはループバックアドレス127.0.0.1:9090のみで待ち受けます。
mixed-port: 7890
allow-lan: false
mode: rule
external-controller: 127.0.0.1:9090
tun:
enable: falseこれらの項目は、クライアントが対応するローカル設定または上書き機能を通じて適用してください。すべてのクライアントが同じ方法でYAMLをマージするとは限りません。特にリスト形式の項目は、全体を置き換える方式と、先頭への追加や末尾への追加に対応する方式があります。適用後は最終設定を確認し、既存のプロキシグループやルールが意図せず消えていないか確認してください。
- ポート：まず
7890が他のプロセスに使用されていないか確認します。ポートを変更したら、ターミナルのプロキシ環境変数や、手動設定したアプリのプロキシも合わせて変更してください。 - TUN：デスクトップでは権限、ルーティング、他のVPNとの連携が関係します。iPhoneでは通常、システムのネットワーク拡張機能を使って通信を取り込みます。デスクトップの
tun.stackやネットワークインターフェース名をそのまま流用することはできません。 - DNS：まず各端末で動作する名前解決の設定を維持してください。DNSポリシーを共有する場合は、項目ごとに対応状況を確認します。YAMLを解析できるというだけで、動作も同じだと判断しないでください。
- コントローラー：通常、端末をまたいで公開する必要はありません。LAN経由で操作する必要がある場合は、認証とアクセス範囲を別途設定し、待ち受けアドレスを単純にすべてのネットワークインターフェースへ変更しないでください。
独自ルールはフォールバックルールより前に配置
Clash形式のルールは上から順に判定されます。以下は、ドメインのDIRECTルールを最終フォールバックより前に配置する例です。PROXYは完全な設定内に存在するプロキシ名またはプロキシグループ名に置き換えてください。
rules:
- DOMAIN-SUFFIX,example.org,DIRECT
- MATCH,PROXY既存のMATCHより後ろに新しいルールを追加すると、通常そのルールは判定されません。共有ルールでは、特定の端末にしかないプロキシグループ名への依存も避けましょう。各端末で同じ名前のグループを用意し、その中で異なるノードを選べるようにするのがおすすめです。グループ名を統一しても、選択するノードまで同じにする必要はありません。
会社のイントラネット用ドメイン、LANアドレス、特定のWi-Fi向けの例外ルールは、ローカル設定に分けるのが適しています。Macが接続しているネットワークでしか機能しないことがあり、モバイル回線のiPhoneにコピーしても役に立たないどころか、想定外の接続先になる場合があります。
同期後の確認とよくある問題
更新のたびに「ソース → 最終設定 → ルール判定 → 実際の接続先」の順に確認すると、クライアントを何度も再インストールするより効率的です。まず1台で検証してから他の端末へ反映すれば、問題の範囲を絞り込めます。
- ソースを確認：サブスクリプションの更新日時、ファイルの更新日時、またはGitのコミット履歴を確認し、3台すべてに同じ変更が届いていることを確かめます。
- 設定を確認：現在有効な設定の名前、プロキシグループの数、新しいルールが最終設定に反映されているかを確認します。
- 通信の取り込みを確認：デスクトップではシステムプロキシまたはTUNの状態を確認します。iPhoneではクライアントの接続状態を確認し、他のVPNとの競合にも注意してください。
- 振り分けを確認：DIRECTになる想定のサービスと、プロキシ経由になる想定のサービスにそれぞれ接続し、接続ログで該当ルール、プロキシグループ、実際のノードを確認します。
同じサブスクリプションなのにノード一覧が異なる
まず出力形式、クライアントのプロトコル対応状況、ローカルのフィルター条件を確認してから、更新日時を比較してください。サブスクリプションサービスがクライアント識別情報に応じて異なる内容を生成する場合もあります。ノード一覧の件数だけで同期失敗と判断しないでください。トークンを含むレスポンス全体を公開して比較するのも避けましょう。
ルールが同じでも接続先が異なる
正常な動作の場合もあります。手動選択したグループの現在のノードは、通常各端末で個別に保存されます。自動選択グループは端末ごとのネットワーク環境で測定します。Macが自宅のWi-Fiに接続し、iPhoneがモバイル回線を使っている場合、プロキシグループの定義が同じでも異なるノードが選ばれることがあります。問題を再現するには、各端末で一時的に同じノードを選んでから違いを確認してください。
ファイルを更新したのにクライアントに反映されない
まず、ファイルのコピーをインポートしていないか、別の設定が有効になっていないか、サブスクリプション更新後に再読み込みが成功したかを確認します。現在使えている設定を残したうえで、再インポートを試してください。長期運用には「共通のサブスクリプションまたはルールソース＋端末ごとのローカル上書き」という構成がおすすめです。ルールの履歴管理が必要ならGitを追加し、少数のファイルを手動でやり取りするだけならiCloudを使います。同期範囲を明確にするほど、マルチデバイスの問題を特定しやすくなります。