Clash・mihomo高度な設定ガイド：プロキシグループ、DNS、TUN

設定ファイルと反映順

サブスクリプション、生成設定、実行状態の違い

Clashクライアントでは通常、リモートから取得したサブスクリプション、クライアントが加工した最終設定、カーネルに読み込まれた実行状態の3つを扱います。サブスクリプションのコピーを編集しても画面に反映されない場合、設定値が無効なのではなく、クライアントが別の生成ファイルを使っている可能性があります。変更を始める前に、現在有効な設定名、カーネルの種類、クライアントで最終設定を確認できる場所を確かめ、現在のモード、ポート、プロキシグループの選択内容を記録しておきましょう。

サブスクリプションにはノード、プロキシグループ、ルール、DNSが含まれる場合もあれば、ノード一覧だけの場合もあります。クライアントがシステムプロキシ、TUNの有効化、オーバーライド設定に応じて項目を追加することもあるため、ディスク上の元のYAMLがそのまま反映されるとは限りません。リモートの内容を入力、本地のオーバーライドを変換、実行中の設定を確認対象として捉えるとよいでしょう。差異がある場合は、この流れに沿って段階ごとに比較してください。3か所を同時に変更すると、次回更新時にどの設定が残るのか把握しにくくなります。

最小構成で基本動作を確認する

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選択

この最小例は構造を理解するためのものです。mixed-portはHTTPとSOCKSの両方のプロキシ要求を受け付け、ルールモードではルール一覧に従って接続を処理し、最後のフォールバックルールは手動選択グループに渡します。プロキシノードは含まれておらず、グループ内にあるのはDIRECTだけなので、プロキシ経由の接続にはなりません。実際に使う際は、有効なノードやプロキシグループを残し、各グループに追加してください。例に合わせるために、サブスクリプションに含まれる認証情報、トランスポート設定、サーバー側で必要な項目を削除しないでください。

YAMLではタブではなくスペースでインデントします。同じ階層のリスト項目は位置をそろえ、特殊文字を含む名前やパスワードは引用符で囲むとよいでしょう。トップレベルのdns、rules、proxy-groupsは、同じドキュメント内で重複して定義しないでください。重複キーはパーサーに拒否されたり、後の値で上書きされたりすることがあります。コードを貼り付けたら、まずインデント、次に名前の参照関係を確認してください。YAMLとして解析できても、プロキシグループの参照やルールの意味が正しいとは限りません。

構文を確認してから、段階的に再読み込みする

カーネルを直接使う場合は、mihomo -t -f config.yamlを実行して設定を検証できます。クライアントがカーネルをコマンド検索パスに追加していない場合は、実際の実行ファイルのパスを指定してください。ルールセットのキャッシュなどの相対パスは作業ディレクトリに依存するため、テスト時は実行環境と同じディレクトリを使います。構文チェックで見つかるのは主に構造や参照の問題です。実際の通信テストの代わりにはならず、リモートのルールセットが確実に取得できることも保証しません。

変更前に、正常に動作していた設定全体を保存し、クライアントのオーバーライド設定も記録しておきましょう。一度に変更するテーマは1つに絞り、検証に通ってから再読み込みします。待受アドレス、仮想NIC、ルーティングに関わる項目を変更した場合は、クライアントの案内に従ってカーネルを再起動してください。再読み込みが成功しても、既存の接続がすべて新しい設定に切り替わったとは限りません。検証時は対象の接続を作り直し、スイッチの表示だけでなく、ログで設定の読み込み結果も確認してください。

カーネルが起動しない場合は、まず直前に動作していた設定へ戻し、構文エラー、ポートの競合、権限不足を切り分けてください。ポートの問題はmixed-portの使用中エラーの対処法、設定構造はYAML設定のセクション解説を参照してください。基本接続を復旧してから高度な設定に進むほうが、動かない設定にパッチを重ねるより原因を特定しやすくなります。

プロキシグループの種類とルール分岐の実践

ルールで宛先を決め、プロキシグループで出口を選ぶ

ルール一覧は接続をどのプロキシグループに渡すかを決め、プロキシグループは候補から実際の出口を選びます。候補にはノードや別のプロキシグループのほか、組み込みのDIRECTやREJECTも指定できます。この2つの層は分けて設計しましょう。まず手動選択、自動選択、業務サービス用など、用途ごとにグループを定義し、ルールから変更の少ないグループ名を参照します。ノードの追加や削除は下位の層で扱えば、サブスクリプション更新のたびにルール全体を書き換える手間を減らせます。

selectはユーザーが画面上で候補を選ぶ方式です。全体の入口や、出口を固定したいサービスに適しています。選択中のノードが使えなくなっても、候補を自動で切り替えることはありません。自動グループを選んでいる場合は別です。ログイン位置を維持したい場合や、長時間のセッションでは、手動で出口を固定したほうが頻繁に切り替えるより分かりやすいことがあります。グループ名は画面の表示名であると同時に、ルールが参照する識別子でもあります。名前を変更したら、そのグループを参照するルールや上位のプロキシグループも忘れずに更新してください。

自動選択、フェイルオーバー、負荷分散

