Clash マルチデバイス設定同期：サブスクリプション・セルフホスト・手動エクスポートの3つの方法

まず、同期すべきものは何かを切り分ける

複数のデバイスで「設定が食い違う」とき、原因の多くはクライアント側ではなく、性質の異なるデータをまとめて管理していることにあります。保存場所・更新方法・自動同期の可否はそれぞれ違うので、まず切り分けてから方法を考えます。

本当に統一すべきなのは設定本体と providers キャッシュです。前者はポート・DNS・TUN・ルールを決め、後者はノード一覧を決めます。どのノードを選んでいるか、mode が rule なのか global なのかは、もともとデバイスごとに設定すべきもので、揃える必要はありません。

よくある誤解：サブスクリプションが同じでも設定は同じにならない

サブスクリプションが決めるのはノードの取得元だけです。mixed-port、dns、tun、rules といったフィールドは各クライアントがローカルで保持しており、サブスクリプションを変えてもポートやローカルルールは同期されません。つまり「3台に同じリンクを入れた」ことと「3台が同じ動作をする」ことは別問題で、後者は以下の方法で担保します。

方法1：サブスクリプションリンクによる自動同期

3台のデバイスに同じサブスクリプション URL を登録し、クライアントが一定間隔で自動取得します。デスクトップ・Android・iOS のいずれも対応しており、もっとも適用範囲が広く、運用コストも最も低い方法です。

ポートが書き換わったときの症状

サブスクリプションによって mixed-port が 7890 から 7891 に変わると、システムプロキシやブラウザ拡張に固定で書かれた 7890 は古いポートを指したままになります。症状は、クライアントは接続済みと表示されるのに Web ページが一切開かないというものです。確認するには external-controller のパネル（既定では 127.0.0.1:9090 をリッスン）を開き、実際に有効なポートを見ます。

# 現在有効なポート・モード・DNS 設定を確認する
curl -s http://127.0.0.1:9090/configs

コマンドラインが使いにくい場合は、デスクトップクライアントの「設定」ページに表示されるポートと、ブラウザ拡張の値を照合するだけで十分です。

適用範囲

• 向いている：デバイス1〜3台、ルールはサブスクリプションに完全追従、追加のファイル管理をしたくない場合。
• 向かない：自前のルールがある、デバイスごとにポートを分けたい、サブスクリプションの構成を頻繁に調整する場合。

方法2：セルフホストで1つの YAML を全デバイスで管理

設定本体を直接ダウンロードできる場所（プライベートなオブジェクトストレージ、自前の nginx、プライベートリポジトリの raw リンクなど）に置き、各デバイスはその URL をサブスクリプションとして読み込みます。以降はルールを変えるときはこの1ファイルだけを編集すれば、各端末が次回取得した時点で反映されます。

ノードの取得元とルールを分離する

ノードを proxies に直接書かず、proxy-providers でカーネル自身に取得させます。ポート・DNS・ルールなど自分で管理する部分は、すべて base config に書きます。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: warning
external-controller: 127.0.0.1:9090
unified-delay: true
tcp-concurrent: true

proxy-providers:
  airport-a:
    type: http
    url: "https://sub.example.com/api/v1/client/subscribe?token=9f2c1a7b4e"
    interval: 3600
    path: ./providers/airport-a.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
      timeout: 3000

rule-providers:
  reject:
    type: http
    behavior: domain
    format: mrs
    url: "https://example.com/rules/reject.mrs"
    path: ./ruleset/reject.mrs
    interval: 86400

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
  fallback:
    - https://1.1.1.1/dns-query

2つの interval の単位はいずれも秒です。3600 なら1時間ごとにノードを取得、86400 なら1日ごとにルールセットを取得します。ノードの変動が頻繁なら前者を 1800 に短縮し、ルールセットはそれほど頻繁でなくて構いません。

公開前にローカルで構文チェック

# 設定チェックのみ。プロキシは起動しない
mihomo -t -d /etc/mihomo -f config.yaml

チェックを通ってからホスト URL に反映します。各デバイスがホスト URL を読み込んだ後は、ノードは providers が定期取得し、ルールの変更も各端末が設定を再取得するだけで済み、1台ずつ書き換える必要はありません。

フィールドとカーネルバージョンの対応

方法3：手動でのエクスポートとインポート

オフラインのデバイス、ルーター、一時的なデバッグにしか使う価値はありません。やり方は設定本体をエクスポートし、providers/、ruleset/ のキャッシュディレクトリも一緒にコピーします。キャッシュディレクトリを欠かすと無駄足になります。

