Clashの応用設定ガイド：プロキシグループ・DNS・TUNルール

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

プロキシグループは、ルールに一致したトラフィックの出口を決めるもので、接続先のWebサイトを判定する機能ではありません。設定のproxiesで実際のノードを定義し、proxy-groupsでノードや他のプロキシグループをまとめて選択可能な出口を作り、rulesからその出口名を参照します。3つの階層で使う名前は正確に一致させる必要があります。ノード名を似た名前に変えても、既存のルールが新しい名前を自動で認識することはありません。

変更を始める前に、設定画面で現在有効なサブスクリプションを確認し、プロキシ画面で既存のプロキシグループを調べてください。プロバイダーが自動選択、地域別分類、アプリ別ルーティングなどの多層構造を設定済みの場合があります。同名のグループを追加すると競合し、一覧全体を上書きすると既存ルールの参照先がなくなるおそれがあります。設定を丸ごとコピーするより、先に名前と参照関係を記録するほうが問題を見つけやすくなります。

手動選択・速度テスト・フェイルオーバー

selectは出口を手動で選ぶ方式で、地域やログイン環境を固定したいアプリに適しています。クライアントに記憶された選択結果は、永続化設定の影響を受ける場合もあります。YAMLの先頭メンバーだけを見て判断しないでください。トラブル対処では、プロキシ画面でグループを展開して実際の選択先を確認します。グループ内で別のグループを参照している場合は、実際に使われるノードが見つかるまで展開してください。

url-testは疎通テストの結果をもとに出口を選ぶ方式で、用途の近いノードが複数ある場合に適しています。テスト先の安定性、ノードからの到達性、テスト間隔が短すぎないかなどが結果に影響します。一度のテストで速かったからといって、すべてのWebサイトで速いとは限りません。ダウンロード、動画、業務サービスでは通信経路が異なることがあるため、テスト結果を通信速度のランキングとして扱わないでください。

fallbackはリスト順に利用可能なメンバーを優先する方式で、主系と予備系を明確に分けたい場合に適しています。load-balanceは選択した方式に従って接続を振り分ける機能で、1つのダウンロード接続を複数ノードに分割して帯域を合算するものではありません。アカウントの利用地域、決済確認、接続元IPの制限がある場合、出口を頻繁に変えると追加認証が必要になることがあります。まずは手動選択または主系・予備系の構成で動作を確認してください。

種類	主な選択基準	適した用途
`select`	ユーザーが明示的に選択	出口を固定したい場合や、問題を再現しやすくしたい場合
`url-test`	疎通テストの結果	候補ノードの用途が近く、自動切り替えを許容できる場合
`fallback`	メンバーの順序と利用可能性	主系と予備系が明確な場合
`load-balance`	接続の振り分け方式	複数の出口を利用できるサービス

まずは構成を説明できる出口階層を作る

次の例では、プロキシグループをルールから参照する方法だけを示します。プロキシサーバーは含まれません。組み込みの2つのアウトバウンドはそのまま識別できるため、架空のノード情報を用意する必要はありません。既存設定に追加する際は、同名のトップレベル項目をもう一つ書くのではなく、リストを統合してください。この例では直結を初期値としています。プロキシ経由にする場合は、読み込み済みサブスクリプションの実在するノードまたは既存グループをメンバーに追加し、クライアントで選択してください。

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

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

自動選択グループを使う場合は、url、interval、toleranceを設定できます。intervalの単位は秒で、toleranceはわずかな差による頻繁な切り替えを抑えるための値です。間隔を短くすればよいとは限りません。特にモバイル回線や従量課金の環境では、複数のグループが同時にテストすると余分な通信が発生します。まずは適度なテスト間隔にして、ログを見て調整が本当に必要か確認してください。

グループ同士を参照できますが、循環参照は避けてください。たとえば「業務用出口」から「自動出口」を参照する一方向の構成は明確です。一方、「自動出口」のメンバーに「業務用出口」も含めると、コアが有効な依存関係を構築できません。サブスクリプションを複数統合すると、異なる購読先で同じグループ名が使われていることが多く、こうした問題が起きやすくなります。ローカルで管理するグループには用途が分かる固定の接頭辞を付け、サブスクリプション更新で変わる可能性のある表示名に依存しないようにしましょう。

プロキシグループを検証するときは、まずルールモードのまま、どのルールに一致するか明確なドメインにアクセスします。次に接続画面で、適用されたルール、プロキシの経路、実際の出口を確認してください。接続履歴がない場合は、トラフィックがコアに届いているかを先に調べます。履歴はあるのにグループが違う場合は、ルールの順序を確認してください。モード、ノード、DNSを同時に変更すると、成功・失敗の原因を特定しにくくなります。

ルールセットのサブスクリプション管理

