Clash高度な設定ガイド

プロキシグループの種類と使い方

プロキシグループは、ルールに一致した接続の出口を決めるものです。システム通信の取り込みや、ドメインのIPアドレスへの変換は行いません。トラブル時は、まず通信がカーネルに届いているかを確認し、次に一致したルールがどのグループを指定しているか、最後にグループ内の選択先を確認します。プロキシ画面で出口を切り替えても、ルールの指定先を確認しなければ、その接続に関係のないグループを操作し続けることがあります。

手動選択と自動選択の違い

selectは手動選択型で、出口を明示的に指定したい場合に向いています。url-testは接続テストの結果に基づいて自動選択するため、よく使う出口の状態変化に対応したい場合に便利です。fallbackはリストの順に利用可能なメンバーを選ぶ方式で、最速のメンバーを毎回探すのではなく、優先順位を重視します。違いは選択方法であり、ノード自体の回線品質が変わるわけではありません。

load-balanceは複数の出口に接続を振り分ける機能です。1回のダウンロードを複数回線に分割して帯域を合算するものではありません。振り分け方式によっては、同じサービスから見える送信元アドレスが変わる場合があります。アカウントでセッション維持が必要なら、出口を固定するか、整合性を保つ振り分け方式が要件に合うか確認してください。自動切り替えをすべてのサイトに適した標準設定と考えるのは避けましょう。

ヘルスチェックで使うのは、グループに設定されたテスト用アドレスです。実際の通信では、別のドメイン、プロトコル、ポートを使う場合があります。テスト成功はその経路に接続できたことを示すだけで、すべてのサイトにアクセスできる保証にはなりません。頻繁なテストは余分な通信やモバイル端末のスリープ解除につながるため、利用環境に合わせて間隔を設定し、画面を更新し続ける目的で短くしすぎないようにしてください。

仕組みを把握しやすい小さな設定から始める

以下のグループは、組み込みのDIRECTとREJECTを参照する例です。命名と参照関係を示すもので、プロキシ出口は作成されません。設定を読み込んだら、プロキシ画面で選択先を切り替え、新しいテスト接続を開始して、許可と拒否の違いを確認してください。流れを理解してから、既存のサブスクリプションに含まれるノード名や下位グループ名をリストに追加します。名前は完全一致させてください。

proxy-groups:
  - name: 手動出口
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,手動出口
  - MATCH,DIRECT

実際の運用では、業務用グループから自動選択グループを参照させたり、手動でのトラブル対処用にDIRECTを残したりできます。ただし、グループ間の参照は一方向にしてください。AグループがBを含み、BもAを含むような構成にはできません。ノード名を変更しても、ルールやグループ内にある旧名が新しい名前に読み替えられることはありません。設定の読み込みに失敗した場合は、ログに存在しない参照先や循環参照の警告がないか確認してください。

メンバーがproxy-providersにある場合、グループでは通常、useでプロバイダーを参照します。プロバイダー名をノード名としてproxiesに書くわけではありません。プロバイダーはノードの集合を提供し、プロキシグループはその集合から接続先を選びます。役割を分けておけば、サブスクリプションを入れ替える際は提供元だけを変更し、業務ルールからは安定したグループ名を参照できます。

選択結果と接続のライフサイクルを確認する

グループ内の選択先を変更しても、通常はその後に確立する接続に適用されます。ブラウザーが再利用する接続、実行中のダウンロード、常時接続アプリは、以前の出口を使い続けることがあります。テスト前に対象の接続を閉じ、新しいリクエストを開始してください。通信を中断する場合は、作業内容を先に保存しましょう。ページを再読み込みしただけで出口が切り替わったと判断せず、接続画面に表示される経路を確認してください。

自動選択グループが頻繁に切り替わる場合は、メンバー数が多すぎないか、テスト先に特殊な処理が適用されていないか、DNSがテスト経路に影響していないかを確認してから、許容値や間隔の調整を検討します。一度に変更するのは一項目だけにし、変更前の値と結果を記録してください。すべてのメンバーで失敗する場合は、自動選択の階層を増やすのではなく、ローカルネットワーク、サブスクリプションの有効性、ノードの名前解決など共通の依存先を先に確認します。

ルールセットを使った管理

