Clashの複数端末設定同期：サブスクリプション・オーバーライド・プライベートリポジトリ

Windows、macOS、Linux、モバイル端末で Clash または mihomo を使う場合、同期すべきものは通常1つの YAML だけではありません。プロキシノードはサブスクリプション、ルールはリモートルールセット、プロキシグループは個人の好み、ポート、TUN、LANアクセス、DNSの待受アドレスは端末環境に左右されます。クライアントのデータディレクトリ全体をそのままコピーすると、キャッシュ、実行状態、データベース、プラットフォーム固有の項目まで別の端末へ持ち込むことになり、ポート競合、設定の読み込み失敗、ローカル変更の上書きにつながりやすくなります。

安定して運用するには、まず設定を階層化します。継続的に更新されるリモートデータはサブスクリプションや Provider に任せ、端末間で共通するルールとプロキシグループはレビュー可能なベース設定にまとめ、ポート、TUN、DNS、LAN関連の項目は端末ごとのオーバーライド層に残します。サブスクリプションURL、オーバーライドファイル、プライベートリポジトリは排他的な三択ではありません。それぞれデータ配布、端末差分、バージョン管理という異なる課題を解決します。

まず同期範囲を決める：設定ソース、端末パラメータ、実行データ

複数端末同期の第一歩はツール選びではなく、どの内容を同じ権威ソースで管理するかを決めることです。Clashの設定は次の4種類に分けると運用しやすくなります。

• リモートリソース：プロキシノードのサブスクリプション、プロキシ Provider、ルール Provider。リモート側で管理され、クライアントが設定した間隔で更新します。
• 共有ロジック：プロキシグループ名、ルールの順序、ドメインルール、地域別ルーティング、フォールバック方針。ベース YAML やバージョン管理リポジトリで管理するのに適しています。
• 端末パラメータ：mixed-port、コントロールポート、LAN待受、TUNの有効化、ネットワークアダプターの選択、一部のDNS待受設定。端末ごとに管理すべき項目です。
• 実行データ：ログ、キャッシュ、接続履歴、Geoデータのダウンロード結果、Providerキャッシュ、クライアントデータベース。これらは各端末で個別に生成します。

クライアントの「設定ディレクトリ」には、これら複数種類のデータが同時に含まれていることが少なくありません。そのため、ディレクトリ全体をクラウドストレージで双方向同期するのは避けるべきです。2台の端末を同時に動かすと、データベースや状態ファイルが繰り返し上書きされる可能性があります。OSが違えば、保存先、権限、改行形式も異なります。移行が必要な場合は、使用中のデータディレクトリを共有フォルダーとして扱うのではなく、明確な YAML またはクライアントが提供するバックアップファイルをエクスポートしてください。

方法1：サブスクリプションURLでノードを同期する

サブスクリプションURLは、「複数の端末で同じノード群を取得する」用途に最適です。各端末で同じURLをインポートし、クライアントに定期更新させます。ノード一覧を手作業でコピーする必要がなく、ノード名、アドレス、利用可否が変わっても各端末が個別に最新情報を取得できます。

ただし、サブスクリプションが提供するのは通常、プロキシ項目だけ、またはサーバー側で生成された完全な設定ファイルです。サーバー側の完全設定にプロキシグループやルールが含まれている場合、クライアントの更新時もリモート側の内容が優先されます。ローカルのカスタマイズを上書きから守るには、変更していないサブスクリプション設定を保持し、クライアントが対応するマージ、スクリプト、オーバーライド機能で端末固有のルールを追加します。クライアントによって「オーバーライド」「設定のマージ」「前処理スクリプト」の実装は異なるため、移行前に処理順序を確認してください。

mihomo の設定では、ノードソースを proxy-providers として宣言し、共有ベース設定からリモート Provider だけを参照する方法もあります。次の構成は、更新間隔、キャッシュパス、ヘルスチェックの関係を示したものです。

proxy-providers:
  primary:
    type: http
    url: https://sub.example.net/profiles/team-laptop.yaml
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

proxy-groups:
  - name: 手動選択
    type: select
    use:
      - primary
    proxies:
      - DIRECT

