Clashのプロキシグループ、ルールセット、ネットワークスタック設定

プロキシグループの種類と管理しやすい振り分け構成

プロキシグループは、ノードを単に分類するフォルダーではなく、ルールと実際の出口をつなぐ安定したインターフェースです。ルールは「プロキシ」「ストリーミング」「ダウンロード」といった長期的に変わりにくい名前だけを参照し、ノードの追加・削除、購読先の変更、地域の調整はグループ内で行います。これにより、購読先を変更してもルールを書き直す必要がなく、特定のサービスの出口を切り替える際にドメインを一つずつ探す必要もありません。プロキシグループを設計するときは、まず通信の階層を整理し、その後でグループの種類を決めましょう。購読中のすべてのノードを一つの選択グループに詰め込む方法は避けてください。

よく使う4種類のグループの選び方

selectは手動選択グループで、総合入口、特定地域、安定した出口が必要なサービスに適しています。現在の選択を自動変更しないため、動作を予測しやすいのが特徴です。url-testはテスト先と間隔に基づいて可用性を確認し、候補の中から応答の速いノードを選びます。日常的なWeb閲覧に向いています。fallbackはリスト順に最初の利用可能なノードを使うため、優先順位と継続性を重視する構成に適しています。load-balanceは複数のノードに接続を分散します。並列リクエストの多い処理には便利ですが、同じWebサイトへの接続ごとに出口が変わる可能性があり、ログイン状態やアクセス制限の厳しいサイトでは不向きです。

遅延テストの値は、その時点のネットワーク条件におけるテスト先の応答時間を示すだけで、ダウンロード速度ではなく、実際の利用可否の代わりにもなりません。テスト先には、安定していてサイズが小さく、HTTPSですぐ応答するリソースを選びます。intervalが短すぎると継続的に探査リクエストを発生させ、長すぎるとノード停止後の反映が遅れます。家庭のネットワークでは数分単位から始めるのが一般的です。モバイル回線ではバックグラウンド制限や回線切り替えも考慮し、テストグループだけに復旧を任せないでください。

まず地域グループ、次に用途グループを作る

安定しやすい構成は通常3層です。最下層はノードまたはプロキシプロバイダー、中間層は「香港自動」「日本予備」「米国手動選択」といった地域グループ、最上層は「プロキシ」「ストリーミング」「開発サービス」といった用途グループです。用途グループは地域グループを参照し、ルールは用途グループだけを参照します。各用途グループに元のノードを数十個ずつ直接入れると、購読先の名称変更、ノード停止、重複ノードによってすべてのグループが管理しにくくなります。

proxy-groups:
  - name: 香港自動
    type: url-test
    use:
      - provider-main
    filter: "(?i)港|HK|Hong Kong"
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

  - name: 日本予備
    type: fallback
    use:
      - provider-main
    filter: "(?i)日|JP|Japan"
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: プロキシ
    type: select
    proxies:
      - 香港自動
      - 日本予備
      - DIRECT

  - name: 開発サービス
    type: select
    proxies:
      - プロキシ
      - 香港自動
      - 日本予備
      - DIRECT

useはproxy-providersの名前を参照し、proxiesは具体的なノード、組み込みポリシー、その他のプロキシグループを参照します。両者を自由に置き換えることはできません。フィルター式は、漢字の地域名、英語略称、正式な英語名など、プロバイダーごとの命名差をできるだけ吸収できるようにします。ただし、式を広げすぎるのも危険です。「US」は別の単語に誤マッチする可能性があるため、名前の区切り文字と実際の購読形式を組み合わせてテストしてください。

プロキシグループ間の循環参照も避ける必要があります。たとえば「プロキシ」が「自動選択」を含み、「自動選択」も候補として「プロキシ」を参照すると、コアは最終的な出口を決定できません。変更後にグループが空になる、ポリシーを選択できない、設定の読み込みに失敗するといった問題が起きたら、まず名前が完全に一致しているか確認し、その後で参照方向を確認します。全角・半角の記号、前後の空白、大文字小文字の違いでも、見た目が同じで実際には異なる名前になります。

最後に、明確な総合入口グループを一つ残すと、一時的な切り分けが簡単になります。特定のWebサイトで異常が起きたら、まず総合入口を別の地域またはDIRECTに手動で切り替え、問題がノード、ルール、対象サイトのどこにあるかを確認します。入口を切り替えてすぐ復旧するなら、現在のノードと地域グループを優先的に確認します。常に直接接続になるなら、ルールの順序とモードを確認します。すべてのポリシーでアクセスできない場合は、DNS、TUN、システムネットワークスタックを調べます。プロキシグループが明確なら、以降の各章も検証しやすくなります。