ルールセットを使うと、頻繁に変わるマッチ条件をメイン設定から分離し、メイン設定には参照先と順序だけを残せます。Webサイトのドメイン一覧が更新されても、プロキシグループやポート設定を何度も変更する必要がありません。ノードのサブスクリプションとは別のものです。ノードのサブスクリプションは出口を提供し、ルールセットはマッチ条件を提供します。最終的な出口は、RULE-SETルールで指定したポリシーによって決まります。

ルールセットを管理する前に、既存ルールを用途ごとに整理してください。デバイスやLANの例外は通常、優先順位を高くします。その後に明確なサイト別ルールを置き、地域別の条件や最終的なフォールバックは後ろに配置します。Mihomoは通常、上から順に評価して最初に一致したルールを適用するため、後ろにある詳細なルールが前方の広範なルールを自動で上書きすることはありません。ルールの順序は、ドメイン一覧の内容と同じくらい重要です。

まず動作タイプを選び、次にファイル形式を指定

behaviorはルール内容の意味を表します。domainはドメインの集合を扱い、ipcidrはIPアドレスの範囲を扱います。classicalには、タイプ接頭辞付きのルール条件を含められます。一方、formatはYAML、プレーンテキスト、対応するバイナリ形式など、ファイルの形式を表します。形式が正しくても動作タイプが合っているとは限りません。どちらも提供元の内容に合わせて指定してください。

次の例ではリモートアドレスに依存しないローカルファイルを使います。まず、クライアントからアクセスできる設定ディレクトリにファイルを作成し、プロバイダー定義とルール参照をメイン設定に統合してください。相対パスは、クライアントが実際にコアへ渡す作業ディレクトリを基準にします。ブラウザーのダウンロード先ではありません。ログにファイルが見つからないと表示された場合は、ドメインではなく設定ディレクトリと実行環境を確認してください。

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,手動出口

対応するlocal-direct.yamlの内容は次のとおりです。ここではルール条件を残し、各行に出口ポリシーは書いていません。出口はメイン設定から一括して指定します。末尾のno-resolveは、このIPアドレスルールでドメインの名前解決を積極的に行わないという意味で、クライアント全体のDNSを無効にするものではありません。前の章にある「手動出口」は、そこで作成したグループを使うか、既存のグループ名に置き換えてください。

payload:
  - DOMAIN-SUFFIX,example.org
  - IP-CIDR,192.168.0.0/16,no-resolve
  - IP-CIDR,10.0.0.0/8,no-resolve

リモート管理に移行する場合は、プロバイダーをtype: httpに変更し、実際にアクセスできるurl、ローカルキャッシュのpath、秒単位のintervalを設定します。ファイルの拡張子だけで内容を判断しないでください。サーバーからログインページ、アクセス制限の案内、通常のWebページが返される場合、URLがYAMLで終わっていてもルールセットとして読み込めません。まずレスポンス本文を確認し、その後に設定項目を確認してください。

更新失敗とルール未一致は分けて対処

更新に失敗したら、まずダウンロード経路が使えるか確認してください。ルールセットの更新にもネットワークが必要です。唯一使える出口を、まだ取得できていないリソースに完全に依存させないでください。キャッシュが残っていると、クライアントが古い内容を使い続けることがあります。そのため、ネットワークに接続できることだけでは新しいルールが読み込まれた証拠になりません。プロバイダーの状態とログで更新完了を確認してから、キャッシュの内容が想定どおりか調べてください。

更新に成功したのにルールが一致しない場合は、まず前方に広い条件のルールがないか確認します。同じドメイン接尾辞がすでに直結になっている場合や、先行するIPルールが一致している場合があります。次に、接続先がドメインかIPかを確認してください。ドメインとの対応付けがないIP接続は、ドメインルールに一致しないことがあります。最後に新しい接続でテストしているか確認します。ブラウザーの接続プールにより、既存の接続が使われ続ける場合があります。

ルールセットが大きくなってきたら、複数の提供元を無計画に追加しないでください。内容が重複したり、更新周期が異なったり、同じサイトに相反する分類が設定されたりすることがあります。基本となる分類セットを一つ決め、必要なローカル例外だけを追加するほうが管理しやすくなります。各プロバイダーについて用途、提供元、動作タイプ、参照位置を記録してください。削除する際は、先に参照ルールを削除し、その後でプロバイダー定義を削除します。

ローカル例外は、できるだけ対象範囲を限定して記述してください。特定のドメインだけ出口を変更したい場合に、トップレベルドメイン全体や広いアドレス範囲を同じポリシーに含める必要はありません。IPルールでは、名前解決が発生するかどうかも確認してください。広いネットワーク範囲に一致させるために、不要なDNS問い合わせを起こさないようにしましょう。ルールの一致理由が明確であるほど、誤った振り分けを調べる範囲を絞れます。

