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

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

まず、プロキシノード、プロキシグループ、ルールの役割を分けて考えましょう。ノードは実際のプロキシ接続先、プロキシグループは接続先の選択方法、ルールは接続をどのグループに振り分けるかを決めます。多数のルールにノードを直接指定すれば、最初は分かりやすくても、ノード名を変更するたびに修正が必要になり、管理しにくくなります。ルールから用途の変わらないグループを参照し、グループ内でノードを入れ替える方法がおすすめです。設定内の名前は文字単位で照合されるため、空白、大文字・小文字、日本語の句読点が違うだけでも参照に失敗することがあります。

手動選択・遅延テスト・フェイルオーバー

selectは手動選択型のグループで、全体の出口や用途別の出口に適しています。グループにはノードだけでなく、別のプロキシグループも登録できます。url-testは指定したURLへ定期的に接続して応答時間や利用可否を調べ、その結果に基づいて出口を選ぶ方式です。条件の近いノードから選ぶ用途に向いています。fallbackは候補の順序を重視し、先頭の出口が利用できる間はそれを使い、利用できなくなった場合に次の出口へ切り替えます。遅延順にノードを並べ替える機能ではないため、速度測定グループの代わりではなく、主回線と予備回線を明確に分けたい場合に使います。

load-balanceは設定した振り分け方式に応じて接続ごとに出口を分散させますが、単一のダウンロード接続の速度を合算する機能ではありません。ログイン状態や出口の固定、接続地域の一貫性が重要なサービスでは、出口が頻繁に変わると追加認証が発生することがあります。まず手動選択グループでサービスの動作を確認してから、負荷分散を使うか検討してください。ノードの速度テスト結果は、あくまで測定先への接続結果です。動画、コードリポジトリ、ゲームへの接続が必ず速くなるとは限らないため、実際の用途でも確認しましょう。

状態を確認しやすい2層構造にする

以下の構成例では、手動選択と自動テストを分けています。「サブスクリプションノード」は、既存のproxy-providersで定義済みのプロバイダー名を指定してください。利用可能なノードが1つ以上必要です。まず「手動選択」を自動選択グループに渡し、アクセスに問題があればコントローラーから具体的な出口に切り替えます。この例をファイル末尾にそのまま重ねて追加しないでください。既存のproxy-groupsがある場合は、同じトップレベルキーを保ったまま、そのリストに項目を追加します。

proxy-groups:
  - name: 自動選択
    type: url-test
    use:
      - サブスクリプションノード
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

  - name: 手動選択
    type: select
    proxies:
      - 自動選択
      - DIRECT
    use:
      - サブスクリプションノード

intervalの単位は秒で、接続テストの間隔を指定します。toleranceの単位はミリ秒で、小さな遅延変動による切り替えを抑えます。lazyを有効にすると、グループが使われていない間に不要なテストを減らせます。ただし、実際のテスト頻度はプロバイダーのヘルスチェック設定にも左右されます。グループのテストとサブスクリプションのヘルスチェックを、どちらも短い間隔に設定するのは避けましょう。特にモバイル回線では、継続的なテストによって端末の起動や通信量が増えます。まず、障害への対処に本当に短い間隔が必要か確認してください。

参照関係、ループ、接続の安定性を確認する

プロキシグループの参照は一方向に保ちましょう。たとえば、用途別グループから全体の出口へ、全体の出口から自動選択グループへ、自動選択グループからノードへとつなぎます。2つのグループが互いを参照したり、複数段を経由して自分自身に戻ったりしないようにしてください。エラーが発生したら、該当グループから参照先を順に確認します。名前が存在するか、プロバイダーが読み込まれているか、フィルターですべてのノードが除外されていないかを調べましょう。空のグループは、上流のノードがフィルターで除外されていることが原因の場合もあります。ルールを繰り返し変更しても解決しません。

プロキシグループを切り替えても、変更が反映されるのは主にその後に確立する接続です。既存の長時間接続はすぐに移行しないことがあります。テスト時は、まず対象アプリの古い接続を閉じてからリクエストを再実行してください。必要なら該当する接続だけを終了し、端末全体を再起動する必要はありません。ログインが必要なサービスは用途別グループに出口を固定し、テスト結果の変動で出口が頻繁に切り替わらないようにしましょう。ルールと全体モードの違いはプロキシモード3種類の解説も参考にしてください。全体モードを切り替えただけでは、プロキシグループの設定が正しい証拠にはなりません。

ルールセットをプロバイダーで管理

