嗅探（スニッフィング）が「便利」と「地雷」の両面を持つ理由
プロキシのルールは本来、接続が「どのドメインに向かっているか」を知れたほど書きやすくなります。ところが初期SYNだけを見た段階では宛先がIPであり、HTTPSならTLS ClientHello の SNI を読まないとホスト名が分からない──これを補うのがスニッファーです。HTTPなら Host ヘッダ、TLSなら SNI、QUICなら初期パケットに含まれる識別子、といったアプリケーションデータからドメインを復元し、ルールエンジンへ渡します。
一方で override-destination: true のようにスニフ結果で接続の行き先そのものを書き換える構成では、評価に使われるドメイン文字列が「ブラウザのアドレスバー」と一致しないケースが出ます。さらに Fake-IP は名前解決をコア側で握り、ローカルに見えるIP帯と実経路の対応を内部テーブルで持ちます。この二つが重なると、ユーザーがYAMLに書いた DOMAIN 行が「思ったタイミングで」ではなく、「スニフ結果が確定したあと」に効く、あるいは手前の IP-CIDR や GEOIP に先に負ける、といったズレとして表面化します。
症状の典型は次のような粒度です。同じ購読テンプレでもサイトによって快／不快が分かれる、特定のサブドメインだけ証明書エラーに見える（実際は別エッジへ流れた）、アプリだけ失敗してブラウザは生きる、HTTP/3 を切ると直る──背景にはプロトコル差とスニフ成功率の差が必ずあります。コア世代やクライアントGUIのラベルが違っても、考え方は共通なので、まずログに出る「解釈されたホスト名」を正として読む癖をつけます。
手順1：スニッファー有効化の前後でA-B比較し、再現条件を固定する
いきなり YAML をいじる前に、嗅探オフのプロファイルで同じURLが開くかを確定させます。バックアップを取り、sniffer: ブロックごとコメントアウトするか enable: false に落としてリロードし、同端末・同ブラウザ・シークレットウィンドウで再試行します。オフで直るなら、原因の探索範囲は「DNS全断」ではなく嗅探とその周辺オプションに絞れます。
再現手順は短く固定してください。例：「毎回 example.com のトップを開く」「社内VPNとClashを同時に上げる」「HTTP/3 のみを切る」。並行してクライアントのモード（TUN／システムプロキシ）も固定します。モードを変えるとパケットがコアを通る順序が変わり、スニフ成功率も変わるからです。TUN周辺の全体像は TUNとシステムプロキシの整理稿 も参照してください。
sniffer: enable: true override-destination: true
上記のように override-destination が true のテンプレートをそのまま流用している場合、まずここを疑う価値が高いです。逆にオフで症状が消えないなら、嗅探以外（証明書検証、MTU、IPv6デュアルスタック、別VPNの競合）へ視線を移します。
手順2：ログレベルを上げ、「スニフ→上書き→ルール」の1本を追う
log-level を一時的に debug へ上げ、問題のホストへの接続を1本だけ再現します。見るべきは大きく三層です。（1）プロトコルごとのスニフ成功／失敗、（2）override後にルールへ渡っているドメイン文字列、（3）matched rule と実際のポリシー です。（3）だけ既に 分流ログ照合稿 で深掘りしていますが、嗅探問題では（2）の文字列がブラウザ表示と違ってもそれが正である場合があります。
log-level: debug
ログを貼って相談するときほど、マスクすべきはホスト名とサブスクURLです。切り分けが終わったら必ず info など通常レベルへ戻し、長時間 debug を運用に載せないでください。I/OとCPUの負荷が増え、接続数の多いマシンでは体感できます。
手順3：Fake-IP と「ルールが見ている名前」が一致しているか確認する
Fake-IP はユーザーの体感を大きく改善しますが、アプリが握るドメイン文字列 と コアがルール評価に使う文字列 が分岐する余地も生みます。嗅探で上書きが入ると、その分岐はさらに増えます。まず dns セクションの enhanced-mode や fake-ip-range、および fake-ip-filter（名称は実装で揺れるため、利用中のバージョンのドキュメントを正にする）を開き、問題ドメインが意図せず別経路で解決されていないかを確認します。詳細な手順は DNS Fake-IP 排障稿 に譲りますが、嗅探切り分けでは「Fake-IPテーブルに載った名前」と「スニフで確定した名前」が同一かを必ず見比べます。
次にルールの並びを見て、IPや国コードで先にマッチする行 が無いかを疑います。スニフが遅れる、あるいは失敗すると一瞬だけIP評価に落ち、GEOIP や巨大な RULE-SET に吸われるケースがあります。ここは紙に書くのが早いです。リスト上から順に「この行はDOMAINかIPか」「スニフ前と後でどちらのキーが効くか」をメモし、先勝ちの負け を可視化してください。
手順4：override-destination を一時オフにして差分を見る
実務では、まず override-destination: false（または該当フラグをオフに相当する書き方）へ落とし、同一ホストでログを重ねます。これで安定するなら、悩みの核は宛先上書きが期待とズレたドメインへ接続をねじ曲げているか、上書き後の文字列がルール想定と合っていない、のどちらかにほぼ絞れます。
オフにするとルールへ渡る情報が変わるため、「嗅探の恩恵（QUICっぽい挙動の補正）」が減る副作用もあります。恒久対応としては、（1）問題ドメインをスニッファーの skip-domain 系（実装依存のキー名）で除外し上書きの影響圏を狭める、（2）TLS443のみスニフするなど ports を絞る、（3）むしろルール側をスニフ後のホスト名に合わせて DOMAIN-SUFFIX を足す、の三段で選びます。いずれもログの文字列を正にしてから行ってください。
手順5：ルール順とRULE-SETの「広い行」を見直す
購読テンプレは、巨大な RULE-SET を先頭付近に置きがちです。スニッフィングはドメイン評価を豊かにする一方、より上にある広い条件 に最終的に吸い込まれていると、ユーザーの細かい DOMAIN 例外が永遠に届きません。すでに 分流デバッグ稿 で述べた通り、rules は上から先勝ちです。嗅探を足したことで「DOMAINでマッチしていたはず」が「実際は別行のIP条件」に化けた、という説明がつく場合は、まず実際にマッチした行番号 をログで確定させます。
さらに TLS 周辺の表層症状（証明書名前不一致っぽいエラー）が出るときは、出口のズレとセットで TLS握手・SNI の稿 も参照してください。SNIが別名を指したまま別リージョンのノードへ出ると、ブラウザのエラーメッセージは誤解を生みやすいです。
手順6：コアとクライアントを最新に揃え、未対応指令を疑う
スニッファーやDNSまわりのキー名は、mihomo のマイナーバージョンで意味が微妙に変わることがあります。古いGUIに新しいコア、あるいはその逆を混ぜると、「設定は保存されているように見えるが実体は無視されている」状態も起こり得ます。長期運用なら、コア更新の手順を Metaコア更新ガイド に合わせて一度通し、再現テストをやり直すのが安全です。
最後に、嗅探は万能ではないと割り切ります。HTTP/3 優先のアプリ、独自DoHを抱えるアプリ、プロセス単位でプロキシをバイパスするアプリでは、スニフが空振りしやすく、その結果ルールがIP側へ寄ります。そのとき責めるべきは嗅探ではなく、そもそもトラフィックがコアに見えているかです。TUNで全体を覆うか、アプリ側のプロキシ設定を合わせるか、どちらかが崩れていると嗅探以前の問題になります。
よくある質問（整理）
「嗅探を入れたら速くなった／遅くなった」はどう解釈しますか？
スニフ処理そのもののコストより、ルールが以前と別の出口へ切り替わったことによるRTT変化であることが多いです。ログでポリシーが変わったかを確認してください。
skip-domain に入れるべきドメインの選び方は？
症状が出るホストから始め、安定したら一段ずつ範囲を広げます。いきなり上位の .cdn.example を広く除外すると、別の問題を隠すことがあるため、まずは再現が取れたフルのFQDN に絞るのが安全です。
Redir-host に切り替えたほうが早いですか？
ケースバイケースです。Fake-IPの利点を活かしたいなら嗅探側を調整し、逆に名前解決と見え方を素直に揃えたいなら redir-host を試す価値があります。どちらも要件次第なので、運用コストと失敗モードを比較してください。
6手順でも矛盾する場合は？
同時稼働している別VPN、企業ポータル、ローカル防火壁の「プロセス例外」を疑います。Clashのログが正しくても、パケットは別NICへ抜けます。インターフェース優先度とルーティングテーブルを併記して切り分けてください。
まとめ：嗅探は「ドメインの真相を取りに行く」機能だが、ルール順とFake-IPとセットで読む
スニッフィングと override-destination は、HTTPSの実務において強力な補助輪です。同時に、評価されるドメイン文字列が人間の直感とズレるので、ログに出た「解釈済みホスト名」を正にしてルールを読む必要が出ます。Fake-IP と組み合わせたときは、その正しさが二層（DNSとアプリ層）に分かれやすい点に注意してください。
運用では、A-B比較で嗅探の影響圏をまず確定し、ログ三層（スニフ／上書き／matched rule）を1本に束ね、必要なら宛先上書きを止めるか対象を狭める、の順が最短です。テンプレを盲信せず、自環境のプロトコル比率（TLS443とQUICの混在）に合わせて調整してください。
同系のプロキシ実装のなかでも、Clash／Meta はログと設定の対応を追いやすい部類です。ダウンロードページ で対応クライアントを揃え、購読リンク（サブスクリプションURL）から同一プロファイルを端末間で持ち運べば、嗅探ON／OFFの比較も安全に繰り返せます。
ほかのチュートリアルや最新記事は 技術コラム からどうぞ。