interval は Provider の取得間隔を指定します。ヘルスチェックの間隔は登録されたプロキシの状態確認に使われ、サブスクリプションの再ダウンロード間隔とは異なります。キャッシュパスは現在の端末上のローカルパスにし、同期リポジトリへ含める必要はありません。例にあるドメインは構造説明用です。実際には自分のサブスクリプションURLを入力し、ネットワーク環境からアクセスできるテスト先を選んでください。

サブスクリプション認証情報の分離

サブスクリプションURLには、リソースへのアクセスに使える認証情報が含まれていることがあります。機密情報として扱い、実際のURLを公開リポジトリ、スクリーンショット、障害ログ、公開可能な設定断片に書かないでください。複数端末で使う場合は、各クライアントにURLをローカル保存し、共有リポジトリには認証情報を含まないプロキシグループとルールだけを置きます。サーバー側で端末ごとの専用URLを発行できるなら、端末単位の認証情報に分けることで、1台だけアクセスを停止しやすくなります。

また、一般的な Clash クライアントが、Gitのログイン状態を必要とするプライベートリポジトリURLを直接読み取れるとは限りません。ブラウザーでプライベートファイルを開けても、カーネルがHTTPリクエストを送る際に同じ認証情報を付けるとは限りません。有効期限の短いダウンロードURLも、期限切れ後に自動更新を失敗させます。そのため、配布側はクライアントが継続的に取得できるアクセス方式を用意する必要があります。

方法2：オーバーライドファイルで端末差分を管理する

オーバーライド層は、「ルールはほぼ同じだが、システムパラメータが異なる」ケースに適しています。たとえばデスクトップPCではシステムプロキシを参照しないアプリの一部をTUNで処理し、業務用端末ではシステムプロキシだけを有効にし、家庭内の端末ではLANアクセスを許可する、といった構成です。こうした差分を1つの YAML に詰め込むと、同期のたびに端末固有の値を手で戻すことになります。

共有ベース設定は中立的な状態に保ち、端末ごとに短い差分ファイルを管理します。論理的には次のように分割できます。

profiles/
  base.yaml
overrides/
  windows-desktop.yaml
  macbook.yaml
  linux-shell.yaml
rules/
  local-direct.yaml
  service-routing.yaml

Windowsのデスクトップ用オーバーライドではTUNを有効にして自動ルーティングを指定できます。Linuxのコマンドライン環境では固定の混合ポートだけが必要な場合があり、macOSでは使用するクライアントとシステム権限に応じてTUNの有効化を判断します。allow-lan、bind-address、外部コントローラーの待受アドレスも端末パラメータとして扱うべきです。これらはLAN内でのアクセス可能範囲を変えるためです。

mixed-port: 7890
allow-lan: false

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

オーバーライドだからといって、任意の YAML が自動的に重ね合わせられるわけではありません。クライアントによって浅いマージ、深いマージ、スクリプト処理、フィールド置換など方式が異なります。特に配列は差が出やすい項目です。たとえばオーバーライド側の rules 配列が、ベース設定のルール末尾に追加されず、全体を置き換える場合があります。プロキシグループの配列も全体置換として扱われることがあります。同期フローを初めて構築する際は、少数のテストルールで実際のマージ結果を確認してから、完全な設定を移行してください。

DNS設定も共有項目と端末項目を分ける

DNSのルールロジックは共有できます。たとえば Fake-IP を使うか、どのドメインを除外リストに入れるか、どのルールセットでルーティングするか、といった項目です。一方、待受アドレス、LAN向けDNSサービス、システムDNSの引き継ぎ方法は端末環境に依存します。モバイルホットスポット、家庭内LAN、社内ネットワークでは、内部ドメインの名前解決要件が異なることがあります。すべての端末で同じ nameserver と待受設定を同期しても、1台で正常に動くからといって別の端末にも適用できるとは限りません。

TUNを使う場合は、クライアントのカーネルバージョンとプラットフォーム権限が対象フィールドに対応しているかも確認してください。mihomo の拡張設定を、旧版のオリジナル Clash フィールドにしか対応しないクライアントへそのまま渡すべきではありません。クロスプラットフォームで同期する前に、各クライアントが実際に使用するカーネルを確認し、共有設定で採用するフィールドを決めます。

方法3：プライベートリポジトリで共有設定と変更履歴を管理する