ルールセットの購読管理とマッチング順序

数千件のドメインやIPルールをメイン設定に直接書き込むと、ファイルが読みにくくなり、更新のたびに設定全体を置き換えることになります。rule-providersはルールを個別にダウンロード、キャッシュ、更新できる集合へ分離する機能です。メイン設定にはプロバイダー定義と少数のRULE-SET参照だけを残します。ルールセットを更新してもプロキシグループを変更する必要がなく、設定構造もバージョン管理しやすくなります。広告ドメイン、LANアドレス、特定サービスのドメイン、地域IP帯などは購読化に向いています。一方、1〜2個のドメインだけを対象にする個別ルールは、メイン設定の先頭に置いた方が分かりやすいでしょう。

behaviorでルールセットの解釈方法を決める

domainはドメイン集合に使用します。エントリには完全なドメイン、ドメインサフィックス、キーワード形式などを記述できますが、具体的な書式はペイロード形式によって異なります。ipcidrはIPv4またはIPv6のネットワーク範囲に使用し、マッチングには対象IPが必要です。classicalは、DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAMEなど、タイプ接頭辞とパラメーターを含む従来形式のルールを扱えます。元ファイルが従来形式なのにbehaviorをdomainにすると、ダウンロードは成功してもエントリが期待どおり動作しないことがあります。ルールセットを作る前にファイルの内容を確認し、ファイル名だけで判断しないでください。

formatにはyaml、text、またはコアが対応するバイナリ形式をよく使います。YAMLペイロードには通常、トップレベルキーとしてpayloadが含まれます。テキスト形式は1行に1件の構成が一般的です。pathはローカルキャッシュの保存先で、各プロバイダーには異なるパスを指定し、後から取得したファイルが先のファイルを上書きしないようにします。intervalは更新間隔を制御します。ルール自体の変更頻度が低いなら、数分おきに取得する必要はありません。リモート取得に失敗しても既存キャッシュは通常利用できるため、一時的な更新失敗をすべてのルールが無効になったと誤解しないでください。

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

  service-rules:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/service-rules.yaml
    url: https://example.com/rules/service-rules.yaml
    interval: 86400

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/private-ip.yaml
    url: https://example.com/rules/private-ip.yaml
    interval: 86400

rules:
  - DOMAIN,router.local,DIRECT
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-rules,プロキシ
  - RULE-SET,private-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,プロキシ

例のアドレスは構造を示すためのものです。実際の設定では、自分でアクセス可能性と内容形式を確認したルールソースに置き換えてください。ルールファイルに認証が必要な場合、長期的な認証情報を公開同期されるメイン設定に保存しないでください。ローカル生成フロー、管理下のリバースプロキシ、クライアントが対応する安全な保存方式などを使い、エクスポートした診断情報にアクセスパラメーターが含まれないようにします。

ルールは上から評価され、最初にマッチした時点で停止する

Clashではルールの数より順序が重要です。完全一致のドメインと個人用上書きは前方に置き、用途別ルールセットを中央に、広い地域ルールを後方に置き、最後にMATCHで残りの通信を受けます。先にGEOIP,CN,DIRECTを記述すると、後続のサービスルールセットが該当IPをプロキシへ送ろうとしても、すでにマッチした接続は下のルールを確認しません。同様に、MATCHを途中に置くと、それ以降のルールはすべて機能しなくなります。

no-resolveは、ルールのマッチング段階でドメインを能動的に解決したくないIPルールに適しています。対象がもともとIPなら通常どおりマッチしますが、対象がドメインの場合、ネットワーク範囲を判定するための追加の名前解決は行いません。不要なDNS動作を減らせますが、特定のIPルールで出口を決める設定では、ルールシステムに入る前に対象アドレスが利用可能か確認してください。すべてのIPルールに機械的にこのパラメーターを付けるのは避けましょう。

ルールセットがマッチしないときは、まず3点を確認します。プロバイダーの状態が成功しているか、ファイル形式とbehaviorが一致しているか、対象リクエストにマッチ可能なドメインが含まれているかです。ブラウザーが暗号化DNSを使用している、アプリがIPへ直接接続している、TUNがそのプロセスを受け持っていないといった場合、実際のマッチ対象は想定と異なる可能性があります。接続一覧で実際の対象、マッチしたルール、ポリシーを確認し、運任せにルール順だけを繰り返し変更しないでください。

長期運用では、各ルールセットについてソース、用途、behaviorの種類、対応するプロキシグループを記録しておくと便利です。新しいルールはまず単独のルールとしてメイン設定の先頭に置き、数日観察して誤判定がないことを確認してから自作ルールセットへ統合します。ルールを削除するときも接続ログを確認し、「今はアクセスがない」ことを「今後も不要」と取り違えないでください。メイン設定各セクションの並びをさらに理解したい場合は、Clash設定ファイルのYAML各セクションとフィールドを順に解説をご覧ください。

