OpenClash Fake-IP 出问题时，先别换订阅，也别把 OpenWrt 的 DNS 页面全部改一遍。最小可控的做法是：LAN 设备只问路由器，路由器的 53 端口仍由 dnsmasq 承接，OpenClash 负责需要进入 Mihomo DNS 的那部分查询，本地域名和设备发现域名不要拿 Fake-IP。

这篇只处理 OpenWrt / iStoreOS 路由器上的 OpenClash DNS 冲突。官方 OpenClash 仓库把它定位为运行在 OpenWrt 上的 Mihomo/Clash 客户端，并在依赖里列出 dnsmasq-full；Mihomo DNS 文档则提供 fake-ip、redir-host、fake-ip-filter、nameserver-policy 等字段。路由器上的麻烦通常不是单个字段写错，而是这些组件同时接管了 DNS 入口。

先把家庭 DNS 入口定下来

家庭网关上不要让手机、电视、NAS 各自拿不同 DNS。排查阶段先把 LAN 设备的 DNS 统一成 OpenWrt 路由器地址，例如 192.168.1.1。这样浏览器打不开、电视应用超时、NAS 主机名失效时，你能从路由器日志里看到同一条链路。

位置排查阶段建议看到异常时说明什么
LAN 设备 DNSDHCP 下发路由器 IP设备拿到公共 DNS 时，查询可能绕开 OpenClash
dnsmasq保留 DHCP 和 53 入口dnsmasq 停掉后，.lan、主机名、DHCP 租约都可能乱
OpenClash DNS只接收被转交的查询日志没有 DNS 记录，说明查询没进 OpenClash
上游 DNS不指回路由器 53指回本机容易形成 DNS 回环

OpenWrt 的 dnsmasq 文档说明它承担 DHCP 和 DNS 功能。路由器作为主网关时，dnsmasq 不只是一个解析器，它还关系到设备租约、主机名、本地域名和 DHCP 选项。Fake-IP 排错时直接关 dnsmasq，往往会把一个 DNS 问题扩大成整段 LAN 的设备问题。

dnsmasq、Fake-IP、上游 DNS 三张表要分开看

这类冲突最容易被误判成“DNS 不好用”。更准确的拆法是：入口、映射、上游三层分别是谁负责。

层级负责对象正常状态常见冲突
dnsmasqLAN 设备入口、DHCP、路由器本地域名LAN 查询先进路由器 53，再按配置转交设备被手动填了别的 DNS，或 dnsmasq 没读到 OpenClash 片段
Fake-IP给被代理域名下发 198.18.0.0/16 这类虚拟地址外部域名进入 Mihomo 映射表，连接阶段可按规则处理NAS、打印机、路由器后台、.lan 也被映射成 Fake-IP
上游 DNS真实解析器、DoH/DoT 或按域名分流的解析策略OpenClash 查询外部域名时能拿到真实解析结果上游写成本机或路由器 53，查询绕回 dnsmasq
nameserver-policy特定域名走指定解析器内网、国内外服务、特殊域名各走明确路径规则太宽，把本地域名送到远端上游

Mihomo DNS 文档里的 enhanced-mode 可以用 fake-ip，也可以用 redir-host。Fake-IP 的优势是规则阶段更容易接管连接，但它要求 fake-ip-filter 写得足够克制。OpenWrt 上尤其要避开这些对象：

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.0/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.home.arpa"
    - "localhost"
    - "router.lan"
    - "openwrt.lan"
    - "time.windows.com"

这段不是让你照抄进生产配置，而是提供一个排错基线。你家的 NAS 域名、软路由管理域名、打印机发现域名、HomeKit 或 Chromecast 相关域名，都可能需要单独加入过滤。

OpenClash 日志里没有 DNS，先查转交链路

OpenClash 页面显示运行，不代表 LAN 设备的 DNS 已经进了 OpenClash。先在路由器 SSH 里看监听和日志：

netstat -lntup | grep ':53'
logread -e dnsmasq
logread -e openclash
uci show dhcp.@dnsmasq[0]

如果 logread -e dnsmasq 能看到设备查询，但 OpenClash 日志完全没有 DNS 记录，问题多半发生在 dnsmasq 到 OpenClash 的转交。此时看 OpenClash 是否写入了 dnsmasq 片段、端口是否一致、服务重启后片段是否还在。

如果 OpenClash 日志有 DNS 查询，但设备仍打不开网页，再看 Fake-IP 映射和连接阶段。Fake-IP 下发成功只是 DNS 阶段完成，不代表后续连接一定命中正确规则。可以同时看：