種類	選択方法	設定のポイント
`select`	ユーザーが手動で選択	入口が分かりやすく、出口を固定したい場合に適する
`url-test`	疎通テストの結果に基づいて選択	テスト先を統一し、切り替え幅を設定
`fallback`	利用可能な候補のうち、優先順位が最も高いものを使用	候補を優先順に並べる
`load-balance`	ルールに基づいて接続を振り分ける	出口の一貫性とセッション要件を確認

url-testは、同種のノードから自動選択する用途に向いています。ただし、疎通テストの結果が示すのはテスト先への接続状況であり、すべてのWebサイトでの使い勝手を表すわけではありません。fallbackは候補の順序を重視します。先頭の候補が利用可能なら優先して使うため、主系・予備系を明確に分けたい場合に適しています。どちらも疎通テストに依存します。テスト先自体にアクセスできない、証明書に問題がある、ネットワークで制限されているといった場合、実際には使える候補が失敗と判定されることがあります。トラブル対処ではテスト先を個別に確認してください。

load-balanceは複数の接続を振り分けるもので、1つの接続を分割して帯域を合算する機能ではありません。ラウンドロビンでは、同じサービスの複数の接続が異なる出口を使う場合があります。一貫性ハッシュを使っても、関連するすべてのドメインが同じノードを使うとは限りません。決済、ログイン、接続元アドレスに敏感なサービスは、出口を固定した専用グループに分けるのが適切です。接続中にポリシーを変更しても、確立済みの通信は通常そのまま維持されるため、新しい選択結果を確認するには再接続が必要です。

proxy-groups:
  - name: 自動選択
    type: url-test
    use:
      - 主要ノード
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: プロキシ入口
    type: select
    proxies:
      - 自動選択
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,プロキシ入口
  - MATCH,プロキシ入口

この例では「主要ノード」というプロキシグループがすでに存在するものとします。useで参照するのはグループ名であり、サブスクリプションのURLではありません。疎通テスト先は、実際にアクセスでき、応答が安定していると確認済みのものに変更できます。間隔の単位は秒です。遅延のわずかな差で頻繁に切り替わらないよう許容値を設定しますが、実際の通信速度を保証するものではありません。ノード数が多い場合はテスト頻度を抑え、まず標準または控えめな間隔で様子を見てから、端末の性能やネットワーク環境に合わせて調整してください。

空のグループ、循環参照、ルールの適用先を確認する

プロキシグループに候補が表示されない場合、グループがまだ読み込まれていない、名前が一致していない、正規表現でノードが見つからないといった原因が考えられます。まずフィルターを一時的に外して実際の候補を確認し、その後で条件を戻してください。グループ同士を階層的に参照することはできますが、循環参照は作れません。たとえば、総合入口が自動グループを含み、その自動グループが総合入口を参照すると、出口を解決できなくなります。「用途別グループ → 選択グループ → ノードまたは集合」の一方向の構造にすると確認しやすくなります。

検証時は、利用可能と分かっている候補を1つ固定して対象サービスにアクセスし、ルールが想定したグループに渡されることを確認してから自動選択を試してください。先に自動選択を試すと、接続失敗の原因がルール、名前解決、ノードのどれにあるのか分からず、自動グループだけが疑われることがあります。プラットフォームごとの画面やカーネル機能を比較する場合はクライアント比較をご覧ください。グループの種類を画面から直接編集できるかどうかは、使用中のクライアントの設定画面で確認してください。

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

マッチングデータと処理方針を分けて管理する

ドメインやIPアドレスの一覧が増えると、すべてをメイン設定に書くのは読みやすさや更新の面で負担になります。rule-providersを使うと、マッチングデータをルールセットとして分離し、メイン設定には取得元と適用順だけを記述できます。ルールセットはどの対象がカテゴリに属するかを定義し、RULE-SETルールはそのカテゴリをどのポリシーに渡すかを指定します。これにより、プロキシグループを変えずに対象リストを更新したり、ドメインデータを書き直さずに出口を変更したりできます。

ルールは上から順に評価され、通常は最初に一致したルールで接続先が決まります。特定ドメインの例外は範囲の広いルールより前に置き、MATCHは最後のフォールバックとして末尾に置いてください。ルールセットの呼び出し位置は、内部のデータと同じくらい重要です。正しい拒否リストでもフォールバックの後に置けば適用されません。広範囲のDIRECTルールをプロキシ対象のルールより前に置くと、接続が先に振り分けられてしまうこともあります。ルールを変更する前に、まず優先順位を整理しましょう。

動作とデータ形式を正しく選ぶ

rule-providers:
  内部ドメイン:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/internal.yaml

rules:
  - DOMAIN-SUFFIX,github.com,プロキシ入口
  - RULE-SET,内部ドメイン,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,プロキシ入口

上のメイン設定はローカルファイルを参照し、「プロキシ入口」グループがすでにあるものとしています。対応するrules/internal.yamlは次のように記述できます。例では説明用に予約されたドメインを使用しており、実在のサービスには依存しません。+.example.comはルートドメインとそのサブドメインを表します。実際に使う場合は管理対象に置き換え、カーネルからアクセスできる場所にファイルを配置してください。クライアントの設定ディレクトリに制限がある場合は、クライアントのインポート機能やルールセット管理画面を優先して利用してください。

payload:
  - '+.example.com'
  - '+.example.org'

