Clash Meta Sniffer を有効化したら HTTPS エラー？証明書スキップとドメイン除外で段階的に修正する

Sniffer が解決する問題

redir-host モードや一部の TUN 環境では、接続がカーネル内で最初に「宛先 IP」として現れることがあります。ルールが DOMAIN / DOMAIN-SUFFIX に多く依存している場合、ホスト名なしでは正しいポリシーにヒットしにくくなります。Sniffer を有効にすると、コアが早期に TLS トラフィックからドメインのヒントを取り出し、IP だけで推測するのではなく実際にアクセスしているサイトに基づいてルールエンジンが判断できるようになります。

これは「HTTPS を中間者解読する」のとは別物です。標準の Sniffer が読み取るのはハンドシェイクのメタデータであり、アプリケーション層の平文ではありません。そのため、ブラウザが証明書とドメインが一致しない・証明書チェーンが無効と報告する場合は、「スニッフィングとルーティング書き換えの副作用」なのか、「上流ノード・システム時刻・サブスクリプション TLS・または対象サイト自体の問題」なのか、区別して考える必要があります。

典型的な症状：Sniffer 起因かを見分ける

ルールを変更する前に「トグル比較」を行うことを推奨します。同一ノード・同一分流のまま、sniffer.enable または GUI のスニッフィングスイッチだけを切り替えて確認します。

• 一部のドメインのみエラーになり、他のサイトは正常。Sniffer を無効にするとすぐ回復する。
• 銀行・行政・企業 VPN・一部のアプリがプロキシ環境下で突然ログインできなくなり、ログに TLS 関連の失敗や繰り返しの再試行が見える。
• fake-ip 使用中にルールがドメインマッチングに依存しているとき、Sniffer を有効にした後ポリシーヒットがずれる（本来直結すべきものがプロキシに乗る、またはその逆）という現象が、偶発的な証明書警告を伴って起きる。
• override-destination を有効にした後に問題が急増した場合——「宛先書き換え」が対象アプリの期待と一致していないことを示しています。

Sniffer を無効にしても問題が続く場合は、まず 「接続中なのに繋がらない？DNS と fake-ip」 の流れを参照してください。dns.enhanced-mode・nameserver と fallback・システムやブラウザの DoH がカーネル DNS を迂回していないかを確認します。

ステップ 1：スニッフィング除外（skip-domain）

最も安定した修正方法は、Sniffer をグローバルに無効にすることではなく、既知の問題があるドメインをスニッフィング除外リストに追加して、その接続が（カーネルのドキュメントの意味合いで）スニッフィングロジックに参加しないようにすることです。GUI クライアントでは「スニッフィングをスキップするドメイン」「Sniffer 除外」などの表記で表示されることがあり、設定上は多くの場合 skip-domain リストに対応しています。

記法として後方一致がよく使われており、+.example.com のようにサブドメインを網羅できます。通具体的なワイルドカードルールは使用している Mihomo バージョンのドキュメントを参照してください。以下は構成イメージです。実際の YAML のマージ位置やインデントに合わせて調整してください：

# Illustrative sniffer block — align with your Mihomo version docs
sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443]
    QUIC:
      ports: [443]
  skip-domain:
    - '+.bank.example'
    - '+.internal.corp'
  force-dns-mapping: true
  parse-pure-ip: false
  override-destination: false

実践上の注意：一度に長大なリストをコピーしないでください。まず接続ログで異常サイトの正確なホスト名を特定し、1〜3 個のドメインを追加するたびに設定をリロードして再検証する——そのサイクルを繰り返すのが確実です。安定したら、サブスクリプションやテンプレートに含まれるデフォルトの除外項目と統合するかどうかを検討します。

override-destination と fake-ip の連携

override-destination: true を設定すると、カーネルがスニッフィングで取得したドメイン情報を使って接続先を書き換えるようになります。複雑な CDN や複数証明書のシナリオでは分流精度が向上することがありますが、「クライアントが IP や特定の証明書 SAN を期待しているのに、実際の通信経路が別のパスに誘導された」という不整合が起きやすくもなります。このオプションを有効にした直後に問題が集中した場合は、まず false に戻してベースラインが回復するか確認してから、個々のポリシーグループでより細かいドメインルールが必要かどうかを個別に評価します。

fake-ip と Sniffer はいずれも「ドメインレベルのルール」を機能させるためのものですが、組み合わせが適切でないと解決フェーズと接続フェーズが一致しないわかりにくい状況が生まれます。同サイトの DNS 専門記事と合わせて、一度に一つの変数だけ変更する原則を徹底してください——まず DNS モードと nameserver を固定した上で Sniffer を動かすか、Sniffer をオフにして DNS を検証してから Sniffer をオンにして除外を追加する、という順序が安全です。

「証明書検証スキップ」が必要な場面