ルールセットを使うと、更新頻度の高いドメインやIPアドレス範囲の一覧をメイン設定から分離できます。メイン設定には判定の順序と出口名を記述し、ルールファイルで照合対象を管理します。用途別ドメインの更新時にプロキシグループ全体を何度も修正せずに済み、更新による差分も追いやすくなります。ルールプロバイダーとプロキシプロバイダーは別のものです。前者が提供するのは照合条件であり、接続可能なプロキシノードではありません。また、ダウンロードが成功しても、メインのルール一覧から参照されていなければ適用されません。

behaviorとファイル形式を選ぶ

behavior: domainはドメイン一覧向けで、同じ種類のサイトをまとめて管理できます。ipcidrはIPアドレス範囲向けです。classicalには、ドメインサフィックス、キーワード、IPアドレス範囲などの従来型ルールを含められます。ファイルの拡張子ではなく、実際の内容に合わせて選んでください。ファイル内の項目形式と、プロバイダーのformatおよびbehaviorを一致させる必要があります。ルール種別のプレフィックスが付いた内容を、ドメインだけの一覧として読み込むと、解析エラーが発生したり、想定と異なる照合結果になったりします。

まずローカルのルールファイルで構造を確認してから、リモート更新を設定するとトラブルの原因を特定しやすくなります。以下の./rules/work.yamlはコアの作業ディレクトリからの相対パスであり、GUIクライアントのインストール先とは限りません。クライアントがサンドボックスやサービスとして動作している場合は、クライアントの設定ディレクトリを確認し、コアから読み取れることも確かめてください。メインルールの「手動選択」は前の章で使ったグループ名です。実際の設定で別の名前を使っている場合は、ここも合わせて変更します。

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

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - RULE-SET,ワークサイト,手動選択
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,手動選択

# rules/work.yaml の内容
payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com
  - DOMAIN-SUFFIX,gitlab.com

ルールの順序を決めてから更新を設定する

ルールは通常、上から順に評価され、一致するとその時点で振り分け先が決まります。例外などの具体的なルールは広範なルールより前に置き、最後にフォールバック用のMATCHを配置してください。そうしないと、後続のルールは評価されません。同じドメインが複数のルールセットに含まれる場合、より具体的な方が自動で選ばれるのではなく、ルールの記述順で決まります。変更前に接続の詳細で、一致したルール、グループ、出口を記録しておきましょう。その後、1つのルールだけを移動して比較します。一覧全体を入れ替えて、Webページが開くかだけを確認するのは避けてください。

リモートプロバイダーに切り替える場合は、種類をhttpにして、取得元のurl、ローカルキャッシュのpath、更新間隔のintervalを設定します。取得先には、内容とメンテナンス方法を確認済みのルールを指定してください。ネット上の任意のリストが信頼できるとは限りません。プロバイダーごとに異なるキャッシュパスを設定しましょう。同じパスを共有すると、更新内容が互いに上書きされることがあります。更新間隔は元ファイルの更新頻度に合わせます。何度も取得するより、数時間から数日おきにするのが適切な場合が多く、トラブル調査時には手動で更新できます。

リモートダウンロードには起動時の依存関係にも注意が必要です。ルールファイルの取得にプロキシが必要なのに、そのプロキシの選択が同じルールセットに依存していると、初回起動時に循環する可能性があります。ダウンロード用に使用可能な出口を明示するか、あらかじめルールをキャッシュしておき、キャッシュのない状態でも起動できるか確認してください。「設定を読み込めた」だけでプロバイダーの状態まで正常と判断しないでください。メイン設定の読み込み後もルールを取得中だったり、古いキャッシュを使用していたりすることがあります。プロバイダーの更新日時とエラー情報も確認しましょう。

IPアドレスルールとフォールバックを確認する

no-resolveは、IPアドレス条件との照合だけを目的にドメイン名の名前解決を行いたくない場合に使います。すべての通信でDNSをスキップする設定ではありません。接続に宛先IPアドレスが含まれていれば、IPルールに一致することがあります。ドメイン名しか分からずIPアドレスがない場合は、このオプションを付けたルールが評価対象から外れることがあります。広い範囲のルールに追加する前に、後続のルールがどのように通信を処理するか確認してください。LAN、プライベートアドレス、自前のサービスには明示的な直接接続ルールを設け、最後のプロキシフォールバックだけに頼らないようにしましょう。

