RPRX
如果发现存在其它问题，也请直接反馈 比如目前发现任意门 TPROXY 那里不能缓存 conns，只能发一个包就 close，否则行为会异常，等下打算看看把 dial 改为 listen 的表现
> > 用action里的版本试一试 > > 就是用的 action 里最新版本测试的。 那试试 v1.8.9 @Fangliding https://github.com/XTLS/Xray-core/pull/3152#issuecomment-2002900794 这个你重测了吗
如果只是 HTTPUpgrade 0-RTT 配合 Caddy 有问题，代码里加个 100ms 延时应该就解决了，~~但我觉得更应该 PR 修改 Caddy 的代码~~
之前我看大猩猩的 WS 服务端是不允许客户端握手后面直接跟着数据，那些反代和 CDN 如果在 HTTPUpgrade 后就只是纯转发流量的话应该无此限制，有限制的话加个延时可以解决，但是我更想把 0-RTT 改成首包粘包，~~所以还是去 PR 修改 Caddy 的代码吧~~
> 哦，看来我的猜测正确的， HTTPUpgrade 0-RTT 的兼容性无法等同 WebSocket 0-RTT。 是的，就像 HTTPUpgrade 的兼容性无法等同 WebSocket 我说一下吧，**直连不要用这两个传输方式，过 CDN 才要，所以 0-RTT 的实现兼容 CDN 就够了，自己的服务器端要用兼容的反代软件**
Pin 了，加粗那句话麻烦写到这两个传输方式的文档里 @Fangliding
> ~我觉得说明一下httpupgrade的兼容问题就行了吧 没啥人踩坑的情况下不用加那么多指导~ ~~防止大聪明们想玩 HTTPUpgrade 直连，就像去年 WebSocket 直连的小白们被封麻了，说了好多遍不要用了才消停~~
ECH 不能结合 uTLS 的话不太实用，~~去给 uTLS PR 个 ECH 吧，应该不难~~
所以有时间研究给 uTLS 加 ECH 吗，就是说 ECH 不就是把真实 Client Hello 加个密吗，有客户端配置即加密参数的话很简单吧
看了下 https://github.com/golang/go/issues/63369#issuecomment-2083070008 ，"We're planning on server support in 1.24."，~~然而对 Xray 来说似乎只需要 client support~~