DNS設定の最適化と漏えいの切り分け

DNS設定では、ドメインを誰が解決するか、問い合わせ自体がどのネットワーク出口から送信されるか、解決結果をルールシステムへどう渡すかという3つの異なる問題を扱います。パブリックDNSのアドレスを一つ変更するだけでは、通常この3つを同時に解決できません。システムDNS、Clash内蔵DNS、ブラウザーのセキュアDNS、アプリ独自の名前解決が共存することもあります。切り分けではまず実際のリクエスト経路を確認し、その後でサーバーを選びます。制御しやすい構成では、管理対象のアプリをClash DNSへ統一して送り、ルールとプロキシポリシーで後続の接続を決定します。

nameserver、proxy-server-nameserver、direct-nameserver

nameserverは通常のドメイン問い合わせで使う主要な上流サーバーです。HTTPSまたはTLS形式を使うと、ローカルネットワークによる平文問い合わせへの干渉を抑えられますが、接続が暗号化されても問い合わせが必ずプロキシ経由になるわけではありません。出口はコアの機能、ルール、ブートストラップ名前解決によって決まります。proxy-server-nameserverは主にプロキシサーバー自身のドメイン解決に使い、「プロキシへ接続するための名前解決が、まだ確立していないプロキシを必要とする」という循環を避けます。direct-nameserverは明示的に直接接続する問い合わせに使い、LAN機器名やローカルネットワークサービスに適していますが、クライアントとコアが対応している必要があります。

default-nameserverは暗号化DNSサーバー自体のアドレス解決に使われ、通常は直接アクセスできるIP形式のリゾルバーを指定します。すべての問い合わせの最終的な上流ではなく、多数のアドレスを詰め込む場所でもありません。暗号化DNSのURLがドメイン名で、デフォルトリゾルバーにアクセスできない場合、クライアント起動後にすべてのドメインが停止したように見える一方、IPへ直接アクセスすると正常なことがあります。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "time.*.gov"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

listenをすべてのインターフェースで待ち受けると、LAN上の他の機器からポートへアクセスできる可能性があります。本機だけで使うなら、ループバックアドレスへのバインドを優先します。LAN用DNSとして使う場合は、システムファイアウォール、アクセス制御、ルーター設定も同時に確認してください。ポートが使用中だと、コアの起動に失敗したりDNSモジュールが待ち受けできなかったりします。Windowsではシステムのネットワークツール、macOSとLinuxではlsofまたはssで使用プロセスを確認できます。

# Windows PowerShell
Get-NetUDPEndpoint -LocalPort 1053

# macOS
lsof -nP -iUDP:1053

# Linux
ss -lunp | grep 1053

Fake-IPとredir-hostの選び方

fake-ipは、まず予約アドレス範囲のマッピングアドレスを返し、接続がコアに到達した後で元のドメインを復元します。これによりルールシステムがドメイン情報を保持しやすくなり、ドメインルールのマッチングが安定します。「名前解決後にIPだけで判定する」状況も減らせます。一方、LAN内検出、時刻同期、ゲーム接続、プリンター、実際の名前解決結果に依存するプログラムでは互換性の問題が起きることがあり、fake-ip-filterへの追加が必要です。フィルター項目は実際に失敗したドメインをもとに少しずつ追加し、非常に長いリストをそのままコピーしないでください。多くのドメインがFake-IPを迂回すると、統一的な振り分け効果が弱まります。

redir-hostは実際の名前解決結果を返すため、互換性を理解しやすいことが多い一方、ドメインと接続の対応関係がDNSマッピングキャッシュに依存します。CDN、複数アドレスの切り替え、アプリ独自の名前解決では、ルール判定がFake-IPより不安定になる可能性があります。選択時は特定のテストサイトだけで判断せず、普段使うアプリ、LANサービス、スリープ復帰、ネットワーク切り替えまで検証してください。

DNS漏えいはリクエスト経路で確認する

一般に漏えいとは、管理された上流またはプロキシ経路で処理すべき問い合わせが、システム、ルーター、通信事業者のネットワーク、ブラウザーによって独自に送信される状態を指します。オンライン検査で確認できるのは、検査ページが発生させた一部の問い合わせだけで、すべてのアプリが同じ経路を使っている証明にはなりません。より確実な方法は、まずブラウザー内蔵のセキュアDNSを無効にするか、システム設定と一致させ、その後Clashのログ、システムDNS設定、ローカルポートの通信を確認することです。本サイトのClashのDNS漏えい検査方法と防止設定の手順では、オンライン検査とローカル観察を組み合わせた手順を紹介しています。

