プラットフォーム 読了時間：約12分

PCとスマホで設定を共有する方法｜サブスクリプションURL・WebDAV・プライベートGitを比較

サブスクリプションURL、WebDAVバックアップ、プライベートGitの3つの同期方法を比較。更新タイミングや競合の解決方法、用途の違いを解説します。

1. 共有する設定・ノードサブスクリプション・クライアント設定を区別する

PCとスマホで同じサブスクリプションURLを使っていても、すべての設定が同期されるわけではありません。Mihomoはプロキシ接続、ルール、DNSを処理するコアです。設定のインポートや定期更新、画面上のオプションの保存、システム権限の取得はクライアントが担います。WebDAVバックアップやGitからの取得も、通常はクライアントまたは外部ツールの機能であり、Mihomoコアが自動で同期するものではありません。

作業を始める前に、サブスクリプションから返される内容を確認しましょう。完全な設定ファイルには通常、proxiesまたはproxy-providers、proxy-groups、rulesなどが含まれます。ノード情報だけのサブスクリプションは、クライアントで変換するか、別のメイン設定から参照する必要があります。ノード一覧を完全な設定として読み込むと、ノードは表示されても、想定したプロキシグループやルールがない場合があります。

  • 共有に向くもの：プロキシグループ名、ルーティングルール、ルールセットの参照、互換性を確認済みのノードソース。
  • 端末ごとに保存するもの：システムプロキシのオン・オフ、TUNの権限、Androidのアプリ別プロキシ設定、クライアントのウィンドウや起動設定。
  • 個別に確認が必要なもの：DNSの待ち受けアドレス、受信ポート、ネットワークインターフェース名、外部コントローラーの接続先、ローカルのファイルパス。

2. 3つの方法：更新の仕組みと用途

方法 同期するデータ 更新のタイミング 競合時の対応 主な用途
サブスクリプションURL サーバーで公開されたノードまたは設定 クライアントから手動または定期的に取得 リモートの内容を再インポート。ローカルでの変更は上書きされる場合がある 個人が複数端末で同じ公開設定を使う
WebDAV クライアント対応のバックアップファイル バックアップと復元。自動化できるかはクライアントによる コピーを保存してから、復元元を選ぶ 端末の買い替え、再インストール、同系列クライアントへの移行
プライベートGit テキスト形式の設定、ルール、変更履歴 コミット、プッシュ、プル後に反映 差分を行単位で比較して手動マージ 独自ルールの管理、複数端末での共同編集、過去の状態への復元

3つの方法を組み合わせることもできますが、同じ有効設定ファイルを複数のツールから同時に書き換えるのは避けましょう。たとえば、Gitでルールのソースファイルを管理し、サブスクリプションURLで生成結果を公開、WebDAVでクライアントのローカル設定をバックアップします。データの種類ごとに書き込み元を1つにすれば、上書きの原因も特定しやすくなります。

3. サブスクリプションURL：同じ配信元から個別に更新

インポート後は更新日時だけでなく内容を確認する

  1. 提供元の管理画面から、ClashまたはMihomo向けのサブスクリプションURLを取得し、契約プランで複数端末や同時接続が認められているか確認します。
  2. PCとスマホそれぞれの設定管理画面でリモートURLをインポートします。メニュー名はクライアントによって異なるため、「URLからインポート」などのリモート設定用メニューを選びましょう。
  3. 一度手動で更新し、プロキシグループ名、ルール数、現在有効な設定を確認します。更新のダウンロードに成功しても、その設定に切り替わったとは限りません。
  4. 両方の端末でシステムプロキシまたはVPNの権限を設定し、Webページにアクセスしてみましょう。その後、接続ログでルールの適用状況と通信の出口を確認します。