ルールの更新後に一部の通信で問題が起きたら、まず更新を止め、以前のルールファイルに戻して具体的な追加・削除箇所を比較します。新しいドメインがより上位のカテゴリに追加されていないか、IPアドレス範囲が広がっていないか、フォールバック先が変わっていないか確認してください。ファイルを読み込めているのにルールが一致しない場合は、接続にドメイン名が保持されているか、スニッフィングが使えるか、アプリがコアを経由しているかを確認します。ルールモードでよくある現象はよくある質問もご覧ください。設定全体を書き直すのではなく、問題を再現できる最小限のルールを残して調べましょう。

DNS設定の最適化

DNSのトラブル対処では、まず名前解決の経路を整理します。アプリが問い合わせをどこへ送るのか、問い合わせがコアに届くのか、コアはどの上流DNSに問い合わせるのか、その問い合わせがどの出口を通るのかを確認してください。ブラウザーでWebページが開けても、システムDNS、アプリの暗号化DNS、コアのDNSがすべて同じ経路を使っているとは限りません。特にTUNを有効にすると、これまでルーターが処理していたDNS問い合わせをクライアントが処理することがあります。複数のDNS強制ツールを併用すると、結果の原因を追いにくくなります。

待ち受け、上流DNS、起動用DNSを区別する

listenはコアがDNS問い合わせを受け付けるアドレスであり、上流DNSサーバーのアドレスではありません。ループバックアドレスにバインドすれば通常は同じ端末から利用でき、LANアドレスにバインドする場合はファイアウォールとアクセス範囲も考慮する必要があります。nameserverは通常の問い合わせに使う上流DNSを指定します。default-nameserverは上流DNSのホスト名を解決するために使い、DNSサーバーのアドレスを知るために先に名前解決が必要になる問題を防ぎます。起動用DNSにIPアドレスを指定すると、この循環を避けやすくなりますが、現在のネットワークからそのサーバーへ接続できることを確認してください。

以下は設定確認のための基本例です。非特権ポートでローカルに待ち受け、暗号化された上流DNSを使い、指定したドメインサフィックスには別のDNSサーバーを割り当てます。この設定だけでシステムDNSが変更されたり、すべてのアプリの問い合わせが自動的にコアへ送られたりするわけではありません。設定を追加した後は、クライアントのDNS取り込み設定か、次章のTUN設定で問い合わせを受け渡します。クライアントがすでに待ち受けポートを管理している場合、同じポートをむやみに指定しないでください。アドレスの競合や設定の二重化につながることがあります。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "+.example.org":
      - 223.5.5.5

上流DNSを増やすのではなく、ドメインごとに使い分ける

nameserver-policyは、社内ネットワーク、自前のドメイン、特定の名前解決経路が必要なサービスに適しています。社内ドメインには内部レコードを応答できるDNSサーバーを指定してください。内部の問い合わせをパブリックDNSへ送ると、名前が存在しない、または誤ったアドレスが返ることがあります。例のexample.orgはサフィックス照合の書き方を示すためのもので、特別な振り分けが必要な実際のサービスを指すわけではありません。使用時はドメインとDNSサーバーの対応関係を確認し、自分が所有するドメイン、または利用を許可されたドメインに置き換えてください。

上流DNSを増やしても、必ずしも名前解決の信頼性は高まりません。上流DNSごとにコンテンツ配信ネットワークの応答先が異なったり、キャッシュの状態が異なったりするため、複数の応答が混在するとアクセスが不安定になることがあります。fallbackを使う場合は、フィルター条件と切り替えの仕組みも理解してください。単にプライマリーDNSのタイムアウト後に使う予備リストとは限りません。まず経路を1つに絞って確認し、名前解決の所要時間、返されたアドレス、実際のアクセス結果を記録しましょう。問題がDNS層にあると分かってから、追加の振り分けを検討してください。

DNS問い合わせにルーティングルールを適用する場合、respect-rulesで経路を制御できます。ただし、プロキシサーバーのドメイン名をproxy-server-nameserverなどで解決できるようにしてください。そうしないと、プロキシに接続するためのアドレス解決にプロキシが必要となり、接続が循環することがあります。機能の対応状況は、コアの公式ドキュメントと実行ログで確認してください。GUIクライアントのDNSスイッチが追加設定を生成することもあるため、設定エディターに表示されたテキストだけで判断しないようにしましょう。

キャッシュ、IPv6、アプリ内蔵DNSを確認する

テストは3段階で行います。まずコアの待ち受けポートへ直接問い合わせ、次にシステムの既定DNSでテストし、最後に実際のアプリからアクセスします。サーバーとポートを指定できるツールを使い、たとえばdig @127.0.0.1 -p 1053 example.orgを実行します。1段階目は正常で2段階目に失敗する場合は、システム設定と問い合わせの取り込み経路を確認してください。最初の2段階が正常でもブラウザーの動作が異なる場合は、ブラウザーのセキュアDNS、アプリ内プロキシ、既存キャッシュを調べます。設定変更後は、古い接続の影響を避けるため、接続を再確立してテストしましょう。