「IPは開けるのにドメインが開けない」場合は、DNSモジュールの起動状態、待ち受けポート、上流への到達性から確認します。「一部のドメインだけ解決が遅い」場合は、複数の上流の一つが長時間タイムアウトしていないか、IPv6問い合わせがネットワークで破棄されていないかを確認します。「プロキシに送るべきなのに直接接続される」場合は、アプリがシステムの名前解決を迂回していないか、接続一覧にドメインが保持されているか、対象ルールが広い直接接続ルールより前にあるかを確認してください。

TUNの有効化・無効化後にシステムへ誤ったDNSが残った場合は、まずクライアントを完全に終了し、ネットワークアダプターをDNS自動取得へ戻してから再起動します。システムプロキシ、仮想ネットワークアダプター、DNSを変更するツールを複数同時に動かさないでください。それぞれ単独では正常でも、後から起動したツールが先の設定を上書きし、断続的な障害を起こすことがあります。

TUNモード、Fake-IP、システムネットワークスタック

システムプロキシは、プロキシ設定を自発的に読み取るアプリにしか影響しません。コマンドラインプログラム、ゲーム、ストアコンポーネント、一部のデスクトップクライアント、ソケットを直接作成するプログラムは完全に無視することがあります。TUNモードは仮想ネットワークアダプターでより広範なIP通信を受け取り、Clashのルールへ渡します。プロキシを認識しないアプリも統一的に処理したい場合に適しています。ただし「強力なシステムプロキシスイッチ」ではなく、ルーティング、DNS、仮想インターフェース、権限が関わるネットワーク経路です。有効化する前に、通常のシステムプロキシが正常に動作することを確認してください。

主要フィールドとスタックの選択

enableはTUNを制御します。auto-routeは必要なルートをコアに設定させます。auto-detect-interfaceは現在のデフォルトの外向きインターフェースを検出し、有線・無線・テザリングの切り替え後に手動変更する手間を減らします。dns-hijackは指定ポートのDNSリクエストを内蔵DNSへ渡します。stackはネットワークスタックの実装を選択し、一般的な値にはsystem、gvisor、混合処理に対応するスタックなどがあります。対応範囲はコアとプラットフォームによって異なるため、現在のクライアントが実際に提供する選択肢を基準にしてください。

systemは通常、システムのネットワーク機能を利用するため、性能と互換性が自然になりやすい一方、OSの違いによる影響を受けます。gvisorはユーザー空間のネットワークスタックを使います。分離が明確で、環境によってはシステムスタックの制限を回避できますが、特殊なプロトコルや高並列接続では異なる挙動になることがあります。スタックの切り替えは切り分けの手段であり、障害の根拠がない状態で頻繁に変更しないでください。毎回一つの変数だけを変更し、同じネットワーク条件で検証します。

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

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

strict-routeは、想定したルートを通信が迂回する可能性を減らしますが、仮想マシン、コンテナ、企業VPN、複雑なLANでは既存ルーティングに影響することがあります。有効化後にLAN機器、リモートデスクトップ、開発コンテナへ突然接続できなくなった場合は、有効化前後のルーティングテーブルを比較し、プライベートネットワークが正しいインターフェースを通っているか確認してください。LANへアクセスする場合、プライベートアドレスを直接接続にするルールは使えますが、ルールで決められるのはコアへ入った後の出口だけです。誤ったシステムルートに奪われた接続を修復することはできません。

Fake-IPアドレスは実際の宛先アドレスではない

Fake-IPを有効にすると、パケットキャプチャやシステムの接続一覧に198.18.0.0/16のようなアドレスが表示されるのは正常です。アプリはまずこのマッピングアドレスへ接続し、コアがマッピングテーブルからドメインを復元して、ルールと実際の名前解決を実行します。このアドレス範囲を通常の直接接続ルートへ追加したり、リモートサーバーのアドレスと解釈したりしないでください。Fake-IPへの接続がTUNに取り込まれないと、システムは予約アドレスを実在の宛先として扱い、すぐ失敗するか長時間待機します。

つまり、Fake-IPとTUNの要点は一連のループを完成させることです。DNS問い合わせでClashがマッピングアドレスを返し、アプリがそのアドレスへ接続し、ルーティングが接続をClashへ戻します。どこか一つを別のツールが受け持つと、マッピングが壊れる可能性があります。代表的な競合には、システムを迂回するブラウザー独自DNS、デフォルトルートを奪う別の仮想アダプター、予約アドレス範囲をフィルタリングする企業向けセキュリティソフト、スリープ復帰後も高い優先度で残る古い仮想インターフェースがあります。