カスタムルール、複数端末のオーバーライド、長期運用するスクリプトが増えてきたら、YAMLを何度も送るよりもプライベート Git リポジトリのほうが変更を追跡しやすくなります。リポジトリの主な価値は、どのロジックを誰がなぜ変更したのか、問題が起きたときにどこへ戻せるのかを記録することです。サブスクリプションサービスを直接置き換えるものではありません。

リポジトリにはレビュー可能なソースファイルだけを保存し、クライアントの実行ディレクトリはコミットしないことを推奨します。バージョン管理に含めるのは、ベース YAML、端末オーバーライド、ルールファイル、生成スクリプト、利用手順です。ログ、キャッシュ、データベース、実際のサブスクリプションURL、クライアントが自動取得する Provider ファイルは除外してください。

clash-config/
  profiles/
    base.yaml
  overrides/
    desktop.yaml
    laptop.yaml
    server.yaml
  rules/
    private-network.yaml
    work-services.yaml
  scripts/
    build-config.js
  README.md
  .gitignore

チームや家族で同じルールセットを共有する場合は、リポジトリ内でプロキシグループ名を統一します。たとえばルールから参照できる名前を 手動選択、自動選択、DIRECT に限定し、端末オーバーライドで勝手に改名しないようにします。新しいルールを追加しても、ある端末に対象プロキシグループがなくて読み込みに失敗する事態を防げます。

プライベートリポジトリの設定は、2通りの方法でデプロイできます。1つ目は各端末でリポジトリを取得し、ローカルスクリプトでベース層と端末層を結合して最終 YAML を生成する方法です。2つ目は管理された環境で最終設定を生成し、クライアントがアクセスできる配布URLへ公開する方法です。前者はローカルデバッグに向いていますが、端末ごとに Git と生成環境が必要です。後者はサブスクリプションのインポートだけを行うクライアントに適していますが、配布権限を適切に管理する必要があります。

リポジトリとクライアントが変更権を奪い合わないようにする

リポジトリとクライアントのどちらを権威ソースにするかを明確にしてください。ルールをリポジトリ基準で管理するなら、クライアントが生成した最終設定を長期的に手編集しないことです。変更が必要な場合はソースファイルへ戻り、テストしてから再生成します。端末で一時的にルールを追加した場合は、まずローカル検証として記録し、有効性を確認してから共有層へ取り込みます。そうしないと、次回の取得や生成でクライアント側の変更が消え、リポジトリにも差分の理由が残りません。

YAMLアンカーは同一ファイル内の重複を減らせますが、複数の独立ファイルを自然にまたいで使えるものではありません。設定を分割した後の結合方法は、クライアントのオーバーライド機能または外部生成処理に依存します。ファイル拡張子だけで直接マージできると判断しないでください。

更新順序を固定する：リモートリソース、オーバーライド、最終確認の順

複数端末同期で最も多い問題は、設定の書き間違いではなく更新順序の不一致です。ある端末がサブスクリプションを先に更新してからオーバーライドを適用し、別の端末が完全設定を先に上書きしてからサブスクリプションを更新すると、最終的なプロキシグループやルールが異なる可能性があります。すべての端末で次の手順を統一してください。

1. 現在の権威ソースを確認。今回変更するのがサブスクリプション、共有ベース設定、端末オーバーライドのどれかを確認し、生成結果を直接編集しないようにします。
2. 共有設定を取得。プライベートリポジトリから最新のベース層とルールファイルを取得し、先にバージョン競合を解消します。
3. リモートリソースを更新。プロキシ Provider とルール Provider を更新し、URLに引き続きアクセスできることを確認します。
4. 端末オーバーライドを適用。この端末のポート、TUN、DNS待受、LAN関連のパラメータを追加します。
5. 設定テストを実行。クライアントの設定チェックまたはカーネルのテスト機能で、YAML構文、プロキシグループの参照、ルールの宛先が有効か確認します。
6. 再読み込みして通信を確認。ダイレクト接続のドメイン、プロキシ経由のドメイン、DNSクエリ、システムプロキシを参照しないアプリをそれぞれテストします。
7. 残す変更だけをコミット。共有ロジックに属すると確認できた変更だけをリポジトリへ入れ、端末固有のポートやローカルパスは端末層に残します。

更新中に複数端末から同じクラウドストレージ上のファイルへ同時に結果を書き込むのは避けてください。Gitはテキストのバージョン管理に使えますが、クライアントのデータベースや生成ファイルは通常マージに向きません。別の端末で作業を続ける場合は、先にコミットとプッシュを完了してから対象端末で取得し、双方が古いバージョンを基に同じルールを編集する事態を避けます。