ルールセットを使うと、ドメイン、IPアドレス、クラシックルールをメイン設定から分離でき、変更頻度の高い業務リストを管理しやすくなります。メイン設定には提供元の定義、参照箇所、出口の選択を残し、内容の更新はルールプロバイダーに任せます。ドメインを一つ追加するたびにサブスクリプション全体を編集せずに済み、「一致条件の変更」と「出口ポリシーの変更」も区別しやすくなります。

ルールの内容、形式、参照先を区別する

rule-providersで読み込むルールソースを定義し、RULE-SETでルールソースをマッチング処理に組み込みます。プロバイダーを定義しただけで参照しなければ、ルールは適用されません。ルールの接続先には、存在するプロキシグループか組み込みポリシーを指定する必要があります。通常、ルールセットに業務用の出口まで含めるべきではありません。出口を含めると、同じリストを異なる設定で再利用しにくくなります。

behaviorはルールの内容を示します。domainはドメインの集合、ipcidrはアドレス範囲、classicalはクラシック形式のルールに使います。formatは保存形式を示します。クラシックルールのファイルをドメイン集合として読み込むと、ダウンロードに成功しても解析に失敗する場合があります。ソースを選ぶ際は、内容の形式とbehaviorの種類を両方確認してください。

以下はローカルのクラシックルールセットを使う例です。まずファイルの場所と参照関係を確認するのに適しています。例にある相対パスはカーネルの作業ディレクトリを基準に解決され、Webページのある場所やインストール先を指すとは限りません。クライアントから管理でき、カーネルに読み取り権限がある設定ディレクトリにファイルを作成し、ログで読み込み先を確認してください。作業ディレクトリの扱いはクライアントによって異なる場合があります。

# メイン設定の一部
rule-providers:
  work-sites:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/work-sites.yaml

rules:
  - RULE-SET,work-sites,DIRECT
  - MATCH,DIRECT

# ./rules/work-sites.yaml
payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,example.org

リモート更新ではダウンロード経路も個別に確認する

ローカルファイルからリモートルールソースに切り替える場合は、ソースのドキュメントに従ってtype: http、実際のURL、キャッシュパス、更新間隔を設定します。紹介ページをルールファイルのURLとして指定しないでください。HTMLが返る場合、HTTPリクエストが成功していてもカーネルにとっては不正な内容です。まずブラウザーで取得内容を確認し、その後カーネルログでダウンロードと解析の結果を調べます。

ルールの更新失敗と、ルールに一致しない問題は別です。前者ではリモートURL、接続、解析、保存先の書き込み権限を確認します。後者では、対象がファイルに含まれているか、参照先が存在するか、先行ルールに振り分けられていないかを確認してください。通信に失敗しても古いキャッシュが使われる場合があります。現在通信を振り分けられているからといって、直近の更新成功を示すわけではありません。

更新間隔の単位は通常秒です。ソースの更新頻度に合わせて設定してください。変更の少ない業務リストを頻繁にダウンロードする必要はなく、過剰なリクエストはサーバー側のレート制限につながることがあります。複数のプロバイダーには、できるだけ別々のキャッシュパスを指定して上書きを防ぎましょう。ソースURLを変更する前に、現在使えるファイルを保管します。新しい内容が解析できることを確認してから旧定義を削除すれば、更新ミスによる設定の中断を減らせます。

最初に一致したルールが適用される順序を意識する

ルールは上から順に判定されます。通常、具体的な例外を広い範囲のルールより前に置き、最後にフォールバックのMATCHを配置します。同じドメインが複数のルールセットに含まれていても、どちらが具体的か自動で比較されることはありません。先に一致した参照先が適用されます。複数のリストを管理する場合は、重複だけでなく、メインルール一覧での優先順位も記録してください。

IPアドレスのルールは、一致対象のアドレスを得るためにドメインの名前解決が必要な場合があります。no-resolveは特定のIPルールでの能動的な名前解決を防ぐもので、DNS全体を無効にする設定ではありません。すべてのIPルールに機械的に付けると、本来は名前解決結果に依存する通信がフォールバックに流れることがあります。アプリがドメインと宛先アドレスのどちらを送信しているか、先行ルールが一致しているかを踏まえて判断してください。