コアのDNSでIPv6の応答を無効にしても、OSのIPv6通信が完全に停止するわけではありません。アプリがキャッシュや別のDNSを使ったり、IPv6アドレスに直接接続したりすることがあります。逆にIPv6を有効にする場合も、AAAAレコードが返るかどうかだけでは不十分です。端末のルート、プロキシの出口、接続先サービスのすべてがIPv6に対応している必要があります。一部のネットワークだけで問題が起きる場合は、すべてのDNS設定を何度も切り替えるのではなく、IPv4とIPv6を分けてテストしてください。システムのネットワーク設定を変更する前に、元の値を記録して戻せるようにしましょう。

DNS設定の変更後に断続的な障害が起きたら、まず上流DNSへ接続できるか、待ち受けポートが競合していないか、問い合わせが実際にコアへ届いているかを確認してから、キャッシュの削除を検討します。キャッシュには本来の役割があります。頻繁に消すと問い合わせが増えるほか、起動時の依存関係による問題を見えにくくすることがあります。公衆Wi-Fi、企業ネットワーク、家庭用ルーターでは利用できるDNSプロトコルが異なる場合があるため、それぞれの環境で確認してください。1回の問い合わせが成功しただけですべての環境の問題が解決したと考えたり、特定のDNSサーバーのアドレスを恒久的な正解と見なしたりしないでください。

TUNとFake-IP

TUNは仮想ネットワークインターフェースでルート条件に合う通信を受け取り、システムプロキシに従わない一部のアプリにも対応します。Fake-IPはドメイン名に仮想アドレスを割り当て、後続の接続でコアがドメイン名を復元できるようにします。併用されることは多いものの、別々の機能です。システムプロキシが動作していても、TUNの権限やルーティングが正しいとは限りません。仮想アドレスが見えても、その接続がリモートプロキシへ送られているとは限りません。通信の取り込み、ドメイン名の対応付け、ルール照合、最終的な出口を個別に確認してください。

取り込み、ルーティング、名前解決の順に有効化する

まず現在のシステムプロキシモードで、サブスクリプションとノードが使えることを確認します。次にルーティングを変更する他のツールを停止し、最後にTUNを有効にしてください。デスクトップクライアントではサービスのインストール、管理者権限、システム拡張が必要な場合があります。モバイル端末では、通常システムのVPNインターフェースを通じて通信を取り込みます。プラットフォームごとに手順が異なるため、デスクトップの権限設定をそのまま流用しないでください。初回設定ではダウンロードページで最初に紹介しているClash Plusをダウンロードし、OSの案内に従って権限を許可します。その後、現在のクライアントが対象フィールドに対応したコアを使っているか確認してください。

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"

auto-routeは必要なルートの設定にコアを参加させ、auto-detect-interfaceは外部インターフェースの識別を補助します。プロキシ自身の接続が再びTUNへ送られるのを防ぐために使います。stackはネットワークスタックの実装を指定します。選択肢や適用条件はOSの対応状況によって異なるため、すべての端末に共通する最適値があるわけではありません。例では確認の出発点としてmixedを使用しています。起動ログに非対応と表示された場合は、DNSやルールを同時に調整するのではなく、クライアントのドキュメントに従ってください。

仮想アドレスとDNS取り込みの範囲を理解する

Fake-IPが返すアドレスはローカルの対応付けに使うもので、Webサイトの実際のグローバルIPアドレスではありません。「名前解決の結果がおかしい」だけで設定の失敗と判断せず、アクセスが完了するか、接続の詳細からドメイン名を復元できるかを確認してください。実際のIPアドレスが必要なLAN内の機器検索、一部のネットワーク機器、特殊なアプリでは、該当ドメインをfake-ip-filterに追加し、実アドレスを使った名前解決に切り替えられます。フィルターが変えるのは応答形式であり、通信を自動的に直接接続にする機能ではありません。直接接続が必要な場合は、対応するルールも設定してください。

dns-hijackのany:53が対象にするのは、TUNに入り、条件に合致する従来型のDNSリクエストです。すべてのDNSを取り込めるわけではありません。アプリ内蔵のHTTPS暗号化DNSは通常別のポートを使うため、この設定だけでは識別できません。アプリがコアを通さずに名前解決すると、コアには宛先アドレスだけが見えることがあります。その場合、ドメインルールに一致するかどうかはスニッフィングなどの条件にも左右されます。まず問い合わせのプロトコルと実際の入口を確認してから、アプリ設定を変更してください。経路の違いを隠すために、広範なルーティングルールを追加するのは避けましょう。

