まず結論：ルールの参照元は共通にし、端末ごとの設定は分ける

Mac・iPhone・iPadで同じClash設定を長く使うなら、同じリモート設定を参照し、端末ごとのローカル設定は個別に管理する方法がおすすめです。iCloud Driveはファイルを手動で受け渡す用途に、Gitプライベートリポジトリはルール変更の管理や旧版への復元に向いています。同期される対象は方法によって異なるため、「ファイルが更新された」ことを「クライアントに適用された」ことと混同しないようにしましょう。

ここでいう「同じ設定」とは、主にノードの参照元、グループ名、ルールを揃えることです。各端末の最終的なYAMLを一字一句同じにする必要はありません。macOSの待ち受けポート、TUNルーティング、補助サービスの設定をiOSへそのまま移すのは適切ではありません。また、iPhoneやiPadのクライアントがClash YAMLを直接読み込めるとは限りません。

方法 適したケース 更新方法 主な管理コスト
リモート設定の購読 複数端末で互換クライアントを使い、設定の配信元が安定している 各端末で取得して再読み込み 購読、上書き設定、更新状況の管理
iCloud Drive 端末が少なく、完全な設定ファイルを手動で編集することがある ファイルのダウンロード後、手動でインポート 複製ファイル、競合、再インポートへの対応
Gitプライベートリポジトリ 独自ルールが多く、変更履歴を残したい 変更を確認・マージしてから配信またはインポート アクセス権、認証情報、配信手順の管理

同期前に確認：コア、設定レイヤー、ローカル状態

Appleシリコンかどうかで設定形式は決まらない

Appleシリコン搭載Macにはarm64版、Intel Macにはx86_64版を選びます。この違いはプログラムの実行に関わるもので、YAMLの構文が自動で変わるわけではありません。設定の互換性を左右するのはコアとクライアントの実装です。Clash本家、Clash Meta（現mihomo）、その他のコアを使うiOSクライアントでは、プロトコル、ルールセット、DNS、TUNの各フィールドの対応状況が異なることがあります。

各端末でクライアントとコアのバージョン、設定名、最後に正常読み込みできた時刻を記録しておくと便利です。アプリのバージョンが同じでも、コアまで同じとは限りません。購読の更新に成功した場合も、ダウンロード段階が完了しただけかもしれないため、解析結果と現在有効な設定を確認してください。

設定を3つのレイヤーに分ける

  • 共有する内容：ノードの参照元、グループ名、ドメイン・IPの振り分けルール、ルールセットのURL。できるだけ全端末で揃えます。
  • 端末ごとの設定：待ち受けポート、LANアクセス、TUN、DNSの制御、ログレベル。OSやネットワーク環境に合わせて個別に設定します。
  • 実行状態：選択中のノード、速度測定結果、接続履歴。通常はクライアントのデータベースに保存され、YAMLファイルを同期しても自動では共有されません。

たとえば、すべての端末に「日常プロキシ」というグループがあっても、同じノードが自動的に選択されるわけではありません。通信経路を揃えたい場合は、各端末でグループの現在の選択先を確認してください。自動速度測定を使うグループも、Wi-Fiやモバイル回線、測定時刻によって結果が異なることがあります。

方法1：同じリモート購読を使い、端末ごとに更新する

日常使いにはリモート購読が最も便利です。信頼できるHTTPS URLから設定を配信し、各端末で個別に取得します。まず、配信される内容が完全なClash YAMLなのか、ノード一覧のみなのか、Base64形式のノード文字列なのかを確認してください。後者2つは、ルールやグループを含む完全な設定として、そのまま使えるとは限りません。

初回インポートと更新の手順

  1. Macのクライアントにある設定管理画面からリモート設定を追加し、購読URLを入力します。「Apple端末共通ルール」のように、見分けやすい名前を付けてください。
  2. ダウンロード後、解析ログを確認します。proxiesまたはproxy-providers、proxy-groups、rulesなど、必要な項目が揃っていることを確認してから、現在の設定として適用してください。
  3. iPhoneやiPadのクライアントでも、リモート設定のインポート機能から同じ配信元を追加します。その形式に対応していない場合は、配信元が用意する対応形式を使ってください。ファイルの拡張子を変えるだけでは解決しません。
  4. 3台それぞれで更新と再読み込みを行い、ルール数、グループ名、読み込みエラーを確認します。設定の表示名だけを見比べないでください。
  5. 最後に、直接接続とプロキシ接続を1つずつテストし、接続履歴で実際に適用されたルールと通信経路を確認します。

クライアントによってメニュー名は「設定」「Profiles」「購読」など異なり、すべてのアプリに共通する操作手順はありません。システムプロキシやVPNのオン・オフと設定の更新も別の操作です。新しいファイルをダウンロードした後、設定を切り替えるかトンネルを再接続しないと反映されないクライアントもあります。

完全な購読設定の更新とノードプロバイダーの更新は別