ルールを検証する際は、ルールセットに確実に含まれるテスト用ドメインを選び、既存の接続を閉じてから再アクセスします。接続画面で一致したルールの種類と接続先を確認してください。ログに読み込みエラーがないのにフォールバックに流れる場合は、アプリ独自のDNSを使っていないか、IPアドレスへ直接接続していないか、別のルールが先に一致していないかを調べます。「サイト全体が問題なく使える」という印象を、個別の接続記録の代わりにしないでください。

DNS設定の最適化

DNSはドメインからIPアドレスを取得する仕組みですが、プロキシ接続では名前解決が行われる場所が異なることがあります。システムDNS、ブラウザーの暗号化DNS、Mihomo内蔵DNS、プロキシサーバー側の名前解決は、それぞれ分けて考えてください。ClashのDNS漏れや名前解決の異常を調べる際は、どのプログラムがどこへ問い合わせているかを確認してから、カーネルのDNS設定を変更する必要があるか判断します。

通常の名前解決とブートストラップ用の名前解決を理解する

nameserverは通常の名前解決に使う上流サーバーを定義します。上流サーバーをドメイン名で指定する場合、そのサーバー名を解決するための経路も必要です。default-nameserverは主にこの名前解決のために使われ、すべての業務ドメインが通る共通の入口ではありません。ブートストラップ用の上流とプロキシ出口が相互に依存すると、接続確立前にプロキシ経由の名前解決が必要になる循環が起き、起動時に接続できなくなることがあります。

proxy-server-nameserverを使うと、プロキシノードのドメイン名を別の上流で解決でき、ノード自身の接続にそのノードの名前解決を依存させずに済みます。nameserver-policyは条件に応じて業務ドメインの上流を指定でき、社内ネットワークや企業サービスなど、特定の名前解決結果が必要な場合に適しています。設定項目ごとに解決する問題は異なります。「予備」を増やす目的で、すべてのサーバーを各リストに重複して記述しないでください。

以下はFake-IPを有効にし、通常の問い合わせを暗号化された上流に送る例です。示しているのは項目の構成であり、あらゆるネットワークで接続できることを保証するものではありません。使用前に上流が利用環境に適しているか確認してください。クライアントがすでにDNS設定を生成している場合は、既存のマッピングに統合し、トップレベルのdnsキーが重複して上書きの原因にならないようにします。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://cloudflare-dns.com/dns-query

名前解決と接続の経路を説明できる状態にする

暗号化DNSは問い合わせの通信を保護するもので、問い合わせが自動的にプロキシ経由になるわけではなく、取得した結果が現在の接続出口に適しているとも限りません。直接接続する通信ではローカルから到達できるアドレスが必要な場合があり、プロキシ通信では出口側で名前解決される場合があります。一部のサイトでIPアドレスが取得できるのに接続できない場合は、上流サーバーの名前だけで設定を判断せず、名前解決の結果、ルールの振り分け先、実際の出口を合わせて確認してください。

DNS接続にもルーティングルールを適用する場合は、respect-rulesを検討できます。ただし有効にする前に、ノードのドメイン名を解決する独立した経路を用意し、DNS上流自体がどのルールで処理されるか確認してください。そうしないと、DNS問い合わせにプロキシが必要なのに、そのプロキシノードの名前解決も同じDNS問い合わせに依存することになり、起動時に利用可能な出口がなくなります。

企業ドメインやLAN内のドメインは特に慎重に扱ってください。パブリックDNSは内部アドレスを知らない場合があり、システムDNSを安易に置き換えると業務アプリが動かなくなることがあります。内部ドメインのサフィックス、指定のDNSサーバー、そのサーバーへ接続する経路を確認してから、ポリシーで適用範囲を絞ってください。すべてのドメインを社内専用サーバーに送ったり、内部の問い合わせを意図せず外部の上流へ送ったりしないようにします。

キャッシュ、問い合わせ元、アドレスファミリーごとに切り分ける

DNSを変更した後は、アプリ、システム、カーネルそれぞれのキャッシュを考慮してください。ブラウザーが既存の接続を再利用していると、システムキャッシュを消しても新しい問い合わせが発生しないことがあります。まず対象の接続を閉じ、必要に応じてテストするアプリを再起動してからログを確認します。コマンドラインツールの問い合わせ結果で分かるのは、そのツールが使った名前解決経路だけです。ブラウザー、ゲーム、その他のアプリも同じ経路を使うとは限りません。