behavior: domainはドメインデータ、ipcidrはIPアドレス範囲、classicalは複数種類のルール式に使用します。データの書式はそれぞれ異なり、混在させることはできません。ドメインの一覧にDOMAIN-SUFFIXのルール行全体を直接入れないでください。従来形式のルールセットには通常マッチ条件だけを記述し、適用するポリシーは呼び出し元のRULE-SETで指定します。メインルール一覧をそのままコピーして、各項目の末尾にポリシーを付け加える必要はありません。

形式の指定も内容に合わせてください。YAML形式では通常payloadのリストを使い、テキスト形式では仕様に従って1行ごとにデータを記述します。バイナリ形式のルールセットには、対応する動作と生成ツールが必要です。ダウンロードに成功したことは、応答内容を正しく解析できるという意味ではありません。エラーページ、ログインページ、リダイレクト後のHTMLがキャッシュに保存されることもあります。更新に失敗した場合は、ネットワーク要求が完了したかだけでなく、解析ログやファイルの先頭、実際の応答内容を確認してください。

リモート更新、キャッシュ、起動時の依存関係

リモートのルールセットを使う場合は、type: http、実際にダウンロードできる信頼できるURL、キャッシュパス、更新間隔を設定します。更新時に互いのファイルを上書きしないよう、ルールセットごとに異なるキャッシュファイルを指定してください。初回起動時にルールの取得元への接続にプロキシが必要で、そのプロキシ接続もダウンロード前のルールに依存すると、起動時に依存関係の循環が発生します。ルール取得用に利用可能な出口を指定するか、あらかじめローカルキャッシュを用意してください。無限に再試行して依存関係の循環を隠すのではなく、まず最小限のルールで基本のプロキシ接続が動くことを確認しましょう。

既知の宛先IPアドレスだけで照合したいIPルールには、必要に応じてno-resolveを指定できます。そのルールの確認のためだけにドメインを追加で名前解決するのを避けられます。一方、ドメイン情報しかなく実IPアドレスがまだ分からない接続には、ルールが適用されない場合があります。これは万能な高速化スイッチではなく、照合のタイミングを変える設定です。ドメインルール、DNSポリシー、IPルールはまとめて確認してください。特にFake-IPモードでは、合成アドレスをサーバーの実アドレスとみなしてネットワークの振り分けを設計しないでください。

回帰テストでは、プロキシを使うべき対象、DIRECTで接続すべき対象、拒否されるべきテスト対象をそれぞれ1つ以上確認してください。Webページが開けるかだけで判断せず、接続の詳細でルールの種類、ルールセット名、最終ポリシーを確認します。ルールが正しく適用されても問題が続く場合は、プロキシグループの出口、DNSの応答、既存接続のキャッシュを確認してください。重複ルールをすぐに増やすと、次回のトラブル対処で長くなった例外リストが妨げになります。

DNS設定と名前解決の経路を最適化する

名前解決の経路を整理する

DNS設定では、アプリが問い合わせをどこへ送るのか、カーネルがどの上流DNSを選ぶのか、上流DNSのホスト名自体を誰が解決するのかという3点を考慮します。システムDNS、ブラウザーのセキュアDNS、アプリ内蔵のリゾルバー、mihomoのDNSが同時に使われる場合があるため、上流DNSを変更してもすべてのアプリの動作が変わるとは限りません。最適化を始める前に、接続がカーネルを通っているか、ログに該当する問い合わせが記録されているかを確認してください。問い合わせがカーネルに届いていなければ、カーネルのキャッシュや上流DNSの順序を何度変更しても解決しないことがあります。

nameserverは通常の名前解決に使う上流DNSを指定し、default-nameserverは主に上流DNS自体のホスト名を解決するための導入段階で使います。上流に暗号化DNSのURLを指定しても、そのホスト名を使うには先に実IPアドレスを取得する必要があります。導入段階の名前解決に失敗すると、全体がタイムアウトすることがあります。現在のネットワークから実際に到達できるDNSを導入用に選び、業務ドメインの名前解決とは役割を分けてください。上流DNSのアドレスが、まだ確立していないプロキシ経路に依存しないようにすることも重要です。

確認しやすい基本の名前解決経路を確保する

dns:
  enable: true
  listen: 127.0.0.1:1053
  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.com':
      - 223.5.5.5
  fake-ip-filter:
    - '*.lan'
    - '*.local'

この例ではDNSをローカルホストだけで待ち受け、例示用ドメインには専用の上流DNSを指定します。待受ポートを設定してもシステムDNSが自動で切り替わるわけではなく、他の端末の問い合わせを自動で引き受けることもありません。システム設定、クライアントのネットワーク制御、アプリのプロキシ経路を通じて問い合わせが届いた場合にのみ使われます。上流DNSへ接続できるかはネットワーク環境によって異なるため、まず基本経路が動作することを確認してから、ドメインごとのポリシーを追加してください。LAN内のドメインには、内部レコードを知っているDNSを使い、安易にパブリックDNSへ問い合わせないようにしましょう。