クライアントの「購読を自動更新」は、通常、設定全体を更新します。一方、mihomoのproxy-providersが更新するのはノードプロバイダーの内容です。プロバイダーのinterval: 3600で3600秒ごとに更新を試みる設定にしても、メイン設定のrulesが変更されるわけではありません。同様に、rule-providersが更新するのは該当するルールセットであり、YAML全体の再ダウンロードではありません。

独自ルールが必要な場合は、クライアントが明確にサポートするローカル上書き、マージ、スクリプト機能を優先してください。ダウンロード済みキャッシュのYAMLを直接編集すると、次回の購読更新で変更が上書きされることがあります。上書き機能はすべての端末で使えるわけではないため、ダウンロード前・後・読み込み時のどの段階で反映されるかを事前に確認してください。

方法2：iCloud Driveでファイルを同期し、クライアントへ手動インポート

iCloudは、自分で設定を管理し、ときどき別の端末へ配布する使い方に向いています。同期するのはファイルであり、YAMLの検証やクライアントによる変更監視は行いません。システムのファイル選択画面からインポートすると、アプリのサンドボックス内にコピーが作られる場合があります。その後、元ファイルを変更してもコピーは自動更新されません。

ファイル受け渡しの手順を決める

  1. Macで「システム設定」→「Apple Account」→「iCloud」→「iCloud Drive」を開き、同期が有効になっていることを確認します。旧バージョンのOSでは「Apple ID」と表示される場合があります。
  2. Finderの「iCloud Drive」にClash-Sharedフォルダを作成し、UTF-8形式のshared.yamlを保存します。リッチテキスト形式が追加される編集方法は避けてください。
  3. iPhoneまたはiPadで「設定」→「Apple Account」→「iCloud」→「iCloud Drive」を開き、「このiPhoneを同期」または「このiPadを同期」を有効にします。
  4. 「ファイル」→「ブラウズ」→「iCloud Drive」→Clash-Sharedを開き、ファイル名が表示されるだけでなく、実際にダウンロードが完了するまで待ちます。
  5. クライアントのローカルファイル読み込み機能からYAMLを選び、インポート後の設定名、解析結果、有効状態を確認してください。元ファイルを再編集した場合は、同じ手順で再インポートまたは更新します。

上記は近年のOSで一般的なメニュー名を使った手順です。画面や項目名はOSのバージョンによって異なる場合があります。「ファイル」にiCloud Driveが表示されない場合は、アカウントとiCloud Driveの設定を確認してください。クラウド同期の問題を調べるために、設定を何度も新規作成する必要はありません。

更新を確認するための目印を付ける

YAMLの先頭にコメントを1行残しておくと、原文を表示できるクライアントでファイルを見分けやすくなります。このコメントは手動確認用で、ルールの動作には影響せず、クライアントの一覧に表示される保証もありません。

# config-revision: 2026-09-09-r1
  • 主ファイルの編集はMacだけで行い、iPhoneとiPadはインポート専用にすると、複数端末での同時編集による競合ファイルを減らせます。
  • shared-2026-09-08.yamlのように、直前の正常なファイルを残しておきます。3台すべてで問題がないことを確認してから、古い複製を整理してください。
  • アプリがiCloud Driveのファイルに継続してアクセスできない場合は、システムのファイル選択画面からアクセス権を付与し直すか、再インポートしてください。以前のアクセス権が永久に有効だとは限りません。

方法3：Gitプライベートリポジトリでルールと変更履歴を管理

ルールを頻繁に調整する場合、Gitの利点は変更履歴を残し、差分を確認して旧バージョンへ戻せることです。iOSでGitを自動実行するためのものではありません。より安全な方法は、リポジトリには公開しても問題のないルールとテンプレートだけを保存し、Macで取得・生成した最終設定を、リモートURLまたはファイル経由でスマートフォンやタブレットに配布することです。

ルールと認証情報を分けて保存する

独自ルールはrules.yamlに保存し、実際の購読URLやローカルで生成したファイルは、Gitに登録しないディレクトリに置く方法がおすすめです。以下は.gitignoreの記述例です。ファイル名は実際の生成手順に合わせてください。

secrets/
runtime/
*.local.yaml
.DS_Store

.gitignoreが対象にするのは、まだ追跡されていないファイルだけです。すでにコミット履歴に含まれた認証情報は削除されません。トークンをコミットしてしまった場合は、まずサービス側で無効化またはローテーションし、その後でリポジトリの履歴を処理してください。プライベートリポジトリでもアクセス権の管理は必要ですが、長期間有効な購読情報を履歴に含めないようにしましょう。

Macで変更を確認してから、ほかの端末へ配布する

以下のコマンドは、リポジトリがすでにクローンされ、リモート名がorigin、共有ブランチがmainであることを前提としています。まず作業ツリーの状態を確認し、次にリモートのルールとの差分を確認してください。未完了のローカル変更がある場合は、上書きしないよう先に保存して処理します。

git status --short
git fetch origin
git diff HEAD..origin/main -- rules.yaml
git pull --ff-only

更新後は、まずMacで生成された設定を確認し、実際のクライアントで読み込みテストを行います。mihomoのコマンドライン版をインストールしている場合は、最終ファイルを使って設定を検証できます。

