Clash Verge Rev 在 macOS 怎么设置 Fake-IP DNS?
如果你在 macOS 上使用 Clash Verge Rev,却不知道 Fake-IP DNS 应该在哪里开启,本文将从配置文件选择到参数保存逐步说明。完成设置后,你可以更稳定地使用域名分流,并通过测试确认 DNS 模式是否真正生效。
Fake-IP DNS 是什么
在 macOS 上使用 Clash Verge Rev 时,Fake-IP DNS 并不是 macOS「网络」设置里的一个普通开关,而是 mihomo 内核在配置文件中提供的 DNS 增强模式。开启后,Clash 收到应用发起的域名查询时,不会立即把真实 IP 返回给应用,而是从专用地址段中分配一个假地址,例如 198.18.0.0/16 内的地址。应用随后连接这个假地址,mihomo 再根据内部映射找回原始域名,并按照域名规则决定直连还是代理。
这种机制的价值在于,域名信息可以在连接进入 Clash 后参与分流。即使目标服务器的真实 IP 还没有返回到本机,DOMAIN-SUFFIX、GEOSITE 等域名规则仍然可以先匹配。对于需要按域名区分国内外流量的配置,Fake-IP 往往比传统的 redir-host 更容易保持规则命中,也能减少应用直接使用系统 DNS 查询真实域名的机会。
不过,Fake-IP 不等于自动接管 macOS 上的所有 DNS。Clash Verge Rev 仍然需要运行 DNS 模块,并通过系统代理或 TUN 模式让查询进入 Clash。只在配置里写入 enhanced-mode: fake-ip,但没有选中这份配置、没有启用 DNS,或者应用绕过系统代理自行联网,最终都可能看不到预期效果。
先确认内核类型
本文以 Clash Verge Rev 搭配 mihomo 内核为前提。打开客户端的内核信息或关于页面,确认当前使用的是 mihomo,再编辑配置文件。原版 Clash 对部分 mihomo 字段并不兼容,直接套用配置可能导致加载失败或字段被忽略。
设置前的准备工作
修改 DNS 之前,先准备一份可以正常加载的订阅配置,并保留原始配置副本。Clash Verge Rev 的配置通常来自订阅链接,客户端可能在更新订阅时重新生成配置。如果直接修改自动更新的原文件,下一次更新后手动添加的 DNS 段可能被覆盖,导致 Fake-IP 看起来「突然失效」。
- 确认订阅已经成功加载。在配置列表中选择当前使用的配置,确保代理节点和策略组可以正常显示。空配置、过期订阅或 YAML 语法错误都应该先处理。
- 复制一份配置用于测试。可以在配置页面复制当前配置,或先把原文件保存到其他位置。测试配置命名为「macOS-Fake-IP」之类的短名称,出现问题时方便切回原配置。
- 确认没有其他 VPN 或代理工具抢占 DNS。Little Snitch、其他 TUN 软件、浏览器独立代理以及系统级 VPN 都可能改变路由和解析结果,排查时尽量只保留 Clash Verge Rev。
- 记录当前状态。记下当前是否开启系统代理、TUN、IPv6,以及浏览器的安全 DNS 状态。修改后逐项对照,才能知道是哪一项产生了变化。
macOS 上常见的区别是:系统代理主要服务于遵守 HTTP、HTTPS 或 SOCKS 代理设置的应用;TUN 则通过虚拟网络接口接管更多类型的连接。Safari、Chrome 等浏览器通常会遵守系统代理,但命令行工具、游戏、更新器和部分 Electron 应用不一定遵守。若目标是验证 DNS 是否完整进入 Clash,建议在配置正确后再开启 TUN,而不是只打开系统代理就结束。
在 Clash Verge Rev 中编辑 DNS
打开 Clash Verge Rev 后,进入配置文件列表,选中准备测试的配置。不同版本的界面可能把入口写成「配置」「Profiles」或「编辑配置」,但核心动作一致:找到当前生效的 YAML 配置,在顶层增加或修改 dns 段。dns 必须与 proxies、proxy-groups、rules 处于同一缩进层级,不能把它误放进某个代理节点下面。
如果配置里已经有 dns:,不要再添加第二个同名段。YAML 中同级重复键可能导致后一个覆盖前一个,也可能被解析器判定为错误。正确做法是合并字段,只保留一个完整的 DNS 配置。下面是一份适合 macOS 测试的基础示例:
dns:
enable: true
ipv6: false
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "+.lan"
- "+.local"
- "localhost.ptlogin2.qq.com"
default-nameserver:
- 192.0.2.53
nameserver:
- https://192.0.2.53/dns-query
proxy-server-nameserver:
- https://192.0.2.53/dns-query
示例里的 192.0.2.53 是文档保留地址,只用于展示字段结构,不能直接当作真实 DNS 服务器使用。实际使用时,应替换为你信任且能够访问的 DNS 上游。若上游使用 DoH 或 DoT,先确认当前配置支持对应协议,并根据服务提供方给出的地址填写,不要把不存在的占位地址原样保存。
enable: true开启 mihomo DNS 模块;如果这里是false,Fake-IP 不会生效。listen是 Clash DNS 服务监听的本地地址和端口。使用1053可以避开 macOS 上其他服务占用 53 端口的情况,具体是否需要调整取决于客户端的 DNS 接管方式。enhanced-mode: fake-ip是核心开关,必须使用连字符写法,不能写成enhanced_mode。fake-ip-range指定假地址池。不要把它改成家庭局域网正在使用的网段,否则可能与路由器、NAS 或打印机地址冲突。fake-ip-filter用于排除不适合 Fake-IP 的域名。局域网域名、部分登录检测、NTP 和设备发现服务通常需要真实地址。default-nameserver是解析 DoH、DoT 上游域名时使用的引导 DNS,一般填写纯 IP,不要写https://或tls://。proxy-server-nameserver用于解析代理节点服务器的域名。节点域名无法连接时,单独配置这一项有助于避免解析链路互相依赖。
保存配置并启用 Fake-IP
配置内容写好后,先执行保存或应用操作,再回到配置列表确认这份文件仍然处于选中状态。Clash Verge Rev 有「编辑后保存」和「更新订阅」两个不同动作:保存是把当前修改写入本地配置,更新订阅则可能重新下载远程内容。测试期间不要立即点击更新订阅,否则刚刚添加的 DNS 段可能被远程配置覆盖。
- 在配置编辑器中检查
dns:的缩进,确认它位于顶层,并且只存在一个dns段。 - 保存配置后,重新选择这份配置,观察客户端是否提示 YAML 解析错误。如果出现错误,优先检查冒号、引号、列表横线和空格缩进。
- 进入设置或主界面,打开系统代理。先使用「规则」模式,选中一个可以稳定连接的节点或策略组。
- 如果需要让不遵守系统代理的应用也使用 Clash,再开启 TUN,并按 macOS 提示安装或授权网络扩展、帮助程序。
- 等待配置重新加载后,查看日志和连接记录,确认 DNS 模块没有端口占用、上游不可达或权限不足的报错。
- 关闭浏览器中独立配置的代理和临时 VPN,再进行 DNS 测试,避免多个解析链路同时运行。
开启 TUN 时,macOS 可能弹出允许添加 VPN 配置、安装网络扩展或输入系统密码的提示。这些授权是建立虚拟网卡和接管流量所需的系统权限。若拒绝授权,系统代理仍可能可以工作,但 TUN、DNS 劫持或整机接管不会完整生效。遇到「TUN 已开启但没有流量」时,应到系统设置的「网络」或「VPN 与过滤器」相关页面确认 Clash Verge Rev 的扩展没有被禁用。
不要随意占用 53 端口
macOS 可能已经有本地 DNS 服务或其他网络软件监听 53 端口。若日志显示 bind failed、address already in use 等错误,可以暂时让 Clash 监听 1053,再通过客户端的 TUN DNS 劫持接管查询。是否能自动接管 53,取决于当前 mihomo 版本和客户端授权状态。
用终端确认 Fake-IP 是否生效
保存并启用配置后,不要只看客户端界面上的开关。Fake-IP 是否真正生效,需要结合终端查询、Clash 日志和实际访问结果判断。打开 macOS「终端」,先清理本机缓存,再执行查询:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
nslookup example.com
example.com 只是测试域名示例。观察 nslookup 返回的服务器和地址信息:如果查询确实进入 Fake-IP 模式,目标域名通常会得到 198.18.x.x 范围内的地址;如果返回的是公网真实地址,并不能单独证明配置错误,因为可能命中了 Fake-IP 过滤列表、查询没有进入 Clash,或者当前客户端使用了其他 DNS 路径。
- 先在 Clash Verge Rev 中打开日志,搜索 DNS、fake-ip、nameserver 或刚才测试的域名,确认查询是否到达内核。
- 执行
scutil --dns,查看 macOS 当前 DNS resolver 的状态,注意它反映的是系统解析器信息,不一定完整展示 TUN 内部的劫持链路。 - 分别测试一个普通公网域名、一个局域网域名和一个明确加入
fake-ip-filter的域名,比较三者返回结果。 - 访问一个需要代理的目标,确认连接记录中显示的是正确域名和预期策略组,而不是只显示一个无法识别的假 IP。
- 暂时关闭 Clash 的系统代理或 TUN,再重复查询。关闭后结果与开启时明显不同,才能说明接管链路确实参与了查询。
| 测试现象 | 可能结论 | 优先检查项 |
|---|---|---|
| 公网域名返回 198.18.x.x | Fake-IP 映射大概率已建立 | 继续检查实际连接是否按域名分流 |
| 所有域名都返回真实公网 IP | Fake-IP 未启用或查询绕过 Clash | 检查配置是否选中、DNS 是否开启、TUN 是否授权 |
| 局域网域名无法访问 | 该域名不适合返回假地址 | 把对应后缀加入 fake-ip-filter |
| 配置加载失败 | YAML 语法或内核字段不兼容 | 检查缩进、重复 dns 段和内核版本 |
| 浏览器正常但命令行异常 | 两个应用使用了不同的代理路径 | 检查 TUN、终端环境变量和浏览器安全 DNS |
测试时不要把「返回 198.18.x.x」当作唯一标准。Fake-IP 只说明本地拿到的是映射地址,真正的使用结果还取决于域名映射是否保存、规则是否命中、节点是否可用以及目标应用是否支持这类连接。若网页打不开,先在日志中确认原始域名,再检查代理策略组,不要立刻把问题归因于 DNS。
macOS 上的常见问题与调整方法
更新订阅后 Fake-IP 消失
这是最常见的情况。远程订阅更新后,客户端用服务商返回的内容替换了本地配置,手动添加的 dns 段自然不再存在。解决方法是使用客户端提供的配置覆写、Merge 或本地补丁能力,把 DNS 设置作为独立覆写项保存;如果当前版本没有这类入口,就复制订阅配置为本地测试文件,并记得以后更新后重新检查。
某些应用连接失败
Fake-IP 对绝大多数网页访问没有问题,但局域网发现、设备投屏、部分游戏、企业内网和依赖真实 IP 的程序可能不兼容。先把相关域名加入 fake-ip-filter,再重启应用并清理 DNS 缓存。如果问题仍在,可以临时把 enhanced-mode 改为 redir-host 做对照。两种模式都能工作时,优先根据应用兼容性和分流需求选择,而不是盲目追求 Fake-IP。
IPv6 导致结果不一致
macOS 在双栈网络中可能同时请求 A 和 AAAA 记录。如果 Clash 配置没有完整接管 IPv6,应用可能拿到 IPv6 地址后绕过预期路径。排查阶段可以暂时设置 ipv6: false,观察问题是否消失;如果你的网络、节点和规则都明确支持 IPv6,再单独开启并测试 IPv6 流量。不要只因为终端返回了 IPv4 假地址,就认为 AAAA 查询也已经被正确接管。
浏览器安全 DNS 绕过 Clash
Chrome、Firefox 和其他浏览器可能启用「安全 DNS」或 DoH。浏览器直接向指定的 DoH 服务发起请求时,系统 resolver 和 Clash 的普通 DNS 监听都可能看不到这条查询。测试 Fake-IP 时,建议暂时关闭浏览器的独立安全 DNS,或者确认该功能明确配置为遵守系统代理。浏览器能打开网页并不代表所有 DNS 查询都经过 Clash,仍要以日志和对照测试为准。
一份稳定配置的检查清单
完成设置后,可以按下面的顺序做一次最终确认。这样既能验证 Fake-IP,也能避免为了修复一个域名问题而破坏整个 macOS 网络环境。
- 当前生效配置只有一个
dns段,且enable为true。 enhanced-mode使用fake-ip,fake-ip-range没有与局域网网段重叠。fake-ip-filter至少包含+.lan、+.local等本地名称,其他例外域名按实际故障逐项添加。default-nameserver填写可用的纯 IP,引导解析不会写成 DoH 或 DoT URL。- 系统代理和 TUN 只按需要开启,不同时运行会争抢网络扩展的其他代理软件。
- 订阅更新后再次确认覆写内容仍然存在,避免配置被远程文件恢复。
- 使用
nslookup、scutil --dns、Clash 日志和实际访问结果交叉验证。
如果只是希望浏览器和常规桌面软件按规则代理,系统代理加正确的 DNS 配置通常已经够用;如果还需要接管终端、游戏或不遵守系统代理的程序,再开启 TUN。Fake-IP 负责域名映射和分流配合,TUN 负责更广泛的流量接管,两者是不同层面的功能。理解这一点后,遇到解析正常但某个应用仍然直连时,就能把排查重点放到 TUN、应用代理行为和规则匹配上,而不是反复修改 DNS 上游。