PassWall2 DNS 泄露怎么修复？按类型定位后再改配置
简答：先不要直接改 FakeDNS 或更换远程 DNS。PassWall2 DNS 泄露应按“客户端是否经过运行 PassWall2 的网关 → 是否有明文 53/853 → 浏览器或手机是否自行使用 DoH/DoT → IPv6 是否绕过”顺序排查。最快的对照方法是：暂时关闭终端自定义 DNS 和 IPv6，确认客户端网关、DNS 都指向 PassWall2 路由器，再用 dig、tcpdump 和两个检测页面复测。
定义：PassWall2 DNS 泄露，是指终端的 DNS 查询绕过预期的 PassWall2 分流链，直接发往运营商、本地网络或其他未计划的解析器；检测页面显示某个 DNS 出口并不自动等于泄露，必须结合你的拓扑和分流设计判断。
先试这一步：统一网关、DNS 与拓扑
本站是第三方使用指南站，不是 PassWall2 项目的官方网站。OpenWrt 默认使用 dnsmasq 与 odhcpd 提供 DNS、DHCP 和 DHCPv6 服务，客户端如果没有把默认网关和 DNS 指向运行 PassWall2 的设备，后面的重定向设置可能不会生效。相关服务关系可参考 OpenWrt DHCP 与 DNS 配置。
| 场景 | 客户端默认网关 | 客户端 DNS | 先检查什么 |
|---|---|---|---|
| PassWall2 主路由 | PassWall2 路由器 LAN 地址 | 同一 LAN 地址 | DHCP 是否下发了其他 DNS |
| 旁路由 | 按你的设计指向主路由或旁路由 | 应指向实际负责 DNS 的设备 | 主路由 DHCP 是否仍在下发旧 DNS |
| 单设备测试 | 当前 Wi-Fi 或有线网关 | 先设为自动获取 | 浏览器 DoH、Android 私人 DNS 是否接管 |
在客户端执行以下命令，先记录结果，不要急着修复：
ipconfig /all
nslookup example.com
# Linux 或 macOS
ip route
scutil --dns 2>/dev/null || resolvectl status
dig example.com结果判断：Windows 的 Default Gateway、DNS Servers，或 Linux/macOS 的默认路由与解析器，如果不是运行 PassWall2 的设备，先修正 DHCP 或客户端网络配置。旁路由不要同时让主路由、旁路由和终端分别承担不同的 DNS 入口，否则很难判断请求实际走哪条链。
第 1 步：区分 DNS 泄露、污染、本机失效和 IPv6 绕过
- DNS 泄露：检测结果出现不在预期拓扑内的运营商、本地网络或终端自定义解析器；要结合抓包确认请求是否真的离开了预期链路。
- DNS 污染或解析异常：查询结果错误、超时或返回异常地址，但请求可能仍然到达了你配置的 DNS；这不是单凭检测页面就能判定的泄露。
- 路由器本机 DNS 失效：LAN 客户端能上网，但路由器执行
nslookup、opkg update或订阅更新失败。PassWall2 项目仓库的 Issue 1080 记录过 OpenWrt 24.10.x 下本机解析失败、/etc/resolv.conf指向回环地址而目标端口没有监听的案例，但这是特定配置的故障记录，不代表所有设备都会出现。 - IPv6 绕过：IPv4 查询或流量经过 PassWall2，但终端通过 IPv6 DNS、IPv6 默认路由或浏览器独立连接绕过了原有路径。
PassWall2 的默认配置文件和生成脚本包含直连 DNS、远程 DNS、远程 DNS 协议、FakeDNS、DNS 监听端口等字段，字段名称会随版本和核心变化，修改前应以 LuCI 当前页面及生成配置为准，可参阅 PassWall2 默认配置 与 PassWall2 sing-box 配置生成代码。
第 2 步：分别检查 53、853、443 和 IPv6
检查 UDP/TCP 53
在路由器 SSH 中先确认本机监听：
ss -lntup 2>/dev/null | grep -E ':(53|853|443)[[:space:]]' || netstat -lntup 2>/dev/null | grep -E ':(53|853|443)[[:space:]]'
logread | grep -Ei 'passwall2|dnsmasq|odhcpd|dns'ss 可能不在精简系统中；如果命令不存在，不要把空输出当成“没有监听”，先按当前 OpenWrt 软件源安装提供 ss 的包，或使用系统已有的 netstat。53 端口通常由 dnsmasq、AdGuard Home、mosdns、SmartDNS 或 PassWall2 生成的 DNS 进程之一负责，先确认谁占用端口，再决定是否调整。
从 LAN 客户端测试指定服务器：
nslookup example.com ROUTER_LAN_IP
nslookup example.com 1.1.1.1如果第一条失败，优先查路由器 DNS 服务或防火墙；如果第二条成功但第一条失败，说明客户端可以直连外部 DNS，这本身不证明 PassWall2 泄露，却说明“只允许统一 DNS 入口”的设计没有实现。
检查 TCP/UDP 853
853 常见于 DoT。用 TCP 测试只能说明端口可建立 TCP 连接，不适用于 UDP 或 QUIC：
nc -vz DNS_SERVER_IP 853
nc -vz DNS_SERVER_IP 443不要因为 853 可连接就认定发生泄露；关键是终端是否主动使用了 DoT，以及 PassWall2 是否计划接管该请求。Android 的“私人 DNS”可以设置为关闭、自动或指定提供商主机名，入口通常是“设置 → 网络和互联网 → 私人 DNS”，具体名称以系统版本为准，可参考 Android 网络与私人 DNS 帮助。
检查 443 与浏览器 DoH
浏览器 DoH 会把 DNS 查询封装在 HTTPS 中，通常表现为 443 流量，单看 53 端口抓包可能看不到。Firefox 的入口是“设置 → 隐私与安全 → DNS over HTTPS”，其官方说明区分了 Active、Not active 和 Off 状态，参阅 Firefox DNS over HTTPS 帮助。Chrome、Edge 等浏览器也可能有“使用安全 DNS”选项。
定位期间，先关闭浏览器安全 DNS、Android 私人 DNS 和系统自定义 DNS，重新测试；如果泄露消失，再决定是否恢复。不要把“关闭 DoH”当成永久隐私方案：定位完成后，可以重新开启 DoH，但要确认其 443 流量符合你的代理出站设计，并再次验收。
检查 IPv6
nslookup -type=AAAA example.com
curl -6 -I --max-time 10 https://example.com
ip -6 route如果终端仍有 IPv6 默认路由，但 PassWall2 当前配置没有接管 IPv6，先在单个客户端或 LAN 接口做临时 IPv6 对照测试。LuCI 常见路径为“网络 → 接口 → LAN → DHCP 服务器 → IPv6 设置”，字段可能包括 RA、DHCPv6 和 IPv6 DNS；不要把 odhcpd 的 NDP 选项写成不存在的值，修改前先查看当前配置：
uci show dhcp.lan | grep -E 'ra|dhcpv6|ndp|dns'
ip -6 addr
ip -6 route临时关闭 IPv6 后，如果 DNS 检测结果恢复正常，说明应继续检查 IPv6 DNS、RA/DHCPv6 广播与 PassWall2 IPv6 转发，而不是直接断言是 FakeDNS 的问题。
第 3 步：按场景修复 PassWall2 与 LuCI 配置
| 现象 | LuCI 检查路径 | 最小处理 | 结果判断 |
|---|---|---|---|
| 客户端绕过路由器 DNS | 网络 → 接口 → LAN → DHCP 服务器；同时检查客户端 DNS | 让 DHCP 只下发负责 DNS 的 LAN 地址；关闭终端自定义 DNS 做对照 | nslookup 默认服务器指向预期设备 |
| 明文 53 未被统一接管 | PassWall2 → 基本设置或 DNS 设置；名称以当前版本为准 | 检查“DNS 重定向”是否与现有 AdGuard Home、mosdns 或 SmartDNS 的入口冲突；只保留一个明确的 53 入口 | 抓包中客户端请求到达预期监听端口 |
| 直连 DNS 与远程 DNS 选错 | PassWall2 → DNS；检查直连 DNS、远程 DNS、远程 DNS 出站 | 明确国内或直连域名由谁解析，代理域名由谁解析；不要让多个组件互相回环 | 日志显示查询命中预期规则，订阅更新也能解析 |
| FakeDNS 开启后异常 | PassWall2 → DNS 或高级设置 → FakeDNS | 先记录当前配置，再临时关闭 FakeDNS 做 A/AAAA 查询对照；不要手工填写未核实的 FakeDNS 地址池 | 关闭后若恢复，继续查生成配置、缓存和分流规则 |
| IPv6 绕过 | 网络 → 接口 → LAN → DHCP 服务器 → IPv6 设置 | 先临时关闭 LAN 的 IPv6 广播或客户端 IPv6 做对照，再按实际支持情况恢复并配置接管 | IPv4、IPv6 两类检测结果都符合预期 |
“DNS 重定向”不是越多越好。如果同时运行 PassWall2、AdGuard Home、mosdns 或 SmartDNS，先画出唯一链路，例如“LAN 客户端 → AdGuard Home:53 → dnsmasq:54 → PassWall2 DNS 端口”，然后逐个确认监听端口。PassWall2 仓库的 Issue 1287 记录过 dnsmasq 重定向规则残留导致请求绕过上游 DNS 的特定案例，因此排查时应同时查看 LuCI 配置和实际防火墙规则，而不是只看页面开关状态。
uci show dhcp | grep -E 'dns_redirect|port|server'
uci show passwall2 | grep -E 'dns_redirect|dnsmasq_dns_redirect|dns'
nft list ruleset 2>/dev/null | grep -Ei 'dns|dport 53|redirect|passwall'
iptables-save 2>/dev/null | grep -Ei 'dns|dport 53|REDIRECT'第 4 步：处理路由器本机 DNS 失效与 dnsmasq 冲突
修改前先备份 DHCP、PassWall2 和防火墙配置：
mkdir -p /root/dns-backup
cp -a /etc/config/dhcp /etc/config/passwall2 /etc/config/firewall /root/dns-backup/ 2>/dev/null
cat /etc/resolv.conf
ps w | grep -E 'dnsmasq|passwall2|sing-box|xray|AdGuard|mosdns|smartdns' | grep -v grep如果 LAN 客户端正常、路由器本机执行 nslookup example.com 失败，重点看 /etc/resolv.conf、127.0.0.1 或 ::1 的监听端口，以及 PassWall2 日志：
nslookup example.com 127.0.0.1
logread | grep -Ei 'passwall2|dnsmasq|connection refused|nftset'
/etc/init.d/passwall2 status 2>/dev/null || truePassWall2 的公开 Issue 1080 将一类本机 DNS 失败与基础版 dnsmasq 缺少 NFTSet 支持联系起来，并记录了更换 dnsmasq-full 后恢复的案例；这只能作为候选原因，不能在没有核对 OpenWrt 版本、软件包和日志时直接执行卸载替换。确认你的发行版包管理器、软件源和依赖后，再考虑：
opkg list-installed | grep -E '^dnsmasq|nft'
apk info 2>/dev/null | grep -E 'dnsmasq|nft' || true若确实需要替换软件包，先确认备份可恢复，并在维护窗口操作。替换后重启相关服务，再验证本机解析、LAN 解析和规则命中；不要把软件流量卸载、FakeDNS 或其他无关选项一起改动，否则无法判断是哪项变化起作用。
第 5 步：用抓包、日志和两个检测站验收
先在路由器抓取一小段 DNS 流量。接口名称可用 ip link 查看，下面的 br-lan 只是占位示例：
tcpdump -ni br-lan 'port 53 or port 853 or port 443' -c 80
logread -f | grep -Ei 'passwall2|dnsmasq|dns|fake'结果判断：
- 客户端访问测试域名时，能在预期 LAN 或 DNS 入口看到请求，说明至少到达了该入口。
- 若直接看到客户端向外部 DNS 的 53 或 853 发包，说明客户端存在直连路径，需要检查系统 DNS、私人 DNS、DoT 和浏览器设置。
- 若只有 443 流量，不能仅凭端口判断是否为 DoH；应结合浏览器设置、进程日志和目标地址继续确认。
- TCP 测试只能验证 TCP 连接，不代表 UDP、QUIC 或实际 DNS 查询成功。
网页检测建议至少交叉使用两个工具，例如 BrowserLeaks DNS Leak Test 与 dnsleak.dev DNS Leak Test。前者说明会通过多组随机域名观察浏览器使用的 DNS 服务器，后者也提示检测结果反映的是测试请求看到的解析器。检测站看到的是递归解析器出口，不一定等于你在路由器中填写的上游地址，因此必须与抓包、日志和本地命令结合。
最终验收至少完成四项：默认 DNS 指向预期网关；53/853 没有未计划的直连；浏览器 DoH、Android 私人 DNS 和系统自定义 DNS 已按设计恢复或关闭；IPv4 与 IPv6 分别测试后结果一致。若恢复浏览器 DoH 或 IPv6，必须重新跑一遍验收。
常见误操作与最小回退方案
- 误操作：看到检测站显示运营商 DNS 就立刻更换远程 DNS。回退：先用
tcpdump确认请求路径，并核对该解析器是否本来就是你设计中的上游。 - 误操作：同时开启 dnsmasq DNS 重定向、PassWall2 DNS 重定向和第三方 DNS 服务。回退：保留一个明确的 53 入口，其他组件改为转发到指定端口，重启后检查实际规则。
- 误操作：把 FakeDNS 地址池直接照抄到所有版本。回退：删除手工填写的地址池，使用当前设备生成的配置，并以实际 A/AAAA 查询结果为准。
- 误操作：只关闭 IPv6 却不检查 RA、DHCPv6 和终端缓存。回退：重新连接网络，清理缓存，再分别测试 A 和 AAAA。
最小可用的排查变量示例：路由器 LAN 地址用 ROUTER_LAN_IP，LAN 接口用 br-lan，PassWall2 DNS 端口用 PASSWALL_DNS_PORT。不要把这些占位值直接当作你的真实端口。
参考资料
- OpenWrt DHCP 与 DNS 配置
- Openwrt-Passwall/openwrt-passwall2 项目仓库
- PassWall2 Issue 1080：路由器本机 DNS 失效案例
- PassWall2 Issue 1287：dnsmasq DNS 重定向规则案例
- Android 网络与私人 DNS 帮助
- Firefox DNS over HTTPS 帮助
常见问题
PassWall2 DNS 检测显示运营商 DNS，就一定是泄露吗？
不一定。检测站显示的是它观察到的递归解析器出口，可能是你的预期上游，也可能是客户端绕过了路由器。应结合客户端默认 DNS、tcpdump、PassWall2 日志和实际分流设计判断。
PassWall2 DNS 重定向应该一直开启吗？
不能一概而论。如果没有其他 DNS 服务，DNS 重定向可以作为统一入口的一部分；如果同时运行 AdGuard Home、mosdns 或 SmartDNS，应先确定唯一的 53 入口，避免 dnsmasq、PassWall2 和第三方服务互相重定向或形成回环。字段名和行为以当前版本界面及生成规则为准。
FakeDNS 要不要关闭才能修复 DNS 泄露？
不建议把关闭 FakeDNS 当作通用答案。先关闭做对照可以帮助定位，但若关闭后恢复，只能说明 FakeDNS、生成配置、缓存或分流链中存在需要继续核对的差异；不要直接套用未核实的地址池。
浏览器 DoH 和 Android 私人 DNS 应该关闭多久？
定位期间可以临时关闭，避免浏览器或系统直接建立独立的 DNS 通道。修复完成后，可按你的隐私和分流设计重新开启，但必须确认 443 或 DoT 流量符合预期，并重新测试 IPv4、IPv6 和 DNS 检测结果。
旁路由模式下，主路由和旁路由谁应该发 DNS？
应先确定唯一负责 DNS 的设备。客户端默认网关可以按旁路由方案设计，但 DHCP 下发的 DNS 必须指向实际提供 DNS 服务且能被 PassWall2 接管的设备；不要让主路由 DHCP、旁路由和终端分别下发不同 DNS。
相关阅读
参考资料
- OpenWrt DHCP 与 DNS 配置（openwrt.org）
- OpenWrt DHCP 与 DNS 示例（openwrt.org）
- Openwrt-Passwall/openwrt-passwall2 项目仓库
- PassWall2 默认配置文件
- PassWall2 sing-box 配置生成代码
- PassWall2 Issue 1080：路由器本机 DNS 失效案例
- PassWall2 Issue 1287：dnsmasq DNS 重定向规则案例
- BrowserLeaks DNS Leak Test（browserleaks.com）
- dnsleak.dev DNS Leak Test（dnsleak.dev）