RPRX
~~我还想让 VLESS 出站也能返回个 reader / writer，这样可以把客户端 outbound reverse 那个 pipe 给省掉~~
我觉得 VMess inbound 倒是无所谓，只是往 Mux/Reverse 再加 pipe 这种事情尽量避免吧
> Vless 不需要应该被视为是一个特例。 感觉有点怪，难道是因为 VLESS 的加解密是额外的 Read/Write？
有更多的人正视并尝试解决这个问题总归是好事，其实 Vision 也有 Seed https://github.com/XTLS/Xray-core/pull/3260 ，只是 Xray 现在主要在解决其它问题 *It is always good to have more people facing and trying to solve this problem. In fact, Vision also has Seed https://github.com/XTLS/Xray-core/pull/3260,...
目前来说 Hysteria 等协议的目标是 **通过激进的发包策略来提升弱网环境的代理可用性**，但是有以下缺点： 1. 激进发包其实就是抢资源，会弱化其他人的体验，**如果大家都用，那只会更爆炸** 2. 它们的目标不是抗封锁，社区也没有 GFW 对 QUIC 动手的历史数据，尚不清楚 GFW 会如何针对性封锁这些协议 所以可以再观望一下，尤其是第一点要想清楚，这就跟补习一样，别人补，你看了也想补，最后大家都补了，就成了无意义内卷，而且既然它们成了主流，GFW 就会研究它们和普通 QUIC 的不同，最后大家只能回归普通 QUIC，~~反正预言是放这儿了~~
https://github.com/XTLS/Xray-core/issues/3547#issuecomment-2232800832
https://github.com/XTLS/Xray-core/issues/3547#issuecomment-3549896520
@shakibamoshiri 我部分支持你的看法，比如说我觉得对 Xray-core 来说，相比于努力引入一个又一个不同的协议但随着时间的推移、后续维护乏力等原因导致跟不上新版本，不如专注于把 VLESS 打造成全场景覆盖的协议并认真维护，显然性价比更高、更可持续 但是有两个例外，一是过于通用的协议，二是 Xray 出站会加被机场普遍使用的协议，Hy2 就属于这种，并且被 Q 麻了危害也不大了
> Therefore, please prevent blocking by randomizing the xpadding. 我们的意思很明确，等这样的 blocking 出现后再采取措施规避它
> However, if your intention is for me to wait until they block and then report it, that's fine, and I'll wait. Exactly.