mihomo -t -f runtime/shared.yaml

検証に通るのは、そのコアで設定を検査できたことを示すだけです。すべてのプロキシノードに接続できる保証ではなく、iOSクライアントとの互換性テストの代わりにもなりません。その後、設定を公開するかiCloudに保存し、ほかの端末で更新してください。リモートルールセットでは、クライアントが対応するbehaviorとファイル形式も必要です。通常のルール断片を、あらゆる種類のルールプロバイダ用ファイルとして扱うことはできません。

Gitプライベートリポジトリのファイル直リンクは、認証が必要だったり、リダイレクトやキャッシュ、アクセス期限が設定されていたりすることがあります。WebページのURLをクライアントに貼り付ければYAMLを取得できるとは限りません。ログイン画面ではなくファイル本文が返されることを確認してください。クライアントで安全に認証できない場合は、Macで取得してファイルで配布する方法のほうが管理しやすくなります。

Mac・iPhone・iPadで個別に管理する設定

同期する範囲をあらかじめ決めておくと、「Macでは使えるのにスマートフォンでは通信できない」といった問題を減らせます。以下は、これらのフィールドに対応するClash系コア向けのローカル設定例です。ノードやグループを含む、そのまま使える完全な設定ではありません。ポートをGUIから管理するクライアントでは、最終的に適用される設定を優先してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
項目 Mac iPhone / iPad
接続方式 アプリの用途に合わせてシステムプロキシまたはTUNを選択 通常はクライアントが提供するVPNトンネル経由で通信を制御
待ち受けポート 例：ローカルの混合ポート7890。ポートの競合に注意 クライアントの実装に従い、Macと同じポートを使わない
LANアクセス プロキシ共有が不要なら無効にする マルチデバイス同期の前提にしない
DNS / TUN ローカルルーティング、名前解決、ほかのVPNとの競合を確認 アプリがサポートするDNSとトンネル設定を優先

ここでのポート7890は例であり、すべてのクライアントに共通する既定値ではありません。Macでシステムプロキシを有効にしても、その設定に従うアプリにしか影響しません。TUNが通信を制御する範囲は、ルーティングや除外設定によって変わります。設定を同期しても、macOSの補助サービスの認証や、iOSのVPN設定に必要な許可が自動で完了することはありません。

DNSも安易にコピーしないでください。自宅のWi-Fi、会社のネットワーク、モバイル回線では、同じDNSサービスでも動作が異なることがあります。共有設定にfake-ip、DNSの振り分け、DNS制御が含まれる場合は、各端末が対応しているかを確認してください。まず名前解決が正常に動作することを確かめてからルールの適用状況を確認すると、DNSの失敗を購読の不具合と取り違えにくくなります。

同期後にルールが一致しない場合の5つの確認ポイント

  1. 参照元が同じか確認する。3台で同じ設定元、形式、オプションを使っているか確認します。購読変換の出力オプションが異なると、ノードやルールも異なる場合があります。
  2. 新しい内容を取得したか確認する。最後に更新が成功した時刻、更新コメント、ルール数を確認します。iCloudにファイル名が表示されてもダウンロード済みとは限りません。リモートAPIがHTTP 200を返しても、エラーの説明文が返されている場合があります。
  3. 読み込み済みか確認する。設定一覧を見るだけでなく、現在有効な設定を確認してください。読み込みに失敗しても、古い設定のまま動作を続けるクライアントがあります。エラーログも確認しましょう。
  4. 上書きの順序を確認する。ローカル上書きによってmode、DNS、グループ、ルールが変わっていないか確認します。通常のルールは上から順に照合されるため、前方の広い条件が後方の詳細なルールより先に適用されることがあります。
  5. 実際の通信経路を確認する。接続履歴で対象ドメイン、適用ルール、グループ、最終的に選ばれたノードを比較します。同じグループでも、端末ごとに手動選択や速度測定の結果が異なる場合があります。

小さな変更で同期の流れ全体をテストする

まず更新コメントを変更し、設定に実在するグループを使って、テスト用ドメインに対する具体的なルールを1つ調整します。そのルールは、先に一致する可能性がある広いルールと、フォールバックのMATCHより前に置いてください。3台で更新して再読み込みした後、新しい接続を試し、適用されたルールを履歴で確認します。既存の長時間接続は、新しいルールで再接続されるとは限りません。

ファイルが届いたかだけ確認するなら、更新コメントを比較します。振り分けが機能しているかを確かめるには、接続履歴の確認が必要です。テストを分けることで、「ファイルが更新されない」「解析に失敗する」「ルールの順序が誤っている」を切り分けられます。テスト後は一時的なルールを元に戻し、正常な設定を残してください。

設定を始める前に、クライアント比較で各プラットフォームの対応形式や機能を確認し、クイックスタートを参考に初回インポートを行ってください。接続や名前解決に問題がある場合は、トラブルシューティングガイドを使って順に確認します。購読、DNS、トンネル方式を一度に変更するのは避けましょう。