nslookup example.com 192.168.1.1
nslookup openwrt.lan 192.168.1.1
ip neigh
logread -e openclash | tail -n 80

example.com 返回 Fake-IP 不一定是坏信号；openwrt.lan、NAS 主机名或打印机域名返回 Fake-IP 才需要处理。

上游 DNS 不要绕回路由器

OpenClash 的上游 DNS 如果写成 127.0.0.1:53、192.168.1.1:53 或路由器 LAN 地址，容易出现回环：LAN 设备问 dnsmasq，dnsmasq 转 OpenClash，OpenClash 又问回 dnsmasq。轻则网页间歇超时，重则所有域名都卡在等待解析。

排查阶段把上游分清：

需求可用写法不建议写法
普通外部域名明确的 UDP DNS、DoH 或 DoT 上游路由器 LAN IP 的 53 端口
本地域名由 dnsmasq 或 OpenWrt 本机处理送到远端公共解析器
特定服务域名nameserver-policy 指向专用上游用一个兜底上游处理所有域名
路由器自身更新保持可解析的系统 DNS依赖尚未启动的 OpenClash DNS

如果你维护多端配置，订阅可以用兼容 Clash / Singbox / V2Ray 的订阅做格式基线；但路由器 DNS 冲突仍要在 OpenWrt 本机排，不要把上游回环、dnsmasq 片段缺失或 Fake-IP 过滤漏项归到订阅本身。

LAN 设备验证表：别只测路由器自己

软路由上 nslookup 正常，不代表手机、电视和 NAS 都正常。路由器本机、LAN 设备、无线 AP 下的设备，可能拿到不同 DNS 或走不同网关。

设备验证动作正常结果异常时看哪里
OpenWrt 路由器nslookup example.com 127.0.0.1本机能解析，日志有记录系统 DNS、OpenClash 服务、上游 DNS
Windows / macOS 笔记本nslookup example.com 192.168.1.1返回可用结果，OpenClash 或 dnsmasq 有日志DHCP 下发 DNS、浏览器 DoH、手动 DNS
iPhone / Android断开重连 Wi-Fi 后访问常用网页不再间歇等待解析私人 DNS、旧 DHCP 租约、旁路由网关
NAS用主机名访问管理页主机名解析为 LAN 真实 IPfake-ip-filter、dnsmasq 租约、本地域名
电视 / 盒子打开应用商店或系统更新页DNS 查询不再超时设备硬编码 DNS、防火墙重定向、IPv6
打印机 / IoT手机能发现设备mDNS、本地域名不被 Fake-IP 改写.local、组播、AP 隔离

这张表的重点是 LAN 真实 IP。内网设备名、.lan、.local、home.arpa 和路由器后台域名，不应该被 Fake-IP 池替换。只要这些名字返回 198.18.x.x，就先补过滤，不要继续改上游。

改配置时一次只动一层

OpenClash、dnsmasq、DHCP、上游 DNS、Fake-IP 过滤都能影响同一个现象。排错时按这个顺序动：

  1. 保存当前 OpenClash 配置、OpenWrt 网络配置和 DHCP/DNS 页面截图。
  2. 让 LAN 设备 DNS 只指向路由器。
  3. 保留 dnsmasq 入口，确认 53 端口没有被其他插件抢走。
  4. 清理 OpenClash 上游 DNS，避免指回路由器。
  5. 把内网域名和设备发现域名加入 fake-ip-filter。
  6. 重启 dnsmasq 和 OpenClash，再让一台 LAN 设备重新获取 DHCP。

对应命令可以简化成：

/etc/init.d/dnsmasq restart
/etc/init.d/openclash restart
logread -f

不要同时启用多个透明代理插件接管 DNS。PassWall、SmartDNS、AdGuard Home、MosDNS、OpenClash 可以共存于同一台 OpenWrt，但排错阶段必须知道 53 入口是谁、上游是谁、谁负责返回 Fake-IP。

哪些 DNS 故障不该硬套 OpenClash Fake-IP

这篇没有测试所有固件分支，也没有覆盖运营商光猫、企业 AC、校园网认证、IPv6-only、旁路由双网关和 Docker 版 Mihomo。iStoreOS 的菜单和预装插件可能和原版 OpenWrt 不同，但 DNS 链路仍然要回到 DHCP、dnsmasq、OpenClash 和上游解析器。

还有两类情况要单独处理：

  • 如果只有某个应用打不开，但系统域名解析正常，继续查规则命中、SNI、应用内 DoH 或该应用的缓存。
  • 如果所有 LAN 设备都拿不到 IP，先修 DHCP；DNS 和 Fake-IP 还没开始工作。

OpenClash DNS 排完后继续看哪些页面