Clash Meta で Sniffer を有効にしても HTTPS が誤ったノードへ？mihomo ログで SNI を確認して分流を直す（2026）

1. なぜ「ルールは正しい」のに HTTPS だけズレるのか

多くのユーザーは、DOMAIN-SUFFIX や GEOSITE で目的のサイトを指定した策略を用意しています。それでも挙動がおかしいとき、まず疑うべきは「ルールが評価される時点で、コアはどんな“名前”を握っているか」です。HTTP であれば最初のリクエスト行や Host ヘッダが読めますが、HTTPS ではペイロードが暗号化されるため、プロキシ実装によっては接続先が 203.0.113.10:443 のように IP のままルールエンジンに渡ります。この状態では、ドメイン系ルールに到達する前に GEOIP や IP-CIDR、あるいは上位数行の広い MATCHに吸われ、結果として直結や別ノードに送られることがあります。

つまり症状の本質は「策略が悪い」より評価キーが IP になっていることが多い、と捉えると早いです。ここで Sniffer が有効なら、TLS ハンドシェイクの段階で SNI を取り出し、ドメイン名としてルールを再評価できるようになります。逆に言えば、Sniffer がオフ、または対象プロトコル外、もしくはログ上 SNI が空／別名のままなら、書いたドメインルールに一生乗らない、という現象が残り続けます。

2. Sniffer の役割と「IP のまま評価される」状態

mihomo / Clash Meta における Sniffer は、ざっくり言えば「暗号化された TCP ストリームの手前だけを覗いて、ホスト名らしき文字列を復元する」仕組みです。HTTPS なら典型は TLS ClientHello 内の SNIです。HTTP/1.1 の平文なら Host、QUIC には別の検出パスが絡む、といった具合に、プロトコルごとに“取れる名前”が異なります。そのため「Sniffer をオンにした」と言っても、実際にマッチしたスニッファの種類や、override-destination で宛先を書き換えるかどうかによって、ルールに渡る見え方は変わります。

ストリーミングや CDN まわりでは、動画・認証・計測ドメインが分かれやすく、一見同じサービスでも接続ごとに SNI が変わることは日常茶飯事です。Disney+ や配信系で DNS・fake-ip・Sniffer を噛み合わせる話は、別稿でストリーミング視点から整理しています。本稿ではHTTPS 一般の「名前が見えない／違う名前が見える」問題にフォーカスし、ログの読み方で足場を固めます。

3. ログで Sniffer と SNI を確認する（debug とフィルタ）

まず log-level: debug に上げ、問題のサイトへアクセスした直後のログだけを切り出します。GUI（例：Clash Verge Rev）ならビューアで 対象 IP、ポート 443、あるいは策略名で絞り込みます。見たいのは次のような観点です。（1）接続が最初、IP 宛てに張られているか。（2）その後に sniff／TLS／SNI らしい行が続くか。（3）最終的にどのルール名へマッチしたか。（4）実際に使われたアウトバウンド（DIRECT かどのプロキシか）。この四つが揃うと、「名前が取れていない」のか「名前は取れているがルール順で負けている」のかが分かれます。

ログに SNI が一度も出てこない場合は、Sniffer 自体が無効・対象外・あるいはクライアントが期待するパスを通っていない（例：プロセスが TUN を迂回、別のローカルプロキシが先に終端している）などを疑います。逆に SNI は出るが期待ドメインと違う場合は、CDN のエッジ名・別ホストへのリダイレクト・サードパーティドメインが本体より先に目立っている、といった「ルールに書くべきホストがズレている」パターンです。購読更新や CLI だけがおかしいときの TLS／DNS の見方は、Windows 向け購読ログ稿とも補完関係にあります。

# config.yaml fragment — enable debug while inspecting sniffer / SNI (revert after)
log-level: debug

4. SNI と証明書（CN／SAN）が違うときの読み方

トラブルシュートで混同しやすいのが、SNI（クライアントが「この名前で接続したい」と宣言する値）と、サーバ証明書に載るドメイン（SAN など）です。通常は一致しますが、マルチ CDN・ワイルドカード・古いミドルウェアなどで見え方が分岐することがあります。プロキシのログでは、実装・バージョンによっては sniff 結果としてのホスト名と、TLS 検証まわりのメッセージが近接して出ます。ここで「ブラウザでは開けるのにプロキシログでは証明書の名前が別」と感じたら、実際に張っている接続がユーザーが思っているホストと同一かを疑ってください。拡張や別タブが別ドメインへバックグラウンド接続しているだけ、ということは珍しくありません。

