[Bug]: Windows下使用tun模式时，若core为xray，stack=gvisor且路由为全局时无法正常工作

[je5442804]

预期情况

tun模式下正常上网，xray/sing-box core进程CPU/内存占用正常

实际情况

tun模式下无法上网，且sing-box.exe进程CPU/内存飙升

复现方法

win10/win11 环境下，tun设置为stack=gvisor, 关闭Strict Route以防其他bug，路由设置为全局，不改变默认core即xray，然后开启tun
必定造成sing-box.exe CPU 100%

日志信息

日志表明: 疯狂对节点的 IP:Port 收发包
....
from tcp:127.0.0.1:31291 accepted tcp:xxx.xxx.xxx.122:50100 [socks -> proxy]
from tcp:127.0.0.1:31291 accepted tcp:xxx.xxx.xxx.122:50100 [socks -> proxy]
from tcp:127.0.0.1:31291 accepted tcp:xxx.xxx.xxx.122:50100 [socks -> proxy]
.....

额外信息

stack=system或mixed时，配置任何路由（绕过大陆/黑名单/全局) 工作正常
stack=gvisor时,配置绕过大陆/黑名单工作正常，仅全局时会出现问题

疑似路由排除列表/进程排除列表不正确造成的死循环，尚不了解问题的根本原因
tun?
sing_box?
xray->sing_box?(感觉像这个)

可能很多人会说，用system/mixed就好了，
但某些电脑特殊情况下无法使用system/mixed,
例如Windows 防火墙服务损坏/被强制关闭 (mpssvc,mpsdrv)

1: 已测试多个节点，包括使用xray-core自建测试节点（Trojan, SS)，测试时系统代理均为"清除系统代理"，使用默认core xray(即xray->sing_box)
2: 已测试与Strict Route无关(这个似乎影响DNS那边?).
3: 已测试IPv6/Mtu大小 无关，测试的节点列表有些有IPv6，有些没有IPv6.
4: 已测试了两台不同环境的win10，两台不同环境的win11，测试了v2rayN v7.9.0, v7.9.2 ,xray/sing_box内核版本差距不大，都能够100%复现.
5: 已测试与是否开启UDP无关.
6: 只要手动指定节点core 为sing_box，则问题迎刃而解.

以前还偶尔遇到stack=gvisor时tun模式无法使用，重启v2rayN无效但重启电脑能够解决，不过已经无法复现了xd

的确有部分人注意到了，指定core为sing_box能解决部分tun问题，但没有深入了解为什么.
这不是一个必须修复的问题，但有必要了解到这种情况，并让用户广泛知晓，很多人不会在开tun时应优先手动指定sing_box解决疑难杂症.

我确认已更新至最新版本

• 是

我确认已查询历史issues

• 是