nameserver-policyはドメインに応じて名前解決の上流DNSを選びます。変わるのはDNSの経路であり、接続の出口ではありません。指定したDNSがドメインのアドレスを返した後も、接続先はルールに基づいてプロキシかDIRECTかを決めます。反対に、ドメインがプロキシルールに一致しても、DNS問い合わせが同じプロキシ出口を通るとは限りません。DNSポリシーとルーティングポリシーは別々の一覧にして確認すると、「DNSを指定すること」と「プロキシノードを指定すること」を混同せずに済みます。

プロキシノードの名前解決と予備DNSの役割

ノードサーバーがドメイン名で指定されている場合、その名前解決はプロキシ接続を確立する前に必要です。ノード自身への依存を避けるには、proxy-server-nameserverを使ってプロキシサーバーのドメイン名を解決する上流DNSを個別に指定できます。ルールに応じてDNSの出口を選ぶ機能を使う場合も、この項目を合わせて確認してください。多段プロキシ、リモートルールセットの取得、暗号化DNSを併用するときは、すべての問い合わせを同じ経路に通すことより、依存関係の循環がないことが重要です。

fallbackとfallback-filterはセットで理解してください。後者は、どの応答を予備DNSで使うかの判定に関わるため、「メインDNSに失敗したら必ず切り替える」という単純な優先順位ではありません。範囲の広すぎるフィルターを設定すると、多くのドメインで予備DNSの応答が採用されたり、問い合わせが増えたりすることがあります。明確な要件がなければ、まず確認しやすい単一路線を使ってください。特別な処理が必要なドメインや応答を具体的に説明できる場合に限り、条件を1つずつ追加しましょう。

暗号化DNSは問い合わせの通信を保護しますが、適切な出口の選択に代わるものではなく、返された情報がローカル環境からのアクセスに適しているとも限りません。IPv6も同様に、経路全体の対応が必要です。システムがIPv6アドレスを取得できても、プロキシノード、ルーティング、接続先サービスがすべて利用可能な経路に対応しているとは限りません。一部のWebサイトだけ読み込みに時間がかかる場合は、AAAAレコードの応答と実際のIPv6接続性を確認してから、カーネルDNSのIPv6設定を調整してください。問題をすべてDNSの品質のせいにしないようにしましょう。

問い合わせの入口とキャッシュの影響を確認する

テストでは、システムの既定DNSと指定した待受ポートへの問い合わせをそれぞれ実行し、同じ経路を使っているか比較します。ポート指定に対応するツールを使う場合は、dig @127.0.0.1 -p 1053 example.comのように実行できます。ツールは別途用意する必要があり、クライアントに必ず付属するわけではありません。Fake-IPでは合成アドレスが返ることがありますが、それは想定どおりの動作の場合があります。パブリックDNSの応答と異なるというだけで設定ミスと判断しないでください。より確かな判断材料は、問い合わせログ、アドレスのマッピング、続いて確立される接続の整合性です。

変更後はアプリの接続を作り直し、必要ならアプリ独自のDNSキャッシュを消去してください。ブラウザーのセキュアDNSがシステムの名前解決を迂回していないかも確認します。テスト記録には問い合わせの入口と使用した上流DNSを明記し、異なる経路の結果を直接比較しないようにしましょう。内部ドメインだけ失敗する場合は、まずローカルDNSとドメイン別ポリシーを確認します。すべてのドメインが失敗する場合は、上流DNSの導入設定、待受ポート、ネットワークからの到達性を確認してください。

TUN、Fake-IP、ネットワーク制御

システムプロキシと仮想NICによる制御を区別する

システムプロキシは、システム設定に従うアプリにHTTPまたはSOCKSの接続先を提供しますが、すべての通信がカーネルを経由するとは限りません。TUNは仮想NICとルーティングルールを使って通信を受け取り、プロキシを直接設定できないアプリにも適しています。両者は必ずしも排他的ではありませんが、同時に有効にする場合は、各接続がどこから入るかを把握する必要があります。TUNのスイッチがオンでも、クライアントが機能の有効化を試みたことを示すだけです。仮想NIC、ルート、DNS、権限がすべて有効か確認してください。

デスクトップOSでは、仮想NICやルートの管理に管理者権限、サービスモード、補助コンポーネントが必要な場合があります。具体的な設定画面はクライアントによって異なります。AndroidではVpnServiceを使ってネットワークを制御するのが一般的ですが、バックグラウンドで動作し続けるかどうかは省電力設定にも左右されます。デスクトップ向けYAMLのルーティング項目をすべてモバイル版の画面にそのまま適用しないでください。既存の企業VPNやほかのネットワーク制御ツールが動作している場合も、設定をすぐに重ねず、各ツールが制御するルートの範囲を確認しましょう。

控えめなTUN設定から始める

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

この例では、ネットワーク制御とDNSの関連を示しています。実際に使う場合は、既存のtunとdnsのセクションに組み込んでください。auto-routeはルートの自動設定、auto-detect-interfaceは出口となるNICの検出に使います。スタックの種類は、プラットフォームの対応状況とカーネルログを確認して選びます。クライアントがすでにこれらの項目を管理している場合は、クライアントの設定画面で変更してください。ローカルオーバーライドと画面上のスイッチが互いに上書きし合うのを避けられます。例で使われているスタックが、すべての端末に最適とは限りません。