ipv6: falseはカーネルDNSの関連応答を制御するもので、OS全体のIPv6を無効にする設定でも、すべてのアプリのIPv6接続を止める設定でもありません。IPv6が使えるネットワークでは、対象の通信を取り込む必要があるか明確にしてください。一部のアドレスファミリーで接続に失敗する場合は、プロトコルを無効にして恒久対処とするのではなく、同じドメインのアドレスとルーティングを比較しましょう。

DNS漏れを調べる前に、期待する動作を明確にしてください。どのアプリの名前解決をカーネルに任せるか、どの内部問い合わせをローカル経路に残すか、ブラウザー独自の暗号化DNSを許可するかを決めます。検査ページにDNSサービス名が表示されても、それだけでは手掛かりにすぎません。システムのDNS設定、アプリの設定、接続記録、必要に応じてネットワークキャプチャを照合し、意図した直接問い合わせと予期しない迂回を区別するのが確実です。

TUNとFake-IP

TUNは仮想ネットワークインターフェースを通じて通信を受け取り、Fake-IPは合成アドレスとドメインの対応関係を保持します。役割は異なります。TUNを有効にしてもすべてのDNSがカーネルに届くとは限らず、Fake-IPを有効にしてもすべてのアプリの通信が取り込まれるわけではありません。設定時は仮想インターフェース、システムルート、DNS問い合わせ経路、ルール判定を合わせて確認してください。どれか一つでも欠けると、一部だけ正常に見えることがあります。

元に戻せる通信取り込みの手順から始める

システムプロキシは、プロキシ設定に従うアプリに適しています。その設定を読み取らないアプリではTUNが必要になる場合があります。両方を必ず併用する必要はありません。初回テストでは現在使える設定を残し、システムのプロキシとDNSの元の状態を記録してから、サービスモードとTUNを有効にします。基本的なネットワーク接続まで失われた場合は、追加した通信取り込みをいったん停止し、接続を復旧してからログを調べてください。

Clash Verge RevのTUN機能は、サービス権限とプラットフォームの対応状況に依存します。Windowsではサービスが正常に動作していること、仮想インターフェースが作成できること、セキュリティソフトにブロックされていないことを確認します。macOSでは必要な権限を許可し、Linuxでは実行権限、ルーティング、ファイアウォールを確認してください。同じYAMLでもOSによってルーティングの実装は異なります。スイッチがオンになっているだけで通信を取り込めたと判断しないでください。

以下は一般的な通信取り込み設定の例です。DNS部分は前章の設定に統合してください。auto-routeはカーネルにルート設定を依頼し、auto-detect-interfaceは出口インターフェースの自動検出に使います。dns-hijackは対象となる従来型のDNS問い合わせを内蔵DNSへ転送します。適切な権限があり、ネットワーク構成を把握できている環境で、それぞれの動作を確認してください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

合成アドレスと除外リストを理解する

Fake-IPが返す合成アドレスは、元のドメインをカーネルに対応付けるためのもので、Webサイトの実サーバーのアドレスではありません。アプリがそのアドレスに接続すると、カーネルはドメイン名を復元し、ドメインルールを適用できます。診断ツールに合成アドレスが表示されても、それだけで名前解決の異常とは言えません。後続の接続が同じカーネルに届くか、対応付けが残っているかを確認してください。

アプリが合成アドレスを取得した後にTUNを経由せず直接接続する場合や、スリープ復帰後も古い対応情報をキャッシュしている場合、接続に失敗することがあります。まずルーティングとキャッシュの有効期間を確認し、すぐにすべてのドメインを除外リストに追加するのは避けてください。実アドレスが必要なアプリ、独自の疎通確認を行うアプリ、LAN内の機器を検出するアプリに限り、fake-ip-filterの対象を最小限に絞ります。

除外リストの意味はフィルターモードによって異なります。項目を追加する前に、現在のモードとその動作を確認してください。通常の除外モードでは、一致したドメインに実際の名前解決結果が返されます。別のフィルターモードに切り替えると、リストの意味が変わる場合があります。意味が逆の設定を複数のガイドからコピーして混在させないでください。変更後は関連キャッシュを消去し、アプリの実際の操作で検証します。

複数のネットワークアダプター、別のトンネル、スリープ復帰への対処