次のようなケースでは、基本的に手動の方法しか選べません。

• 対象デバイスからホスト URL にアクセスできない場合。たとえば社内ネットワークやオフライン環境。
• 1つのルールや DNS 設定のセットを一時的に検証したいだけで、ホスト側のファイルを触りたくない場合。
• ルーターなどの組み込み環境で、USB メモリや SCP でしかファイルを置けない場合。

競合の処理：変更をレイヤーに分ける

3つの方法を併用すると、競合はほぼ同じ原因から生じます。それは、同じフィールドが2か所で変更されていることです。解決策は変更をレイヤーに分けることです。サブスクリプションやホスト側のファイルには共通部分だけを置き、デバイスごとの差異はマージ層に置きます。

マージ層には差分だけを書く

# Merge 設定：config.yaml 全体を複製せず、変更したい部分だけを書く
prepend-rules:
  - DOMAIN-SUFFIX,intranet.example.com,DIRECT
prepend-proxy-groups:
  - name: 手動選択
    type: select
    proxies: [自動選択, DIRECT]

ルールは prepend-rules で先頭に挿入し、サブスクリプション内蔵のルールより優先してマッチさせます。プロキシグループは prepend-proxy-groups で一覧の先頭に置くと、画面上で直接選べて便利です。サブスクリプションを更新してもマージ層の内容は上書きされません。ここが「サブスクリプションの設定を直接編集する」よりも信頼できる点です。

整合性チェックリスト

# provider の最終取得時刻とノード数を確認する
curl -s http://127.0.0.1:9090/providers/proxies

経験則が1つあります。同じフィールドを定義してよい場所は1か所だけ、ということです。ポート・DNS・TUN は base config に、ノードの取得元は proxy-providers に、デバイスごとの差異はマージ層に書きます。選択中のノードと動作モードは各デバイスに任せます。これを守れば、3台のデバイス間の違いは「今どのノードを選んでいるか」だけになります。

LAN 内で注意すべき2点

• external-controller は既定で 127.0.0.1 のみをリッスンします。他のデバイスからパネルにアクセスするには、明示的に 0.0.0.0:9090 に変更し、secret を設定する必要があります。
• 複数のデバイスで同時に allow-lan を有効にしても互いに競合しませんが、他のデバイスは正しいデバイスの IP を指定する必要があります。ポートは 7890 のままで構いません。

3つの方法の選び方

最もよくある組み合わせは、メインのデバイスはホスト URL とマージ層、スマホと予備機はサブスクリプションリンクを直接登録、ルーターのようにネット経由の更新が難しいデバイスは手動でファイルを置く、というものです。3つを併用しても、同じフィールドの定義場所が1か所だけである限り、互いに衝突しません。

よくある質問

スマホと PC に同じサブスクリプションを入れたのに、ノード数が違う

まず両方のデバイスで手動更新を1回ずつ行ってから比較します。それでも一致しない場合は、サブスクリプション URL が完全に同じか確認します。一部のサブスクリプションはクライアントの種類に応じて異なる形式を返すため、コピー時に末尾の &flag=clash のようなパラメータが欠けると結果が変わります。

サブスクリプション更新後にローカルルールが消えた。どう残すか

ルールをサブスクリプション本体に書かないでください。デスクトップ版はローカルルールをマージチェーンの prepend-rules に入れます。マージチェーンに対応していないクライアントは、自前のホスト URL に切り替え、ルールを base config の rules セクションに書きます。

同じ設定が macOS では正常なのに、Android では起動時にエラーになる

プラットフォーム依存のフィールドが異なるためです。tun、redir-port、tproxy-port はデスクトップと Linux 側の書き方で、Android ではクライアント自身の VPN サービスが引き継ぎます。また external-controller を 0.0.0.0:9090 と書きながら secret を設定していないと、一部のクライアントは起動を拒否します。これらのフィールドを base config から外し、各端末のマージ層に移せば解決します。

複数のデバイスで同時に TUN モードを有効にすると競合する？

競合しません。各デバイスの TUN はその端末内でのみ有効です。同じ LAN 内でいずれも allow-lan を有効にしている場合は、他のデバイスが正しいデバイス IP を指すように注意してください。パネルのポートは既定でローカルのみをリッスンするため、デバイスをまたいでアクセスするには明示的に開放し、secret を設定します。