dns-hijackは、対象となる従来型のDNS要求をカーネルのリゾルバーに渡すための設定です。この例は、すべてのDNS通信を制御できるという意味ではありません。アプリがHTTPSなどの暗号化された経路で問い合わせる場合、通信は通常の宛先ポートへのDNS要求として見えないため、ルーティングとアプリの設定を確認する必要があります。内部リゾルバー、ルーターのドメイン、特殊なネットワークには例外が必要な場合もあります。まず問い合わせの入口を確認してから対象範囲を決め、問題の切り分けの代わりに制御範囲を広げないようにしてください。

Fake-IPはマッピングに使うアドレスであり、実際のサービスアドレスではない

Fake-IPはドメインに合成アドレスを割り当て、カーネルがドメインとアドレスの対応を保存して、後続のアプリ接続を元のドメインに関連付けます。一部の環境では実アドレスを事前に解決する必要を減らせ、ドメインルールも適用しやすくなります。合成アドレスはリモートサーバーのアドレスではないため、リモート側のファイアウォール許可リストに使ったり、同じカーネルを経由しない別の端末から直接使ったりしないでください。アプリにマッピングがキャッシュされていても、接続が対応するカーネルに戻らなければアクセスできないことがあります。

fake-ip-filterは、指定したドメインにFake-IPを割り当てないための設定です。LAN内の機器検出、内部サービス、互換性に問題がある業務などに適しています。フィルターに該当した場合は実際のDNS応答が返りますが、その接続は引き続きルーティングとルールで処理されます。自動的にDIRECTになるわけではありません。まず問題のあるドメインから例外に追加し、それらを正しく名前解決できることを確認してください。一般的なドメインを広範囲にフィルターへ入れると、モードの動作が変わり、ドメインの対応付けがほかの情報源に依存するようになります。

LAN内のネットワーク、コンテナのネットワーク、企業VPNは、合成アドレスの範囲や自動ルーティングと競合することがあります。特定のアドレス範囲に接続できない場合は、DNSをすべて変更する前に、システムのルートテーブルと既存のNICを確認してください。アドレスプールを変更する場合は、既存ネットワークと重ならないことを確認してから、クライアントで対応しているルート除外を設定します。特定のネットワークを除外すると、その通信はカーネルを通らなくなり、カーネルのルールで振り分けられなくなる可能性があります。あらかじめこの境界を把握しておきましょう。

NIC、ルート、名前解決、接続の順に確認する

TUNを有効にした後に完全にネットワークへ接続できなくなった場合は、まずTUNを無効にして元のネットワークを復旧し、カーネルの権限と仮想NICの作成状況を確認してください。次に、既定の出口NICが誤って認識されていないか確認します。特に複数NIC、テザリング、VPNが同時に使われている端末では注意が必要です。ルートが正しいと確認できたらDNSをテストします。ドメインを解決できても接続できない場合は、適用ルールとノードのプロトコル対応を確認してください。複数のスタックやDNS設定を続けて切り替える前に、各段階で再現可能なリクエストを使って検証しましょう。

Androidのバックグラウンド動作時だけ切断される場合は、システム権限と省電力設定を確認してください。詳しくはAndroidのVpnServiceとバックグラウンド動作の維持を参照してください。LAN内の端末だけに影響する場合は、共有プロキシポート、ファイアウォール、待受アドレスを個別に確認します。PC自身のTUNが動いているからといって、ほかの端末もプロキシに接続できているとは限りません。

ドメインスニッフィングとルール判定

スニッフィングでドメイン情報を補い、DNSの代わりにはしない

接続がカーネルに届いても、利用できるドメイン情報が含まれているとは限りません。アプリがIPアドレスへ直接接続する場合や、DNS問い合わせがカーネルの外で行われた場合、ルールエンジンに宛先アドレスしか見えないことがあります。ドメインスニッフィングは接続の初期データからホスト情報を抽出し、ルール判定に必要なドメイン情報を補います。アプリに汎用的な名前解決機能を提供するものではなく、すべての接続を識別できるとも限りません。トラブル対処では、まずドメイン情報がどの段階で失われているかを確認してから、スニッフィングが必要か判断してください。

主な情報源には、HTTPリクエストのHostフィールドや、TLSハンドシェイクで確認できるサーバー名があります。QUICの識別は、プロトコルへの対応とデータを解析できるかどうかにも左右されます。暗号化されたクライアントHello、標準外のハンドシェイク、ドメイン名を持たないプロトコル、確立済みの接続では、識別が難しいことがあります。スニッフィングの成功率だけで設定の正しさを判断しないでください。識別できない接続には適切なIPルールとフォールバックを用意し、あらゆる情報の補完をスニッフィングに頼らないようにしましょう。

対象を広げる前にプロトコルとポートを絞る

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
      override-destination: false
  skip-domain:
    - '+.example.com'

この例では、一般的なHTTPとTLSのポートだけで識別を有効にし、宛先アドレスの上書きは無効にしています。除外対象には説明用のドメインを使っているため、実際には互換性の問題が確認された対象に置き換えてください。ポート一覧は識別の対象範囲であり、ファイアウォールのポートを開放する設定でも、対象接続を自動的にプロキシへ送る設定でもありません。接続先は引き続きルール一覧で決まります。大量のポートで一度に有効化するより、範囲を絞って確認するほうが、どのプロトコルの動作が変わったのか特定しやすくなります。

