Clash Sniffer 嗅探无效？mihomo 流媒体域名识别与规则修正流程

典型现象：Sniffer 开了，流媒体仍「不认域名」 一文看懂

文中 YAML 可干脆粘贴到配置中再按环境微调。若你尚未理清分流规则写法，可先读 Clash 规则分流详解；得透明代理总览可对照 Clash TUN 模式指南。

你在基于 mihomo（Clash Meta）的客户端里开启了 Sniffer（嗅探），期望长视频、音乐或海外应用能像指引里写的那样，按 DOMAIN-SUFFIX 命中独立策略组。

实际却是：连接日志里大批仍是纯 IP，或者明明写了 netflix.com 一类规则，流量却进了 DIRECT 与 漏网之鱼。这类难点很少是「嗅探模块坏了」，更多是嗅探结果有没有参与路由决策、以及规则与 DNS 谁先拍板没有对齐。

先看这一点：这篇文章按真实排障顺序展开：① 嗅探是否对该协议/端口生效 → ② 是否启用 override destination 用嗅探域名改写目的地址 → ③ 规则表顺序是否把流媒体规则挡在后面 → ④ DNS 模式（尤其 fake-ip）下解析与元数据是否一致。

先理解：嗅探处理的是「目的地址只有 IP」时的域名恢复 核心要点

关键点在于：恢复出域名 ≠ 无人值守用于规则匹配。是否用嗅探到的名字覆盖当前连接的目的信息，由配置项（如 override-destination）决定；若关闭覆盖，日志里你也许能「看到」域名，但策略仍按 IP 路径走，表现就像「嗅探无效」。另外，若连接走的不是高频 HTTPS 端口、或被 skip-domain / 跳过列表提前排除，嗅探也不会介入。

在 TUN 或部分系统代理状态下，内核或本地栈交给内核/代理的也许是「发往某公网 IP 的 TLS 流」，此时路由模块最初看到的 destination 只是 IP，无法干脆做 DOMAIN / DOMAIN-SUFFIX 匹配。

mihomo 的 Sniffer 会在允许的前提条件条件条件下解析 TLS Client Hello 中的 SNI 或明文 HTTP Host，从而恢复出一个主机名。

第一气：核对 sniffer 段——开关、端口与 override 逐条拆解

force-domain 与 skip-domain 用于细调：对某些域强制嗅探、或对已知会误伤的域跳过。流媒体排错时，若你发现某 CDN 子域反复嗅探不成功，可先在日志确认是否被 skip 列表命中，再考虑缩小跳过范围。

sniffer:
  enable: true
  override-destination: true
  sniff:
    TLS:
      ports: [443, 8443]
    HTTP:
      ports: [80, 8080-8880]
  skip-domain:
    - '+.push.apple.com'

补充说明：在配置根级增加或核对 sniffer: 段（具体键名以你所用内核版这篇文章档为准；以下为 mihomo 高频写法骨架）。确保 enable: true，并为 TLS 与 HTTP 声明得嗅探的端口；流媒体 App 绝多数数走 443/TLS，少数调试或明文接口也许在 80。

请把根级的 override-destination: true 视作本主题的核心开关之一（具体层级以当前 mihomo 文档为准）：它表示在嗅探成功时，用嗅探得到的主机名参与后续规则与转发决策。

若你仅开启嗅探却将该项设为 false，很容易出现「有 SNI 信息但仍按 IP 规则走」的错觉。若客户端图形操作操作操作界面有等价条目（名称也许写作「运用嗅探结果覆盖目标地址」之类），请与 YAML 保持一致。

第二步：规则首位级——DOMAIN-SUFFIX 要放在真正生效之前 底层逻辑

同一原则适用于「国内直连 + 国外代理」模板：凡是依赖域名识别的站点，都要保证在「按 IP 分国内外」之前有机会匹配。更多策略组与写法可参考 Disney+ 流媒体分流实测 中的置顶思路，把 Netflix、Spotify 等换成你实际运用的列表即可。

换个角度：mihomo 按 rules 列表自上而下匹配，先命中先执行。高频失误是：前面存在宽泛的 GEOIP、IP-CIDR 或一条粗粒度的 MATCH，导致流媒体相关连接在「轮到域名规则」之前就已经定了策略。尤其当嗅探尚未改写目的地址时，连接会以 IP 形式命中 GEOIP,CN 等规则，表现即为国内直连，与你在后面写的 DOMAIN-SUFFIX,netflix.com 无关。

