移动和电信，帮忙测试下 quic

@LnTrx 这个穿透的 nat 位于美帝，有点不可思议

@LnTrx
目标 IP: <a href="172.67.3.188">172.67.3.188</a>

1 172.18.37.209 0 ms 0 ms 0 ms 局域网 *
2 192.168.1.1 3 ms 4 ms 4 ms 局域网 * EchoLife_WAP.lan
3 100.x.x.x 6 ms 9 ms 11 ms 共享地址 *
4 223.x.x.x 4 ms 4 ms 7 ms 中国 江苏 chinamobile.com 移动
5 183.207.x.x 5 ms 5 ms 17 ms 中国 江苏 chinamobile.com 移动
6 183.207.x.x 7 ms 7 ms 7 ms 中国 江苏 chinamobile.com 移动
7 183.207.x.x 21 ms 22 ms 27 ms 中国 江苏 chinamobile.com 移动
8 * * * *
9 * * * *
10 * * * *
11 * * * *
12 * * * *
13 * * * *
14 * * * *
15 172.67.3.188 105 ms 106 ms 108 ms CLOUDFLARE.COM cloudflare.com AS13335

@titanium98118 #20
@sky96111 #12
@cwbsw #5

实测，关闭 ss 代理，把 v 的解析写入 hosts， 通过 quic 可以直连 v，无 sni 阻断。sni 阻断只针对 tcp 连接。

貌似 quic 有些 bug，第一次连接需要 http2 支持，即 tcp 支持。当第一次链接成功后，第二次再刷新，就变成了 http3.
也没有搜索到相关的资料。

@guanyin8cn
可能和这个东西有关。
Support for HTTPSSVC records in DNS.
When enabled, Chrome may query a configured DoH server for HTTPSSVC records. If any HTTPSSVC records are returned, Chrome may upgrade the URL to HTTPS. If the records indicate support for QUIC, Chrome may attempt QUIC on the first connection. – Mac, Windows, Chrome OS, Android

#dns-httpssvc

"Answer": [
{
"name": "v2ex.com.",
"type": 65,
"TTL": 299,
"data": "1 . alpn=h3-29,h3-28,h3-27,h2 ipv4hint=104.20.9.218,104.20.10.218,172.67.3.188 ipv6hint=2606:4700:10::6814:9da,2606:4700:10::6814:ada,2606:4700:10::ac43:3bc"
}
]

@LnTrx #19
我把 我自己的一个域名，指向 104.20.10.218 ，发现确实有针对特定 i p 和特定协议有流量穿透。不过这流量穿透到美帝有点不可思议啊。会不会是 cf 自己搞的流量穿透？

@v2clay 流量穿透应该是运营商的行为，穿透的出口应该是香港，只不过这几跳可能被隐藏了