⚙️ 設定 ⏱ 約17分で読めます

Clash Meta sniffing でサイト異常？無効化と DOMAIN-SUFFIX 例外を段階検証（Mihomo／DNS）

TUN や Rule で運用しているのに、特定の HTTPS サイトだけ証明書警告が出る、ログイン後の画面が真っ白、CSS やフォントなど一部のリソースだけ読み込めない——そんなとき検索しがちなのが sniffing（日本語では「スニッフィング」や設定画面上の sniffer と表記されることが多い）です。本稿は Clash Meta 系コア（多くの GUI が同梱する Mihomo 想定）で、嗅探まわりがルールや DNS と噛み合わず症状を増幅していないかを切り分ける手順を、丸ごと無効化から ドメイン単位の例外、DNS 整合まで段階的に整理します。すでに TUN モードの深掘り や各 OS の初回セットアップ記事を読んでいる方の「次の一歩」として、プロキシを全面オフにせずに済ませる落とし所を狙います。

まず症状を言語化する（sniffing が疑わしいパターン）

すべてのサイトで同じように壊れるなら、ノード障害や DNS の全般設定、回線側の要因が先に疑われます。一方、ごく一部のドメインだけおかしいときは、(1) そのホストが 意図しないポリシーにマッチしている、(2) 名前解決と実接続の見かけがズレている、(3) TLS のメタ情報（SNI など）の取り扱いがアプリや CDN の前提と衝突している、のどれかが多いです。ここで (3) に当たるケースを、実務ではしばしば sniffing 周りの設定変更で緩和できます。

典型例としては、銀行や社内ポータル、一部のクラウドコンソールで、ブラウザの鍵マークは正常なのに中身の API だけ失敗する、同一ページ内の別サブドメインだけタイムアウトする、HTTP/3（QUIC）有効時だけ挙動が変わる、といった切り分けにくい挙動です。ここまで来たら、まずコアのログに どのホスト名でルールが評価されているかをメモし、カスタムルールの優先順位 とセットで見るのが近道です。

sniffing（sniffer）がコア内で担う役割

ざっくり言うと、暗号化された TCP 接続の先頭パケットなどから、アプリケーション層の名前（TLS の Server Name など）を推定し、ルールマッチに使うためのヒントを補う仕組みです。プロキシ越しの転送では、接続先 IP だけでは「どのドメイン向けの通信か」がルールエンジンから見えにくい場面があり、その穴埋めとしてスニッファが置かれます。

ただし推定は万能ではありません。プロトコル実装の差、中間機器、ESNI／ECH のような拡張、あるいは 同一 IP に多数の仮想ホストが乗る CDN など、環境によっては推定結果とアプリの期待がズレます。そのズレが、結果として 誤った出口 や 意図しない再ハンドシェイク に見えることがあります。用語として Clash Meta と Mihomo はしばしば同列に語られますが、本稿では「購読テンプレが載せるコアの sniffer 設定」という実務寄りの意味でまとめます。

💡 ヒント sniffing は「通信を盗み見る」という印象を与えますが、ここでの主目的は ルーティング判断のためのメタデータ補完です。それでも端末ポリシー上は説明が必要な職場では、IT 部門の方針を優先してください。

DNS（fake-ip・DoH）とセットでズレやすい理由

fake-ip を使う構成では、ブラウザが最初に見る IP と、実サーバ側の証明書が想定する名前の対応が直感と違って見えることがあります。これ自体は設計上の動きですが、そこに スニッファによる宛先上書き（override 系の挙動）が重なると、「ルール上はこのドメインのはずなのに、接続確立の段階で別の経路に滑った」ように見えることがあります。

またブラウザの Secure DNS（DoH） がオンだと、OS リゾルバやコアの dns: ブロックと二重に名前解決が走り、ログに出るホストと開発者ツールの Network タブの見え方が一致しないことがあります。切り分けのときは、一度だけブラウザ側 DoH をオフにして再現性を比較するのが有効です。TUN 下で DNS をどう吸い上げるかの全体像は TUN の解説 とあわせて読むと頭の中で一本つながります。

段階 1：sniffing をまずオフにして再現するか見る

いちばん素直な実験は、sniffer を無効化して同じ操作を繰り返すことです。症状が消えるなら、原因の候補を「スニッファとその周辺オプション」に絞り込めます。消えない場合は、本命は ルール順 や ノード品質、純粋な DNS 側に寄ります。

GUI クライアントによっては「スニッファ」トグルがプロファイルを書き換えるだけの実装になっているため、最終的には 実際にコアへ渡っている YAML を確認してください。購読更新で上書きされる場合は、オーバーライドやローカル差分に同じキーを置く運用が安全です。

# Minimal example — confirm exact keys in your core version docs
sniffer:
  enable: false

オフにしたあとで 特定のサイトだけ不具合が残るなら、次段では「スニッファは戻しつつ、そのドメイン列だけ推定をスキップする」方向が現実的です。

段階 2：ドメイン単位で sniffer をスキップする（例外の書き方）

丸ごと無効化は副作用が小さい一方、IP しか見えない通信のルール精度が落ちることがあります。そこで 問題の FQDN だけ sniffer の対象外にするのがバランスのよい妥協点になりがちです。実装側では skip-domain やそれに相当するリスト名が使われることが多く、先頭の +. でサフィックス一致を表す記法がよく出てきます。

