Clash Meta Sniffer と QUIC／SNI 分流を有効化する手順 2026

なぜ Sniffer が必要になるのか

Clash Meta（コア実装として広く使われている mihomo）では、トラフィックがプロキシチェーンに乗る時点で、接続の「本来のホスト名」がすでに失われていることがあります。典型的には、TLS の Client Hello に含まれる SNI（Server Name Indication）や、HTTP/3 が使う QUIC の初期パケットからホスト名を復元しないと、コア側は「IP アドレスとポート」しか見えず、DOMAIN や DOMAIN-SUFFIX ベースの分流ルールに正しく載りません。

その結果、ブラウザでは期待どおり見えるのに、実際の出口ノードだけズレる、あるいは意図したポリシーグループではなくデフォルト経路に落ちる、といった症状が出ます。Sniffer（嗅探）は、このギャップを埋めるための公式の仕組みで、パケットの先頭部分を解析してホスト名を推定し、ルールエンジンがドメイン単位で判断できるようにします。TUN でシステム全体を握っている場合でも、嗅探がオフのままだと同種の取りこぼしが残ることがあるため、TUN モードのガイドとあわせて理解しておくと運用が安定します。

QUIC と SNI が分流に効く理由

SNI は、複数ドメインを同一 IP でホストする環境で、クライアントが「どの証明書を見せてほしいか」をサーバへ伝えるためのフィールドです。プロキシが中継する段階でこの情報を読めれば、DOMAIN-SUFFIX,example.com,PROXY_GROUP のようなルールと素直に対応づけられます。

一方、QUIC（UDP 上の HTTP/3）は、TCP の TLS と異なり、接続の最初から暗号化されたフレームが並ぶため、従来の「TLS だけ見れば足りる」前提が崩れやすい領域です。モダンなブラウザや一部アプリは HTTP/3 を優先するため、HTTPS のドメイン分流が「たまにだけ」効かない現象は、QUIC 側の嗅探やポート設計が未整備である可能性が高くなります。ここを押さえると、「ルールは書いたのに挙動が再現性なくブレる」系の報告がかなり減ります。

Sniffer を有効化する考え方（設定の骨格）

実際のキー名やネストは、利用中の mihomo のバージョンと、GUI クライアントが YAML へどう写し込むかに依存します。概念としては、設定の sniffer（または同等のセクション）で 嗅探のオン／オフ、対象プロトコル（TLS、QUIC など）、対象ポート、必要に応じて 強制／除外ドメイン を指定します。

多くの構成では、HTTPS の標準ポートである 443 を TLS と QUIC の両方でカバーするイメージになります。サブスクリプション提供者が推奨するスニファ設定がある場合は、まずそれに従うのが安全です。自前で最小構成から足していく場合は、TLS と QUIC を同時に有効化し、問題が出たドメインだけ skip-domain 側へ逃がす、という段階的な調整が現場では扱いやすいです。

参考までに、骨格のイメージを YAML で示します（ご利用のバージョンの公式ドキュメントと照合してください）。

sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443]
    QUIC:
      ports: [443]
  skip-domain:
    - "example-internal.lan"
  force-domain:
    - "+.cdn.example.com"

force-domain は嗅探結果を優先して適用したいホスト、skip-domain は逆に嗅探を避けたいホスト、という整理です。社内証明書や特殊な中間装置が挟まる環境では、誤検知やパフォーマンスへの影響が出ることがあるため、除外リストのメンテナンスがセットになります。

分流ルール側で押さえるべきこと

Sniffer がホスト名を復元できても、ルールの評価順が先に広いパターン（例：大きな GEOIP やワイルドカードに近い MATCH）で決まってしまえば、望むポリシーグループには届きません。ドメイン単位で細かく振り分けたいサービスは、原則としてリストの上方へ寄せ、後段のフォールバックに飲み込まれないようにします。