リモートルールは設定サプライチェーンの一部です。用途が明確で、内容を確認できる提供元を選びましょう。更新前に直前の正常なファイルを保管し、更新後は代表的なドメインをいくつか選んでプロキシ経路を確認してください。トップレベル項目やインデントについて詳しくは、Clash設定ファイルのYAMLを項目ごとに解説をご覧ください。マージの問題を直すために、同じ項目を重複して追加しないでください。

DNS設定の最適化

DNS設定の目的は、DNSサーバーの数を増やすことではなく、名前解決の経路と接続の出口を整合させることです。1つのリクエストに、アプリ独自の名前解決、システムDNS、コアのDNS、プロキシサーバーの名前解決が関わる場合があります。問い合わせがどの層で行われたかを判断して初めて、ブラウザーでは正常なのにコマンドラインでは失敗する理由や、出口を切り替えても以前のIPアドレスにつながる理由を説明できます。

クライアントのdns.enableを有効にするとコアのDNS機能が有効になりますが、すべてのアプリが必ずそのDNSを使うわけではありません。システムプロキシはプロキシ設定に対応するアプリの接続を処理しますが、システムDNSまで制御するとは限りません。TUNによるDNSハイジャックは別の経路です。アプリ内蔵の暗号化DNSも通常の53番ポートへの問い合わせを迂回することがあるため、スイッチの状態だけで全ての名前解決が統一されたとは判断できません。

ブートストラップDNS・通常DNS・ポリシー別DNSを分けて考える

default-nameserverはDNS上流サーバー自身のホスト名を解決するための設定で、通常は直接到達できるIPアドレスを指定します。nameserverは通常の上流DNSサーバー一覧です。nameserver-policyでは、ドメインごとに特定の上流DNSサーバーを指定できます。これはDNS問い合わせ先を制御するもので、rulesによる通信の出口制御とは別です。両方を個別に確認してください。

次の例では通常の名前解決と、特定ドメイン向けのDNSポリシーを設定します。待ち受け先はループバックインターフェースに限定し、システムサービスとの競合を避けやすい高いポート番号を使います。この設定だけではOSのDNS設定は変更されず、TUNも有効になりません。まずクエリコマンドから待ち受けポートに直接問い合わせ、コアが応答することを確認してからアプリでの利用を検討してください。統合時は既存のDNS設定を置き換えるか整理し、ファイル末尾に2つ目の定義を追加しないでください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "+.example.org":
      - 223.5.5.5

例にあるドメインポリシーはマッチ方法を示すもので、そのドメインが指定されたDNSサーバーを必ず使うべきという意味ではありません。企業のイントラネットドメインには、実際に名前解決できる社内DNSを指定してください。公開DNSをそのまま流用しないでください。社内DNSを使う場合は、問い合わせが通るネットワークインターフェースとルートも確認します。社外では社内DNSに到達できないことがあり、長期間の固定設定が断続的な障害につながる場合があります。

ルールベースのDNS出力制御を有効にする場合は、respect-rulesとproxy-server-nameserverの組み合わせも確認してください。プロキシサーバーのアドレスがドメイン名の場合、コアはプロキシに接続する前にその名前を解決する必要があります。その名前解決まで、まだ確立していないプロキシ経由に限定すると接続できません。プロキシサーバーのドメイン名には、独立して到達可能なDNS経路を用意し、起動時の依存関係が循環しないようにしてください。

フォールバックはDNSサーバーを二重化するだけの機能ではない

fallbackとfallback-filterはセットで理解してください。後者はどのような応答でフォールバックDNSを使うかを決めるもので、プライマリDNSがタイムアウトしたときに予備アドレスを順番に試すだけの設定ではありません。フィルター条件を確認せずにフォールバックDNSだけ追加すると、同じドメインでも想定外のIPアドレスが選ばれることがあります。まず小さな設定で基本の名前解決を確認し、具体的なDNS汚染や地域差の問題に応じて振り分け条件を追加してください。

暗号化DNSを有効にすると、上流DNSまでの問い合わせ通信を保護できますが、現在の出口に適した名前解決結果が得られるとは限りません。リモートDNSが別地域向けのCDNアドレスを返し、通信経路が遠回りになることもあります。特定のWebサイトの読み込みが遅い場合は、DNSの応答、実際の接続先IP、出口の経路を比較してください。すべての速度差をノードの問題と決めつけたり、ドメインごとに細かなポリシーを作ったりする必要はありません。

IPv6は経路全体を確認してください。システムがIPv6アドレスを取得できても、プロキシノード、TUNルート、接続先サイトまでIPv6で正常に通信できるとは限りません。DNSのIPv6応答を無効にするとトラブル対処の範囲を絞れますが、システムのルーティング確認の代わりにはなりません。アプリがキャッシュ済みのアドレスを使う場合は、設定変更後も接続が続くことがあります。関連アプリの接続を終了してから再度名前解決とテストを行うと、結果を比較しやすくなります。