切り分けの実務的なコツは、問題再現中にだけログを取り、同一秒付近の行を時系列で並べることです。複数ホストが同時に 443 を開くと、ログが交錯して誤結合しやすいので、シークレットウィンドウで対象サイトのみ開く、他のダウンロードを止めるなど、ノイズを減らすのが有効です。

5. 設定の典型パターン（override-destination 含む）

Sniffer ブロックはプロファイルによって書き方が多少異なりますが、考え方は共通です。どのプロトコルを解析するか、解析結果で宛先を上書きするか（override-destination）、除外する CIDR やポート、の三つを確認します。override-destination: true は、 sniff したドメインを以降のルール評価に効かせやすくする一方、環境によっては期待と違うホストへ書き換わるので、ログで「書き換わった後の名前」まで見る習慣が大事です。逆にオフのままだと、実装次第ではSNI はログに出てもルール入力が IP のまま、というギャップが残ることがあります。手元のバージョンのドキュメントと、実際の debug 行を突き合わせてください。

次の例は構造イメージ用の断片です。キー名やネストは利用中のコア／テンプレートに合わせて読み替えてください。

# Example only — align keys with your mihomo / Clash Meta template
sniffer:
  enable: true
  override-destination: true
  sniff:
    TLS:
      ports: [443, 8443]
    HTTP:
      ports: [80, 8080-8880]
  skip-domain:
    - "+.push.apple.com"

6. ルール順・DNS・fake-ip・プロキシモードの落とし穴

Sniffer 以前に、ルールの上から順に最初の一致が勝つことを忘れると長時間迷います。典型は、広い GEOIP,CN,DIRECT や大きな IP-CIDR が先にあり、ドメイン指定が下に沈んでいるパターンです。HTTPS で IP 評価が先行すると、国内 CDN の IP に当たって DIRECT、という結果が出やすく、ユーザーから見ると「Sniffer を入れたのに直結する」に見えます。対策は、ログで実際にマッチしたルール名を特定し、優先度を入れ替えることです。自動選択系の策略の挙動は url-test / fallback の稿とも関連しますが、そもそもドメインルールに到達していない場合は、数値調整以前の問題です。

また DNS の fake-ip を使うプロファイルでは、アプリが見る IP と実サーバの関係が直感とズレやすく、Sniffer や nameserver-policy、fake-ip-filter の組み合わせが重要です。「名前は合っているのに挙動だけおかしい」ときは、DNS セクションとルールをセットで見直してください。さらに システムプロキシのみ／TUN の違いで、対象プロセスがプロキシチェーンに乗るかが変わります。ブラウザだけ問題が出るなら拡張や Secure DNS、別プロファイルの「プロキシ無効アプリ」なども疑います。

7. チェックリスト（上から順に潰す）

現場では次の順で潰すと迷いが減ります。すべてログの事実ベースで確認してください。

この表は万能の診断表ではありませんが、「SNI がログに存在するか」で二分すると、かなりのケースが次の一手に進めます。

8. まとめ

Clash Meta／mihomo で HTTPS の分流がおかしいとき、Sniffer は「ドメインルールに乗せるための前処理」です。ルール文章だけをいじっても、評価時点のキーが IP のままなら改善しません。debug ログで SNI の有無、最終マッチ、実アウトバウンドを一列に追えば、Sniffer 以前の問題（プロキシ経路）か、Sniffer 以降の問題（ルール順・DNS）かがはっきりします。ストリーミングや AI 系のようにドメインが散らばる用途では、この読み方がそのまま運用品質に効きます。

同種ツールのなかでも、Clash 系は表現力とログの粒度のバランスが取りやすく、「設定を増やしすぎずに観測できる」という意味で再現性が高い部類です。基本手順のおさらいは チュートリアル総覧にまとまっていますが、HTTPS の挙動は本稿のようにSNI とルール評価の接点から見るのが近道です。

まずは手元の環境でログを一度だけ丁寧に取り、ボトルネックを一つに絞ってから設定を変えるのが安全です。クライアントの入手と各プラットフォーム向け一覧は → 無料で Clash をダウンロードし、快適な接続体験を試す からどうぞ。