1 なぜルールが「本当のドメイン」で動かないのか
Clash Meta（Mihomo）では、DOMAIN や DOMAIN-SUFFIX といったルールは「接続の宛先として認識できたホスト名」に対してマッチします。ところが HTTPS は暗号化されており、最初のパケットの時点ではしばしば IP アドレスだけが見えます。TUN モードや Redir でも、コアが「どのドメイン向けの TLS か」をまだ知らないうちにルーティング判定が走ると、GEOIP や広い MATCH に吸い込まれ、意図したプロキシグループに届かないことがあります。FakeIP を使う構成では名前解決結果が仮想 IP になりやすく、ブラウザやアプリが握っているドメイン情報と、コア側がルール評価に使う情報のズレがさらに起きやすい、という説明もよくされます。
そこで登場するのが Sniffer（スニファー）です。TLS Client Hello に含まれる SNI（Server Name Indication）や、平文の HTTP における Host ヘッダなどからドメイン名を取り出し、ルールエンジンが期待する形に揃えます。DNS 側の整備だけでは足りないケースを補う「TLS 側のドメイン復元」であり、DoH／FakeIP のベストプラクティスとセットで読むと全体像が掴みやすいです。出口の選び方そのもの（自動測速やフェイルオーバー）はURL-Test／Fallback の記事で扱うレイヤーであり、本稿は「ルールに載る名前を正す」側に焦点を当てます。
2 Sniffer が復元する情報
典型的な HTTPS では、クライアントが送信する TLS Client Hello に接続先のホスト名が SNI として入ります。Sniffer はこのフィールドを解析し、ドメイン単位のルールと突き合わせ可能な文字列として扱えるようにします。HTTP/1.1 の平文リクエストであれば Host: から同様に取得できます。QUIC（HTTP/3）を使う場合も、実装と設定に応じて解析対象に含められることがありますが、環境によっては挙動が異なるため、困ったときはクライアントのログで「どのプロトコルとして認識されているか」を確認するとよいです。
重要なのは、Sniffer はプライバシー設定そのものではないことです。あくまでローカルのルーティングとルールマッチの精度を上げるための機能であり、通信の暗号を解除するものではありません。企業ネットワークや規制地域での利用はポリシーに従ってください。また、一部の特殊な TLS 実装や ESNI／ECH など、SNI が見えにくい経路では期待どおりに復元できない場合もあり、そのときはルール設計（IP ベースやプロセスベース）との併用が現実的です。
3 Mihomo で Sniffer を有効にする
設定のトップレベルに sniffer ブロックを置き、enable: true にします。sniff 以下で TLS や HTTP の対象ポートを列挙するのが一般的です。クライアントによっては GUI の「スニファー」「嗅探」などの名称で同じ項目が出ます。Mihomo のバージョンによりキー名や省略形がわずかに異なることがあるため、手元のドキュメントと生成された設定を突き合わせてください。
force-dns-mapping や parse-pure-ip は、DNS まわりの挙動と組み合わせたときに「名前と IP の対応をより積極的に追う」ための補助フラグとして使われます。誤ったサイトだけが別ノードへ行く症状が続くときは、これらをオンにしたうえでログを見比べると改善する例があります。ただしトラフィック種別やルールの書き方によっては副作用もあるため、一度に全部オンにせず、変更点を一つずつ試すのが安全です。
# Sniffer: restore domain from TLS SNI / HTTP Host for rule matching
sniffer:
enable: true
sniff:
TLS:
ports:
- 443
- 8443
HTTP:
ports:
- 80
- 8080-8880
force-dns-mapping: true
parse-pure-ip: true
override-destination: true4 override-destination の意味
override-destination: true は、嗅探で得たドメイン情報を使って、内部の接続宛先表現を「ルールが解釈しやすい形」に寄せるスイッチです。ざっくり言えば、「IP だけだった流れを、SNI から読み取ったホスト名側の論理に合わせる」ためのオプションであり、DOMAIN-SUFFIX,example.com,PROXY のような行が期待どおり効きやすくなります。一方で、まれにアプリケーションの挙動やサーバ側のバーチャルホスト前提と衝突する報告もあるため、問題が出たら一旦 false に戻して差分を切り分けるのが実務的です。
「嗅探は有効だが一部だけおかしい」場合は、まずルールの順序を疑ってください。細かいドメイン例外を上に、広い GEOIP や MATCH を下に、という Clash の基本は Sniffer 利用時も同じです。Sniffer はあくまでマッチ材料を増やすもので、ルールが粗いままでは別の戦略グループに流れ続けます。
5 DNS・FakeIP との連携
DNS は「名前を IP に解く」役、Sniffer は「すでに流れている TLS から名前を読む」役、と整理すると混乱が減ります。FakeIP モードではクライアントが受け取る IP が実サーバとは異なることがあり、ルールが IP ベースだと意図せぬ経路になることがあります。Sniffer と force-dns-mapping を組み合わせると、名前とセッションの対応づけがしやすくなるケースがありますが、銀の弾ではありません。DNS 記事で述べているとおり、fake-ip-filter や DoH の選択も併せて見直すとよいです。
ブラウザの Secure DNS と OS の解決経路が二重にある環境では、見かけ上の「ドメイン」と実際にコアが扱うフローがずれることがあります。そのようなときも、接続ログの SNI とルールヒット順を眺めると、Sniffer をオンにした効果が検証しやすくなります。
6 よくある落とし穴
- Sniffer をオンにしたのに変わらない： ルールが広すぎて先にマッチしている、または購読側 YAML がローカル編集を上書きしている、などが典型です。セレクタで別グループに固定されていないかも確認します。
- 一部プロトコルだけ失敗する： QUIC やカスタム TLS のみを使うアプリでは、解析対象ポートやプロトコルが合っていない可能性があります。ログのプロトコル名とポートを追います。
- override-destination で挙動が逆に悪化： バックエンドが SNI と実ホストを厳密に突き合わせる構成では、オフの方が安定することがあります。オンオフを比較してください。
- 古いコア・古い GUI： Sniffer 周りは更新頻度が高いため、Mihomo 系の現行版へ揃えると挙動差が解消することがあります。
- プライバシーと規約： 本稿は技術説明です。利用規約・法規・職場ポリシーを遵守し、信頼できる設定源のみを用いてください。
7 まとめ
TUN や FakeIP を入れても一部 HTTPS だけ誤ったノードへ行くときは、ルールが参照する「ドメイン」が TLS 段階でまだ揃っていない可能性が高く、その穴を埋めるのが Clash Meta Sniffer です。SNI や HTTP の Host からホスト名を復元し、DOMAIN 系ルールと整合させます。override-destination はその復元結果をルーティング判断に効かせるためのスイッチですが、万能ではないのでログとセットで検証します。DNS は名前解決、Sniffer は TLS 上の名前読み取り、戦略グループは出口選択、と役割を分けて考えると、自動選別やフェイルオーバーの設定とも矛盾しません。
GUI クライアントでは YAML を直接編集しなくても同等のトグルがある場合があります。それでも一度テキストで全体像を把握しておくと、購読更新で消えたときの復旧が速くなります。ビルドの入手とインストール手順はダウンロードページから自 OS に合うものを選べます。
総じて、HTTPS の誤分流は「暗号化のせいでドメインが見えない」「DNS とコアの見え方がズレる」「ルールの順序が粗い」の三つに分解して調べると早いです。Sniffer はその第一項に効く強力な手段ですが、残り二項もあわせて整えると安定します。
