1. 共通設定と端末別設定を分ける

PCとスマホでClash設定を共有する場合、共通化に向いているのはノードの取得元、プロキシグループ名、ルールによる振り分け設定です。クライアントのデータフォルダ全体を共有するわけではありません。Clash Metaで使われるmihomoコアは設定を読み込み、通信を処理します。一方、サブスクリプションの更新、システムプロキシ、VPN権限、設定の上書きはクライアント側で個別に管理されます。この2つの層を混同しないようにしましょう。

たとえばWindowsではシステムプロキシを 127.0.0.1:7890 に設定できますが、Androidでは通常、クライアントがVPNインターフェースを作成して通信を取り込みます。両端で同じ rules を読み込んでも、通信がコアに届く仕組みは異なります。同期できた状態とは、ルールとノードの取得元が一致し、端末ごとの通信制御も正しく設定されていることです。すべてのスイッチを同じにすることではありません。

  • 共有する設定：proxy-providers、proxy-groups、rule-providers、rules、および両端で動作確認したDNSポリシー。
  • 端末ごとの設定：mixed-port、allow-lan、tun、待ち受けアドレス、コントローラーのAPIキー、ローカルファイルのパス。
  • クライアントの状態：選択中のノード、速度テスト結果、ログ、キャッシュ、VPN権限。通常、設定同期の対象にはしません。

2. 3つの同期方法と更新の仕組み

方法 端末への更新方法 主な注意点 適した用途
サブスクリプションURL クライアントがHTTP経由で定期または手動取得 サーバー側の設定とクライアント側の上書きを分けて管理 ノードが頻繁に変わり、スマホでは主に読み込む場合
プライベートGitリポジトリ 変更をpullしてから、ファイルをインポートまたは再読み込み Gitツールと個別のインポート作業が必要 ルールの変更が多く、差分確認やロールバックが必要な場合
WebDAV 同期ツールでファイルをダウンロードし、クライアントにインポート ファイルの競合解決と設定の反映は別の作業 プライベートストレージがあり、主に1台の端末で編集する場合

mihomoは、リモートGitリポジトリに新しいコミットがあっても自動でpullせず、WebDAVも自動監視しません。クライアントがそれらの接続方法に対応しているか、個別に確認してください。WebDAVバックアップ機能があっても、保存されるのは設定や設定一覧だけで、リモートのYAMLをリアルタイムのサブスクリプションとして読み込むとは限りません。

3. サブスクリプション管理：設定元を統一し、端末ごとの上書きを保持

まずサブスクリプションの返却内容を確認

完全なClash設定には proxies、proxy-groups、rules が含まれます。ノード一覧だけを返す場合は、proxy-providers から参照する形式が適していることもあります。また、mihomoで直接読み込めるYAMLではなく、エンコードされたノードリンクを返すサブスクリプションもあります。2台の端末で同じ設定形式を選び、URLの拡張子だけで判断しないようにしましょう。

  1. PCのクライアントで設定管理を開き、リモート設定を追加します。サービスが発行した正しいサブスクリプションURLを入力し、まず手動で更新してください。
  2. スマホにも同じURLをインポートし、プロキシグループ名とルール数を確認します。結果が異なる場合は、サブスクリプション形式の設定や、クライアント識別情報によってサーバーが異なる内容を返していないかを確認してください。
  3. 端末ごとの差分は、設定に紐づくローカル上書きに記述します。次回の更新で置き換えられるリモートファイルを直接編集しないでください。
  4. 更新間隔は端末ごとに設定します。クライアントが対応していれば、たとえば24時間ごとに設定できます。スマホはOSのバックグラウンド制限を受けるため、定期更新が予定時刻どおりに実行されるとは限りません。

リモート設定全体の取得間隔は、通常クライアント側で管理します。proxy-providers 内の interval: 3600 は、そのプロバイダーを3600秒ごとに更新する設定であり、クライアントによるサブスクリプション全体の更新設定を置き換えるものではありません。ルールプロバイダーにも個別の更新間隔があるため、それぞれ確認してください。

ホスティング・変換サービスのプライバシー上の注意

サブスクリプションURLを外部の変換サービスに渡すと、そのサービスがノード情報を読み取れる可能性があります。変換サービスを自分で運用する場合も、アクセス制御、リクエストログ、キャッシュを適切に保護してください。形式変換が本当に必要な場合だけ、この仕組みを追加しましょう。元のサブスクリプションがmihomo互換の設定を返すなら、直接インポートするほうが問題を切り分けやすくなります。

自分の完全な設定をホスティングする場合は、HTTPSとアクセス制御を使い、ログに機密情報を含むURLが残らないようにしてください。リクエストヘッダー認証に対応したクライアントでは、専用の認証情報を使えます。URL認証のみ対応するクライアントでは、URLを慎重に管理してください。URLが漏れた場合はトークンを無効化または再発行します。ローカルの設定名を変えてもアクセス権は取り消せません。