override-destinationは、スニッフィングで取得したドメインを接続先として上書きするかどうかを制御します。「ルール判定用のドメインを取得する」こととは別の設定です。もともとIPアドレスへ接続していたサービスで上書きを有効にすると、名前解決が改めて行われ、最終的な接続先が変わる場合があります。固定IPのサービス、特殊なCDNの振り分け、社内ゲートウェイでは互換性に影響することがあります。まずは控えめな設定を維持し、業務上どうしても必要だと確認できてから、プロトコルやドメインを限定して調整してください。

誤検出と業務上の例外に対処する

サービスによっては接続を再利用する、アクセス時の名前とは異なる名前でハンドシェイクする、中間ゲートウェイを経由するといったことがあります。スニッフィングで取得した名前が、ユーザーが最初に入力したドメインとは限らず、ルールが別の分類に一致する場合があります。有効化後に特定のサービスで問題が起きた場合は、スニッフィング前後のドメイン、宛先アドレス、適用ポリシーを記録してから、対象を絞った除外を追加してください。ドメインルールをすべて無効にしたり、サービス全体を強制的にDIRECTにしたりすると、変更範囲が広がってしまいます。

force-domainやIPアドレスのみの接続に対する識別などは、さらに詳細な制御項目です。必要性は実際の接続経路とカーネルの対応状況によって異なります。強制対象をすべてのドメインに広げないでください。合理的な要件は「あるアプリが特定のドメインとの対応情報を持たないため、識別を補う必要がある」のように具体化できます。影響を受ける接続を特定できない場合は、まずDNSの入口とFake-IPのマッピングを確認してください。強制スニッフィングが必要に見える問題の多くは、DNSと接続が同じ経路を通っていないことが原因です。

スニッフィングは接続初期の処理にも関わります。タイミングに敏感なアプリでは、プロトコルの待機や識別失敗が接続確立の挙動に影響する可能性があるため、実際に使う通信プロトコルでテストしてください。ブラウザーでホームページが開けても、アプリ内の音声通話、動画、その他の長時間接続が正常とは限りません。ログの詳細度を上げるのはトラブル対処の間だけにし、完了後は通常のレベルに戻してください。不要なドメインや接続情報を長期間記録しないようにしましょう。

識別結果をルール分岐全体に当てはめて検証する

検証には、同じ操作を繰り返せる対象を選びます。まずスニッフィングを無効にして接続し、基準となる結果を記録してから、有効にして再接続し、ルールの適用先が想定どおり変わるか比較してください。宛先にドメイン情報がなくてもIPルールで正しく処理できるなら、画面にドメインを表示するためだけに複雑な設定を追加する必要はありません。ドメインを識別できてもフォールバックルールに一致する場合は、ルールの順序、名前の表記、ルールセットの内容を確認してください。ドメインを識別しただけで、そのドメイン用のルールが自動で作られるわけではありません。

固定IP、証明書エラー、プロキシゲートウェイを使うサービスでは、プロキシ接続が確立されたかだけでなく、アプリケーション層のエラーも確認してください。カーネルは通常、スニッフィングのために通信本文を復号することはなく、サーバー証明書やアカウント権限の問題を修復することもできません。「ドメイン情報の取得」「ポリシーの選択」「接続先」「アプリのリクエスト成功」を別々の結果として記録すると、後続のサービスエラーをスニッフィングの失敗と誤解せずに済みます。

接続先アドレスを維持する必要がある社内システムでは、明示的なドメインルール、内部DNS、対象を絞ったスニッフィング除外を優先してください。複雑な業務で、1つの全体設定ですべて同じ結果になるとは限りません。スニッフィングを無効にする場合も、以前それに頼っていた接続が適切なフォールバックに振り分けられるか確認しましょう。設定を削除して確認を終えないでください。基本用語は用語集で確認できます。

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

リモートの入力とローカルで管理する設定を分ける

サブスクリプションの更新では、通常リモートから内容を再取得します。ダウンロードしたコピーを直接編集すると、次の更新で変更が失われることがあります。設定を維持するには、クライアントが用意するオーバーライド、マージ、スクリプトの機能を使います。ただし、これらはmihomoで統一された画面機能ではありません。Clash Plus、Clash Verge Rev、FlClashなどでは、処理のタイミングや項目のマージ方法が異なる場合があります。機能名が似ているからといって同じルールで上書きされると思い込まず、操作前に最終設定を確認してください。

ローカルで管理する設定には、待受範囲、DNSの優先設定、内部ドメインのルール、固定のプロキシグループ構成などが適しています。ノードのパラメーターや外部ルールデータはリモート更新に任せるとよいでしょう。両者を分ければ、ノードの更新のたびにローカル設定が変わるのを防げます。リモート設定にすでにルール全体が含まれている場合は、その構成を残すのか、自分の構成を使うのかを先に決めてからオーバーライドを設定してください。構成を重ねた結果、どちらが最終的な制御権を持つのか分からなくなるのを避けられます。

プロキシグループで複数のノード提供元をまとめる

