TGSAN

只有1909会这样吗，等有空的时候我试一下

> @TGSAN 估计规则匹配有问题，建议检查日志 第二段中： “不使用RULE模式，采用DIRECT模式结果仍然是这样”

``` 12-02 12:28:06INFO [UDP] 198.18.0.1:64382 --> stun.miwifi.com:3478 using DIRECT 12-02 12:31:24INFO [UDP] 198.18.0.1:64382 --> stun.stunprotocol.org:3478 using DIRECT 12-02 12:32:03INFO [UDP] 198.18.0.1:50950 --> stun.qq.com:3478 using DIRECT ``` `stun.miwifi.com:3478/stun.stunprotocol.org:3478/stun.qq.com:3478` 这三个

> @TGSAN qq那个域名是国内的，所以会匹配成直连 没有使用规则模式，是直连模式

> @ArchGuyWu 你看，全都是直连 因为是直连模式，不是规则模式

全局选DIRECT和直连都一样

> ### Meta版本开启TUN模式： > #### UDP使用SS协议： > * NatTypeTester 测试结果为 UnsupportedServer > * 实际端口穿透测试（通过WebRTC）： > 对端 FullCone：可以连接 > 对端 RestrictedCone：可以连接 > 对端 PortRestrictedCone：无法连接 > 对端 Symmetric：无法连接 > 结论：猜测实际为Symmetric NAT >...

> @TGSAN 看了一下你先前的回复，大概明白了，direct模式下NAT等级取决于自身网络，所以用不用clash区别不大，需使用代理节点才能提高NAT等级 是，但是原始网络环境已经是FullCone了，开启TUN模式直连不应导致降级。同时代理服务端支持FullCone的情况下开启TUN也不应降级。

> 我这里meta开启tun模式（clash verge windows），使用NatTypeTester测试结果一样也为UnsupportedServer，看了下分流日志udp分流是正确的（走了代理）。另外使用V2rayN测试NAT类型为FullCone，排除节点本身的udp问题，看来meta核心在这块的确有点问题 其实用DIRECT模式复现是最能说明问题的，之前发现这个问题其实是发现STUN测试NAT类型有问题，然后想着直接加一条规则，把STUN全走直连试试，结果还是有问题。

I have a recreated YouTube client that is very lightweight (less than 500 KiB) and requires no installation. Although it only supports Windows, it has been actively maintained for 4...