rules:
  - DOMAIN-SUFFIX,netflix.com,STREAMING
  - DOMAIN-SUFFIX,nflxvideo.net,STREAMING
  - DOMAIN-SUFFIX,spotify.com,STREAMING
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

处理方式是：把确定的流媒体域名规则（含你从官方文档或抓包整理的 DOMAIN-SUFFIX / DOMAIN-KEYWORD）移到 GEOIP 与过宽 IP 规则之前。示例（策略组名请换成你的）：

第三步：DNS 模式与 fake-ip——和嗅探一起读 一文看懂

运用 fake-ip 时，本地 DNS 模块也许对部分查询返回虚假 IP，连接初始目的地址通常是 fake-ip 池中的地址；此时更依赖 Sniffer 从 TLS 还原真实域名去做规则匹配。若 DNS 配置中把某些域指向了失误模式、或 redir-host 与 fake-ip 混用策略不一致，也许出现「解析层以为是一个域、连接层却是另一条路径」的错位。

推荐逐项确认：① dns: 下 enhanced-mode（或等价项）是否为 fake-ip；② fake-ip-filter 是否误把流媒体相关域放进「不返回 fake-ip」列表，导致行为与预期不符；③ 若开启 prefer-h3、nameserver-policy 等，是否对特定后缀走了异常上游，进而影响连接建立时机。嗅探与 DNS 是上下游关系：DNS 负责「名字到地址」的本地策略，嗅探负责「在只有 IP 流时还原名字」；两者需与规则层同一套域名认知，否则你会在日志里看到矛盾信息。

可复制：流媒体策略组与嗅探联用骨架 核心要点

下面是一段将 STREAMING 策略组与嗅探、规则前缀结合的最小骨架（节点与订阅请自行衔接）。要点仍是：sniffer 开启 override + 流媒体规则前置。

proxy-groups:
  - name: STREAMING
    type: select
    proxies:
      - 你的节点组

sniffer:
  enable: true
  override-destination: true
  sniff:
    TLS:
      ports: [443]

rules:
  - DOMAIN-SUFFIX,youtube.com,STREAMING
  - DOMAIN-SUFFIX,googlevideo.com,STREAMING
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

具体来说：实战时请按 App 实际连通域名增补后缀（众多服务会运用多家 CDN，单一后缀不够）。可先在客户端连接日志中过滤目标域名或 IP，再反查应写入的 DOMAIN-SUFFIX。

排查清单（推荐按顺序打勾） 逐条拆解

  1. 嗅探总开关是否为 enable: true，且 TLS/HTTP 端口覆盖你观察到的流量端口。
  2. 根级是否设置 override-destination: true（或 GUI 等价项），确保嗅探域名参与规则匹配。
  3. skip-domain / 跳过列表是否误伤目标流媒体域；必要时临时注释缩小范围做对比测试。
  4. rules 顺序：流媒体 DOMAIN-SUFFIX 是否位于过宽的 IP/GEOIP/MATCH 规则之前。
  5. DNS：fake-ip 与 fake-ip-filter 是否与嗅探、规则联动符合预期；必要时在日志中对比「解析结果」与「嗅探主机名」。
  6. 若仅用系统代理、未开 TUN，确认应用流量确实进入 mihomo；部分应用会绕过系统代理，此时嗅探根本收不到流。

合规提示：请在你所在地法律与服务条款允许的前提条件条件下运用代理与连通流媒体素材；这篇文章仅讨论客户端网络行为与配置排错，不构成对无论哪种受地域限制服务的规避推荐。

小结 底层逻辑

Clash Sniffer 在 mihomo 中的价值，是把「只有 IP 的连接」还原成可匹配域名的元数据；要让 DOMAIN-SUFFIX 与流媒体策略组真正生效，必须同时开启改写目的地址、并把域名规则放在 IP 类规则之前，再配合 fake-ip 与 DNS 统一认知。

按这篇文章顺序逐项核对后，多数「嗅探开了却像没开」的案例都能定位到配置层而非内核故障。若你希望在一套图形客户端里统一管理订阅、嗅探与 TUN，可从本站 下载页面 挑选适合你系统的版本。→ 立即免费下载 Clash，开启流畅上网新运用感受

若节点时延测试异常或 DNS/UDP 现象与这篇文章交织，可对照 Clash 节点全红与 DNS/UDP 排障；订阅与引入难点请参考 Clash 订阅引入指引。