複数のネットワークアダプターがあると、自動検出で想定と異なるデフォルト出口が選ばれる場合があります。社内ネットワーク、スマートフォンのテザリング、別のVPNを併用する際は、どの接続が物理ネットワークを担い、どれが社内リソース用かを整理してください。ルートは設定数を増やせば完全になるものではありません。複数のツールがデフォルトルートやDNSを書き換えると、通信がループしたり、誤ったインターフェースへ送られたりすることがあります。

strict-routeは特定のプラットフォームでルーティングを厳密にできますが、初回設定時の万能な解決策ではありません。LANへのアクセスや他のソフトとの互換性に影響する場合があります。通常の自動ルートで迂回が起きることを確認し、対象OSの実装を理解したうえで、項目ごとにテストしてください。テストにはWeb閲覧、LANサービス、企業アプリ、スリープからの復帰を含めます。

DNSハイジャックの主な対象は、条件に一致した従来型のDNS問い合わせです。アプリ内の暗号化DNSが自動的に通常の問い合わせへ変わるわけではありません。ブラウザーやアプリ独自の名前解決用接続には、別途設定やルールが必要な場合があります。特定のプログラムが期待する接続記録に現れない場合は、ハイジャックの項目を増やし続けるのではなく、ネットワーク権限、プロキシ設定、独自の名前解決を確認してください。

「TUNを有効にしたらインターネットに接続できない」場合は、カーネルが起動しているか、サービスが利用可能か、インターフェースが作成されたか、デフォルトルートが妥当か、DNSが応答するか、最後にプロキシ出口が機能するかの順に確認します。TUNを無効にした状態と比較すると、原因を絞り込みやすくなります。ノード、DNS、ネットワークスタック、ルールソースを同時に変更しないでください。復旧しても、どの変更が効いたか分からなくなります。

ドメインスニッフィング

ドメインスニッフィングは、接続開始時のプロトコル情報からホスト名を取得し、宛先IPアドレスしか分からない接続にドメイン情報を補う機能です。ドメインルールの判定改善に使えますが、通信を復号する機能ではなく、すべての接続からドメイン名を復元できるわけでもありません。有効にする前に、不足しているのがドメイン情報、ルール、通信の取り込み経路のどれなのかを確認し、関係のない接続障害までスニッフィングの設定に結び付けないようにしてください。

取得できる情報の範囲を把握する

通常のHTTPリクエストにはホスト名が含まれる場合があり、TLSハンドシェイクからサーバー名を取得できる場合もあります。QUICにも識別方法があります。取得できる情報はプロトコル、実装、暗号化方式によって異なります。暗号化されたクライアントHelloなどが使われると、以前は識別に使えた名前がそのまま見えなくなることがあります。すべてのHTTPS接続で正しいドメインを復元できると期待しないでください。

スニッフィングで得られた名前が、アプリの業務上の通信先をすべて表すとは限りません。アプリが複数のサービスに接続することもあり、CDNでは複数のサービスが同じアドレスを使うこともあります。接続が再利用されると、後続のリクエストでハンドシェイクが繰り返されない場合もあります。個々の接続を確認し、一度スニッフィングに成功したからといって、その後のすべての通信が同じ業務用グループに振り分けられると判断しないでください。

以下の例は、HTTPとTLSの明確なポート範囲に限って識別を試み、元の宛先を保持して強制的な書き換えは行いません。まず識別によってルール判定が改善するか確認し、必要に応じて対象範囲を広げるための設定です。クライアントによって画面の項目や生成される設定は異なる場合があります。保存後は、画面のチェック状態だけで完全なYAMLが生成されたと判断せず、実行時設定を確認してください。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
        - 8443
      override-destination: false

ドメインの識別と接続先の書き換えを分けて検証する

override-destinationは、識別したドメインで接続先を置き換えるかどうかを制御します。表示名だけでなく、その後の名前解決や実際の接続方法にも影響します。元のアドレス、アクセス地域、専用の接続先を必要とするサービスでは、宛先を置き換えることで正常な動作が損なわれる場合があります。まず保守的な設定で検証し、必要性を確認できた範囲だけ調整してください。

アプリがすでにプロキシプロトコルでドメイン名を送っている場合や、Fake-IPの対応情報からドメインを特定できる場合は、スニッフィングを有効にしても効果が限られることがあります。プロトコルごとにポート範囲を広げると、処理負荷とトラブル時の確認箇所が増えます。ドメイン情報がすでに揃っている環境では、すべてのプロトコルを有効にするより、対象を絞った方が管理しやすくなります。