digが使えるシステムでは、次のコマンドで例の待ち受けポートを確認できます。応答が返るか、時間がかかりすぎていないか、現在のモードに合ったアドレス種別かを確認してください。問い合わせに成功しても、そのときコアのDNSに直接アクセスできたことしか分かりません。実際のアプリから接続し、別のDNSを使っていないか確認する必要があります。テスト用の問い合わせツールがインストールされていなくても、確認のためにシステム全体のDNSを変更する必要はありません。

dig @127.0.0.1 -p 1053 example.org A
dig @127.0.0.1 -p 1053 example.org AAAA

キャッシュのトラブル対処は層ごとに進めます。ブラウザー、OS、コアのそれぞれが名前解決結果を保存している場合があります。ポリシーを変更したら、まず新しい接続を作成し、必要な場合に該当する層のキャッシュを消してください。毎回PCを再起動する必要はありません。ログにDNSエラーが続く場合は、失敗したドメインと使用した上流DNSを記録します。特定のサイトだけで問題が起きる場合は、ドメインポリシーとアプリ側の設定を優先して確認してください。エラーの読み方はログの意味と問題の特定方法をご覧ください。

TUNとFake-IP

TUNは仮想ネットワークインターフェースでトラフィックを受け取り、システムプロキシ設定を参照しないアプリにも適しています。Fake-IPはDNSの動作方式の一つです。コアが内部マッピング用のアドレスを返し、後続の接続でドメイン情報を復元します。よく併用されますが、別々の機能であり、すべての環境で同時に有効にする必要はありません。必要なのがトラフィックの取り込みなのか、ドメイン情報の関連付けなのかを確認してから、変更する層を決めてください。

システムプロキシで必要な用途を満たせる場合は、まずTUNを無効のままにします。コマンドラインツール、ゲーム、その他の直接接続アプリも制御する必要がある場合は、TUNを有効にしてシステム権限を確認してください。Clash Verge Revのサービスモード、OSの許可設定、他のネットワークソフトが仮想インターフェースの作成に影響することがあります。画面上のスイッチがオンでも、インターフェース、ルート、接続履歴を確認する必要があります。

まずトラフィックの経路を確立し、その後DNSモードを調整

次の例では、TUNの自動ルーティングとFake-IPを組み合わせた一般的な設定を示します。仮想インターフェースの作成とルート設定を行う権限が必要です。クライアントの設定画面から権限の状態を確認してください。プラットフォームによってプロトコルスタックやインターフェースの対応状況は異なります。他の環境で使われている値を、そのまま最適なパフォーマンス設定とみなさないでください。互換性の問題が発生した場合は、まず元のプロトコルスタックに戻してください。

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-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - https://dns.alidns.com/dns-query

auto-routeは関連するルートを追加し、auto-detect-interfaceは送信インターフェースを検出します。複数のネットワークカード、仮想マシンのブリッジ、企業VPNが同時にある環境で、常に正しい経路を選べるとは限りません。Wi-Fiの切り替え、有線接続、別のトンネルの起動後に通信が突然止まった場合は、サブスクリプションを作り直すのではなく、送信インターフェースとルートの変化を先に確認してください。

dns-hijackによる通常のDNSハイジャックは、あらゆる形式の名前解決を遮断するものではありません。アプリ独自のHTTPS DNSは暗号化された通信であり、通常のDNSパケットとして処理できない場合がほとんどです。OSのローカルDNSサービスにも独自の転送経路があることがあります。検証時はDNSの応答と接続画面に表示されるドメインの両方を確認してください。53番ポートのルールを設定したからといって、すべてのアプリが制御下にあるとは限りません。

Fake-IPアドレスはマッピング用であり、リモートサーバーではない

Fake-IPモードで予約済みアドレス範囲のIPが表示されるのは想定どおりで、そのIPだけを見て接続先サイトの障害と判断しないでください。実際の通信では、接続がマッピングを管理するコアに戻る必要があります。アプリがマッピング用アドレスを取得しても、コアを迂回して直接接続すると失敗することがあります。そのためDNSの取り込みとトラフィックのルーティングは連動させる必要があります。システムDNSだけをコアに向けても、設定が不十分な場合があります。

fake-ip-filterは、特定のドメインに実際のDNS応答を返すための設定です。LAN内デバイス名や、互換性に問題があるアプリのドメインなどが対象になります。項目を増やすほど安定するわけではありません。除外するドメインが多すぎると、利用できるドメインマッピング情報が減り、後続のルールのマッチ経路も変わることがあります。具体的に問題が起きる対象を確認してから、最小限の範囲で例外を追加してください。最初から公共のドメイン空間全体を除外しないでください。