記法の詳細やベストプラクティスはルール分流の深掘り記事に譲りますが、Sniffer 文脈では「嗅探で得たドメインが、どのルール行に最初にマッチするか」をログやダッシュボードで確認する習慣が効きます。サブスクのルールセットが巨大な場合、同名ドメインの重複定義に気づかず順序だけが意図とズレている、というケースも珍しくありません。

TUN・DNS とセットで見る理由

TUN を使う構成では、パケットがコアに入る経路は整っていても、DNS がコア外で先に解決されていると、接続の見え方が分裂します。fake-ip モードでは名前と IP の対応がコア内で完結するよう設計される一方、redir-host 系やシステム DNS 直叩きが混ざると、「ルール上はドメイン指定なのに実際は IP ベースで処理されている」すなわち嗅探以前の段階で期待とズレることがあります。

したがって Sniffer を入れても直らないときは、まず DNS モード・fake-ip-filter・DoH の経路を疑い、端末やブラウザの「セキュア DNS」を一時的に切って再現性を比較すると切り分けが速いです。IPv6 が有効な環境では、IPv4 だけをルールで握っても IPv6 が別経路へ抜ける、というパターンもあるため、スタック全体のルーティングを併せて確認してください。

有効化しても分流が効かないときのチェックリスト

コアが本当に Meta／mihomo か

Sniffer は Clash Meta 系コアの機能です。レガシーな Clash Premium 系のみのクライアントでは同等の設定が存在しないか、別名の機能に置き換わっていることがあります。About 画面や設定のエクスポートでバージョン文字列を確認し、ドキュメントも Meta 向けのものを参照してください。

QUIC が別ポートを使っていないか

443 以外の UDP ポートへフォールバックする実装や、中間機器によるポート書き換えがあると、嗅探対象から漏れます。ファイアウォールログとクライアントの接続ログを突き合わせ、実際に流れている 5 タプルを確認すると原因が絞れます。

ECH やピン留め証明書の影響

TLS の仕様進化（例：Encrypted Client Hello など）や、アプリ側の証明書ピン留めは、嗅探や MITM 系の機能と衝突しやすい領域です。特定アプリだけ不調な場合は、そのアプリが独自のネットワークスタックを持っていないか、企業向けプロファイルで追加の検査が入っていないかも含めて調べてください。

ルールが IP ベースで早期決着していないか

IP-CIDR や GEOIP が先にマッチすると、ドメイン嗅探の結果が活きないまま経路が確定します。該当トラフィックの実 IP がどのブロックに属するかを確認し、ドメインルールへ寄せるべきか、リスト順を入れ替えるべきかを判断します。

変更は一度に複数入れず、Sniffer → ルール順 → DNS → TUN の順に一つずつ検証すると、どのレイヤで期待とズレたかが残りやすくなります。

プライバシーとパフォーマンスの注意

Sniffer はローカルでパケットのメタデータを読む行為に近いため、原理的には端末内の処理負荷がわずかに増えます。通常利用では体感差は小さいことが多いものの、ルールセットが極端に大きい端末や、同時接続数の多い P2P 用途ではプロファイルの見直しが有効です。また、職場ポリシーやコンプライアンス上「ローカル解析」をどう扱うかは組織ごとに異なるため、社用端末では IT 部門のガイドラインに従ってください。

まとめ

Clash Meta Sniffer は、TLS の SNI と HTTP/3（QUIC） を含む現代的なトラフィックでも、ドメイン単位の分流ルールを破綻させないための重要なピースです。有効化自体は設定の数行で済む一方で、TUN・DNS・ルール順との整合が取れていなければ症状は残ります。本稿のチェックリストに沿ってレイヤを切り分けると、再現性のない「たまにノードがズレる」問題をかなり早く収束させられます。

クライアントの入手と各 OS 向けパッケージの案内は、本サイトのダウンロードページから確認できます。オープンソースのライセンスやソースコードについては GitHub のリポジトリを参照しつつ、実行ファイルの入手とバージョンの対応づけはサイトの導線を優先すると安全です。

Clash クライアントを無料でダウンロードする → 複数プラットフォーム向けのビルドを揃えており、画面の案内に沿えば短時間で初期設定まで進められます。