特定のサイトでスニッフィングを有効にした後に失敗する場合は、同じ出口とルールを使い、新しい接続で再現テストを行います。有効時と無効時で接続先、一致ルール、エラーの種類を比較してください。原因がスニッフィングにあると確認できてから、skip-domainで例外の範囲を絞ります。個別の互換性問題を隠すために、公共サフィックス全体を除外しないでください。

DNS、ルール、ログを組み合わせて原因を特定する

接続記録にアドレスしか表示されない場合は、まず対象が想定したプロトコルとポートかを確認し、次にアプリが既存の接続を再利用していないか調べます。スニッフィングは通常、接続開始時の情報を利用します。接続後に有効にしても、すでに確立した接続から名前を復元できるとは限りません。設定を何度も切り替えるより、対象の接続を閉じてリクエストをやり直す方が、条件を明確にして観察できます。

ドメインが表示されても出口が間違っている場合は、スニッフィングの範囲を広げるのではなく、ルールの順序を見直してください。ドメインの復元で解決するのは情報不足であり、存在しないルールが自動的に作られるわけではありません。ドメインルールに一致しているのに通信できない場合は、選択したノード、DNS、接続先への到達性を確認します。「識別できたか」と「接続できたか」は別の結果として記録してください。

QUICはUDPを使うため、トラブル対処では出口と通信の取り込み経路が該当する通信に対応しているかも確認します。アプリが失敗後に別のプロトコルへ切り替えると、接続できるときとできないときがあるように見える場合があります。スニッフィングの動作確認を目的に、特定のプロトコルを全体で禁止しないでください。接続記録を集めてから、プロトコル単位のルール、アプリ設定の変更、特定サービスだけの例外のどれが必要か判断します。

ログの詳細度はトラブル対処に必要な間だけ上げ、再現確認後は通常の設定に戻してください。ログや接続情報には、アクセス先のドメイン、プロセスのパス、業務用アドレスが含まれる場合があります。画面を共有する前に不要な情報を削除しましょう。設定差分の記録には項目とエラーの種類を残せば十分です。完全なサブスクリプション、ノードの認証情報、問題に関係のないアクセス記録を添付する必要はありません。

ローカルオーバーライドと複数サブスクリプションの統合

サブスクリプションはリモートの設定を提供し、ローカルオーバーライドは端末や個人の利用要件を維持するために使います。リモートのサブスクリプションファイルを直接編集すると、次回の更新で元に戻る場合があります。実行時設定を直接編集しても、クライアントの再生成時に変更が失われることがあります。長期的に管理するには、元のサブスクリプション、オーバーライドの入力、実行時の結果を区別し、各変更をどの層で保存するか明確にしてください。

オーバーライドの入口と適用範囲を確認する

Clash Verge Revでは、サブスクリプションに紐づく拡張機能、またはグローバル拡張の入口からローカル変更を管理します。画面上の名称は実際のクライアントに合わせてください。グローバルオーバーライドは端末共通の設定に、サブスクリプション単位のオーバーライドは特定の提供元だけに適用する例外に適しています。両方の層で同じ項目を変更する場合は、実際の適用順を確認してください。編集画面で最後に保存した場所だけを見ても、最終結果は判断できません。

Mergeオーバーライドではクライアント独自の仕様が使われるため、すべての拡張フィールドがMihomo標準の設定とは限りません。以下のprepend-rulesは、該当するMergeの仕組みでルールを先頭に追加する項目です。処理後のrulesに結果が反映されているか確認してください。通常のカーネル設定にそのまま記述しても、同じマージ処理が自動的に行われるわけではありません。

# 対応するフィールドを使えるMergeオーバーライドの入口に記述
prepend-rules:
  - DOMAIN-SUFFIX,example.com,DIRECT

dns:
  ipv6: false

この例では業務用ルールを一つ追加し、既存のDNS設定にあるフィールドを変更しています。完全な名前解決の設定を定義するものではありません。保存後は実行時設定を確認し、他のDNS上流が意図せず消えていないこと、追加したルールが想定した位置にあることを確かめてください。クライアントのマージ結果が想定と違う場合は、設定を増やすのではなく、まず一つのフィールドに絞ってテストします。