ローカルドメインの接尾辞を例外にしても、デバイス検出プロトコルへの対応にはなりません。プリンター、画面ミラーリング、ファイル共有では、マルチキャスト、ブロードキャスト、OSのサービスも必要になる場合があります。名前解決ができても、デバイスを検出できるとは限りません。トラブル対処では、デバイスのIPに到達できるか、名前を解決できるか、サービスのポートが開いているかを個別に確認してから、ルート除外が必要か判断してください。1台のデバイスを直すために、すべてのプライベートネットワーク通信をプロキシ経由にしないでください。

環境	最初に確認	続けて確認
Windows	サービスの状態と仮想インターフェースの権限	他のVPN、システムファイアウォール、ルートの競合
macOS	クライアントの許可設定とネットワークインターフェース	システムプロキシ、ルート、他のネットワーク拡張機能
Linux	TUNデバイスとルートの管理権限	ネットワーク管理サービス、ファイアウォール、ポリシールーティング

企業VPNと併用する場合は、まず社内ネットワークに必要なルートを維持してください。2つのソフトウェアがどちらもデフォルトルートを制御しようとすると、トラフィックがトンネルを行き来したり、社内サービスに接続できなくなったりすることがあります。有効化前後のルートテーブルを記録し、インターネット、社内アドレス、プロキシサーバーのアドレスを個別にテストしてから、インターフェース除外やサブネット例外が必要か判断します。具体的な設定項目は、現在のコアの機能とシステムのルーティング設計に合わせてください。

Fake-IPを無効にしたり設定を切り替えたりすると、アプリに古いマッピングアドレスが残っている一方で、新しいコアには対応する記録がない場合があります。まずアプリの接続を終了して名前解決をやり直し、必要ならキャッシュを消してください。すべての接続失敗をノードの切断と判断しないでください。マッピングの永続化は、再起動後の一貫性を保つのに役立つ場合がありますが、別のDNSサービスに引き継がれている問題や、コアを迂回するトラフィックを解決するものではありません。

検証の順序を固定します。まず通常のプロキシ接続が使えることを確認し、次にTUNを有効にして、元々プロキシを使わないアプリを確認します。最後にFake-IPへ切り替えてドメインのマッチを確認してください。各段階で正常に動作する設定を残しておきます。TUNを有効にした直後に全体の通信が止まった場合は、まず無効にしてネットワークを復旧し、その後に権限とルートを確認してください。ノードを何度も切り替えても、仮想インターフェースが作成されない問題は解決しません。

ドメインスニッフィング

ドメインスニッフィングは、接続の初期段階で確認できるプロトコル情報からドメインを補います。たとえばHTTPリクエストのHostや、TLSハンドシェイクのサーバー名を参照します。接続先IPしか分からない場合にドメインルールのマッチを改善できますが、すべての接続からドメインを復元できるわけではなく、HTTPSの内容を復号する機能でもありません。使用プロトコル、ハンドシェイク名の秘匿、トラフィックがコアを通っているかどうかなどが結果に影響します。

有効にする前に、実際にドメイン情報が不足しているか確認してください。Fake-IPのマッピングから正しいドメインを取得できている場合、スニッフィングを追加しても効果がないことがあります。接続がそもそもコアに届いていない場合も、スニッフィングのスイッチでは解決できません。典型的な確認対象は、接続画面に接続先IPとポートは表示されるもののドメイン欄が空で、サイトの接尾辞を条件にしたルールが一致しないケースです。

対応するプロトコルとポートを絞って始める

次の設定例は、一般的なWebポートでHTTP、TLS、QUICのスニッフィングを試し、既存のドメイン情報がない接続も処理するものです。TUNを起動したり、DNS設定を置き換えたり、すべてのアプリのプロキシ動作を自動変更したりするものではありません。統合後は新しい接続を作成してください。すでにハンドシェイクが完了した長時間接続では、スニッフィングを有効にしても初期のプロトコル情報は再取得できません。

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

parse-pure-ipは、IPアドレスしか分からない接続の処理を試みる設定であり、任意のバイナリプロトコルを認識できるという意味ではありません。ポート範囲も認識を試みる対象を指定するもので、そのポートで対応プロトコルが動いている保証はありません。すべてのポートにすべてのプロトコルを追加しても、範囲が広がるだけです。ハンドシェイクに読み取り可能なドメイン情報が含まれていない問題は解決できません。

override-destinationは、スニッフィングで得た接続先情報で元の宛先を上書きするかどうかを制御します。「ドメインを取得できるか」とは別の設定です。実際の接続先アドレスが決まっているアプリでは、上書きによって選択されるサービスが変わったり、アプリのキャッシュと一致しなくなったりする場合があります。この例でHTTPの上書きを明示的に無効にしているのは、まずドメインを認識できるか確認し、その後に互換性を見て調整するためです。

認識結果を元の接続先と照合

