Clash Sniffer 嗅探无效?mihomo 流媒体域名识别与规则修正步骤
典型现象:Sniffer 开了,流媒体仍「不认域名」
你在基于 mihomo(Clash Meta)的客户端里打开了 Sniffer(嗅探),期望长视频、音乐或海外应用能像教程里写的那样,按 DOMAIN-SUFFIX 命中独立策略组。实际却是:连接日志里大量仍是纯 IP,或者明明写了 netflix.com 一类规则,流量却进了 DIRECT 与 漏网之鱼。这类问题很少是「嗅探模块坏了」,更多是嗅探结果有没有参与路由决策、以及规则与 DNS 谁先拍板没有对齐。
本文按真实排障顺序展开:① 嗅探是否对该协议/端口生效 → ② 是否启用 override destination 用嗅探域名改写目的地址 → ③ 规则表顺序是否把流媒体规则挡在后面 → ④ DNS 模式(尤其 fake-ip)下解析与元数据是否一致。文中 YAML 可直接粘贴到配置中再按环境微调。若你尚未理清分流规则写法,可先读 Clash 规则分流详解;需要透明代理总览可对照 Clash TUN 模式指南。
先理解:嗅探解决的是「目的地址只有 IP」时的域名恢复
在 TUN 或部分系统代理场景下,内核或本地栈交给内核/代理的可能是「发往某公网 IP 的 TLS 流」,此时路由模块最初看到的 destination 只是 IP,无法直接做 DOMAIN / DOMAIN-SUFFIX 匹配。mihomo 的 Sniffer 会在允许的前提下解析 TLS Client Hello 中的 SNI 或明文 HTTP Host,从而恢复出一个主机名。
关键点在于:恢复出域名 ≠ 自动用于规则匹配。是否用嗅探到的名字覆盖当前连接的目的信息,由配置项(如 override-destination)决定;若关闭覆盖,日志里你也许能「看到」域名,但策略仍按 IP 路径走,表现就像「嗅探无效」。另外,若连接走的不是常见 HTTPS 端口、或被 skip-domain / 跳过列表提前排除,嗅探也不会介入。
第一步:核对 sniffer 段——开关、端口与 override
在配置根级增加或检查 sniffer: 段(具体键名以你所用内核版本文档为准;以下为 mihomo 常见写法骨架)。确保 enable: true,并为 TLS 与 HTTP 声明需要嗅探的端口;流媒体 App 绝大多数走 443/TLS,少数调试或明文接口可能在 80。
sniffer:
enable: true
override-destination: true
sniff:
TLS:
ports: [443, 8443]
HTTP:
ports: [80, 8080-8880]
skip-domain:
- '+.push.apple.com'
请把根级的 override-destination: true 视作本主题的核心开关之一(具体层级以当前 mihomo 文档为准):它表示在嗅探成功时,用嗅探得到的主机名参与后续规则与转发决策。若你仅开启嗅探却将该项设为 false,很容易出现「有 SNI 信息但仍按 IP 规则走」的错觉。若客户端图形界面有等价选项(名称可能写作「使用嗅探结果覆盖目标地址」之类),请与 YAML 保持一致。
force-domain 与 skip-domain 用于细调:对某些域强制嗅探、或对已知会误伤的域跳过。流媒体排错时,若你发现某 CDN 子域反复嗅探失败,可先在日志确认是否被 skip 列表命中,再考虑缩小跳过范围。
第二步:规则优先级——DOMAIN-SUFFIX 要放在真正生效之前
mihomo 按 rules 列表自上而下匹配,先命中先执行。常见错误是:前面存在宽泛的 GEOIP、IP-CIDR 或一条粗粒度的 MATCH,导致流媒体相关连接在「轮到域名规则」之前就已经定了策略。尤其当嗅探尚未改写目的地址时,连接会以 IP 形式命中 GEOIP,CN 等规则,表现即为国内直连,与你在后面写的 DOMAIN-SUFFIX,netflix.com 无关。
处理方式是:把确定的流媒体域名规则(含你从官方文档或抓包整理的 DOMAIN-SUFFIX / DOMAIN-KEYWORD)移到 GEOIP 与过宽 IP 规则之前。示例(策略组名请换成你的):
rules:
- DOMAIN-SUFFIX,netflix.com,STREAMING
- DOMAIN-SUFFIX,nflxvideo.net,STREAMING
- DOMAIN-SUFFIX,spotify.com,STREAMING
- GEOIP,CN,DIRECT
- MATCH,PROXY
同一原则适用于「国内直连 + 国外代理」模板:凡是依赖域名识别的站点,都要保证在「按 IP 分国内外」之前有机会匹配。更多策略组与写法可参考 Disney+ 流媒体分流实测 中的置顶思路,把 Netflix、Spotify 等换成你实际使用的列表即可。
第三步: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。
排查清单(建议按顺序打勾)
- 嗅探总开关是否为
enable: true,且 TLS/HTTP 端口覆盖你观察到的流量端口。 - 根级是否设置 override-destination: true(或 GUI 等价项),确保嗅探域名参与规则匹配。
- skip-domain / 跳过列表是否误伤目标流媒体域;必要时临时注释缩小范围做对比测试。
- rules 顺序:流媒体
DOMAIN-SUFFIX是否位于过宽的 IP/GEOIP/MATCH 规则之前。 - DNS:
fake-ip与fake-ip-filter是否与嗅探、规则联动符合预期;必要时在日志中对比「解析结果」与「嗅探主机名」。 - 若仅用系统代理、未开 TUN,确认应用流量确实进入 mihomo;部分应用会绕过系统代理,此时嗅探根本收不到流。
合规提示:请在你所在地法律与服务条款允许的前提下使用代理与访问流媒体内容;本文仅讨论客户端网络行为与配置排错,不构成对任何受地域限制服务的规避建议。
小结
Clash Sniffer 在 mihomo 中的价值,是把「只有 IP 的连接」还原成可匹配域名的元数据;要让 DOMAIN-SUFFIX 与流媒体策略组真正生效,必须同时打开改写目的地址、并把域名规则放在 IP 类规则之前,再配合 fake-ip 与 DNS 统一认知。按本文顺序逐项核对后,多数「嗅探开了却像没开」的案例都能定位到配置层而非内核故障。若你希望在一套图形客户端里统一管理订阅、嗅探与 TUN,可从本站 下载页面 选择适合你系统的版本。→ 立即免费下载 Clash,开启流畅上网新体验
若节点延迟测试异常或 DNS/UDP 现象与本文交织,可对照 Clash 节点全红与 DNS/UDP 排障;订阅与导入问题请参考 Clash 订阅导入教程。