# Example only — tune list from your connection logs
sniffer:
  enable: true
  skip-domain:
    - '+.cdn.example.com'
    - '+.bank.example.jp'

ここで重要なのは、例外リストは推測で巨大化させないことです。検索で拾った「よくあるドメイン一覧」をそのまま貼ると、後から挙動が読めなくなります。ログに実際に出たホストから DOMAIN-SUFFIX を育てる方が長期運用に向きます。ルール本体での書き方の基礎は カスタムルール完全ガイド、グループ設計は proxy-groups ガイド を参照してください。

⚠️ 注意 skip-domain は「スニッファが触らない」だけで、そのドメインが自動で DIRECT になるわけではありません。出口は引き続き rules が決めます。

段階 3：分流例外として DOMAIN-SUFFIX をルールに足す

スニッファを調整しても、まだ 望ましいノードに乗らない場合は、ルール表で明示的にポリシーを固定します。たとえば社内限定のサイトや国内決済ドメインを DIRECT に落とし、それ以外は従来どおり PROXY 側へ——という二段構えは現場でよく使われます。

# Place more specific rules above broad RULE-SET / MATCH lines
rules:
  - DOMAIN-SUFFIX,example.jp,DIRECT
  - DOMAIN-SUFFIX,cdn.example.jp,MyProxyGroup
  # ... your subscription rules ...
  - MATCH,MyProxyGroup

分流例外のコツは、広い RULE-SET や巨大な GEOIP 行より上に、自分の環境で再現した行だけを置くことです。DOMAIN-SUFFIX は便利ですが広くマッチするため、副作用が気になるドメインは DOMAIN で一段細かく切る判断もあります。優先順位の感覚は カスタムルール記事 の説明どおり、上から先に当たった行が勝つと覚えておけば十分です。

段階 4：ログで「名前」「ルール」「出口」を三方照合する

感覚論で skip-domain を増やすと、数ヶ月後の自分が読めなくなります。実測ループは次の四段にすると再現性が高いです。(1) 症状が出る操作を決める、(2) その瞬間のコアログから FQDN と マッチしたルール名／行のイメージをメモする、(3) 必要ならブラウザの開発者ツールで 失敗したリクエストのホストを拾う、(4) 変更は一度に一項目だけ入れて差分を見る。

すでに チュートリアル で Rule／Global／Direct の切り替えに慣れていると、この検証はかなり速くなります。Global にした瞬間だけ直るなら ルール不足または順序問題、Direct でも直らないなら ローカル回線・対向サービス・証明書ピンニングなどプロキシ外の線が濃くなります。

  1. 1

    ベースライン（sniffer オフ）

    sniffer.enable: false にして問題サイトを開き、エラーが消えるか記録します。ここで改善するならスニッファ関連の設定を主戦場にします。

  2. 2

    スニッファを戻し skip-domain を最小追加

    ログに出たホストからサフィックスを決め、リストを最小限に保ちます。あわせて override-destination など、版によっては挙動の強いオプションがオンなら一度オフを試します（キー名は利用中のドキュメントに合わせてください）。

  3. 3

    rules 側で DOMAIN-SUFFIX 例外を上段へ

    意図したポリシー（DIRECT または特定の proxy-groups）に固定し、巨大セットより上に置きます。変更後もログで同じホストが同じ出口に行くか確認します。

  4. 4

    DNS を一項目ずつ揃える

    fake-ip、nameserver-policy、ブラウザ DoH を同時にいじらず、差分実験します。DNS 整合が取れないと、ルールを直しても証明書やリダイレクトがおかしく見え続けます。

よくある質問

sniffer をオフにすると速度が落ちる？

環境によります。IP ベースのルールや GEOIP 依存が強いテンプレでは、推定が無いと期待した出口に乗らないケースもあります。だからこそ「全体オフ」より skip-domain のような部分例外が現場では選ばれがちです。

DOMAIN-SUFFIX を足したのに変わらない

より上段の広いルールや RULE-SET に先にマッチしている可能性が高いです。ログで実際のマッチ先を確認し、行を移動するか、より具体的な DOMAIN を検討してください。

証明書エラーは sniffing だけのせい？

必ずしもそうではありません。企業プロキシ、セキュリティ製品の HTTPS 検査、サイト側の設定ミスも同じ症状を出します。スニッファ変更で消えるなら仮説の信頼度は上がりますが、消えなければ他線も並行して疑ってください。

まとめ

Clash Meta／Mihomo 系で TUN や Rule を使っているとき、一部 HTTPS だけ壊れる現象は、sniffing と DNS、ルール順の三位一体で説明できることが多いです。本稿の流れは、まず sniffer をオフにして再現性を見る、改善するなら skip-domain で対象を絞る、それでも足りなければ DOMAIN-SUFFIX などの分流例外をルール上段に置く、の三段が実務的な出口です。いずれも ログに出たホストを正にすると、購読テンプレ更新後もメンテしやすくなります。

クライアントの入手と更新は、説明資料との対応が取りやすいよう 本サイトのダウンロードページ を第一にすると安心です。基礎のおさらいは チュートリアル、エコシステムの俯瞰は 2026 年のエコシステム解説 も参照してください。用途に応じて出口を細かく切り替えられる点では、端末全体を常時トンネルする汎用 VPN に比べ、Clash の運用はトラブル時の切り分けがしやすい場面が多いです。

→ Clash を無料ダウンロードし、sniffing と分流例外の設定をクライアント上で試す