リストとマッピングは別々にマージ方法を判断する

YAMLのマッピングはキー単位で扱えますが、リストでは順序、重複、全体置換を考慮する必要があります。ルールリストの前置や後置は、最初に一致するルールに直接影響します。プロキシグループのリストを丸ごと置き換えると、リモートルールが参照するグループ名が消える場合があります。拡張機能ごとにリストの処理は異なるため、「マージに成功した」ことは最終設定とカーネルの読み込み結果の両方で確認してください。

拡張スクリプトは、名前の変更、重複の削除、絞り込み、構造変換が必要な場合に便利ですが、複雑さも増します。入力オブジェクトと戻り値の仕様を明確にし、変更していない項目も保持してください。固定のルールを一つ追加したい場合や、真偽値を一つ設定したいだけなら、内容を直接確認できるMergeの設定を優先し、不要なスクリプトを導入しないようにします。スクリプトが実行できても、出力がカーネルの要件を満たしているとは限りません。

サブスクリプションの更新後は、カスタムグループが引き続きメンバーを参照できるか確認してください。プロバイダーによってノード名が変わったり、ノードが削除されたり、グループ構成が変更されたりすると、個別のノード名に依存するローカルオーバーライドが機能しなくなります。業務ルールから安定したローカルグループを参照し、そのグループ内で提供元の変更を管理する方が堅牢です。ただし、空のグループや名前の衝突には引き続き注意が必要です。あらゆる提供元に永久に対応できる設定はありません。

複数サブスクリプションは単純に複数ファイルを連結するものではない

クライアントに複数のサブスクリプションが登録されていても、通常はすべてが一つの実行設定に同時に読み込まれるわけではありません。一般的には、そのうち一つを現在の設定として選択します。複数の提供元を同時に使う場合は、ノードプロバイダーや明示的な統合機能を検討してください。まずクライアントがその入力方法に対応しているか確認します。完全なYAMLを二つ貼り合わせるだけで自動調整されると考えてはいけません。

複数のソースを統合する場合は、少なくともノード名の重複、プロキシグループ名の重複、ルールの優先順位、グローバル設定の競合に対処する必要があります。複数のソースがDNS、リスニングポート、フォールバックルールをそれぞれ定義している場合、最終的にどれを使うか明確にしなければなりません。実運用では一つのメイン構成を保ち、他のソースはノード集合だけを提供する形にして、異なるプロバイダー名で参照する方が、完全な業務ルールを複数混ぜるより確認しやすくなります。

古いクライアントから移行する場合は、まずサブスクリプションを読み込み、基本的な接続を確認します。次にポート、ルール、DNSを移し、最後にスクリプトの処理を移行してください。旧Parsersの項目や実行環境はMergeと同じではありません。Clash for Windowsからの移行ガイドを参考に一つずつ確認し、使えなくなった古い設定を新しいクライアントに丸ごと上書きしないでください。

変更のたびにローカルで差分を保存し、目的、適用範囲、元に戻す方法を最低限記録してください。問題が起きたら追加したオーバーライドをいったん無効にし、元のサブスクリプションを読み込んで復旧を確認してから、一つずつ再度有効にします。バックアップはアクセスを管理できる場所に保存してください。サブスクリプションURLや認証情報を公開リポジトリに含めてはいけません。共有用の例には構造に必要な項目だけを残します。

外部コントローラー

外部コントローラーはMihomoのコントロールAPIを介して状態を取得し、プロキシを切り替えたり、一部の管理操作を行ったりします。混合プロキシポートとは異なり、アプリがインターネットに接続するための入口でもありません。設定では、通信の転送と管理アクセスを別々に考えます。アプリはプロキシポートに接続し、パネルはコントロールAPIに接続します。二つのアドレスを取り違えると、接続エラーや不正な応答が発生します。

ローカルインターフェースと明確な認証を優先する

external-controllerは待ち受けアドレスを定義します。127.0.0.1にバインドすると、ローカルのIPv4ループバック接続のみを受け付けます。secretはAPIの認証に使うため、十分に強く、他で使っていない値を設定してください。以下のパスワードは説明用であり、実際の運用には使えません。クライアントがこれらの項目をすでに管理している場合は、上書きする前に組み込み画面が現在のAPI設定に依存していないか確認してください。