CDN、複数ドメインで共有するIPアドレス、アプリ内蔵のアドレス一覧などにより、IPとドメインの対応は一意とは限りません。1つのIPで複数のWebサイトが提供されることがあるため、逆引きやアドレスの登録情報だけで現在の通信のドメインを特定することはできません。スニッフィングで得られたプロトコル上の名前はアドレスからの推測より具体的ですが、特にリダイレクトや複数のバックエンドリクエストがある場合は、アプリの実際の通信と照らし合わせてください。

テストでは再現性のあるリクエストを選び、関連する接続を終了してから再度アクセスします。接続画面で接続先ドメイン、マッチしたルール、出口への経路を確認してください。ドメインが表示されてもルールに一致しない場合は、ルールの順序とマッチ方法を確認します。ルールが正しいのにサービスに接続できない場合は、出口、DNSアドレス、宛先の上書きを引き続き確認してください。スニッフィングに成功したことは、接続全体が正常である証拠にはなりません。

ログレベルは接続の流れを確認できる範囲で一時的に上げ、再現操作を一度記録したら通常の設定に戻してください。詳細ログにはアクセス先ドメインや接続情報が含まれることがあり、そのまま長期間保存したり公開したりしないでください。他の人にトラブル対処用の情報を渡す場合は、サブスクリプションURL、アカウント情報、コントロールAPIの認証情報を削除し、必要な設定構造と関連するログだけを残してください。

QUICはUDPを使用します。HTTP/3が正常に動作するかどうかは、プロキシノードとネットワーク経路がUDPに対応しているかにも左右されます。接続できない場合は、プロトコル通信の失敗か、ドメイン認識の失敗かを先に切り分けてください。QUICスニッフィングを無効にしても、アプリがTCPに切り替わるとは限りません。フォールバック動作はアプリの実装に依存するため、このスイッチを汎用的なプロトコル変換機能として扱わないでください。

一部のTLS接続では暗号化されたハンドシェイク名の仕組みや、別のトンネルを使う場合があります。その場合、確認できる情報が減り、スニッフィングで元のドメインを復元できないことがあります。アプリが利用するDNS経路を制御する、Fake-IPのマッピングを維持する、適用範囲を理解した上でアドレスやプロセス条件をルールに加える、といった方法を検討してください。スニッフィングのポート一覧を際限なく広げるのは避けましょう。

特定のアプリで互換性の問題が起きる場合は、現在のコアが対応する項目に従ってskip-domainなどの例外を設定し、対象ドメインを一つずつ除外してテストできます。例外条件は実際に認識された対象と一致させてください。ログにIPしか出ていない場合、実際には現れないドメインを指定しても効果がないことがあります。スニッフィングを無効にすると改善する場合は、ルール全体を削除するのではなく、プロトコル範囲と宛先の上書きを項目ごとに比較してください。

企業内アプリ、固定IPのサービス、デバイス管理ページでは特に注意が必要です。実際のアドレスとは異なる用途のホスト名を送信したり、ゲートウェイ固有の名前解決に依存したりする場合があります。まずLANへの直結ルールを維持し、スニッフィングの結果によって社内通信がインターネット出口に送られないようにしてください。接続、ルール、ログの画面の役割を確認するには、クライアント画面の機能ガイドも参照してください。

ローカル上書きと複数サブスクリプションの統合

サブスクリプションの内容は通常リモートで管理され、ローカルの設定は更新後も維持する必要があります。ダウンロードしたYAMLを直接編集すれば一時的には反映されますが、次の更新で変更が上書きされることがあります。ローカル上書きを使うと、安定した個人設定と定期更新されるリモートの内容を分離できます。重要なのは編集画面の名称ではなく、どの段階で実行され、どの項目に作用し、最終的に何が生成されるかを確認することです。

Clash Verge Revでは、設定画面にある拡張、マージ、スクリプトなどの機能からローカル設定を管理してください。項目名は実際の画面に従います。一部の設定はクライアントの全体設定から実行時のコア設定に書き込まれるため、サブスクリプションファイルの値が最終設定とは限りません。元のファイルに同じ項目を何度も追加するより、まずクライアントの設定を確認し、その後に実行時設定とログを調べるほうが効果的です。

オブジェクトのマージとリストの置換を分けて確認

マージの仕組みによって、オブジェクトと配列の扱いは異なる場合があります。オブジェクトはキーごとにマージされても、rulesやproxy-groupsのようなリストは全体置換、先頭への追加、末尾への追加になることがあります。DNSの項目が一つ維持されたからといって、ルールリストも同じ方法で維持されるとは限りません。まず動作を判別しやすいローカルルールを一つ使って実際の挙動を確認し、その後に変更範囲を広げてください。

次の例は「プロキシグループの選択を保存する」設定の意図を示すもので、汎用的なマージ命令ではありません。クライアントが認識するマージ機能に追加した後、実行時設定に元のサブスクリプションの必要な項目が残っているか確認してください。スクリプトがprofileオブジェクト全体を作り直す場合、後から実行された処理が前の設定を上書きすることがあります。エディター上で保存できたかだけでなく、最終的な出力を確認してください。