4. プライベートGitリポジトリ：ルールのバージョン管理と変更履歴

Gitは、カスタムドメインルール、プロキシグループの構成、端末別の上書きを管理するのに適しています。レビュー可能な設定のソースファイルだけをリポジトリに保存し、サブスクリプションのトークン、ノードのパスワード、コントローラーのAPIキーは端末側で個別に管理しましょう。プライベートリポジトリでも、コミット履歴、共同作業者の権限、CIログの管理が必要です。

次のようなディレクトリ構成にできます。base.yaml に共通設定を保存し、2つの上書きファイルに端末ごとの差分を記述します。ディレクトリを分けただけでは自動でマージされません。最終的に有効な設定を生成するには、クライアントの上書き機能か、独自のビルド処理が必要です。

clash-config/
├── base.yaml
├── overrides/
│   ├── desktop.yaml
│   └── android.yaml
└── README.md

PCでの基本的な更新手順

クローン済みのリポジトリで、以下のコマンドを実行します。まず未コミットの変更がないか確認し、更新時に意図しないマージコミットが作られないよう、fast-forwardのみでpullしてください。更新後は、プロジェクトで決めた方法で実行用設定を生成し、実際に読み込ませる前にテストします。

git status --short
git pull --ff-only
git log -3 --oneline

mihomo -t -f ./runtime.yaml

runtime.yaml はこの手順で生成する完全な設定ファイルであり、Gitに標準で付属するファイルではありません。テストコマンドを実行するには、ローカルにmihomoがインストールされている必要があります。ローカルのプロバイダーファイルを参照する場合は、実行時と同じ作業ディレクトリを使い、必要に応じて -d で指定してください。テストに成功しても、設定を検証できたことを示すだけで、すべてのノードへの接続を保証するものではありません。

スマホでは、信頼できるGitツールでリポジトリを取得してから、クライアントのローカルファイルインポート機能で更新できます。通常のリポジトリ閲覧ページのURLをサブスクリプションURLとして使わないでください。プライベートリポジトリから元ファイルをダウンロードするには、通常、認証も必要です。クライアントがその認証方式に対応しているとは限りません。

設定が壊れたときのロールバック

まず現在の実行設定を保存し、直近のルール変更を確認します。共有済みのコミットを取り消す場合は、端末が参照している履歴を強制的に書き換えるのではなく、git revert で取り消し用コミットを作成してください。機密情報を含むサブスクリプションが履歴に入った場合、最新バージョンから該当行を削除するだけでは漏えいを防げません。まず認証情報を更新し、その後リポジトリの履歴や複製先を処理してください。

5. WebDAV：ファイル転送と設定の読み込みを分ける

WebDAVは、NASやプライベートストレージをすでに利用している場合に向いています。「PCで書き込み、スマホで読み込み」のように、書き込み端末を1台に絞る運用がおすすめです。2台で同時に config.yaml を編集すると、後からアップロードしたファイルが先の変更を上書きしたり、同期ツールが競合コピーを作成したりする可能性があります。Clashクライアントがこれらのファイルをマージすることはありません。

  1. ストレージサービスに設定専用のディレクトリを作り、スマホ用に読み取り専用の認証情報を発行します。設定できる権限はサーバー側の機能によって異なります。
  2. PCから公開予定の設定を、config-2026-09-08.yaml のようなバージョン付きファイルとしてアップロードします。アップロード完了後、配布用に決めたファイルを更新してください。
  3. スマホではまずファイルをローカルにダウンロードし、クライアントのファイルインポート機能から読み込みます。クライアントにWebDAV設定の直接読み込み機能がある場合は、設定本文も実際に更新されるか確認してください。
  4. 直前に正常動作していたファイルを残しておきましょう。インポートに失敗した場合は古いファイルに戻し、唯一のコピーを何度も上書きしないでください。

WebDAVのユーザー名やパスワードをURLに直接埋め込まないでください。一般的な「リモートサブスクリプション」の入力欄が、WebDAVに必要な認証に対応しているとは限りません。HTTP 401が発生した場合は、認証情報とクライアントの対応状況を確認してください。TLS検証を無効にして回避してはいけません。証明書エラーが出た場合は、証明書チェーン、ドメイン名との一致、端末の時刻を修正してください。

6. 端末別の上書き：ポート、TUN、ルール一覧

デスクトップ向けの上書き設定

