这类症状,适合先读本文
仪表盘里延迟测试能通过,聊天和视频也正常,偏偏某几个网站永远转圈、白屏,或者很久才报连接超时——用 Clash 系客户端(内核多为 Mihomo / Clash Meta)时,这种「只有一部分不对劲」的现象并不少见。它很少是单一开关坏了,而往往是域名解析走的路径、从 TLS / HTTP 里还原主机名的 Sniffer(嗅探),以及规则与策略组的先后顺序叠在一起的结果。
本文先说明 dns 里 enhanced-mode 常见的两种取值:Fake-IP 与 Redir-Host 各自解决什么问题、在什么情况下容易踩坑;再给你一棵从上到下的故障树,按顺序回答:该不该关 Sniffer、该不该换 DNS 模式、该不该动规则。更偏「防泄漏与上游设计」的整体思路,可配合《Clash DNS 防泄漏配置指南》阅读;若日志里大量是端口或拨号超时,而不是解析异常,请先对照《从日志判断端口占用还是节点超时》,避免在 DNS 上空转。
DNS 模式:Fake-IP 和 Redir-Host 到底差在哪
在 Mihomo 中,通常需要 dns.enable: true,并用 enhanced-mode 控制「规则引擎看到域名与 IP 的对应关系」的时机。名字听起来抽象,可以换成用户更好理解的说法。
Fake-IP(返回虚拟地址)
应用向系统查询域名时,往往先拿到一段内核分配的虚拟 IP,真正建立连接时再在代理内核里完成真实解析与策略匹配。这样写域名类规则时思路很顺,首包体感也常常更「跟手」。代价是:若 fake-ip-filter(或等价配置)里该进名单的域名没进、不该进的误进,会让「何时拿到真 IP、何时按哪条规则走」出现偏差,表现为只有特定站点异常。局域网主机名、门户认证页、部分依赖真实解析顺序的应用、以及少数金融或企业域名,社区里经常建议放进过滤列表做对照,具体仍以你当前内核文档为准。
Redir-Host(更贴近「先解析再连」)
这一侧更接近传统模型:在上游 DNS 得到的结果会更多地参与后续逻辑,调试时「我在解析阶段看到什么」往往更直观。部分老旧客户端或强校验目标 IP 的链路,有时和 Redir-Host 更合拍。但解析结果更容易暴露在「你信任哪一家上游、是否要走加密 DNS、fallback 何时触发」这些问题上,需要和整体 DNS 段、分流意图一起看;单独把模式改成 Redir-Host 却不调整上游,有时只是把问题挪了个位置。
配置里长什么样(示意)
下面是一段仅用于对照键名与层级的示意,请勿不加思考整段照抄为生产配置;上游地址、过滤列表与策略组名请按你的订阅与网络环境替换。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://dns.example/dns-query
fake-ip-filter:
- '+.lan'
- '+.local'
把 enhanced-mode 改为 redir-host 时,请同时关注 nameserver、fallback 与 nameserver-policy(或你所用版本中的等价项)是否仍合理;大版本迁移时字段可能有变,可先浏览《Clash Meta(Mihomo)升级指南》,避免沿用已废弃写法却以为「DNS 已生效」。
故障树:请从上到下、每次只改一项
下列顺序在真实反馈里复现率较高。请不要一次性改五个地方,否则无法判断是哪一步起了作用。
- 步骤 1:锁定范围。同一 URL 换浏览器、无痕窗口、另一台设备各试一次。若几乎所有站点都挂,优先怀疑节点、本机端口、系统网络或安全软件;若只有个别域名,优先怀疑 DNS 模式、Sniffer、域名规则与策略组。
- 步骤 2:系统与浏览器的「第二套 DNS」。操作系统是否仍指向路由器或运营商 DNS;Chrome/Edge 等是否另开了「安全 DNS / DNS over HTTPS」。这些若与 Clash 虚拟栈不同步,会出现「内核以为接管了,应用却在别处解析」的错位。
- 步骤 3:Sniffer 对照实验。在 Fake-IP 场景下,Sniffer 通过 TLS SNI、HTTP Host 等还原主机名以辅助规则匹配,能救场也能误判:例如非典型 TLS、拆分握手、或中间设备改写握手时,错误的名字会让流量落到
DIRECT或错误的策略组,看起来像「连上了但页面永远不出来」。可先整体关闭 Sniffer 或收窄嗅探范围,再试同一站点是否恢复。 - 步骤 4:
fake-ip-filter与域名规则。将问题域名加入过滤,或把DOMAIN/DOMAIN-SUFFIX规则提前到更具体、更靠前的位置。若规则大量依赖IP-CIDR且匹配顺序与 Fake-IP 阶段不一致,也可能出现「规则写的是代理,实际却按另一张地图走了」的错位感。 - 步骤 5:切换
enhanced-mode。若以上对照仍无解,可临时改为redir-host做 A/B:若明显好转,说明问题多半出在 Fake-IP 与 Sniffer / 过滤 / 规则的组合;若仍一样,则更可能在上游 DNS、节点路径或应用自身。 - 步骤 6:TUN 与 DNS 劫持。仅系统代理时,不少应用会绕过;开启 TUN 并在文档允许范围内配置
dns-hijack一类选项,有助于把查询收束到内核。同时确认 Windows 管理员权限、macOS 网络扩展授权等前置条件已满足,否则「以为开了 TUN」实际并未生效。
若此时日志里仍是大量 dial tcp 超时、握手失败或端口占用提示,请回到日志专题从关键词入手,而不是继续在 DNS 面板里反复横跳。
Sniffer:什么时候该怀疑它
Fake-IP 模式下,连接刚建立时,规则引擎内部的「域名—连接」对应关系未必与应用程序对外表现完全一致,Sniffer 的作用是在这里补一手信息。对常见浏览器访问的 HTTPS 站点,这往往很省事;但一旦嗅探得到的 host 与真实业务域名不一致,就会出现策略匹配对了名字、却错了连接的诡异状态:状态栏可能显示正在连接,文档树却一直是空的,或长时间 pending。
实务上可以按三步缩小范围:先完全关闭 Sniffer 试复现;再仅对需要的协议或目标开启;最后对问题域名用明确的域名规则钉死到正确策略组。若你所在环境出于合规不能长期开启 Sniffer,从一开始就更偏向 Redir-Host 并做好上游 DNS 与分流对齐,有时是更省心的架构选择。
规则与策略:别急着把模式换来换去
在动 enhanced-mode 之前,建议先核对三件事,否则容易陷入「两个模式都试过了还是不行」的疲劳战。
- 规则顺序:更具体的域名规则是否压在过于宽泛的地理类规则或最终的
MATCH之上;远程规则集更新后是否意外改变了顺序。 - 策略组里选中的节点:同一节点在测速工具里可用,并不代表它对目标站点的路径也健康;必要时对问题域名单独建组做对照。
- DNS 决策与分流语义是否一致:连接走代理,解析却长期落在直连 DNS 上,会在 Fake-IP / Redir-Host 下以不同面目暴露出来;需要把
dns段与rules放在同一张「意图地图」上设计。维护大列表时可结合《Rule Providers 进阶指南》,避免主配置文件无限膨胀、难以 diff。
规则提供者与 GeoIP 数据若过旧,也可能把流量误判到错误区域;定期更新订阅与数据文件,和改 DNS 模式一样,都是低成本却常被忽略的步骤。
什么时候更倾向 Redir-Host
若你观察到以下信号,可以把「试用 Redir-Host」列入候选:关闭 Sniffer 后明显稳定,而开启后仅少数站点异常;fake-ip-filter 需要堆很长的例外列表才能维持日常应用;企业内网或老旧 HTTP 客户端与 Fake-IP 明显不兼容;安全软件深度检查 TLS,导致基于 SNI 的推断不可靠。反之,若你更在意规则可读性与延迟表现,并愿意精细维护过滤列表与 Sniffer 范围,Fake-IP 仍然是大量用户的主流选择。
无论选哪边,都建议把复现 URL、一次只改一个变量、以及对应日志片段记下来;这样在论坛或 Issue 里描述问题时,别人也更容易给出针对性建议,而不是让你「换个节点试试」式地盲试。
合规说明
本文仅讨论开源代理客户端在合法合规场景下的通用技术原理与排障思路,不构成对任何地区法律法规的规避指引。请在你所在地法律允许的范围内使用网络技术,并遵守服务条款与他人权益。
小结
「能连上节点却部分网页打不开」这类问题,把层次拆成 DNS enhanced-mode(Fake-IP / Redir-Host)、Sniffer 与 规则 / 策略组 后,路径会清晰很多:Fake-IP 好用但吃配置细节,Redir-Host 直观但更依赖上游与整体 DNS 设计。按本文故障树从上到下做对照实验,你通常能判断当前是该关嗅探、补过滤与域名规则,还是暂时切换模式配合 TUN 收束查询。
相比在碎片帖子里反复试错,一款与 Mihomo 同步迭代、面板能把 DNS 与规则关系讲清楚的 Clash 客户端,往往能把试错成本压得更低。若你准备在手边环境认真跑一遍上述步骤,可先前往本站下载页获取对应系统的安装包,小流量验证通过后再逐步加规则与订阅。→ 立即免费下载 Clash,开启流畅上网新体验