profile:
  store-selected: true
  store-fake-ip: true

ローカルルールの追加では挿入位置が特に重要です。特定のサイトを振り分けるルールは、できるだけ前方に置いてください。既存のMATCHより後ろに追加すると、通常は実行されません。明確なフォールバックルールを一つ用意すれば十分で、サブスクリプションごとに追加する必要はありません。統合後のリストは各行の用途を説明できる状態にします。重複ルールが多いとトラブル対処が難しくなります。

サブスクリプションを2つ使っても、完全な設定ファイルをそのまま連結するわけではない

完全な設定ファイルにはポート、DNS、プロキシグループ、ルールが同時に含まれることが多く、2つのファイルを単純に連結することはできません。YAMLのトップレベルキーが重複すると、パーサーがエラーにしたり、後の値で前の値を上書きしたりします。結果は使用するツールによって異なります。ノードだけを組み合わせたい場合は、複数のリモート提供元が共通設定を取り合わないよう、サブスクリプションをプロキシプロバイダーとして読み込み、プロキシグループとルールはローカルで一元管理する方法を優先してください。

次の例では、構造を先に検証しやすいよう、ローカルのプロキシプロバイダーを2つ使います。2つのファイルはユーザーが用意し、それぞれ有効なproxiesリストを含める必要があります。任意のBase64形式のノード文字列を指定するものではありません。この例に架空のサーバーはなく、プロバイダー参照と直結のフォールバックメンバーだけを示しています。初回のテストでは、統合用の選択グループを有効にする前に、2つのファイルがそれぞれ使えることを確認してください。

proxy-providers:
  source-a:
    type: file
    path: ./providers/source-a.yaml
  source-b:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: サブスクリプション統合
    type: select
    use:
      - source-a
      - source-b
    proxies:
      - DIRECT

プロキシプロバイダーのファイルには、すでに使えるノード定義を残せますが、プロバイダー形式に関係のないルール一式や全体設定は削除してください。リモートプロバイダーに切り替えた後、実際のサブスクリプションURL、キャッシュパス、更新間隔を追加します。形式に互換性がない場合は、信頼できるローカル処理方法か、サービス提供元の対応機能を使ってください。形式の違いはサブスクリプションの追加方法と形式の解説をご覧ください。

複数の提供元を使う場合、ノード名の重複も問題になります。プロバイダー名が異なっていても、同じプロキシグループに表示されるノードを区別しにくくなり、名前で絞り込むスクリプトが誤って一致することがあります。提供元を示す接頭辞や、現在のコアが対応する名前変更機能を使い、安定した名前を保ってください。地域の旗、期間限定のキャンペーン名、通信量の案内だけを長期参照の基準にしないでください。

フィルター式には、対象が見つからない場合の代替手段も用意してください。地域名を含むキーワードで絞り込むと、サービス提供元による名称変更でグループが空になることがあります。空のグループがクライアントに報告されるか確認し、手動で選べる経路を残しておきます。正規表現を使う場合は、まず少数のノードで一致結果を確認してください。未検証の複雑な式をすべてのグループに適用してから、メンバーが消えた理由を推測しないでください。

スクリプトは、名前の統一や少数のルール追加など、明確で再現可能な変換に適しています。記録のない大規模な設定変更を隠す用途には向きません。実行前に入力を保存し、実行後に出力を確認してください。問題が起きた場合は元のサブスクリプションに戻せる必要があります。他の人が作成したスクリプトを使う場合は、外部へのアクセス、ローカル情報の読み取り、コントロールAPIの変更がないか確認してください。「ネットにつながる」ことだけで長期利用に適しているとは判断できません。

外部コントローラー

外部コントロールAPIは、コアの状態確認、接続の閲覧、プロキシ選択の変更に使います。コントローラーパネルは、このAPIを呼び出すフロントエンド画面です。ブラウザーが使うHTTPプロキシポートとは別の接続先です。混合ポートはプロキシ通信を処理し、コントロールポートは管理リクエストを処理します。パネルの接続先に混合ポートを入力すると、通常はクライアントのプロキシ画面ではなく接続エラーになります。

Clash Verge Revにはプロキシ、接続、ログを確認する一般的な画面が用意されているため、日常的な本機での操作はクライアント内で完結することがほとんどです。独立したパネル、リモートデバイスの管理、自動化による状態確認が必要な場合に、外部コントロールを設定してください。制御機能は現在のすべての接続や出口選択に影響する可能性があります。まず待ち受け範囲とアクセス元を検討し、ポートをLANに公開することから始めないでください。

本機で使う場合はループバック待ち受けから始める