プラットフォームごとの権限と競合を理解する

Windowsで有効化後に完全に通信できなくなった場合は、まずTUNを無効にして基本プロキシが復旧することを確認し、仮想ネットワークアダプターが正常に作成されたか、デフォルトインターフェースが正しく認識されているかを確認します。macOSではクライアントにネットワーク拡張機能の権限が付与されていることを確認し、同時に動作する他のVPNを終了します。Linuxサーバーでは、カーネルがTUNデバイスを提供しているか、実行ユーザーにインターフェース作成とルート変更の権限があるかも確認してください。AndroidはシステムのVpnServiceに依存し、通常は一度に一つのアクティブなVPNしか保持できません。関連する権限とバックグラウンド制限については、Android版VpnServiceの権限と省電力対象外設定の要点を参照してください。

TUNの切り分けには段階的なテストが最も効果的です。まずTUNを無効にし、システムプロキシだけでノードを検証します。次にTUNを有効にしますが、ルールは簡単なままにします。その後、ドメイン、直接IP、LANアドレス、システムプロキシを読み取らないアプリをテストし、最後に複雑なDNS、スニッフィング、ルールセットを追加します。最初からすべての高度な機能を有効にすると、どこか一つの失敗が「ネットワークが使えない」としか表示されず、実際の障害箇所を判断しにくくなります。

ドメインスニッフィングの用途、設定、限界

ルールによる振り分けでは、ドメインを入力として扱うのが理想です。ドメインは、頻繁に変わるCDNアドレスよりもサービスの所属を表現しやすいためです。しかし、一部のアプリは自分で名前解決した後、IPへ直接接続します。透過的に取り込まれる通信では、接続開始時に宛先アドレスしか見えないこともあります。ドメインスニッフィングは、TLSハンドシェイクのSNI、HTTPリクエストヘッダー、その他の識別可能な情報から対象ドメインを復元し、ドメインルールが再びマッチできるようにします。これは接続メタデータを補う機能であり、DNSを置き換える万能機能ではありません。

TLSスニッフィングとHTTPスニッフィングで見るもの

TLSスニッフィングは通常、ハンドシェイク中に公開されるサーバー名を読み取るだけで、後続の内容を復号しません。HTTPスニッフィングは、平文リクエストのHostフィールドを読み取れます。対象プロトコルがドメインを含まない、アプリがIPへ直接接続する、接続が既存のチャネルを再利用する、サーバー名を隠す仕組みを使うといった場合、スニッフィングで結果を得られないことがあります。UDPプロトコルの識別範囲もコアの実装と通信内容に左右されるため、すべてのUDP接続でドメインを復元できるとは限りません。

スニッフィングで得たドメインは、接続の実際の目的と一致している必要があります。共有IPに複数のサイトが存在する場合、誤った上書きによってルールが誤判定する可能性があります。証明書やSNIと一致しない専用アドレスへ接続するアプリもあります。設定時はまずよく使うポートだけを有効にして接続記録を確認し、その後で範囲を広げるか判断してください。ログ上の「ドメイン表示率」を上げるためだけにすべてのポートを検査しないでください。

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true
  override-destination: false
  sniff:
    TLS:
      ports:
        - 443
        - 8443
    HTTP:
      ports:
        - 80
        - 8080-8880
  skip-domain:
    - "Mijia Cloud"
    - "+.push.apple.com"

parse-pure-ipは、IPだけの宛先からドメインの復元を試みる機能で、透過プロキシ環境でよく使われます。force-dns-mappingはDNSマッピングと組み合わせて対象を識別し、Fake-IPとの併用で特に一般的です。override-destinationは、スニッフィング結果で元の宛先を上書きするかを決めます。有効にするとルールと接続先がドメインの想定に近づきますが、誤検出の影響も直接的になります。まずは無効のままにし、ログ上の復元結果が安定していることを確認してから、必要に応じて判断してください。

除外リストを追加するタイミング

除外リストは、スニッフィングや宛先の上書きに適さない対象を明示するために使います。LAN機器、スマートホーム、プッシュ通知サービス、特殊な認証プログラム、一部のゲームは固定アドレスや標準外のハンドシェイクに依存することがあります。スニッフィングを無効にすると正常で、有効にすると安定して失敗し、接続ログに無関係なドメインが復元される場合は、該当ドメインやプロセス関連の対象を除外できます。ただし、その前に原因が本当にスニッフィングなのか、TUN、MTU、UDP、ノード自体の問題ではないのかを確認してください。

