如题。小弟的路由器是华硕be86u，还有个小旋风v2组ai mesh，我想实现ps5的netflix,spotify,discord这几个流量可以被mc2接管，其他流量由uu接管，现在是只要一开启uu他就自动接管全部流量，关闭了才可以走mc2，想问问各位大佬有没有什么思路或者建议方法。
附上这几天和AI尝试的总结 已经尝试过的方法 MC2 按 PS5 来源 IP 选择代理策略 日志能看到部分连接命中 PS5 的 SrcIPCIDR 规则，并使用指定代理节点。 但这只能证明进入 MC2 的连接可以正确选择策略，不能证明 PS5 所有相关流量都被接管。 单独接管 Spotify 的 IP 和端口 最初针对观察到的 Spotify 地址和 TCP 4070 添加 TPROXY 规则，有命中，但覆盖不足。 后来改用 dnsmasq＋ipset：通过域名解析动态收集应用 IP，再对 PS5 发往集合内地址的 TCP／UDP 流量做 TPROXY。Spotify 曾恢复播放，MC2 日志也能看到相关连接。 扩展应用域名集合 增加了 Spotify、Discord、Netflix 相关域名，包括 netflix.com、netflix.net、nflxvideo.net 等。 使用额外的临时 dnsmasq 实例： 23553：最初的 Spotify 测试。 23554：后续多个应用的测试。 上游指向 MC2 DNS 23453。 PS5 的 UDP 53 通过 DNAT 转到临时实例。 DNS 日志能看到部分域名解析成功并加入 ipset，但未证明覆盖完整。 手动调整防火墙和策略路由顺序 UU 启动后，会把针对 PS5 的 MARK、RETURN 等规则放到前面，导致后面的 MC2 接管规则无法匹配。 NAT 表也出现 UU 的 DNS 重定向排在临时 DNS 规则之前的情况。 手动调整后曾恢复部分功能，但 UU 再次启动又可能改变顺序。 扩大到 PS5 的全部 TCP／UDP 80、443 为排除单纯的 ipset 漏地址问题，临时把 PS5 发往非本地网段的 TCP／UDP 80、443 都交给 MC2。 TCP 443 有明显命中，MC2 中也能看到 Netflix 视频 CDN 的 TProxy 连接，选择了预期节点，但 Netflix 仍不能稳定播放。 当时 UDP 80／443 规则计数为零，尚不能据此判断是没有对应 UDP 请求，还是流量没有经过这些规则。 观察到的具体冲突 UU 启动后，曾出现以下顺序： mangle PREROUTING：PS5 的 UDP MARK → PS5 的 RETURN → 我们添加的应用 TPROXY → MC2 原有链。 nat PREROUTING：PS5 DNS 转向 UU 指定的 DNS → PS5 RETURN → 临时 DNS 重定向。 策略路由：UU 的 PS5 路由规则排在用于 MC2 本地接收的标记规则之前。 MC2 使用的标记为 0x2333，对应表 233，表内为 local default dev lo。UU 使用了表 179、表 163，后者指向 tun163，相关标记为 0x163。 曾手动把 PS5 的 fwmark 0x2333 lookup 233 调到更高优先级，也把 TPROXY 和临时 DNS 规则移到前面。 不过，后期顺序调整正确、扩大端口接管后，Netflix 仍出现失败，因此不能认定规则顺序是唯一原因。 目前的实际结果 Spotify：曾在 UU 与 MC2 同时运行时恢复播放，但没有长期验证。 Discord：只观察到 TCP 连接进入 MC2，没有实际测试语音。 Netflix：可以登录、浏览内容，但曾卡在 25%；有时当前剧集能播放，换新剧集又失败。 换代理节点没有稳定解决问题，期间出现过 NW-2-5，网络检查也出现过 NW-2-5-1。 曾发现四个 Netflix 视频连接的目标 IP 不在 ipset 中，说明当时确实存在地址覆盖遗漏。 临时扩大到全部 TCP／UDP 80、443 后，仍有播放失败。 在保留 MC2 和当时临时接管规则的情况下，停止 PS5 的 UU 加速，Netflix 随后可以播放。 因此目前怀疑 UU 启用时的 DNS、路由或其他处理与故障有关，但尚未定位完整原因。 另外，Switch 2 不开 UU 时曾报 2110-3131，开 UU 后能联网。还没有完成“UU 与 MC2 都关闭”的对照测试，暂时不确定是否与 PS5 是同一问题。 以上 SSH 修改都是临时测试，没有做开机持久化；尚未完成清理后及多次重启后的完整复测。
附上这几天和AI尝试的总结
已经尝试过的方法
MC2 按 PS5 来源 IP 选择代理策略
日志能看到部分连接命中 PS5 的 SrcIPCIDR 规则，并使用指定代理节点。
但这只能证明进入 MC2 的连接可以正确选择策略，不能证明 PS5 所有相关流量都被接管。
单独接管 Spotify 的 IP 和端口
最初针对观察到的 Spotify 地址和 TCP 4070 添加 TPROXY 规则，有命中，但覆盖不足。
后来改用 dnsmasq＋ipset：通过域名解析动态收集应用 IP，再对 PS5 发往集合内地址的 TCP／UDP 流量做 TPROXY。Spotify 曾恢复播放，MC2 日志也能看到相关连接。
扩展应用域名集合
增加了 Spotify、Discord、Netflix 相关域名，包括 netflix.com、netflix.net、nflxvideo.net 等。
使用额外的临时 dnsmasq 实例：
23553：最初的 Spotify 测试。
23554：后续多个应用的测试。
上游指向 MC2 DNS 23453。
PS5 的 UDP 53 通过 DNAT 转到临时实例。
DNS 日志能看到部分域名解析成功并加入 ipset，但未证明覆盖完整。
手动调整防火墙和策略路由顺序
UU 启动后，会把针对 PS5 的 MARK、RETURN 等规则放到前面，导致后面的 MC2 接管规则无法匹配。
NAT 表也出现 UU 的 DNS 重定向排在临时 DNS 规则之前的情况。
手动调整后曾恢复部分功能，但 UU 再次启动又可能改变顺序。
扩大到 PS5 的全部 TCP／UDP 80、443
为排除单纯的 ipset 漏地址问题，临时把 PS5 发往非本地网段的 TCP／UDP 80、443 都交给 MC2。
TCP 443 有明显命中，MC2 中也能看到 Netflix 视频 CDN 的 TProxy 连接，选择了预期节点，但 Netflix 仍不能稳定播放。
当时 UDP 80／443 规则计数为零，尚不能据此判断是没有对应 UDP 请求，还是流量没有经过这些规则。
观察到的具体冲突
UU 启动后，曾出现以下顺序：
mangle PREROUTING：PS5 的 UDP MARK → PS5 的 RETURN → 我们添加的应用 TPROXY → MC2 原有链。
nat PREROUTING：PS5 DNS 转向 UU 指定的 DNS → PS5 RETURN → 临时 DNS 重定向。
策略路由：UU 的 PS5 路由规则排在用于 MC2 本地接收的标记规则之前。
MC2 使用的标记为 0x2333，对应表 233，表内为 local default dev lo。UU 使用了表 179、表 163，后者指向 tun163，相关标记为 0x163。
曾手动把 PS5 的 fwmark 0x2333 lookup 233 调到更高优先级，也把 TPROXY 和临时 DNS 规则移到前面。
不过，后期顺序调整正确、扩大端口接管后，Netflix 仍出现失败，因此不能认定规则顺序是唯一原因。
目前的实际结果
Spotify：曾在 UU 与 MC2 同时运行时恢复播放，但没有长期验证。
Discord：只观察到 TCP 连接进入 MC2，没有实际测试语音。
Netflix：可以登录、浏览内容，但曾卡在 25%；有时当前剧集能播放，换新剧集又失败。
换代理节点没有稳定解决问题，期间出现过 NW-2-5，网络检查也出现过 NW-2-5-1。
曾发现四个 Netflix 视频连接的目标 IP 不在 ipset 中，说明当时确实存在地址覆盖遗漏。
临时扩大到全部 TCP／UDP 80、443 后，仍有播放失败。
在保留 MC2 和当时临时接管规则的情况下，停止 PS5 的 UU 加速，Netflix 随后可以播放。
因此目前怀疑 UU 启用时的 DNS、路由或其他处理与故障有关，但尚未定位完整原因。
另外，Switch 2 不开 UU 时曾报 2110-3131，开 UU 后能联网。还没有完成“UU 与 MC2 都关闭”的对照测试，暂时不确定是否与 PS5 是同一问题。
以上 SSH 修改都是临时测试，没有做开机持久化；尚未完成清理后及多次重启后的完整复测。
复杂情况下考虑分流，比如单独设备用来加速或者旁路由用来分流，最好是单独一个路由给ps5或者其他设备使用uu
@zns311 #2 之前是这样的，但是uu没法看网飞和听歌，还是想在尝试一下哈哈
@ZzzyT #3 直接加设备，接入随便一个openwrt就行了