LANアクセスと残ったルートへの対処

有効化したら、まずインターネットに接続し、次にルーターの管理画面、プリンター、社内ネットワークをテストします。LANだけに問題がある場合は、ノードをすぐ切り替えるのではなく、直接接続ルールとルーティングの除外範囲を確認してください。企業VPNが専用のネットワーク範囲やDNSを設定する場合、TUNの自動ルートと同時に動かすには、それぞれが担当するアドレスを明確にする必要があります。除外するネットワーク範囲は必要な範囲に絞りましょう。広いアドレス範囲を一度に除外すると、プロキシが必要な通信までコアを迂回し、一部のサービスは復旧しても別の振り分け問題が生じることがあります。

すべての接続に失敗する場合は、まずTUNを無効にしてシステムプロキシでテストします。システムプロキシで接続できれば、ノードに問題があるとは限りません。TUNの初期化ログ、既定の出口インターフェースの識別、ルートの設定を確認してください。クライアントを通常どおり終了すれば、通常は作成した状態が削除されます。異常終了後にネットワークが復旧しない場合は、クライアントの修復機能でサービスとルートを確認し、必要に応じてネットワークを再起動してください。システムのルーティングテーブルを理解しないまま項目をまとめて削除しないでください。特に企業ネットワークから設定されたルートは削除しないようにしましょう。

Fake-IPの対応付けとアプリのDNSキャッシュには有効期間があります。コアの再起動後もアプリが古い仮想アドレスを使い続けると、一時的に接続できないことがあります。まずアプリに再度名前解決させてから、関連するキャッシュを消す必要があるか判断してください。常時稼働やモバイルOSのバックグラウンド制限も動作に影響します。詳しくはスマートフォンのバックグラウンド通信とバッテリー消費・接続維持をご覧ください。検証後は、正常時のインターフェース、ルート、DNS設定を記録しておきましょう。次にネットワークを切り替えたとき、最初から推測せずに差分を確認できます。

ドメインスニッフィング

ドメインルールを使うには、接続に対応するドメイン名をコアが認識できる必要があります。通常のプロキシ経由のリクエストにはドメイン名が含まれることが多い一方、TUN経由の接続では宛先アドレスしか分からないことがあります。アプリ独自の名前解決やキャッシュを使う場合、あるいはアドレスを直接指定する場合に起こりやすい現象です。ドメインスニッフィングは、接続開始時のプロトコル情報から、HTTPのHostフィールドやTLSハンドシェイクのサーバー名などを読み取り、ドメイン名の情報を補います。DNSの代わりではなく、アプリの通信内容をすべて復号する機能でもありません。

ドメイン名が不足していることを確認してからスニッフィングを有効にする

トラブル対処では、まず接続の詳細を確認します。宛先欄にドメイン名が表示され、ルールにも一致しているなら、「設定を完全にする」ためだけに強制オプションを増やす必要はありません。宛先がIPアドレスだけの場合は、まずDNS問い合わせがコアに届いているか、Fake-IPの対応付けが残っているかを確認し、それからスニッフィングを検討してください。有効にすると、ルールの照合条件が変わり、以前はIPアドレスで振り分けていた接続がドメイン名に基づいて処理されることがあります。導入前にいくつかのサービスを選び、設定前後のルールと出口を記録して比較しましょう。

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

sniffは識別を試みるプロトコルとポートを指定するもので、ファイアウォールのポートを開放する設定ではありません。実際に必要な範囲だけを指定すると、どの接続が処理対象になるのか把握しやすくなります。force-dns-mappingは一部のDNS対応付けでスニッフィングの機会を増やす設定ですが、すべてのDNS問い合わせを自動的にコアへ送るわけではありません。parse-pure-ipはIPアドレスを直接宛先とする通信に関係します。例ではこの設定を無効のままにし、明確にアドレスを指定している接続まで広い範囲でドメイン推定の対象にならないようにしています。

ドメイン名の照合と接続先の書き換えを区別する

override-destinationは、スニッフィングで取得したドメイン名を使って接続先を書き換えるかどうかに関係します。無効のままにしておけば、接続先を変えずに、スニッフィングによってルール判定に使える情報が追加されるか確認できます。ハンドシェイクに含まれる名前と実際の接続先が一致しないサービスもあります。自前の入口、共有アドレス、特殊な転送環境では特に注意が必要です。有効化後に証明書エラー、接続のリセット、特定アプリの失敗が起きた場合は、接続先の書き換えを独立した要因として調べ、すぐにノードの障害と判断しないでください。

