一、症状：スニッファと相性の悪い「厳格な HTTPS」
プロキシの外側で見ると、次のようなパターンは「スニッファまわり」の典型です。通常の海外サービスは問題ないのに、国内金融機関、マイナポータル等の政府系、社内ゼロトラストのブラウザゲート、二要素認証付き企業向けの管理画面だけで、例外なく TLS 周りの症状が出る。ブラウザでは「接続はプライバシーで保護されません」「NET::ERR_CERT_…」、あるいは何も出ずに回転だけが続き、アプリでは接続失敗や一定時間でタイムアウトになる。
同じ端末でClash だけ一時停止、またはスニッファだけオフにした瞬間に直る、という挙動が再現すれば、原因の探索範囲をルール行の抜けより先に、暗号化トラフィックに対するホスト名復元（スニッファ）とそれに追随する制御へ寄せられます。逆に、オフにしても治らなければ、TLS 全般やfake-ip・DNS チェーンへ進んでください。本稿は「スニッファONがトリガーに見える」軸に絞ります。
二、スニッファ層で何をしているか
スニッファは、すでに暗号化された通信に対し、TLS Client Hello などに含まれる SNI（接続先で提示するホスト名）等を手がかりに、コア内でドメイン名を推定し、ルール行（DOMAIN 系）と突き合わせやすくするための仕組みです。平文 Host がその時点で見えない接続（IP 直打ち、一部の仮想 IP 系の組み合わせなど）でも、とりあえず「通信はどのサイト相当か」を推定しようとする、というのが大枠の動機です。
一方、銀行・行政・一部の B2B 向けでは、中間者プロキシ前提の証明書検証を厳格に弾く、HTTP/2 や QUIC パスに独自前提がある、証明書ピン留めに近い挙動をクライアントが取る、といった要因が重なり得ます。スニッファが接続意図の上書き（override 系）や挙動互換性の角に触れると、他サイトでは目立たない違和感が、まさに「守りの厚い」サービス群だけに表出しやすい、というのが体感的な説明になります。実装とバージョンで細部は異なるため、以降は再現性のある対照で原因層を固定するのが実務的です。
三、まず区別：fake-ip・ノード不調と混同しない
同じ端末で dns.enhanced-mode: fake-ip を使っていると、スニッファと仮想 IPの症状が同時に出やすいです。切り分けのコツは、まず仮想 IP 特有の手順（fake-ip-filter、DNS 上流、専用の手順）を短時間で一度確認し、それでも「スニッファON／OFF だけ」で成否が分かれるなら、本稿の分域名のスキップに進む、という二段にすることです。ノードが弱いケースは多くのドメインで同時に遅延・切断が出やすいため、「特定カテゴリのサイトだけ」なら、ノード一括差し替えより層を疑う価値があります。
| 起きやすい見え方 | 先に疑う層 | 次の一歩 |
|---|---|---|
| 仮想 IP 帯にだけ依存して困る | fake-ip-filter / DNS チェーン | 専用記事の順に、filter と nameserver を確認 |
| 全般的に遅い・多サイトで失敗 | ノード、出口品質、ルール誤当て | 測速・策略グループ、ログの policy 行を確認 |
| 金融・官公庁等の HTTPS だけ、スニッファOFFで直る | スニッファ（嗅探）と TLS 層 | 以降の対照と skip-domain 系の除外 |
四、対照実験：一時的に止めて層を固定する
設定を一度に大きく動かすと、ログが再現性を失います。まず一変数として、スニッファ全体を一時的にオフにし、コア再読み込みまたはクライアント再起動のうえ、問題のURLだけ再試行します。症状が消えるなら、原因は高い確度で「スニッファ経路（またはスニッファに連動する上書き）」に含められます。戻しながら、TLS のポートだけに嗅探範囲を狭められるなら、まずはそこを試し、全面オンに戻す前に、除外ドメインを足す流れが安全です。
デスクトップGUIでは「自動スニッファ」がシステムプロキシ起動やTUNと結び付いていることがあり、YAML を直したのに挙動が古い、というのは古いフックやサービス残りが原因のことが多いです。スニッファ切り替えのあと、プロキシの無効化→再有効化、仮想アダプタの再起動、OS のネットワークスタック再取得まで含め、一度落ち着かせると、誤診断が減ります。
五、分域名：除外リストと設定の置き方
全面オフを避けたい場合は、問題の正規ホスト名（ログイン遷移先のサブドメイン、静的 CDN、API 用ホスト名も含め）をブラウザの開発者ツールのネットワーク欄で洗い、サフィックス単位に揃えて列挙します。Mihomo 系の典型的な枠では、sniffer 配下のスキップ用ドメイン（skip-domain など。実装・バージョンでキー名が微妙に異なることがあるので、手元のドキュメントを最優先）に、次のように足していく方法があります。
# Illustrative: align keys and nesting with your core version / docs
sniffer:
enable: true
# skip-domain 相当の欄（コア版で名称が異なる場合は読み替え）
skip-domain:
- "+.example-bank.co.jp"
- "+.portal.e-gov.go.jp"
override-destination: true # または UI の「上書き」に相当
sniff:
TLS:
ports: [443, 8443]
HTTP:
ports: [80, 8080-8880]上記の加算・キー名は例示です。実コアの最新ドキュメントに合わせ、マージ元の購読に同名ブロックが二重に入っていないかも要確認です。force-domain 等の積極的な嗅探指定と併用するプロファイルだと、除外リストの優先度が意図とズレることがあるため、同じ sniffer: ブロック内の優先順位を一度通読してください。
端末専用アプリ（銀行アプリ、マイナアプリ等）は、ブラウザと別ホストを叩いていることが多いです。失敗URLが取れない場合は、クライアントログで SNI 相当の行を探し、可能な限り +. 付きのサフィックスに寄せると保守が楽になります。例外を増やしすぎると、ルールと嗅探の整合が曖昧になるため、直ったドメインと理由を短くメモしておく習慣をお勧めします。
六、TUN・システムプロキシ・QUIC まわり
TUN モードでは、仮想 NIC 上でパケットが循環し、DNS ハイジャックやルートとスニッファの組み合わせが一層複雑になります。TUN 単体の切り分けは TUN 記事を参照しつつ、本題では「スニッファOFF かつ TUN そのまま」で解消するかを見ると、TUN 起因と嗅探起因の分離がしやすくなります。ブラウザの QUIC（HTTP/3）を一時的に切り、TCP のみで再現するかも、よく行う比較です。QUIC だけ落ちる場合は、嗅探の対象から外す、またはブラウジング時だけ無効化する、といった運用の現場剣もあります。
七、補足：金融・行政利用での安全運用
本稿は技術的な切り分け手順の共有であり、特定の金融機関・行政手続の利用可否を保証するものではありません。高リスク取引（振込、契約、個人情報の提出）の直前は、公式が案内する推奨環境（OS・ブラウザ、セキュリティソフト、VPN 可否）に合わせ、必要ならプロキシを完全に通さない手順を選ぶのが最も堅いです。スニッファの除外は、あくまで自宅や開発環境で通信を通すための一手段として位置づけ、セキュリティ方針は組織・サービス側の定めに従ってください。ソースコードの参照や課題の追跡は、公式のリポジトリを別途辿る形が一般的です。インストール媒体の主な入手先は、本サイトの配布ポリシーに沿います。
八、まとめ
Clash スニッファ（嗅探）を有効にした結果として、厳格な TLS を課すサービスにだけ HTTPS 不調が出ることは、実運用でそう珍しくありません。まず スニッファ一時停止の対照で原因層を固定し、分域名の除外へ落とし込み、fake-ip や ノード品質は別手順を当てに行く。そうすれば、購読全体を捨てずに局所直ししやすくなります。YAML の語彙はバージョンで揺れるので、ドキュメントでスニッファ欄の正式名称を確認しながら追記してください。
多機能クライアント同士の比較は、一長一短がありますが、ルール・DNS・スニッファを段階的に読み解ける体験は、更新の多い Clash 系の強みのひとつです。安定したバイナリとテンプレを手元に置いてから、ここで挙げた手順に沿ってログを一歩ずつ辿ると、迷いにくいです。