ros路由器+adhome+mosdns+mihomo实现双栈网络环境(ipv4&ipv6)-网络延迟排障

我在排查一个比较奇怪的旁路由延迟问题，想请教大家有没有遇到过类似情况。

一、我的目标架构

我想实现的是：

• RouterOS 继续做全家默认双栈主路由

• IPv6 继续由 RouterOS 原生处理

• AdGuardHome + MosDNS 作为统一 DNS 中枢，尽量避免 DNS 泄漏，并兼容 IPv4/IPv6 共存

• Mihomo 只负责被选中设备的 IPv4 出国流量

• 终端设备尽量无感切换，不想手工改每台设备的网关

也就是说，我想做的是：

• 普通设备：正常走 ROS

• 指定设备：ROS 通过 policy route 把它们的 IPv4 流量旁路到 Mihomo

• 但 DNS 仍然由 AdGuardHome + MosDNS 统一管理

二、当前网络环境

• 主路由：RouterOS RB5009

  • LAN：192.168.5.1/24

• DNS：dns-core = 192.168.5.3

  • 跑 AdGuardHome + MosDNS

• Mihomo：

  • LXC：113 / 192.168.5.2

  • VM：109 / 192.168.5.2

• 测试设备：

  • Win11：192.168.5.249

当前旁路方式是：

• RouterOS 建 PROXY_V4 路由表

• 对 PROXY_V4_CLIENTS 中的设备，在 prerouting 用 mark-routing

• PROXY_V4 的默认路由 next-hop 指向 192.168.5.2

也就是典型的：

• 终端默认网关仍是 192.168.5.1

• 但被选中的 IPv4 流量被 ROS 送去旁路由 192.168.5.2

三、现象

最奇怪的是：

1. 直接走 AdGuardHome → MosDNS 没有这个 7~9 秒延迟

2. 终端如果直接把网关和 DNS 改成 192.168.5.2，国内网站也是秒开

3. 只有在 ROS 用 policy route 把流量旁路到 192.168.5.2 时，国内站会出现首包延迟

例如 Win11 上执行：

curl -I -L -o NUL -s -w "namelookup:%{time_namelookup} connect:%{time_connect} starttransfer:%{time_starttransfer} total:%{time_total}\n" http://www.baidu.com

结果大概是：

• Win11 不在 PROXY_V4：很快

• Win11 在 PROXY_V4：starttransfer 常见 7s ~ 9.6s

• Win11 直接把网关改成 192.168.5.2：又变快

所以现象可以总结成一句：

Mihomo 本身不慢，DNS 本身也不是主矛盾，只有"ROS policy route 到同网段旁路由"这条链路会卡。

四、已经做过的排查

我已经排过这些方向：

• 更换 Mihomo DNS 上游

• 调整 Mihomo DNS / fake-ip / redir-host / sniff / tun / QUIC 相关项

• 验证 AdGuardHome / MosDNS 解析链

• 分别测试 LXC 版 Mihomo 和 VM 版 Mihomo

• 调整 PVE 宿主机 bridge/veth/offload

• 关闭部分 offload 后延迟有过改善，但不能根治

• 换成 VM 后问题依旧，不是单纯 LXC 特有问题

五、最关键抓包结论

无论在 LXC 还是 VM 中抓包，都看到类似现象：

• Win11 发 SYN

• 服务器几乎立刻回 SYN,ACK

• Mihomo 主机也立刻把 SYN,ACK 发回 Win11

• 但 Win11 往往要过 约 7 秒 才真正回 ACK

• ACK 之后，后面的 HEAD /、HTTP/1.1 200 OK 都很快

所以我目前的判断是：

慢的不是 DNS，不是目标站响应，不是 Mihomo 出口，而是 TCP 三次握手最后一步。

更具体地说：

服务端回来的 SYN,ACK 已经到了旁路由，但客户端没有及时确认。

六、我目前对根因的怀疑

我怀疑根因在于：

RouterOS 通过 policy route 把流量送到同网段的旁路由 192.168.5.2 时，形成了不对称回程。

当前结构是：

• Win11：192.168.5.249/24，默认网关 192.168.5.1

• Mihomo：192.168.5.2/24

• ROS 把 Win11 的 IPv4 流量送去 192.168.5.2

于是可能形成：

• 去程：Win11 → ROS → Mihomo

• 回程：Mihomo → Win11

也就是旁路由发现客户端跟自己同网段，就直接回客户端，不再回主路由。
我怀疑这导致了：

• conntrack / 回程路径不一致

• 或某种同网段旁路的实现细节问题

• 从而导致 TCP 握手最后 ACK 明显延迟

七、我接下来打算怎么验证

我现在考虑不再让 Mihomo 与客户端处于同网段，而是：

• PVE 第二块物理口 enp5s0

• 直接连 RouterOS ether7

• 建一条专用 transit 链路，例如：

  • ROS：192.168.6.1/30

  • Mihomo VM：192.168.6.2/30

这样路径强制变成：

• 去程：Win11 → ROS → Mihomo

• 回程：Mihomo → ROS → Win11

也就是把潜在的不对称回程排掉。

八、想请教大家的问题

1. 有没有人遇到过：

   • RouterOS mark-routing + 同网段旁路 next-hop

   • 导致国内站 TCP 首包延迟 7~9 秒

   • 但终端直接把网关改成旁路由后又恢复正常

2. 这种现象是否更像：

   • 同网段旁路不对称回程

   • conntrack 问题

   • rp-filter 问题

   • 还是 RouterOS policy routing 的某种限制/坑

3. 对我这种目标架构：

   • ROS 继续做双栈主网关

   • DNS 继续统一由 AdGuardHome + MosDNS 管

   • Mihomo 仅处理被选中的 IPv4

   是不是更推荐：

   • 不要让旁路由与客户端同网段

   • 而是给 Mihomo 一条单独 transit 网段/物理链路

10 个帖子 - 3 位参与者

阅读完整话题