スニッフィングに適さないドメインがあれば、skip-domainに明確な例外を追加できます。ただし、実際の問題に基づいて設定し、ネット上の長い汎用リストをそのままコピーしないでください。例外を追加する前に何度かテストし、接続から見えるドメイン名、実際のアドレス、一致したルールを記録します。スニッフィングを無効にすると復旧する場合も、原因がプロトコルの識別、接続先の書き換え、ルールの順序のどれなのかを比較してください。原因を特定しておけば、次回の更新時に除外範囲を広げてしのぐ必要がなくなります。

暗号化プロトコルによる制限を理解する

TLSのスニッフィングはハンドシェイクで参照できる情報に依存します。暗号化されたクライアントHelloなどの仕組みが使われている場合、実際のドメイン名を取得できるとは限りません。QUICの識別もプロトコル、実装、パケットから見える情報によって異なります。プロトコル名を設定しても、すべての接続を識別できるわけではありません。ドメイン名を復元できない通信には、適切なIPルールやフォールバックを用意してください。対象ポートを際限なく増やすのは避けましょう。アプリにプロキシ設定がある場合は、ドメイン名を含むプロキシ接続を使う方が、スニッフィングの設定を増やすより明確なこともあります。

スニッフィングの結果をアプリの本人確認に使わないでください。接続に含まれるホスト情報は、そのプロトコル上で得られる手掛かりにすぎず、どのユーザーのリクエストかを証明するものではありません。テナント間の分離やセキュリティ境界としても使えません。共有出口、社内ネットワークの権限管理、アクセス制御には、独立したネットワークと認証の仕組みを使ってください。接続先を厳格に制限する業務環境では、管理者が検証可能なルールを定める必要があります。接続を許可するかどうかの判断やアクセス権の付与を、ドメインスニッフィングだけに任せないでください。

検証では、3種類の接続を用意して比較しましょう。通常どおりコアのDNSを経由するWebサイト、独立したDNSを使うアプリ、IPアドレスを直接指定して接続するサービスです。それぞれで宛先情報、一致したルール、最終的な出口を確認し、ページが開くかどうかだけで判断しないでください。スニッフィングの有効化後に待ち時間が増えた場合は、まずプロトコルを1種類に絞ってテストし、その後で一つずつ戻します。問題を特定できる範囲でログレベルを上げ、調査後は通常のレベルに戻してください。接続情報を大量に記録し続けたり、アクセス履歴を含むログをそのまま公開したりしないようにしましょう。

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

リモートサブスクリプションは定期的に更新されるため、ダウンロード済みの設定を直接編集すると、次回の更新で変更が失われることがあります。ローカル設定の上書きを使えば、ポート、DNS、ルール、プロキシグループの設定を別のレイヤーで管理し、上流のサブスクリプションにはノードの更新を任せられます。クライアントによって「上書き」「マージ」「拡張設定」「スクリプト処理」など名称が異なり、動作も統一されていません。始める前に、どの層を変更する機能なのか確認してください。元のサブスクリプション、クライアントに保存された設定、コアに渡される最終的な実行設定は、同じ内容とは限りません。

マージの順序とリストの扱いを記録する

たとえばmodeのような単一値のフィールドは、通常、後から設定した値が前の値を上書きします。一方、リスト形式のフィールドは、末尾への追加、先頭への挿入、リスト全体の置き換えなど、処理方法が異なります。オブジェクト形式も、浅いマージか再帰的なマージかで結果が変わります。どちらのクライアントにも「マージ」と書かれているからといって、同じ結果になるとは限りません。まずローカルの複製で、通信に影響しないフィールドを1つだけ変更し、最終設定をプレビューして結果を確認してからDNSやルールを追加してください。プレビュー機能がない場合は、実行設定のエクスポートや起動ログを確認できます。共有する前にサブスクリプションURLやノードの認証情報を必ず削除してください。

特にrulesの処理方法を確認してください。上書きでカスタムルールが既存のMATCHの後ろに追加されると、そのルールは実行されない可能性があります。リスト全体を置き換えると、既存のLAN向けルールや用途別の例外が失われることがあります。プロキシグループのリストも同様です。すべてのグループを置き換えると、上流のルールが参照している名前が無効になります。維持するグループ名を一覧にし、カスタムルールを挿入する位置を決めておきましょう。YAMLのトップレベルキーを重複させてマージを再現しないでください。重複キーの処理はパーサーによって異なり、信頼できません。