proxy-providers:
  提供元A:
    type: file
    path: ./providers/source-a.yaml
  提供元B:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: サブスクリプションA
    type: select
    use:
      - 提供元A
  - name: サブスクリプションB
    type: select
    use:
      - 提供元B
  - name: プロキシ入口
    type: select
    proxies:
      - サブスクリプションA
      - サブスクリプションB
      - DIRECT

この例ではローカルのプロキシグループを使うため、どちらのファイルにも有効なproxiesリストが必要です。まずそれぞれの提供元を個別に検証し、その後上位の入口から選択する構成を示しています。Clashの完全な設定、ノードだけを含むYAML、Base64形式の一覧、プロトコル別の共有リンクは、互換性のあるファイル形式ではありません。サブスクリプションのURLをそのままグループに指定しても、カーネルが認識できるとは限りません。返される形式を確認し、必要に応じて信頼できるローカルの処理方法を使ってください。詳しくはサブスクリプション形式の違いをご覧ください。

リモートのプロキシグループを使う場合は、実際のサブスクリプションURL、キャッシュパス、更新間隔を設定し、起動時のダウンロードがどの経路を通るかも確認してください。サブスクリプションURLにはアカウント情報が含まれることが多いため、ローカルの非公開設定にのみ保存してください。公開の変換サイトや質問用のスクリーンショットに貼り付けないでください。教材や共有用の例では、実際のURL、認証情報、アカウントを特定できるパラメーターを削除します。ノードのパスワードを公開していなくても、サブスクリプションURL自体がアクセス権を持つ場合があります。一般公開してよいWebページのURLとは異なるものとして扱ってください。

リストのマージは単純なテキスト連結ではない

辞書形式の項目はキーごとに上書きできますが、リストには置き換え、先頭への追加、末尾への追加など異なる動作があります。ローカルルールをリモートのMATCHの後ろに追加しても、例外を優先させる目的は達成できないことがほとんどです。DNSリストをそのまま置き換えると、元の設定にあった内部DNSが失われる可能性もあります。オーバーライドを設定する前に、期待する操作を明確にし、クライアントが対応しているか確認してください。セクション全体の置き換えにしか対応していない場合は、必要な項目をすべて含むセクションを用意します。一部だけを指定すれば残りが自動で保持されると思い込まないでください。

複数の提供元に同じ名前のノードやプロキシグループが含まれていることがあります。画面に重複名が表示されると識別しにくくなり、ルールやグループからの参照も曖昧になる場合があります。まず提供元の段階で名前を分かりやすく区別し、クライアントが正式に対応している場合のみ名前の修飾機能を使ってください。画面上の表示名だけを変更して、古い参照を残さないようにしましょう。正規表現によるフィルターも、統合後に確認が必要です。接頭辞の追加、提供元の変更、名前の言語変更によって、以前は一致していた式が空の結果になることがあります。

ヘルスチェックも対象の層を分けて考えます。プロキシグループでノードを確認し、自動選択グループでも疎通テストを実行すると、要求が重複することがあります。手動選択グループすべてに自動テストを追加する必要はありません。確認したいのが「グループ内のノードに接続できるか」なのか、「自動グループがどの候補を選ぶべきか」なのかを決めてから、それに合ったテストを設定してください。複数のサブスクリプションを有効にしている場合、各提供元が利用可能でも、共通の上位グループが正しいとは限りません。最終候補とルールからの参照も確認が必要です。

更新とロールバックの手順を標準化する

統合が終わったら、YAMLの解析、グループの読み込み、プロキシ候補、ルールの順序、DNSの応答を順番に確認し、最終設定のプレビューを保存します。その後サブスクリプションを手動で更新し、同じ項目を再確認してローカル設定が保持されることを確かめてください。更新後の検証を経て初めて、オーバーライドが維持される設定とみなせます。現在のセッションだけ有効な画面上の選択は、クライアントが実行状態を保存するかどうかにも左右されるため、再起動後の動作も個別に確認してください。

古いクライアントから移行する場合は、まずローカルオーバーライドと必要なプロキシ選択の記録をエクスポートし、新しいクライアントにインポートして項目ごとに検証してください。クライアント間で画面設定のデータベースをそのまま使えるとは限りません。現在のプラットフォームに対応するクライアントはダウンロードページから選べます。まずサブスクリプションを1つだけ追加して接続を確認し、次に2つ目の提供元、最後に複雑なルールの順で戻すと、変更ごとの検証範囲を明確にできます。

外部コントローラーとインターフェースのセキュリティ

コントロールポートとプロキシポートの用途は異なる

mixed-portはアプリの接続を転送するためのポートです。外部コントローラーポートは、状態の取得や管理操作に使います。パネルはコントロールAPIを通じてプロキシグループ、接続、ログを確認し、モードの切り替えや設定の再読み込みを行う場合もあります。ブラウザーに入力して使う別のプロキシポートではありません。同じアドレスで同じポートを複数の待受に使うことはできません。起動時に競合が発生したら、プロキシ、DNS、コントローラーそれぞれの待受ポートを確認してください。システムプロキシに入力する番号だけを変更しても解決しません。