以下は、上書きのマージに対応したクライアント向けの端末設定例です。単独でインポートできる完全なサブスクリプションではありません。デスクトップでは、最初の同期で通信制御の方式が同時に変わらないよう、システムプロキシを維持してTUNを無効にします。クライアントに「LAN内接続を許可」やポートの設定画面がある場合は、保存後にこれらの値が上書きされていないか確認してください。

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

システムプロキシに設定するHTTPプロキシのアドレスは 127.0.0.1、ポートは 7890 です。ほかのアプリがこのポートを使用している場合は 7891 に変更し、システムプロキシとアプリ内の手動プロキシ設定も合わせて更新してください。YAMLだけを変更して、システムプロキシに古いポートを残さないようにしましょう。

Android向けの上書き設定

スマホでは、両端で共通して使える基本項目だけを上書きし、VPNによる通信制御はクライアントに任せる方法が適しています。AndroidクライアントによってTUNファイルディスクリプターの作成方法や受け渡し方が異なるため、デスクトップ用の tun.auto-route、インターフェース名、ルート除外設定をそのまま流用しないでください。

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

起動時にAndroidのVPN接続を許可し、クライアントのアプリ別プロキシ設定も確認してください。リモートのルールが同じでも、VPNの対象外にしたアプリはmihomoのルール判定に進みません。端末ごとに独立しているため、スマホとPCで同じ7890番ポートを使っても競合しません。

ルールの上書きで自動追加を前提にしない

YAMLのマップ項目やリスト項目をどのようにマージするかは、クライアントの実装によって異なります。以下は rules を完全に置き換える最小例です。最終的な設定に「ノード選択」という名前のプロキシグループが存在することを前提としています。ルールを1つだけ先頭に追加したい場合は、リストが自動で連結されると考えず、クライアントが明示的に提供するルール先頭追加機能を使ってください。

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,ノード選択

ルールは上から順に判定されるため、MATCH は末尾に配置します。この例はLAN内通信の直接接続と最終的な振り分けだけを示しており、元のサブスクリプションに含まれるほかのルールはありません。このまま置き換えると、元のルールが失われます。また、ドメインルールでは home.arpa を名前解決できません。LAN内のドメイン名は、到達可能なローカルDNSで解決する必要があります。端末ごとに接続先のネットワークが異なる場合、DNSの上流サーバーやLAN内の名前解決先は端末別の設定に残してください。

7. 同期後の確認とよくあるトラブル

まず1台で動作を確認してから、もう1台を更新してください。サブスクリプションの更新、DNSの変更、TUNの有効化、ルール順の変更を同時に行うと、接続できないときに原因を特定しにくくなります。以下の確認は、実際には存在しない速度テスト結果に頼らず、クライアントの画面とログで行えます。

  • 設定元が一致：両端で同じサブスクリプションまたは同じGitコミットを使っているか確認します。WebDAVの場合は、ダウンロードしたファイル名と更新日時を確認してください。
  • マージが正しい：サブスクリプションの元データだけでなく、最終的な実行設定を確認します。ポートが7890、モードが rule で、上書きによってプロキシグループが意図せず削除されていないことを確認してください。
  • ルールが適用される：ルールを設定済みのドメインにアクセスし、接続履歴で適用されたルールと最終ポリシーを確認します。出口IPの比較だけで判断しないでください。
  • ローカルネットワークに接続できる：実在するルーターの管理アドレスまたはLAN内のサービスにアクセスし、LANルールとDNSが機能していることを確認します。
  • 再更新しても設定を維持：サブスクリプションをもう一度手動更新し、端末別の上書きが保持され、ルールの順序も変わらないことを確認します。

PCでは使えるのにスマホでは使えないときの確認項目

まずAndroidのVPNが動作しているか、対象アプリがVPNの除外対象になっていないかを確認し、次に設定の読み込みエラーを確認してください。「ポリシーが存在しません」と表示される場合は、ルールで参照しているプロキシグループ名を確認します。ローカルファイルの読み込みに失敗する場合は、共通設定にPC専用のパスが書かれていないか確認してください。両端のコアが対応する機能に違いがある場合は、クライアントとコアのバージョンを記録し、クライアント名だけで互換性を判断せず、エラーに示された項目を調べてください。

用途に合わせて同期方法を選ぶ

ノードをサービス側の更新に追従させたいだけなら、同じサブスクリプションを使い、端末ごとにローカル上書きを設定する方法がおすすめです。ルールを頻繁に変更し、差分を確認したい場合は、プライベートGitで共通設定のソースを管理します。プライベートストレージがあり、主にPCで編集するなら、WebDAVをファイル配布に利用できます。複数の方法を組み合わせることも可能です。たとえばGitでルールを管理し、サブスクリプションでノードを取得し、端末側で権限やポートを設定できます。ただし、各層の更新担当を明確にし、複数の経路から互いの設定を上書きしないようにしてください。