次の例はループバックアドレスだけで待ち受け、ローカルに配置済みのパネル用静的ファイルを参照します。ディレクトリはユーザーが用意し、パスは実際のコアの作業ディレクトリを基準にします。例にあるパスワードは説明用の明確なダミー値です。実際に使う前に、自分で生成した長いランダム値に置き換えてください。実際のパスワードを公開設定、スクリーンショット、共有リンク、バージョン管理リポジトリに記載しないでください。

external-controller: 127.0.0.1:9090
secret: "example-only-change-before-use"
external-ui: ./ui

コントロールポートと混合ポートの使用中は個別に調べてください。設定を保存した後、ログに待ち受け失敗が表示された場合は、別のクライアントやコアのプロセスがそのポートをすでに使用していないか確認します。使用中のポートを避けるために、待ち受けをすべてのインターフェースに変更しないでください。ポートを変更したら、パネルの接続設定も更新します。対処方法は混合ポートの競合を調べる方法を参考にできますが、確認対象のポートは現在のコントロールポートに置き換えてください。

パネルにはAPIのアドレスと認証情報が必要ですが、パネルとコアが同じデバイスで動作しているとは限りません。パネル画面の127.0.0.1はブラウザーを実行しているデバイスを指します。スマートフォンのブラウザーでパネルを開いた場合、デスクトップPCのループバックアドレスではありません。これはリモート接続が失敗するよくある原因です。デスクトップ側で「LANからの接続を許可」を有効にするだけでは解決しません。

別のデバイスから接続する場合は、アドレスだけでなく境界も確認

別のデバイスから管理する必要がある場合は、信頼できるネットワーク、明示的なファイアウォールルール、認証済みのアクセス経路を使ってください。待ち受け先を0.0.0.0にすると複数のインターフェースから接続を受け付けますが、安全なアクセス境界が自動的に設定されるわけではありません。デバイスがインターネット接続、仮想ネットワーク、ゲスト用Wi-Fiに同時に接続していると、想定以上に広い範囲へ公開されることがあります。設定前に一つずつ確認してください。

ブラウザーからAPIにアクセスする際は、同一オリジンポリシー、CORS設定、混在コンテンツの制限が影響することがあります。HTTPSのパネルから通常のHTTP APIを呼び出すと、ブラウザーがリクエストをブロックする場合があります。これはコアが起動していないことを意味しません。まず本機からAPIに応答があることを確認し、次に開発者ツールに表示された具体的なエラーを調べてください。アドレスやプロトコル設定の問題を、あらゆる送信元を許可する広範なCORS設定で覆い隠さないでください。

ローカルのパネル用リソースは、内容を確認でき、APIとの互換性があるプロジェクトから入手し、プロジェクトの手順に沿って配置してください。ディレクトリが存在しても必要なファイルが揃っているとは限らず、ページが開けてもAPIの認証に成功したとは限りません。トラブル対処では「静的ページの読み込み」「APIへの到達」「認証の成功」「操作の成功」を4段階に分け、それぞれ明確な結果を確認してから次へ進みます。画面の白紙表示と認証エラーを混同しないでください。

自動化による状態確認でも、公開範囲を最小限にしてください。本機からのアクセスだけでよいスクリプトなら、利便性のためにコントロールAPIを外部公開する必要はありません。認証情報は安全な実行環境から渡し、スクリプトに直接埋め込まないでください。ブラウザーからダウンロードできるJavaScriptは訪問者が読めます。コードを圧縮したりファイル名を変えたりしても、パスワードは保護できません。トラブル対処用の資料を共有する際は、リクエストヘッダーと接続設定の機密情報も削除してください。

変更後は決まった順序で検証

最初に、実行時設定に想定した待ち受けアドレスが含まれているか、ログにポート競合や設定の解析エラーが出ていないか確認します。次に同じデバイスからAPIに接続できることと、認証結果を確認してください。その後でパネルを読み込み、現在使っているコアに接続していることを確認します。最後に、元に戻しやすいプロキシ選択を一つ変更し、クライアント画面に反映されるか確認してください。

APIに接続できてもパネルにプロキシグループが表示されない場合は、現在の設定でプロキシグループが読み込まれているか確認し、次にパネルとAPIの互換性を調べます。状態を確認できても切り替えができない場合は、対象グループが手動選択に対応しているか、認証やリクエストにエラーがないか確認してください。こうした段階ごとの確認を、クライアントの再インストールで代用しないでください。再インストールしても、誤った接続先アドレスやバックグラウンドに残った別プロセスは自動で直りません。

作業の最後にログレベルを通常の設定に戻し、一時的に開いた待ち受けを閉じ、不要になったローカルパネルのディレクトリや自動化タスクを削除してください。正常に動作する設定のバックアップも残します。バックアップでは公開可能な設定構造と個人用のサブスクリプション情報を分け、共有する際は必要な部分だけを提示してください。今後クライアントやコアを更新した後も、同じ順序で主要機能を再テストすれば、変化が設定、パネル、実行環境のどれに起因するか判断できます。