WAN6 已拿到 IPv6 地址，但在 OpenWrt 上 ping 公网 IPv6 时，立即返回：
ping: sendto: Network unreachable
最后发现，现场存在一条与 mwan3 一致的带标记不可达规则。删除它后，IPv6 恢复。这个案例说明：看到了默认路由，也不代表实际流量一定会使用它。
本文记录一次实际排查。公网源地址已替换为文档示例地址；设备名、规则优先级和 mark 应以自己的设备为准。卸载命令适用于使用 opkg 的 OpenWrt。
默认路由存在，为什么仍然不可达
最初排查时怀疑默认路由缺失，随后输出已经能看到带源地址条件的默认路由：
default from 2001:db8:1234:5600::4 via fe80::1 dev eth1 proto static metric 512 pref medium
default from 2001:db8:1234:5600::/64 via fe80::1 dev eth1 proto static metric 512 pref medium
排查中还临时补了一条普通默认路由：
ip -6 route add default via fe80::1 dev eth1 metric 1024
但 ping 仍立即返回 Network unreachable。此时继续叠加默认路由已经没有帮助，需要检查实际选路和策略规则。
先确认上游网关可达
ping -6 -I eth1 -c 3 fe80::1
三次请求全部收到回复，说明 OpenWrt 到上游网关的链路本地通信正常。IPv6 使用 fe80:: 开头的链路本地地址作为下一跳是正常现象；这里指定设备，是为了确定该地址属于哪条链路。
这一步只能确认网关可达，不能证明公网出口正常。
路由查询正常，发包却失败
ip -6 route get 2606:4700:4700::1111
输出示例：
2606:4700:4700::1111 from :: via fe80::1 dev eth1 src 2001:db8:1234:5600::1234 metric 1024 pref medium
出口、网关和源地址都已经选出，但普通 ping 仍失败。指定查询结果中的源地址后也一样：
ping -6 -I 2001:db8:1234:5600::1234 -c 3 2606:4700:4700::1111
上面的源地址只是脱敏示例，实际测试必须使用设备拥有的真实地址。
关闭 sing-box 后，故障也没有消失，因此继续检查策略路由。
关键证据：unreachable 规则
ip -6 rule show
现场输出：
0: from all lookup local
2061: from all fwmark 0x3d00/0x3f00 blackhole
2062: from all fwmark 0x3e00/0x3f00 unreachable
32766: from all lookup main
其中优先级 2062 的规则表示：mark 在掩码 0x3f00 下匹配 0x3e00 的流量，直接判定为不可达。它位于 main 表查询之前。
普通 ip -6 route get 查询没有指定 mark，也不会走一遍实际发包的防火墙打标过程。实际流量如果在输出路径中被打标，重新选路就可能命中这条不可达规则。这解释了为什么查询看似正常，ping 却立即失败。
针对现场这条规则，临时删除验证：
ip -6 rule del pref 2062
ping -6 -c 3 2606:4700:4700::1111
删除后恢复通信，确认了该规则与本次故障的直接关系。
这组规则与 mwan3 的规则形式一致。不过，现场没有继续保存打标链计数及完整 mwan3 配置，因此不能断言具体是哪项接口探测或策略设置导致流量进入不可达分支。规则本身也不是“只要存在就有故障”，关键在于流量为什么匹配它。
不需要多 WAN 时卸载 mwan3
如果还依赖多 WAN 分流或故障切换，应修正 mwan3 配置。本例选择不再使用它，下面是后续卸载步骤，未将其当作已经执行完成的结果。
先备份配置：
[ ! -f /etc/config/mwan3 ] || cp -p /etc/config/mwan3 /root/mwan3.conf.bak
停止服务并关闭自启动：
if [ -x /etc/init.d/mwan3 ]; then
/etc/init.d/mwan3 stop
/etc/init.d/mwan3 disable
fi
逐个卸载已安装的包：
for pkg in luci-i18n-mwan3-zh-cn luci-app-mwan3 mwan3; do
if opkg list-installed "$pkg" | grep -q "^$pkg "; then
opkg remove "$pkg"
fi
done
若出现依赖冲突，先检查依赖方；不使用强制删除，也不顺手移除其他服务可能共用的底层依赖。
然后检查：
ip -6 rule show
ping -6 -c 3 2606:4700:4700::1111
如果仍然残留与本文完全一致的规则，按完整条件删除：
ip -6 rule del pref 2061 fwmark 0x3d00/0x3f00 blackhole
ip -6 rule del pref 2062 fwmark 0x3e00/0x3f00 unreachable
规则不存在就跳过。不要清空整个策略路由表。合适时机重启后再检查一次，确认没有其他启动脚本重建规则。
清理临时路由
排查期间增加的 metric 1024 默认路由不是已验证的根本修复。确认 WAN6 自动默认路由存在后：
ip -6 route show default
删除对应的临时路由，再验证：
ip -6 route del default via fe80::1 dev eth1 metric 1024
ping -6 -c 3 2606:4700:4700::1111
如果这时又失败，需要单独排查自动路由和源地址选择。不要因为找到了一个问题，就假设其他配置一定正确。
下次遇到类似现象
对于立即报 Network unreachable 的情况，先检查本机路由和策略规则，比一开始就排查 DNS 或公网丢包更直接：
ip -6 route show default
ip -6 route get 2606:4700:4700::1111
ip -6 rule show
WAN 拥有 IPv6 地址、获得给 LAN 使用的委派前缀，以及拥有可用默认路由，是不同的状态。本例进一步说明：即使普通默认路由正常，带 mark 的策略规则仍然可以阻止实际流量。