コントロールAPIにアクセスできるプログラムは通信の処理方法を変更できるため、その権限は通常のステータスページより強力です。デスクトップでは通常、ローカルのループバックアドレスだけにバインドすれば十分です。リモートから管理する場合は、認証付きトンネルや管理されたネットワークの利用を先に検討してください。コントロールアドレスをすべてのNICで待ち受けるようにしても、アクセス範囲が広がるだけで、アクセス制御が自動的に設定されるわけではありません。パネル画面が他のユーザーに見えないからといって安全になるわけでもありません。実際の保護範囲は、待受アドレス、ファイアウォール、認証の組み合わせで決まります。

ローカル待受と認証の設定

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

例に使われているパスワードは教材用の仮の値です。実際に運用する場合は、ローカルで別の強固な値に置き換え、ノードの認証情報やほかのアカウントのパスワードを流用しないでください。クライアントがコントローラーのアドレスや認証項目を管理している場合があります。手動で上書きしてパネルとの接続が切れたら、まず画面に保存された接続情報と一致しているか確認し、認証をすぐに消去しないでください。待受や認証を変更した場合は、パネル側の接続設定も更新する必要があります。複数のパネルに異なる古い値が保存されていると、接続が不安定に見えることがあります。

クライアント内蔵のローカルパネルがある場合は、クライアントが対応する方法で開いてください。カーネルを直接実行する場合は、external-uiに事前に用意したローカルの静的パネルのディレクトリを指定できます。ただし、そのディレクトリには有効なページリソースが必要です。パスを書くだけでパネルが自動生成されるわけではありません。相対パスはカーネルの作業ディレクトリを基準に解釈し、設定ファイルの場所を移動した場合はリソースへのパスも確認してください。パネルを読み込むためだけに、設定ディレクトリ全体のファイル権限を安易に広げないようにしましょう。

ネットワークに接続できない、認証に失敗する、ブラウザーにブロックされる場合を切り分ける

パネルに接続できない場合は、まずカーネルが動作中で、コントローラーのアドレスで実際に待ち受けているか確認します。次にパネルに設定したプロトコル、ホスト、ポート、認証情報を確認してください。ローカルから接続できても他の端末から接続できない場合は、バインド範囲とファイアウォールを調べます。接続できても未認証になる場合は、認証情報を重点的に確認してください。パネルが表示されても状態が空なら、ページリソースは読み込めていてもAPIへの接続に失敗している可能性があります。見た目だけでコントロール経路が確立したと判断しないでください。

ブラウザーのクロスオリジン制限や混在コンテンツの制限が原因になることもあります。HTTPSで開いたパネルからHTTPのコントロールAPIへ要求すると、カーネルに届く前にブラウザーがブロックする場合があります。まずブラウザーの開発者ツールでネットワーク要求の具体的なエラーを確認してから、同一オリジンでの公開、クライアント内蔵の入口、保護された中継方法を検討してください。ブラウザーのエラーをすべてカーネルの非対応と決めつけないでください。エラーを消すために許可するオリジンやネットワークの待受範囲を一気に広げるのも避けましょう。

クロスオリジンでのアクセスが本当に必要な場合は、カーネルとパネルが対応する方法で許可するオリジンを限定し、認証も有効にしてください。リバースプロキシを通じてリモート用の入口を設ける場合は、WebSocketなどの接続も正しく転送できるか確認します。通常の要求は通っても、リアルタイムログだけ切断されることがあります。入口を保護する際は、通信の暗号化とアクセス範囲の両方を考慮してください。パネルの手前にログイン画面を追加しただけで、下層のコントロールポートを信頼できないネットワークに直接公開しないでください。ネットワーク構成の境界が分からない場合は、ローカル待受を維持するのが適切です。

接続の詳細からトラブル対処の手順を組み立てる

コントロールパネルで特に役立つのは、接続の入口、宛先ドメインまたはアドレス、適用されたルール、最終的なポリシー経路です。失敗した要求を調べるときは、接続を作り直して一覧から該当項目を見つけ、想定した業務用グループに入っているか確認してください。記録がまったくない場合は、アプリがプロキシやTUNを経由しているかを先に調べます。記録はあるがルールが違う場合はルールの順序に戻り、ルールは正しいのに接続できない場合はノード、DNS、プロトコルの対応状況を確認します。この順序で進めると、問題を観測可能な段階に絞れます。

ポリシーの切り替えが影響するのは、基本的にその後に選択される接続です。古い接続は引き続き以前の出口を使う場合があります。検証するには対象のテスト接続だけを終了してから、要求を再送信すれば十分です。すべての通信を一度に切断する必要はありません。詳細ログを一時的に有効にする場合は、再現時刻と対象を記録し、確認が終わったら通常のレベルに戻してください。スクリーンショットやログを共有する前に、サブスクリプションURL、認証情報、内部ドメイン、不要な宛先情報を削除しましょう。トラブル対処に必要なのは、障害に関係する証拠であり、個人のネットワーク記録全体ではありません。

運用手順は「動作する設定を保存、1項目ずつ変更、構文確認、段階的に再読み込み、適用結果を検証、サブスクリプションを更新、再検証して復旧ポイントを記録」の順に固定できます。問題が起きたら、入口、名前解決、ルール判定、出口の4段階に沿って確認してください。クライアントの再インストールとサブスクリプションの交換を同時に行う必要はありません。インストールや利用に関するよくある質問はヘルプセンターをご覧ください。インポートや接続の基本手順を確認する場合はクイックスタートガイドに戻ってください。