リスト項目は、現在のコアが対応するドメインマッチング構文に従う必要があります。完全なドメインは単一サービスに、ドメインサフィックスは複数のサブドメインに適しています。サフィックスの範囲が広いほど注意が必要です。たとえばトップレベルドメイン全体を除外すると、多数の接続でスニッフィングが使えなくなります。アプリ名のように見える項目が有効かどうかは、コアが特殊なマーカーをどう解釈するかに依存します。別のクライアントへ移行する際は再確認してください。

スニッフィング、ルール、DNSの連携順序

接続がコアへ入ると、まずFake-IPマッピングからドメインを取得する場合もあれば、スニッフィングでドメインを復元する場合もあります。その後でルールに基づいてポリシーを選択します。DNSマッピングが安定しているなら、スニッフィングは補助的な役割です。アプリがClash DNSを完全に迂回している場合、スニッフィングがドメインルールを有効にする鍵になることがあります。同じアプリが、あるときはドメインルール、別のときはIPルールや最終ルールに入る場合、接続ごとに名前解決や通信経路が異なる可能性があります。

検証時は3段階のルールを用意します。完全一致のドメインルール、対応するIPまたは地域ルール、最後にMATCHです。対象へアクセスした後、どの段階でマッチしたかを確認します。完全一致のドメインルールが常に発動せず、接続記録には正しいドメインが表示されるなら、ルールの順序と綴りを確認します。記録にIPしかないなら、DNSマッピングとスニッフィングを確認します。接続自体が表示されないなら、アプリがシステムプロキシまたはTUNに取り込まれているかを確認してください。Webページが開くかだけを見るより、この比較の方が診断に役立ちます。

GUIクライアントによっては、これらのフィールドを「ドメインスニッフィング」「宛先の上書き」「IPのみの名前解決」などのスイッチに分けていたり、一部の機能だけを公開していたりします。Clash Plus、Clash Verge Rev、FlClashなどでは画面上の位置が完全には一致しませんが、最終的にはエクスポートした実際の設定とコアのログを基準にしてください。クライアントを移行する際は、まず最小限のスニッフィング設定を維持し、現在のコアがフィールドを認識することを確認してから、高度な項目を一つずつ戻します。

ローカル上書きと多重サブスクリプション統合

リモート購読はノード配布の問題を解決し、ローカル上書きは個人のポリシーを長期的に保持します。DNS、ルール、プロキシグループ、実験的なパラメーターを購読ファイルへ直接書き戻すと、次回の更新ですべて上書きされる可能性があります。更新を完全に止めるとノード変更を逃します。より合理的な構成は、リモート購読を入力、ローカル上書きを繰り返し適用できる変換として扱い、クライアントまたは変換処理で最終的な実行設定を生成する方法です。これならノードを更新しながら、自分のルールとネットワークスタック設定も保持できます。

置換、追加、先頭挿入を区別する

クライアントによって上書きの名称は異なりますが、操作は通常3種類に分かれます。トップレベルのフィールドを置き換える、配列の末尾へ項目を追加する、配列の先頭へ項目を挿入する、の3つです。DNSやTUNのような完全なオブジェクトは明示的な置換または深いマージに向いています。ルール配列では個人用の完全一致ルールを先頭に置き、フォールバックルールを最後に残します。プロキシグループは名前で重複排除する必要があり、2つの配列を単純連結してはいけません。

最も危険なのは、購読元の内容を再度取り込まずにrulesやproxy-groups全体を直接上書きすることです。ノードは存在するのにプロキシグループから参照されない、またはルールが個人用の数件だけになる可能性があります。変更前に現在有効な設定をエクスポートし、上書きが購読更新の前に行われるのか後に行われるのかを確認し、クライアントのマージ順も確認してください。同じスクリプトでもクライアントによって実行タイミングが異なるため、結果も変わります。

# ローカル先頭ルールの例
rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - DOMAIN-SUFFIX,developer.example,開発サービス

# ローカルDNS上書きの例
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

YAMLのマージでは、アンカー、空値、型の変化にも注意が必要です。ソースでは配列なのに上書き側でオブジェクトとして記述されたフィールドは、期待どおりにマージできないことが一般的です。nullは削除を意味する場合もあれば、単に空のフィールドになる場合もあり、ツールの実装に左右されます。移植性を高めるため、上書きでは通常のマッピングと配列を使い、特定のGUIクライアント固有のスクリプトAPIに依存しないでください。スクリプトが必要な場合は、入力構造、処理順、期待する出力も記録します。

多重購読ではまず名前を分離する

