liandu2024：v0.1.243 及之前在纯 tun 模式下会整份丢掉扣过段的旁路集合，v0.1.244 已修
在定位一台设备旁路失效时给出两点结论：一是该设备运行在「纯 tun（兼容）」模式，auto_redirect 的 nftables 规则起不来时面板会自动降级再起一次；而 v0.1.243 及之前在纯 tun 下会把扣过段的旁路集合整份丢掉，默认分流的 geoip-cn 与 geoip-private 恰好都是扣过段的，于是一份都没旁路、白名单也不会启用，规则页却仍写着「已配置」，他称这是缺陷并已在 v0.1.244 修好，纯 tun 也改用扣段后的集合编进路由表。二是连接被 DNAT 到 192.168.2.2:7892，而 7892 是 OpenClash / ShellCrash 一类插件的默认透明代理端口，他判断设备上还有别的代理插件在跑，其规则让 auto_redirect 起不来并先把流量截走，建议停用该插件后重启内核。
作者原文@liandu2024谢谢,文字证据把原因定死了,两件事:
1. 你这台 Open-Box 跑在「纯 tun(兼容)」模式——「入口模式:纯 tun」「nft 里当前没有旁路集合」、
nft list set报 No such file、meta 里没有 entryMode,都指向这一点。auto_redirect 的 nftables 规则起不来时,面板会自动降级成纯 tun 再起一次(内核卡片应该有一条「auto_redirect 起不来,已改用纯 tun 模式」的警告)。而 v0.1.243 及之前在纯 tun 下把扣过段的旁路集合整份丢掉了——默认分流的 geoip-cn / geoip-private 恰好都是扣过段的,所以一份都没旁路、白名单也不会启用,规则页却还写「已配置」。这是我们的缺陷,v0.1.244 已修:纯 tun 也用扣段后的集合(编进路由表),规则页「业务入口」会写明「路由表」和「纯 tun 只用黑名单」的原因。请先升到 v0.1.244。2. 更关键的:是谁把连接改写到了 7892? conntrack 那行显示连接被 DNAT 到
192.168.2.2:7892。Open-Box 的重定向端口是随机高位端口(比如 33897),7892 是 OpenClash / ShellCrash 一类插件的默认透明代理端口。N1 上多半还有别的代理插件在跑,它的 nft / iptables 规则让 sing-box 的 auto_redirect 起不来(所以才降级),并且把流量先截走了。麻烦确认一下,贴文字:netstat -lnp | grep 7892 ps | grep -iE "clash|mihomo|passwall|ssr|shellcrash" | grep -v grep把那个插件停掉(或卸掉)之后重启 Open-Box 内核,内核卡片的降级警告应该消失;再用规则页测
test.ustc.edu.cn,右栏「业务入口」应该是「已旁路」。停掉 Open-Box 能跑 578M 说明硬件够,进用户态(不管是哪个插件的)就是 200M 左右,只有入口旁路真正生效才能回到接近 578。