クライアントの完全な設定ファイルの更新間隔は、まず24時間に設定するのがおすすめです。これは初期設定の目安であり、コアの固定値ではありません。提供元に更新頻度の制限がある場合は、その指示に従ってください。Androidのバックグラウンド実行や省電力設定、PCのスリープによって更新が遅れることもあります。ノードの変更時は手動で更新し、結果を確認しましょう。

完全な設定ファイルの更新とproviderの更新は別のタイマー

クライアントによるサブスクリプションの定期取得は、通常、完全な設定ファイルの置き換えや再インポートを行います。一方、MihomoのHTTPタイプのproxy-providersでは、intervalでノードソースの更新間隔を指定します。単位は秒で、たとえばinterval: 3600なら1時間ごとです。HTTPタイプのルールセットの更新間隔は、該当するrule-providersで設定します。これらの項目を変更しても、クライアントによる完全な設定ファイルの更新予定は変わりません。

独自ルールを残すには、クライアントが明示的に対応している上書き機能やマージ機能を使いましょう。ダウンロードしたYAMLにルールを1行追加しただけで、変更がずっと残るとは限りません。次回のサブスクリプション更新でファイルが上書きされることがあります。マージ後はルールの順序も確認してください。特に、フォールバック用のMATCHルールが後続のリクエストを先に拾わないよう注意が必要です。

4. WebDAV：双方向同期ではなく、バックアップと復元に向く

WebDAVはリモートファイルへのアクセス機能を提供しますが、「バックアップのアップロード」「バックアップのダウンロードと復元」「継続的な双方向同期」はそれぞれ別の操作です。WebDAV対応のクライアントでも、保存できるのがクライアント自身のデータベースだけで、別のクライアントにバックアップを直接読み込めないことがあります。移行前に、両方のクライアントが同じバックアップ形式に対応しているか、サブスクリプションURLや認証情報がバックアップに含まれるかを確認してください。

復元できるバックアップ手順を用意する

  1. ストレージサービスに専用フォルダーを作り、同期ツールにはそのフォルダーだけにアクセスできるアカウントまたはアプリパスワードを設定します。
  2. HTTPSのURLで接続します。HTTPSでは通常TCP 443を使用します。サービスが別のポートを指定している場合は、サーバーの実際の接続先を使ってください。
  3. まずPCからバックアップをアップロードし、スマホ側では手動でダウンロードまたは復元します。復元前にスマホの現在の設定を保存し、唯一の利用可能なコピーを直接上書きしないようにしましょう。
  4. 復元後、サブスクリプション、プロキシグループ、端末固有の権限を確認します。VPNの権限とシステムプロキシの状態も、移行先の端末で確認が必要です。

外部のファイル同期ツールでYAMLを同期する場合は、リモートファイルを一時フォルダーにダウンロードし、検証してからクライアントにインポートしましょう。同期ツールから、クライアントが読み込み中のファイルへ直接書き込み続けるのは避けてください。途中でネットワークが切れたりファイルが競合したりしても、稼働中の設定がすぐに置き換わるのを防げます。

両方の端末で変更した場合の選び方

たとえば、PCで09:00にルールを変更し、オフラインのスマホで09:10にサブスクリプションを変更したとします。その後、両方の端末から同じ名前のバックアップをアップロードしても、「更新日時が新しい」だけでは、もう一方の変更が含まれているとは判断できません。端末間で時刻がずれている可能性もあります。まず両方のコピーを保存し、サブスクリプションとルールを比較して、どちらを正本にするか決めましょう。

バイナリ形式や暗号化されたバックアップは、テキストのように行単位でマージできません。より安全なのは、1台をバックアップの公開担当とし、他の端末では主に復元する運用です。バックアップに認証情報が含まれる場合は、クライアントが提供する暗号化機能を使いましょう。HTTPSで転送していても、サーバー上のファイルまで暗号化されるとは限りません。

5. プライベートGit：ルールの変更履歴を管理し、認証情報は分けて扱う