2つの購読を統合するとき、最も多い問題はノードのプロトコルではなく名前の重複です。両方に「自動選択」「フェイルオーバー」「プロキシ」といったグループ名が含まれることがあり、ノード名も重複します。単純連結すると、後から出てきたオブジェクトが前のものを上書きしたり、プロキシグループが誤ったノードを参照したりします。安全な方法は、異なるソースに固定プレフィックスを付けることです。たとえば「メイン購読 / 香港 01」「予備購読 / 香港 01」のようにしてから、ローカルのプロキシグループで統一的に参照します。

クライアントがproxy-providersに対応している場合は、複数のソースをそれぞれプロバイダーとして扱い、useとfilterで地域グループを組み立てられます。すべてのノードを先にメインファイルへ展開する必要はありません。この方法なら更新範囲が明確になり、あるソースが失敗しても別のソースのキャッシュを直接壊しません。プロバイダー名、キャッシュパス、ヘルスチェック用アドレスはそれぞれ独立させます。

proxy-providers:
  provider-main:
    type: http
    url: https://example.com/subscriptions/main.yaml
    path: ./providers/main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

  provider-backup:
    type: http
    url: https://example.com/subscriptions/backup.yaml
    path: ./providers/backup.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: すべてのソース
    type: select
    use:
      - provider-main
      - provider-backup
    proxies:
      - DIRECT

例のアドレスはフィールドの関係を示すためだけのものです。実際の購読URLには通常アクセス認証情報が含まれるため、スクリーンショット、質問サイト、公開リポジトリ、診断ファイルへ貼り付けないでください。設定を共有する前に、proxy-providersのURL、ノードサーバーアドレス、ユーザー名、認証フィールドを削除し、構造上の問題を再現できる最小限の断片だけを残します。

復元可能な設定フローを作る

大きな変更を行う前に、未処理の購読入力、ローカル上書きファイル、最終生成された実行設定の3つを保存します。問題が起きたら、まず最終設定が想定どおりかを比較し、その後で購読の変化、マージロジック、コアの動作を判断します。最終ファイルだけを保存すると、どの段階で誤りが生じたか分からず、次回の購読更新後に再構築することも難しくなります。

調整は固定した順序で行うのがおすすめです。まず単一の購読を更新し、ノードが利用できることを確認します。次に名前フィルターとプロバイダーのヘルスチェックを適用し、その後でプロキシグループを追加します。続いて個人用ルールを先頭に置き、最後にDNS、TUN、スニッフィングを有効にします。各段階で再読み込みしてログを確認してください。最終設定が失敗しても、最初に異常が現れた段階を正確に特定できます。

統合後に「ノードは表示されるのに選択できない」場合は、通常、プロキシグループが存在しないオブジェクトを参照しています。「更新後に個人ルールが消える」場合は、通常、上書きの段階が誤っています。「同名ノードがランダムに変わる」場合は、通常、ソースごとの名前分離ができていません。問題をクライアント画面で何度も削除・再読み込みするより、入力、変換、出力の3層に分けて確認する方が効果的です。

外部コントローラーと安全なリモート管理

外部コントロールインターフェースを使うと、GUIパネルからプロキシグループ、接続、ルール、ログ、プロバイダーの状態を読み取れるほか、ポリシーの切り替え、プロバイダーの更新、接続の終了なども実行できます。コアの実行と管理画面を分離できるため、サーバー、ルーター、独立したコアの運用でよく使われます。このインターフェースには実際の制御権限があるため、通常のステータスページのように公共ネットワークへ直接公開しないでください。

待ち受けアドレス、シークレット、パネルディレクトリ

external-controllerはAPIの待ち受けアドレスを定義します。本機だけで使う場合はループバックアドレスへのバインドが最も安全です。LANからアクセスする場合はLANインターフェースまたはすべてのインターフェースへバインドできますが、ファイアウォールで送信元を制限してください。secretはコントロールインターフェースの認証情報です。独立した十分に長い値を使い、購読、システムアカウント、他のサービスと共有しないでください。external-uiはローカルの静的パネルディレクトリを指定します。コアはファイルとAPIを提供するだけで、ディレクトリの内容が信頼できることを自動的に保証しません。

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./dashboard
external-ui-name: metacubexd
external-ui-url: https://example.com/dashboard.zip

例にあるパスワードとパネルアドレスは構文を示すためだけのものです。実際に使うときはパスワードを変更し、信頼できるソースからパネルファイルを取得してください。GUIクライアントにコントロールパネルが内蔵されている場合、通常はリモートダウンロードアドレスを設定する必要はありません。複数のインスタンスが同じIPとポートを待ち受けることはできません。ポート競合が起きると、後から起動したコアはバインド失敗を報告しますが、パネルが古いインスタンスのデータを表示し続けることがあり、設定が反映されていないと誤解しやすくなります。

