· マルチデバイス · 読了時間：約10分

パソコンとスマホでClashのサブスクリプションを共有する方法｜複数デバイスの設定同期

ClashのサブスクリプションURL共有、設定ファイルの手動コピー、クラウド保存、オーバーライドの再利用を比較し、それぞれの手順と注意点を解説します。

まず確認：サブスクリプションの同期と、すべての設定の同期は別

パソコンで使えている場合、スマホ用にサブスクリプションを別途購入する必要があるのでしょうか。まず、サービス提供元のデバイス数、同時接続数、通信量のルールを確認してください。複数デバイスでの利用が認められていれば、通常は同じサブスクリプションURLをパソコンとスマホにそれぞれ登録できます。各端末が個別に設定を取得するため、スマホをパソコンに接続する必要はありません。通信量は一般に同一アカウントで合算されます。詳細はサービス提供元の案内をご確認ください。

サブスクリプションは、ノードや設定一式を取得するためのリモート接続先です。クライアントは設定の読み込みや更新を行い、端末のネットワークを制御します。同じURLを使っていても、同じ提供元のデータを取得できる可能性があるというだけで、ルール、ノードの選択、動作設定まで一致するとは限りません。

4つの同期方法を比較

方法向いている用途更新方法と制約
各端末に同じサブスクリプションURLを登録個人のパソコンとスマホでノードを共用各端末で個別に更新。端末内の設定はURL経由では同期されない
設定ファイルを手動でコピー設定の移行、オフラインでの保管、固定テスト環境の構築コピー時点のスナップショットを取得。以降の変更は再転送が必要
プライベートクラウドで設定をホストカスタマイズした設定一式を一元管理ファイルに直接アクセスできる入口と、適切なアクセス制御が必要
オーバーライドルールやスクリプトを再利用ノードはサブスクリプションで更新し、個人ルールは各端末で統一各端末で個別に設定。クライアントごとの処理方式に合わせる必要あり

ほとんどの個人ユーザーは、まず同じサブスクリプションURLを各端末に登録する方法がおすすめです。カスタムルールも共通化したい場合に、オーバーライドを追加しましょう。クラウドでのホストには認証情報、更新、アクセス権限の管理が必要です。2台の同期だけを目的に、すぐ環境を構築する必要はありません。

方法1：パソコンとスマホにサブスクリプションURLを個別に登録

形式を確認してからインポートする

  1. サービス提供元のアカウントページで、Clashまたはmihomoと明記されたサブスクリプションのURLを探します。汎用URLしかない場合は、クライアントがその形式を解析できるか先に確認してください。
  2. パソコン版クライアントでサブスクリプション管理画面を開きます。たとえばClash Verge Revでは、「サブスクリプション」→画面上部のURL入力欄→「インポート」が一般的な手順です。ボタンの位置はバージョンによって異なる場合があります。
  3. インポート後、その設定を選択し、「プロキシ」でプロキシグループとノードが表示されることを確認します。サブスクリプションを追加しただけでは、その設定に切り替わっていない場合があります。
  4. 信頼できる方法でURLをスマホに転送します。スマホの「設定」または「サブスクリプション」画面でURLからのインポートを選び、保存して有効化してください。
  5. 両方の端末でそれぞれ更新を実行し、更新時刻を記録します。サービス提供元が新たに追加したノードや名前を変更したノードが、両方に表示されるか確認してください。

スマホアプリが別の設定形式を求めても、URLが無効だと決めつけないでください。まずサービス提供元から対応形式のURLを入手しましょう。変換が必要な場合は、自分で管理するか、信頼性が明確な変換サービスを利用してください。変換サービスにはサブスクリプションの認証情報やノード情報が渡る可能性があります。

更新間隔とノード選択は別々に管理する

パソコンが6時間ごと、スマホが24時間ごとに更新する設定なら、ある時点で表示されるノードが異なっていても不思議ではありません。これらの時間は更新方法の例です。サービス提供元の推奨設定を優先してください。スマホではバックグラウンド動作が制限される場合もあり、定期更新が指定時刻どおりに実行されるとは限りません。

同じ名前のプロキシグループでも、同じノードが選択されているとは限りません。手動選択、自動速度測定の結果、接続履歴は通常、端末ごとに管理されます。違いを調べる場合は、一時的に両端の同じグループで同じノードを選択してみてください。確認後は、それぞれ必要な自動選択方法に戻します。