コミュニティでは skip-cert-verify を万能の解決策として扱うことがありますが、これはほぼ常にプロキシ出口（プロキシノードへの接続）の TLS 検証に作用するものであり、Sniffer 由来の業務サイト証明書エラーの代替修正手段ではありません。true に設定することは、クライアントがノードとの間の経路の証明書を厳密に検証しなくなることを意味し、ハイジャックや偽の出口へ誤接続するリスクが大幅に高まります。これは短期的な障害調査や完全に信頼できる閉域環境でのみ適切です。

より健全な順序は次の通りです：まず証明書チェーンが完全なノードまたはポートに切り替える；次に本機のシステム時刻を確認する；企業のセキュリティソフトが TLS を途中で遮断していないか確認する；最後に一つのプロキシエントリだけで一時的に skip-cert-verify: true を有効にして推測を検証する。グローバルテンプレートでこのオプションを広めないでください。

GUI クライアントでの設定

Clash Verge、OpenClash、各 Windows フロントエンドでは Sniffer の露出レベルが異なります。スニッフィングの全体スイッチ・TLS / QUIC ポート・スキップリストが提供されるものもあれば、生の設定ファイルを直接編集する必要があるものもあります。どの入り口を使う場合でも、単一の情報源を維持してください——「上書き YAML」と「サブスクリプションマージフラグメント」の両方に sniffer を重複定義すると、意図しない順序で上書きされる可能性があります。

TUN や Meta カーネルを使い始めたばかりの場合は、まず 「Clash for Windows インストールと設定」 または 「Clash Verge Rev macOS 初回設定」 のベースラインを完了させてから Sniffer を追加することをお勧めします。そうしないと「ドライバ / 権限の問題」をスニッフィングの問題と誤って判断してしまうことがあります。

設定ファイルを直接編集する場合の一般的な注意点として、sniffer ブロックはトップレベルのキーとして配置し、dns ブロックや rules リストと並列に置くことが多いです。サブスクリプションから取り込んだ設定と自前の設定をマージする際は、後から書かれた方が優先されるケースと前者が保持されるケースがツールによって異なるため、実際に反映されているかをログで確認する習慣をつけると安心です。

よくある質問

Sniffer を有効にしたらほぼ全ての HTTPS が赤くなった

これはグローバルなネットワーク問題・システム時刻のずれ・またはサブスクリプションのノード TLS 問題である可能性が高いです。まず Sniffer を無効にして比較してください。無効にしても全て赤い場合は、ノードの疎通とポートを確認し、ローカルのセキュリティソフトによる HTTPS スキャンを排除してください。

特定のアプリだけ繋がらず、ブラウザは正常

証明書ピンニングまたはアプリ独自の検証である可能性が高いです。そのアプリに関連するドメインに skip-domain を適用するか、そのアプリのトラフィックを DIRECT にしてスニッフィングスタックを迂回させてください（ルール機能に応じた対応方法で選択してください）。

HTTP/3 / QUIC の異常

QUIC スニッフィングを設定している場合は、TLS ブランチと個別に比較検討してください。ネットワーク環境によっては UDP 443 が帯域制限またはブロックされており、「証明書エラー」に似た見た目でハンドシェイクが完了しないケースがあります。

銀行・決済アプリが代理接続で繋がらない

金融系アプリの多くは証明書ピンニングを実装しており、スニッフィングによる接続先の変化に敏感です。これらのアプリのドメインを skip-domain に追加するか、当該アプリのトラフィックを DIRECT ルートに振り分けることで解決できるケースがほとんどです。複数の証明書ホスト名が混在するアプリでは、サブドメイン全体を +.domain.com 形式でまとめて除外すると効率的です。

実践チェックリスト

スニッフィング対象プロトコルの絞り込み

症状がプロトコル特性（TLS か QUIC か）によって偏っている場合は、スニッフィング対象を絞り込むことも有効な選択肢です。例えば QUIC 由来の問題が疑われる場合は、sniff ブロックから QUIC エントリを外して TLS のみに留め、動作が安定するか確認します。反対に TLS を外すと SNI 情報が取れなくなり分流精度が落ちるため、基本は TLS を残したまま QUIC だけ切り離す方向で試すのが無難です。

また、parse-pure-ip: false を設定すると「IP 直打ちアクセス（SNI が取れないケース）」に対してスニッフィングを適用しなくなります。この設定により、SNI を取れない接続が余計な書き換えを受けることを防げます。デフォルト値とバージョンによる差異があるため、使用する Mihomo のリリースノートで挙動を確認してください。

# Illustrative — TLS only, QUIC disabled
sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443, 8443]
  parse-pure-ip: false
  override-destination: false

メンテしやすいクライアントで複雑さを抑える

Sniffer は Meta 系カーネルの進んだ機能です。ドメイン分流の命中率を大幅に改善できる一方、少数の非互換な対象のために小さく明確な除外リストを維持する価値もあります。「スニッフィングスイッチ・除外リスト・DNS モード」を自分の設定メモに書き留めておけば、カーネルをアップグレードしたり GUI を変更したりした際にも素早く元の状態に戻せます。

Clash を無料ダウンロードして、快適な接続体験を始めよう