软路由 DNS 的问题很少出在单个软件。dnsmasq 负责局域网 DHCP 和本地域名，SmartDNS 负责上游选择，PassWall 又可能按规则接管部分查询。三者顺序一乱，所有应用都会像随机坏掉。

这类问题的共同点是：界面上看起来已经开启，真正的入口却可能在另一个端口、另一个服务或另一个配置段。排查时不要同时改三处。先找一个可重复的失败样本，再把日志、字段和验证命令对上。

##判断你是哪一种故障？

故障表现更可能原因现场先看
插件启动提示端口占用多个服务监听 53`netstat -lntup
内网域名不能解析dnsmasq 被关闭或本地解析丢失DHCP/DNS 设置
网页随机超时DNS 查询在本机循环PassWall 与 SmartDNS 日志
重启后配置失效UCI 启动顺序覆盖/etc/config/dhcp 与 smartdns 配置

如果表里有两项同时命中，处理更靠近系统入口的那一项。端口、服务、VPN 权限、DNS 监听都属于入口层；订阅、规则、策略组属于配置层。入口没通时，配置层再正确也看不出效果。

为什么不要一上来重装客户端？

重装会清掉一部分状态，也会把证据一起清掉。很多用户重装后短时间恢复，是因为旧服务、DNS 缓存或监听端口被重启释放了，并不代表根因消失。下一次更新、重启或切换网络后，问题可能原样回来。

更稳妥的办法是保留现状，做最小化测试。只开一个入口，只用一个测试域名，只改一个字段。每次改动后都记录现象，这比反复导入新配置更快。

现场定位：看哪条日志和哪个字段？

  • 命令：netstat -lntup | grep -E ":53|:54|:6053"。
  • 配置路径：OpenWrt → 网络 → DHCP/DNS。
  • PassWall 路径：基本设置 → DNS 设置。
  • 日志关键词：address already in use、dnsmasq、smartdns、fallback。

可以直接执行或在 UI 里完成这些检查：

netstat -lntup | grep -E ":53|:54|:6053"
uci show dhcp.@dnsmasq[0]
logread -e dnsmasq
logread -e smartdns

日志里如果同时出现端口占用和 DNS 失败，处理端口。DNS 组件起不来时，后面的规则命中、策略选择和连接测速都会失真。

字段和客户端兼容表

字段或组件适用客户端/平台作用兼容提醒
dnsmasqOpenWrt 默认DHCP 与本地域名建议保留
SmartDNSOpenWrt 插件上游 DNS 选择常监听 6053 或 5335
PassWall DNSPassWall按代理规则处理域名避免再转回自身
53/UDP系统 DNS 入口局域网设备默认访问只给一个服务
54/6053转发端口内部链路要写清上游

兼容表的用法不是照抄字段，而是确认「谁负责入口，谁负责规则，谁负责 DNS」。一个字段在桌面客户端里只是本机设置，放到 OpenWrt 上就可能影响整段局域网。

修复步骤怎么排？

  1. 决定主入口：通常保留 dnsmasq 处理局域网 53。
  2. 把 SmartDNS 改到内部端口，例如 6053。
  3. 让 dnsmasq 转发到 SmartDNS，或按 PassWall 文档选择接管方式。
  4. 确认 PassWall 不再把查询转回同一个本机端口。
  5. 重启 dnsmasq、SmartDNS、PassWall 后用 nslookup 测内外域名。

如果你维护多台设备，最好先拿一台测试机做验证。确认核心链路恢复后，再把同一套配置同步到手机、平板或软路由。多端共用订阅时，可以准备一份兼容 Clash / Singbox / V2Ray 的订阅作为基线输入，但排错仍要从本机日志开始。

哪些情况不该继续改配置？

出现下面几种情况，先停手：第一，日志已经提示文件缺失或权限不足，却还在改规则；第二，同一台设备上同时开了两个 DNS 接管组件；第三，服务重启后错误字符串变化很大，说明你一次改了太多变量。

还有一种常见误区是把「测速失败」当成所有问题的根因。测速只是客户端发起的一次请求，不能证明 DNS、TUN、Rewrite 或策略组都正常。要用真实 App 或浏览器请求补一次验证。

怎么验证已经恢复？

  • 同一个测试域名连续打开 3 次，结果一致。
  • 日志里不再出现本篇 TL;DR 提到的错误字符串。
  • 连接记录进入预期策略组或出站，而不是落到兜底项。
  • DNS 返回值、监听端口和 UI 状态三者能互相对应。

验证要回到最初的失败样本。不要换一个网站就宣布修好，也不要只看 UI 绿色状态。能复现同一个动作，并在日志里看到清晰命中，才算完整链路。

记录哪些证据才有用？

处理「PassWall、dnsmasq 和 SmartDNS 端口冲突排查」这类问题时，建议把证据写成一行，而不是只截一张失败截图。可记录客户端版本、系统版本、当前入口端口、DNS 监听地址、失败域名、日志关键词和最后一次改动时间。以后同一个配置换到另一台设备上，能直接判断是环境差异还是配置差异。

如果团队里有多人维护配置，变更前后最好各保留一份导出的配置。不要只说「我改了 DNS」或「我开了 TUN」，而是写清具体字段，例如端口从 7890 改到 7897，Fake-IP 过滤新增了 *.lan，或 Script 里新增了一个策略组。这样的记录能减少重复试错，也方便回滚。

实际处理时还要留意时间顺序：先记录修改前状态，再执行一项变更，最后立即复测。若隔了很久才发现异常，期间的系统重启、租约刷新、订阅更新都会干扰判断。

相关阅读