168机场档案透明核验 · 持续更新

全站智能检索

直接说出你的问题

AI 会理解问题含义，并从本站机场档案和实用文章中找出最相关的内容。

试试：

输入问题后按回车搜索。

实用文章

故障排查

哪些域名需要加入 fake-ip-filter？不要先复制超长列表

fake-ip-filter 只应处理确实不能接受合成地址的域名。先复现、对照真实解析，再添加最小域名规则，避免大范围过滤破坏域名路由。

发布于 · 更新于 · 3 项可核验来源

先看重点只有某个域名在 fake-ip 下稳定失败、改用真实解析后恢复，才值得加入 fake-ip-filter。先从日志找出准确域名，优先加单个主机名；涉及局域网发现时再核对 .local/mDNS。不要照抄几百行列表，也不要把整个顶级域名都改成真实解析。

fake-ip-filter 不是“越长越兼容”的白名单。它的作用是让命中的域名不再拿到 fake IP，而是返回真实解析结果。过滤范围扩大后，Mihomo 能用于规则判断的 fake-ip 映射也会减少，排障反而更模糊。

真正需要处理的通常不是某款 App 的名字，而是它请求的少数域名。先证明问题与 fake-ip 有因果关系，再改配置。

先确认失败确实来自 fake-ip

按这个顺序做对照：

  1. 保持同一网络、节点和规则，复现某项明确功能失败；
  2. 在客户端日志中记下失败时实际访问的域名；
  3. 暂时改为 redir-host，或仅让该准确域名返回 real IP；
  4. 完全重开目标 App，再重复原操作；
  5. 只有结果稳定从失败变为成功，才保留过滤项。

如果换节点、切直连或重启 App 后结果也一起变化，就还不能把原因归给 fake-ip。不要把服务端限区、节点 UDP 不可用或证书错误塞进 DNS 过滤器。

哪些情况更可能需要真实解析

  • 局域网设备发现、打印机或 NAS 使用本地名称；
  • App 把 DNS 结果交给同一局域网内的另一台设备；
  • 软件会保存并校验解析到的 IP，而不是只发起普通连接；
  • 日志已显示某个准确域名在收到合成地址后立即失败。

.local 有特殊含义。RFC 6762 规定，以 .local. 结尾的名称通过链路本地 Multicast DNS 处理；这类名称不应被当作普通公网域名交给远端解析。其他自定义局域网后缀则要以路由器和本地 DNS 的实际配置为准，不能因为看起来像内网就随便添加。

从最小规则开始

Mihomo 的黑名单模式表示“匹配项返回真实 IP”。已确认只有 device.example.com 异常时，先加准确主机名，不要直接扩大到 *.example.com：

dns:
  enhanced-mode: fake-ip
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - device.example.com

保存后重载配置、清掉目标 App 的旧连接，再查看该域名是否返回真实地址以及功能是否恢复。配置语法应以当前内核文档和客户端最终配置为准，机场订阅更新也可能覆盖手工改动。

为什么超长公共列表容易误伤

网上的列表往往混合了局域网、游戏、厂商更新、旧版 App 和特定地区的历史问题。你并不知道每一条为什么存在，也很难发现其中一个宽泛通配符让大量域名绕过 fake-ip。

常见副作用包括：

  • 同一站点的域名规则表现前后不一致；
  • 本地 DNS 与代理 DNS 得到不同地址，CDN 结果变差；
  • 列表更新后突然改变原本正常的连接；
  • 真正出错的一个域名被上百条规则淹没。

质量更高的配置应能回答“哪项功能、哪个域名、什么对照结果”。回答不了，就先不加。

修复后保留一份可撤销记录

记录添加日期、域名、复现场景和对照结果。应用或内核升级后再移除一次测试；若问题已经消失，就删除这条例外。过滤规则不是收藏品，失去证据的旧条目只会积累维护成本。

如果你只是看到 DNS 返回 198.18.x.x，先读fake-ip 合成地址说明；这本身不是添加过滤项的理由。

资料来源

以下来源于 2026/8/8 复核。版本、支持平台和发布状态以后续官方页面为准。

  1. Mihomo 官方文档：fake-ip-filter 与匹配模式
  2. Mihomo 官方文档：TUN 与 DNS hijack
  3. RFC 6762：Multicast DNS 与 .local

持续更新

收到新教程，也欢迎纠错

想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。

关注 TG 频道Telegram 纠错邮件纠错