同期競合と読み込み失敗の切り分け

サブスクリプション更新後にカスタムルールが消える

まず、カスタムルールがサブスクリプションから生成されたファイルへ直接書かれていないか確認します。そうであれば、更新時にリモート側の完全設定で上書きされるのは想定された動作です。ルールをクライアントが対応するオーバーライド層へ移すか、独立したベース設定で管理し、rule-providers からルールを参照してください。オーバーライドの適用順序も確認します。サブスクリプション更新後に自動で再適用するクライアントもあれば、手動で設定を再生成する必要があるクライアントもあります。

同じ設定が1台では使えるのに、別の端末では起動できない

まずカーネルの種類、フィールドの対応状況、ローカルリソースを確認します。オリジナルの Clash、Clash Meta、mihomo では拡張フィールドの対応範囲が異なります。TUNにはシステム権限とプラットフォームのネットワークスタックも関係します。次に、ポートの使用状況、ローカルパスの存在、外部コントローラーのアドレス競合を確認します。ルールが原因で待受ポートの作成に失敗することは通常ないため、いきなりルールを削除しないでください。

プロキシグループでプロキシまたは Provider が見つからない

use が参照する Provider 名が、proxy-providers 内の名前と完全に一致しているか確認し、Provider のダウンロードが成功していることも確認します。共有設定でプロキシグループ名を固定している場合、端末オーバーライドで名前を変更しないでください。YAMLはインデントに敏感なので、Providerが誤った階層にインデントされていると、参照先が存在しないように見えることもあります。

端末によってルールのマッチ結果が異なる

リポジトリのソースファイルだけでなく、最終的に読み込まれた設定を比較してください。端末ごとにルール Provider のキャッシュバージョンが異なる場合や、オーバーライドで rules 配列全体が置き換えられている場合があります。ルールの順序が同じか、特に広範囲のドメインルール、GEOIPルール、末尾の MATCH フォールバックを確認します。Clashは通常、ルールを上から順に評価し、先にマッチしたルールが後続の通信経路を決めます。

プライベートリポジトリURLはブラウザーで開けるのに、クライアントの更新に失敗する

多くの場合、認証方式が原因です。ブラウザーにはログイン状態が保存されていますが、Clashカーネルからの Provider リクエストには同じ認証情報が付与されません。URLがWebセッション、一時認証、リダイレクトページに依存していないか確認してください。クライアントは YAML の内容を直接取得し、正常なHTTPレスポンスを受け取る必要があります。ログインページが返されると、見かけ上は成功していても、有効な YAML ではないため解析に失敗します。

3つの方法を組み合わせる際の指針

個人で使う端末が2〜3台程度で、ルール変更も少ない場合は、「サブスクリプションURL＋クライアントオーバーライド」が適しています。ノードはサブスクリプションで更新し、ポートとTUNは各端末に残し、カスタムルールはクライアントが明確に対応するオーバーライド設定へ入れます。保守コストを低く抑えられる方法です。

大量のルールを長期的に管理する場合は、「サブスクリプション Provider、共有ベース設定、端末オーバーライド」の3層構成にします。ベース設定がプロキシグループとルール順序を担当し、Providerがノードとリモートルールを担当し、端末オーバーライドがプラットフォーム差分を担当します。最終設定はクライアントのマージ機能またはローカルスクリプトで生成します。

複数人で協力する場合や端末数が多い場合は、プライベートリポジトリを追加し、ベース設定、ルール、生成プロセスを管理します。リポジトリには実際のサブスクリプション認証情報を保存せず、クライアントキャッシュも同期しません。変更のたびに取得、テスト、コミット、デプロイを行い、各端末は自分に対応する最終設定だけを利用します。

どの組み合わせを選んでも、複数の権威ソースを同時に作らないことが重要です。ノードはサブスクリプション、ルールはリポジトリ、端末パラメータはローカルのオーバーライドで管理し、各内容は1か所だけで編集します。境界を明確にすれば、複数端末同期は「設定全体のコピー」から「階層ごとの更新と検証」へ変わり、サブスクリプション更新、ルール改訂、プラットフォーム差分も個別に扱いやすくなります。