external-controller: 127.0.0.1:9090
secret: "your-password"

パネルに接続できないからといって、待ち受けアドレスをすべてのインターフェースに変更し、認証を削除しないでください。プロキシの切り替えや稼働状態が、より広いネットワークに公開されてしまいます。複数端末からの管理が必要な場合は、アクセス経路を安全に確保し、ファイアウォールで接続元を制限してください。一般的なデスクトップ利用ではローカル管理を優先し、通常のプロキシ利用のためにリモート制御を公開する必要はありません。

コントロールAPIの接続先は通常、プロトコル、ホスト、ポートで構成されます。パネルの認証情報は、カーネルに現在設定されている値と一致させてください。他のプログラムによるポートの占有、カーネルの未起動、クライアントの再起動時に更新された認証情報などが、パネルとの切断原因になることがあります。まずカーネルの起動ログと待ち受け状態を調べ、次にパネルに古い設定が残っていないか確認します。管理用の接続エラーを、プロキシ回線の障害と混同しないでください。

パネルのファイル、API、ブラウザーの制限を区別する

external-uiはローカルのパネル用静的ファイルを置くディレクトリを指定する項目で、任意のWebサイトのURLを指定するものではありません。ディレクトリには実際の入口ファイルとリソースが必要で、カーネルに読み取り権限がなければなりません。ディレクトリ名を指定しただけでパネルが自動生成されるわけではありません。クライアント内蔵の画面で管理できる場合は、静的パネルを追加せず、ファイル更新やAPI公開の管理負担を減らすこともできます。

独立したブラウザーパネルでは、クロスオリジン、混在コンテンツ、ブラウザーのローカルネットワークアクセス制限が問題になることがあります。HTTPSのページからローカルのHTTP APIへアクセスできない場合があり、これはパスワードの正誤とは別の問題です。ブラウザーのエラーが通信拒否、クロスオリジン制限、認証失敗のどれに該当するかを確認してください。すべての接続元に対する制限を広げて解決しようとしないでください。

パネルの提供元も信頼境界の一部です。管理用認証情報を読み取れるページは、APIへ操作を要求できる場合があります。不明なページにコントロール用パスワードを入力しないでください。クロスオリジンアクセスが必要な場合は、使用するカーネルが対応する設定に従って接続元を正確に限定し、ブラウザーが使用するプロトコルとポートも確認します。接続元の指定が間違っている場合は、該当する値だけを修正し、すべてのサイトを許可しないでください。

一時的な制御と永続的な設定を分ける

パネルで変更するのは現在の実行状態です。設定によってはクライアントに保存されますが、設定を再読み込みすると元に戻ることもあります。DNS、ルール、通信の取り込み設定を長期的に維持する場合は、クライアントの設定画面かオーバーライドから管理してください。パネルでの一時的な変更が元ファイルに反映されたと考えないでください。再起動、サブスクリプションの切り替え、自動更新の後には、結果を再確認しましょう。

画面の共有や接続記録のエクスポートでは、ドメイン、プロセスのパス、端末のアドレス、APIの認証情報に注意してください。トラブル報告に必要なのは、通常、エラーの種類、関連する設定項目、再現手順です。構造だけを残して具体的な業務情報は削除できます。ルールに一致しなかったことを示すために完全なサブスクリプションを送ったり、一般的なサポート手段としてコントロールAPIを他者に公開したりしないでください。

クライアント選びとカーネル設定は分けて考えましょう。複数のプラットフォームで使えるクライアントを探す場合は、まずClash Plusを確認し、デスクトップでのオーバーライド要件に応じてClash Verge Revなどと比較できます。画面や拡張機能の仕組みはクライアントごとに異なるため、操作方法が共通とは限りません。インストール方法と対応プラットフォームはダウンロードセンターで確認し、既存の設定は現在のカーネル対応状況に合わせて移行してください。

トラブル対処の流れでは、次の4点を確認できる必要があります。通信がカーネルに届いているか、ドメイン名がどのように解決されるか、ルールが一致した理由は何か、最終的な出口はどこか。コントロールパネルは状態を確認するためのもので、この順序に沿った判断に代わるものではありません。安定した設定に戻したら、ログの詳細度を通常に戻し、一時的に公開した管理用の接続口を閉じ、検証済みのオーバーライド差分を保存して次回更新時に確認できるようにしてください。