方法2：YAML設定ファイルを手動でコピー

YAMLはClashでよく使われる設定テキスト形式で、インデントが構造を表します。手動コピーは、動作確認済みの設定を移行する場合に便利です。ただし、「元のサブスクリプションファイル」と「実行時の設定」は区別してください。実行時の設定には、クライアントが追加したポート、DNS、オーバーライド、ローカルパスがすでに統合されていることがあります。そのまま別の端末に移すと、互換性の問題が起きやすくなります。

  1. 元のクライアントの設定管理画面で対象の設定を探し、「ファイルを開く」またはエクスポート機能を使ってpersonal-config.yamlとして保存します。メニュー名は実際のクライアントに合わせてください。
  2. テキストエディターでproxy-providers、rule-providersなどの外部ファイル参照を確認し、移行先の端末でも各リソースを取得できることを確かめます。
  3. ローカル転送または暗号化したファイル転送でファイルを送り、移行先でファイルからインポートします。問題が起きたときに戻せるよう、既存の動作する設定は残しておきましょう。
  4. まず設定の読み込みが成功することを確認し、次にプロキシ接続をテストします。正常に動作することを確認してから、普段使う設定に切り替えてください。

移行時に問題が起きやすいのはポートとパス

たとえば、パソコンの設定で混合プロキシポートが7890、別のクライアントで実際に待ち受けているポートが7897だとします。いずれも例なので、移行先クライアントの画面と最終的な設定を確認してください。ブラウザーが127.0.0.1:7890を参照し続けていると、クライアントは起動しているのにブラウザーだけネットに接続できないことがあります。

同様に、WindowsのディスクパスはAndroidにそのまま移せません。ローカルルールファイルを参照する設定では、関連ファイルも一緒に移し、移行先クライアントが対応する場所にパスを変更する必要があります。YAMLファイル1つだけで、動作に必要なすべての内容が揃うとは限りません。

ファイルからインポートした設定は、通常、その時点のスナップショットです。YAML内の一部のプロバイダーがリモート更新に対応していても、設定全体が元のサブスクリプションに合わせて自動更新されるわけではありません。移行先クライアントがリモートサブスクリプションの接続先を保持し、認識しているか必ず確認してください。

方法3：プライベートクラウドで設定一式をホスト

複数の端末で、自分が管理する設定一式を使いたい場合は、アクセスを制御できるHTTPSの接続先に設定を置けます。ただし、「クラウドストレージからダウンロードできる」ことと「クライアントがサブスクリプションとして更新できる」ことは別です。クライアントが必要とするのは設定ファイルの生データであり、ログイン画面、プレビュー画面、認証コードが必要なダウンロードページではありません。

公開前に確認したい4つの条件

まず、ローカルで動作を確認した設定をアップロードし、パソコンとスマホでそれぞれ手動更新します。次に、見分けやすいテストルールを1つだけ変更して再度更新し、両方に新しい内容が反映されることを確認してください。一方に古い内容が表示される場合は、すべての端末を何度も再起動するのではなく、ファイルのキャッシュ、更新結果、実際のリクエスト先を確認しましょう。

更新の仕組みが依存関係を作らないようにすることも重要です。設定の接続先へのアクセスにプロキシが必要なのに、端末に利用可能なノードがまだ読み込まれていないと、初回のインポートに失敗する場合があります。初回のインポート用にアクセス可能なネットワーク環境かローカルファイルのバックアップを用意し、日常の更新に失敗した場合も元に戻せるようにしてください。

方法4：サブスクリプションの更新と個人用オーバーライドを分けて管理

オーバーライドとは、サブスクリプションの読み込み後に、クライアントが対応する仕組みで最終設定を変更することです。ノードはサブスクリプションで管理しつつ、個人用のDIRECTルールやポリシーの設定などをローカルに保持できます。サブスクリプションから生成されたファイルを直接編集すると、次回の更新時に変更が上書きされる可能性があります。

以下は、自分が管理するテスト用ドメインを対象としたルールの例です。example.comは予約済みのサンプルドメインで、実際の設定に使うドメインではありません。この断片はルールの構文を示すもので、単独で動作する設定一式ではなく、すべてのクライアントで共通して使えるオーバーライドファイルでもありません。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT

DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致し、DIRECTはプロキシを経由せず直接接続することを表します。ルールは上から順に照合されるため、優先させたい個人ルールは通常、該当する広範なルールや末尾のフォールバックルールより前に置きます。

統合時の動作を確認してから他の端末に反映する

  1. クライアントが対応するのは、ルールの先頭への追加、YAMLのマージ、スクリプト処理のどれかを確認してください。これらは別々の仕組みです。
  2. 配列の処理方法を確認してください。マージ機能によっては、新しいrules配列を既存の配列に追加せず、置き換えるものがあります。上の例をそのまま貼り付けると、サブスクリプションに元からあったルールが失われる場合があります。
  3. 元の端末で最終設定を確認し、個人ルールの順序が正しく、既存のプロキシグループとフォールバックルールも残っていることを確かめます。
  4. 移行先の端末では、そのクライアントが対応する形式でオーバーライドを再設定し、接続ログから実際に適用されたルールを確認してください。

パソコンがJavaScriptオーバーライドに対応し、スマホがYAMLマージにしか対応していない場合、スクリプトをコピーしても実行されるとは限りません。「どのルールを、どの順序で適用するか」という意図を共有し、各端末で個別に実装してください。サブスクリプション内のプロキシグループ名を参照するときは、名前を完全に一致させます。グループ名が変更されると、古い名前を参照するルールによって設定の読み込みに失敗することがあります。

同じサブスクリプションがパソコンでは使えてスマホでは使えない場合の確認手順

手順1：サブスクリプションが正常に解析されたか確認

サブスクリプションの更新結果またはログを開きます。HTTP 401、403が返る場合は、まず認証情報、アクセス権限、アカウントの利用制限を確認してください。429の場合はリクエスト頻度の制限を確認し、更新を連続で実行しないようにします。成功と表示されても設定形式のエラーが出る場合は、レスポンスが実際にはログイン画面ではないか、ノードのプロトコルが移行先のカーネルに対応しているかを確認してください。

手順2：アプリの通信がプロキシを経由しているか確認

デスクトップOSのシステムプロキシ設定が反映されるのは、その設定に従うアプリだけです。TUNは仮想ネットワークインターフェースを使って通信を取り込む方式で、権限、ルーティング、DNSが関係します。サブスクリプションを共有しても、別の端末でTUNが自動的に有効になるわけではありません。AndroidではVPN接続の許可を確認し、デスクトップではシステムプロキシとTUNの設定をそれぞれ確認してください。

手順3：ルール、DNS、対象アプリを比較

まず両端で同じノードを選び、ルールモードにして、同じ接続先にアクセスします。接続ログで適用されたルールと通信の出口を比較してください。一方が直接接続し、もう一方がプロキシ経由の場合は、ローカルオーバーライドと最終的なルールを優先して確認します。同じノードを使っている場合は、DNS、IPv6、ネットワーク環境、接続先サービスによる出口制限を調べます。Wi-Fiとモバイル通信での違いを、そのまま同期失敗と判断しないでください。

手順4：プランの制限とアカウント状態を確認

ノードが表示されていても、アカウントで接続できるとは限りません。残りの通信量、有効期限、同時接続数の上限を確認してください。1つのアカウントを2台で共有している場合、パソコンのバックグラウンドダウンロードでスマホ用の通信量も消費されることがあります。通信量や接続台数の問題を、サブスクリプションの頻繁な更新で解決しようとしないでください。

管理しやすい個人向けマルチデバイス構成

個人用の端末が2〜3台なら、「同じサブスクリプションを各端末に登録し、個人ルールは端末ごとにオーバーライドし、デバイス設定は個別に管理する」方法がおすすめです。各端末のクライアントとカーネルのバージョン、サブスクリプションの更新時刻、実際のポート、動作モード、オーバーライドファイルの保存場所を記録しましょう。記録には用途と場所だけを記載し、サブスクリプションの認証情報全体は書き残さないでください。

同期の目的は、同じ設定をすべての端末に強制することではなく、重複した管理を減らすことです。ノードの参照先とルールの意図は統一できても、権限、ルーティング、ポート、バックグラウンド動作は端末ごとに設定する必要があります。この境界を明確にすれば、複数端末の設定を更新しやすくなり、問題の原因も特定しやすくなります。

Clashをダウンロード