ドメインルールを頻繁に調整する、変更をレビューする、過去の状態に戻すといった用途にはGitが向いています。テキストの変更が記録されるため、どのルールを、誰が、いつ、なぜ変更したのかを確認できます。ただし、プライベートリポジトリにもアカウントや共同編集者、自動化ツールのアクセス管理が必要です。ノードのパスワード、サブスクリプションのトークン、コントローラーのキーを直接コミットしないでください。

ファイルを整理してから同期する

以下はソースファイルの整理例であり、Mihomoが自動認識するディレクトリ構成ではありません。Mihomoには最終的に完全で有効な設定ファイルを読み込ませる必要があります。ファイルを分割する場合は明確な組み立て手順が必要で、コアが自動でマージすると想定してはいけません。

proxy-config/
├── base.yaml
├── rules/
│   └── local.yaml
├── devices/
│   ├── desktop.yaml
│   └── android.yaml
├── .gitignore
└── README.md

base.yamlには共通構成を、rules/にはルールのソースファイルを、devices/には秘密情報を含まないプラットフォームごとの差分を保存します。実際のサブスクリプションURLと生成後の設定ファイルは、リポジトリの外に置いてください。以下の除外ルールは、この例で定めたファイル名だけを対象とするため、コミット前の確認の代わりにはなりません。

# .gitignore
secrets/
private-provider.yaml
runtime.yaml
*.log

変更のたびに同じ手順で進める

  1. まずgit pull --ff-onlyを実行してリモートの変更を取得します。ブランチが分岐していると表示された場合は、差分を解決してから進め、強制的に上書きしないでください。
  2. ルールを編集し、git diffで変更内容を確認します。実際のサブスクリプションURLやノードのパスワードが混入していないことも確認してください。
  3. プロジェクトの手順に沿ってruntime.yamlを生成し、対象端末に対応するMihomoのバージョンで設定を検証します。
  4. 検証に通ったらソースファイルをコミットしてプライベートリポジトリにプッシュします。他の端末では変更を取得し、設定ファイルを再生成してからインポートします。
mihomo -v
mihomo -t -f runtime.yaml
git diff --check
git add base.yaml rules/local.yaml
git commit -m "ローカルのドメイン振り分けルールを調整"
git push

mihomo -t -f runtime.yamlは設定のテストに使うコマンドです。リモートのノードに接続できることや、TUNの権限が整っていることまでは確認できません。設定が相対パスや外部ルールファイルを参照する場合は、同じ作業ディレクトリと依存ファイルも用意してください。Windowsでは実際のコア実行ファイル名を使用できます。クライアントに内蔵されたコアのパスは、インストール方法によって異なります。

スマホ用クライアントには、Gitツールや任意のディレクトリへのアクセス機能がない場合があります。信頼できる取得・反映手順を用意できないなら、PCでリポジトリを管理し、管理されたHTTPS URLで設定を公開してスマホから利用する方法がおすすめです。設定の同期のために、リポジトリのアクセストークンをサブスクリプションURLに直接埋め込まないでください。

6. 複数プラットフォームではポート、TUN、DNSの端末固有設定を保つ

「設定を共有する」とは、すべての項目を一字一句同じにすることではなく、ルールの仕組みを共有することだと考えましょう。デスクトップOSではシステムプロキシを設定できますが、Androidのクライアントは通常、VpnServiceで通信を処理します。権限、ルーティング、アプリごとの制御方法はそれぞれ異なります。

項目・機能 設定の目安 確認ポイント
mixed-port 端末で使用中のポートに合わせる 7890はよく使われる例であり、すべてのクライアント共通の固定ポートではありません
allow-lan LANからの接続が不要なら無効にする 有効にした場合は、待ち受けアドレス、ファイアウォール、認証も確認する
TUNとVPN プラットフォームごとに権限とルーティングを設定する デスクトップのTUN設定は、AndroidのVPN権限の代わりにはなりません
DNSとdns-hijack 端末のネットワーク環境でテストする DNSリクエストが実際にコアへ届いているか確認する
external-controller リモート管理が不要なら外部に公開しない ローカル管理ではループバックアドレスへのバインドを優先し、アクセスキーを設定する

