moranno
moranno
好想法耶，如果能通过面板直接读取对接地址就更好了！
Hope to see this implement soon.
可以参考下@gfw-report的主动探测测试： https://github.com/XTLS/Xray-core/issues/625#issuecomment-955949568 向服务端发送指定大小的数据包，看服务端是否会有所返回，不过我刚刚想了下，这货是UDP啊，服务端响应是不是和TCP完全不一样？不太懂。
> > 若存在主动探测，连接的流程会以如下方式进行： > > > > 1. server 与 client 建立 QUIC 连接（需要证书与 ALPN 匹配） > > 我的疑问在于，在client和server第一次建立链接时，是否 alpn和sni信息还是明文的，而主动探测方做DPI拿到这些信息重发http/3请求，又没有得到正常的http响应，是否就能辨别该端口跑了一个quic协议但是不是web server的服务。可能未来这种服务会挺多，但是现在可能quic协议主要承载了http/3流量。 对...这其实也是一种重防攻击？不过关于重放攻击，TLS默认应该是防重放攻击的吧？
> 此次大批量封443，TUIC也中弹了 请问是你的tuic服务器中弹吗？部署tuic之前是否还运行过其他代理程序？ 还是别人的案例报告？
> > > 此次大批量封443，TUIC也中弹了 > > > > > > 请问是你的tuic服务器中弹吗？部署tuic之前是否还运行过其他代理程序？ 还是别人的案例报告？ > > 同一台vpc vmess+ws+tls+caddy封了443 然后弄了tuic，6小时内8443端口阵亡 然后又弄了vless+h2c+caddy，4443端口，到现在没被封，就是QOS的厉害 请问你的tuic是运行在8443上的吗？如果是udp8443，你如何测试的udp 8443被封呢？ 我之前的tuic也以为被封了，后来才意识到udp无法使用常规的telnet或者port.ping.pe来测试，再次查看发现只是服务端挂了，重启就好了，运行服务端，观察下是否能收到客户端发来的包。
> udp_relay_mode 模式只有客户端支持。 都是基于 QUIC协议的转发，native 模式是使用 QUIC 的 datagram，quic 模式是使用 QUIC 的 unidirectional stream。 前者受限于MAX_DATAGRAM_FRAME_SIZE，不能转发大于 1163 - 8 -（address length） 的 udp 包。后者不受限制。 > > ``` > { > "relay":...