プロバイダーを使って複数のサブスクリプションを管理する

複数のサブスクリプションを使う場合、複数の設定ファイル全体をそのまま連結する必要はありません。各ソースを個別のノードプロバイダーとして登録し、全体の設定でプロキシグループ、ルール、DNSをまとめて管理すると扱いやすくなります。以下は2つのローカルノードファイルを使う構成例です。各ファイルには有効なproxiesリストが必要で、クライアント設定全体をそのまま置くものではありません。ファイルパスは作業ディレクトリからの相対パスです。プロバイダーのヘルスチェックをすでに設定している場合は、グループ内のテストと重なって過剰な頻度にならないよう、実際の用途に合わせて調整してください。

proxy-providers:
  回線A:
    type: file
    path: ./providers/a.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900
  回線B:
    type: file
    path: ./providers/b.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900

proxy-groups:
  - name: 複数サブスクリプションの出口
    type: select
    use:
      - 回線A
      - 回線B

リモートプロバイダーに変更する場合は、自分が正当に利用できる有効なサブスクリプションURLを使い、キャッシュパスと更新間隔を個別に設定してください。サブスクリプションURLにはアクセス認証情報が含まれる場合があるため、公開リポジトリ、スクリーンショット、質問投稿に載せないでください。取得した内容の形式も確認します。クライアントへの完全な設定インポートに使えるURLでも、そのままプロバイダーファイルとして読み込めるとは限りません。ノードリストがないというエラーが出たら、プロトコルのフィールドをむやみに変更せず、レスポンス内容と形式を確認してください。原因は最上位のデータ構造にあるかもしれません。

異なるソースに同じノード名があると、コントローラーでの選択やログの追跡が難しくなり、名前の競合が起きることもあります。クライアントやコアが対応している名前の接頭辞・接尾辞機能を使い、ソースを安定して識別できるようにしましょう。変換スクリプトを使う場合は、まず複製に対して実行し、出力を確認してください。フィルター条件にはソースの意図も含めます。地域名だけに頼ると、上流で名前が変わった際にグループ内のノードがなくなることがあります。マージ後はソースを1つずつ無効にしてテストし、残りのソースだけで想定したフォールバックができるか確認しましょう。

エディターの表示だけでなく、実行設定で検証する

変更のたびに設定をチェックし、再読み込み後にログを確認してください。端末からMihomoを直接実行できる場合は、正しい作業ディレクトリで以下のコマンドを実行します。このコマンドで確認できるのはファイル構造や参照などで、リモートノードやルールの取得先に接続できることまでは保証しません。GUIクライアントでは内蔵の検証機能を使い、2つ目のコアプロセスを起動する必要はありません。2つのプロセスを同時に動かすと、ポートやルートが競合して、本来なかった障害を引き起こすことがあります。

mihomo -t -f ./config.yaml

設定を元に戻せるように、元の設定、ローカル上書き、機密情報を除いた変更内容のメモを保存してください。ノードの認証情報は管理された場所だけに保管し、トラブル対処用の資料に含めないようにしましょう。サブスクリプションの更新後は、最終的なルールの順序、プロバイダーの状態、グループ内のノード数を再確認してください。上流側でグループ名や既定モードが変わったときは特に注意が必要です。初回インストール時の設定順序は初期設定チェックリストを参考にしてください。設定が安定したら、自動書き換えのレイヤーをできるだけ減らし、1つの要件を1つのレイヤーで管理すると、トラブル対処が簡単になります。

外部コントローラー

外部コントローラーは、コアの制御インターフェースを通じて状態を読み取り、プロキシグループの切り替え、接続の確認、プロバイダーの管理を行います。プロキシの接続先ではなく、コントローラーに接続できてもアプリが自動的にプロキシ経由になるわけではありません。アプリが使うプロキシポート、DNSの待ち受けポート、コントローラーの接続先アドレスを区別してください。画面を開けても接続一覧が表示されない場合は、通信を処理しているコアに接続しているか確認します。停止後も残っているサービス、別の設定、同じ端末で起動した2つ目のプロセスに接続している可能性があります。

初期設定ではローカルのみで待ち受ける