端末ごとの上書き設定では、マージの仕様も確認しましょう。クライアントによって、dnsセクション全体を置き換える場合もあれば、マッピングをマージする場合や、rules配列を追加または置き換える場合もあります。上書きエディターの数行だけを見るのではなく、最終的に有効な設定を確認してください。Androidのアプリ別プロキシ設定は、実際にインストールされたアプリのパッケージ名にも依存するため、デスクトップのプロセスルールをそのまま流用するのは避けましょう。

7. 更新時の競合、ロールバック、適用状態の確認

更新後にルールが消えた

まず、ルールがリモートのサブスクリプション、クライアントの上書き設定、一時生成ファイルのどこに書かれていたかを確認し、今回の更新でどの層が置き換わったかを調べます。管理するソースファイルに、たとえば# profile-revision: 2026-08-23-01のようなコメントを追加しておくと便利です。これはリリースを識別するための目印で、ルーティングには影響しません。実際に読み込まれたかどうかは、最終設定とログで確認してください。

PCでは正常なのにスマホで接続できない

現在の設定名、更新日時、コアのバージョン、ノードソース、プロキシグループの選択を順番に比較し、次にスマホのVPN権限とバックグラウンド制限を確認します。同じサブスクリプションでも、同じ時刻に同じノードを使うとは限りません。手動選択したノードやヘルスチェックの状態は、端末ごとに保存されることがあります。まず通信の出口をそろえてからテストすると、原因を絞り込みやすくなります。

新しい設定を読み込めない

  1. 失敗した設定ファイルとエラーログを保存し、エラーが出た項目や行番号を記録します。
  2. 検証済みの直前の設定に戻し、まず接続を復旧させます。複数の設定を一度に変更するのは避けてください。
  3. Gitの場合は直近のコミットを確認します。WebDAVの場合は個別に保存した過去のバックアップを復元します。サブスクリプションの場合は、提供元が過去のバージョンに対応しているか確認します。
  4. 修正後はまず1台でテストし、問題がないことを確認してから他の端末に反映します。

最終確認では少なくとも次の3点をチェックします。コアが設定を読み込めること、プロキシが必要な通信に想定したルールが適用されること、直接接続すべき通信が誤って転送されていないことです。共有設定にDNSやTUNの変更が含まれる場合は、Wi-Fiとモバイル通信の両方で名前解決と接続を確認しましょう。「サブスクリプションの更新に成功」と表示されただけで、設定全体が正常に動作していると判断しないでください。

8. 管理方法に合わせて同期手段を選ぶ

  • プロバイダーのサブスクリプションを主に使う：両方の端末に同じURLを登録し、それぞれ更新間隔を設定します。独自ルールはローカルの上書き設定で管理し、エクスポートしたコピーも保存しましょう。
  • 再インストールや端末の買い替えに備える：クライアント対応のWebDAVバックアップを選び、まず復元形式を確認してから自動バックアップを有効にするか決めます。
  • 独自のルーティングルールを管理する：プライベートGitでテキストのソースファイルを管理し、検証後に公開します。スマホでは利用可能な設定を取得するだけにします。

長期的な運用では、「ソースファイルの保存場所」「変更担当者」「検証方法」「復元方法」を決めておくことが、すべての端末をリアルタイムで上書きし合うことより重要です。共有ルールは一元管理し、プラットフォーム固有の権限は各端末で設定します。更新前に利用可能なコピーを保存しておけば、設定変更時に問題の箇所を特定しやすくなります。設定項目の詳細はルールと設定の解説、クライアントのインストールや権限設定は使い方ガイドをご覧ください。

Clash をダウンロード