ブラウザーからローカルパネルへアクセスするときは、ページアドレスとAPIアドレスを区別してください。パネルファイルはWebサービスが提供し、APIはClashコアが待ち受ける構成もあります。プロトコル、ホスト、ポートのいずれかが異なるとクロスオリジンアクセスになります。許可されるかどうかはコアとブラウザーのポリシーによって決まります。パネルは開くのに接続できないと表示され続ける場合は、まず本機でAPIポートが待ち受けているかを確認し、次にパネルへ入力したコントローラーアドレスとシークレットを確認してください。いきなりコアを再インストールする必要はありません。

LANアクセスで開放する最小範囲

スマートフォンや別のPCから管理する必要がある場合は、コントローラーをLANアドレスにバインドし、システムファイアウォールで信頼できるプライベートネットワークだけに許可します。ルーターでコントロールポートを公開ポートへ転送したり、弱いシークレットを使ったりしないでください。公共ネットワーク上の機器は一般的な管理ポートをスキャンする可能性があり、コントロールインターフェースへアクセスされると、相手に接続先の確認、ポリシーの変更、通信の中断を許すことになります。

より安全なリモート方法は、既存の管理されたプライベートネットワーク、端末間の安全なトンネル、システムのリモート管理機能を使って先にローカルネットワークへ入り、その後でループバックまたはLANインターフェースへアクセスすることです。これならコントローラーをインターネットへ直接公開する必要がありません。リバースプロキシを使う場合は、アクセス認証、送信元制限、WebSocketの正しい処理が必要です。ただしプロキシを一層追加すると設定も複雑になるため、家庭の単一端末での利用には通常不要です。

# Linux：コントロールポートがループバックアドレスだけで待ち受けていることを確認
ss -lntp | grep 9090

# macOS：待ち受けプロセスを確認
lsof -nP -iTCP:9090 -sTCP:LISTEN

# Windows PowerShell：ポートの状態を確認
Get-NetTCPConnection -LocalPort 9090 -State Listen

コントロールパネルで接続問題を切り分ける

パネルの価値はワンクリック切り替えだけでなく、接続、ルール、ポリシーを連続して観察できる点にあります。特定のWebサイトを調べるときは、対象ドメインまたはプロセスで接続を絞り込み、マッチしたルール、ポリシーチェーン、最終ノードを記録します。その後、接続を終了してアプリに再接続させ、変更前のポリシーを古い接続が使い続けないようにします。グループを切り替えただけで接続を再構築しないと、画面は変わったのに実際のリクエストは古い出口を使い続けるという錯覚が起きます。

プロバイダーページでは、購読やルールセットの直近の更新が成功したかを確認できますが、「成功」だけで内容が正しいと判断してはいけません。プロバイダーの項目数に異常がないか、フィルター後のプロキシグループが空になっていないか、ルールセットのbehaviorが一致しているかも確認します。ログページは名前解決失敗、インターフェースのバインド失敗、ルールファイル読み込みエラー、ノードのハンドシェイクエラーの確認に向いています。詳細ログを長時間有効にすると書き込み量とプライバシー露出が増えるため、切り分け後は通常のログレベルへ戻してください。

設定完了後の総合検証

高度な設定が完了したら、自由に閲覧するより固定したテストケースで受け入れ確認を行う方が確実です。まず直接接続サイト、プロキシ経由サイト、LAN機器を確認します。次にブラウザー、コマンドライン、システムプロキシを読み取らないアプリをテストします。その後、DNS問い合わせ、Fake-IPマッピング、ドメインルールを確認し、最後にスリープ復帰、Wi-Fi切り替え、購読更新を検証します。各項目で想定ポリシーと実際のマッチ結果を記録し、異常があれば対応する章へ戻ってください。

設定の読み込みに失敗したら、まずYAMLのインデント、コロン後の空白、配列の階層、重複キーを確認します。読み込みは成功したのに通信がない場合は、システムプロキシまたはTUNによる取り込みを確認します。通信はあるのにポリシーが違う場合は、ドメイン情報、ルール順、プロキシグループの参照を確認します。ポリシーが正しいのに接続できない場合に、ノード、プロトコル、対象サイトを確認します。この順序なら、すべての問題をノードのせいにせずに済みます。

問題の層が特定できない場合は、トラブルシューティングのインストール設定と障害切り分けのカテゴリを確認してください。GUIクライアントを変更したり、別のシステムで設定を再現したりする場合は、クライアントダウンロードページでWindows、macOS、Android、iOS、Linux版を選択できます。GUIは日常的な切り替えと確認に適していますが、最終的な判断は実際の実行設定、接続記録、コアのログを基準にしてください。