external-controllerは制御インターフェースの待ち受けアドレスを指定します。個人用のデスクトップでは、まずループバックアドレスにバインドして、同じ端末からのみアクセスできるようにしましょう。external-uiはローカルのパネル用静的ファイルのディレクトリを指定します。指定先が実在し、コアの作業ディレクトリとの関係が明確である必要があります。以下はローカルでの待ち受けと静的ファイルのディレクトリだけを示す例で、アクセス認証情報は含みません。クライアントが接続先アドレスやパスワードを自動で設定している場合は、その管理方法を優先してください。上書き設定で既存の認証をむやみに消さないようにしましょう。

external-controller: 127.0.0.1:9090
external-ui: ./ui

コントローラーの認証にはsecretなどの設定が関係します。実際に運用する際は、自分で生成した十分に強いパスワードを使い、安全に保管してください。共有するパネルのURL、スクリーンショット、公開設定にパスワードを含めないでください。ローカルにだけバインドしていても、認証が不要になるわけではありません。同じ端末上の他のプログラムや、ブラウザーからのネットワークアクセスも考慮してください。Webページからパネルを利用する場合は、クロスオリジンリクエスト、混在コンテンツ、ローカルネットワークへのアクセスに関するブラウザーの制限にも注意が必要です。ページが表示されても、制御インターフェースへ接続できるとは限りません。

ネットワーク、認証、接続先インスタンスの順に調べる

接続できないときは、まずコアが起動していて待ち受けポートが競合していないことを確認し、パネルに入力したプロトコル、アドレス、ポートを照合します。接続拒否の場合は、待ち受け設定やファイアウォールを確認してください。未認証の応答が返る場合は認証設定を調べます。状態は読めてもプロキシグループが設定と異なる場合は、別のインスタンスに接続している可能性があります。接続を急ぐあまり、アドレスをすぐにすべてのインターフェースに公開したり、認証を恒久的に無効化したりしないでください。まずローカルで最小限の接続経路を確立し、その後で必要な範囲に広げましょう。

別の端末から管理する必要がある場合は、まず管理されたトンネルや既存の管理ネットワークを使い、それから待ち受け設定を検討してください。0.0.0.0にバインドすると、複数のネットワークからインターフェースにアクセスできるようになります。実際に公開される範囲は、ファイアウォール、ルート、ポート転送の設定によって異なります。制御インターフェースでは出口の切り替えや接続の確認などができるため、インターネットに直接公開しないでください。リバースプロキシが必要な場合は、通信の暗号化、アクセス制御、認証を組み合わせ、ブラウザーのクロスオリジン設定も確認します。転送ルールを1つ追加するだけで終わりにしないでください。

接続の詳細を読み取ってから操作する

接続の詳細は、入口、宛先、一致したルール、プロキシグループの経路、実際のノードの順に確認します。入口から、システムプロキシとTUNのどちらを経由したかを判断できます。宛先情報ではドメイン名が保持されているかを確認し、ルールでは選ばれたグループの理由を確認します。プロキシグループの経路には、グループがどのようにノードを選んだかが表示されます。「手動選択」と表示されても最終的な出口まで分かったわけではないため、経路をたどって確認してください。Webページの読み込みで複数の接続が発生した場合は、メインのリクエストとリソース取得をドメインごとに分けて見ます。1つの接続だけでページ全体の経路を判断しないでください。

コントローラーからの切り替えと再読み込みも、それぞれ影響が異なります。プロキシグループの切り替えは主にその後の接続先に影響し、設定の再読み込みはルールやグループ構成を更新することがあります。接続を終了すると、現在のセッションが切断されます。トラブル対処では、まず状態を記録してから対象の接続だけを操作し、ファイル転送、リモートターミナル、会議の通信をまとめて切断しないようにしましょう。ルールプロバイダーの更新に失敗したら、ダウンロードと解析のログを確認します。ノードが使えない場合は出口を調べます。ローカルアプリが接続一覧に表示されない場合は、通信の取り込み設定に戻って確認し、コントローラー上で速度テストを繰り返すだけにしないでください。

日常のメンテナンスは、現在の設定を保存し、1つのテーマを変更し、構文を確認して再読み込みし、ログを見てから対象アプリで接続をやり直す、という短い手順に固定できます。ネットワークを切り替えたときはDNSと既定のインターフェースも確認し、複数のサブスクリプションを更新した後は参照関係とキャッシュを確認しましょう。LANでのプロキシ共有とコントローラーの公開は別の機能です。他の端末からプロキシを使う場合はmixed-portとallow-lanの設定解説をご覧ください。コントローラーのポートをスマートフォンのプロキシ設定に入力しないようにしましょう。それでも原因が分からない場合は、機密情報を除いた最小構成と再現手順を用意し、トラブル対処に関するよくある質問を参照してください。