TGSAN
原理上可以，只是需要做移植才能跑
> sing-tun 添加的是“允许”的规则，与你的防火墙默认拦下了其他流量没有关系。检查 TUN 网卡是否是“专有网络”，放行 NAT 测试软件，并且检查确保没有其他防火墙规则的影响。 1. TUN 网卡为 公用网络  2. NAT 测试软件是放行的，不然不会出现删除 sing-tun 规则重加就会变成 Full Cone 的情况，同时也不会出现 mihomo 全局走 proxy 是 Full Cone，而全局走 DIRECT 又是 Port Restricted...
> sing-tun 添加的是“允许”的规则，与你的防火墙默认拦下了其他流量没有关系。检查 TUN 网卡是否是“专有网络”，放行 NAT 测试软件，并且检查确保没有其他防火墙规则的影响。 另外，sing-tun 添加的是 TCP “允许”规则，而非 UDP “允许”规则，但是由于已经定义了自定义规则而非系统的进程规则，所以也不会有系统弹窗提示新增规则。  在这种情况下变为了 TCP 允许入站，UDP 阻止入站
> 默认创建的适配器是“公用网络”的，修改为“专用网络”需要手动进行，所以添加的规则也仅针对“公用网络”。 首先这个issue始终就和公用网络还是专用网络无关，TUN适配器类型只影响bind在这个适配器上的应用层行为，而mihomo是bind在物理适配器上，且物理适配器即使是专用网络，也不能改变默认入站行为。
不加任何规则=需要用户自行选择 只加入TCP放行=阻止用户选择并拦截UDP。 既然目前的行为已经影响到用户自主选择了，那么“自行添加防火墙规则”本身也站不住脚
> 意思是默认添加的规则阻止了进一步的弹窗的出现吗？如果是这样的话那建议是在 metacubex/sing-tun 另外加一个不操作防火墙的选项或者直接删掉这个功能让用户自行处理。 是这样的，如果添加了规则就会阻止用户选择的弹窗出现，另外由于 sing-tun 添加规则的方式比较特殊，会导致控制面板里的“允许的应用”的删除按钮变成灰色（根据文档来说如果应用接管防火墙设置，而不是追加就默认不允许用户修改），只能在高级防火墙设置才能删除。  
没有在 sing-tun 里提的原因是，因为考虑到代码同步问题，可能未来和上游同步时会变得麻烦起来。还有就是不确定 mihomo 目前依赖的是原始仓库还是 fork，另外就是 fork 仓库里关闭了 issues 功能。
一直说的是 sing-tun 的防火墙规则影响 mihomo，与 tun 功能本身完全无关，建议先看完再说。只要这个规则被写入，那么会影响所有 mihomo 的 direct 出站。比如只要当前路径下开过 tun，那么以后这个路径下的 mihomo 作为服务端也会变成 port res 的 nat 行为。
如果你认为不会造成这样的行为，你可以重置 Windows 防火墙后，按照重现方式复现。这是 issue 而不是 discussion，不要讨论无关内容，谢谢。
Same problem in CodeX VSCode plugin v0.4.47 with gpt-5.1-codex-max