RPRX

> > > [v2fly/v2ray-core#239](https://github.com/v2fly/v2ray-core/pull/239) > > 具体改变：每个 UDP 载荷前加两字节长度的 length，最大值为 2048-2=2046。若不使用 Mux，服务端与客户端均需升级至 v4.30.0+。这是 VLESS 公测版（0）协议结构本身唯一一次 breaking change，正式版（1）的服务端预计会长期同时支持该版本，第三方客户端的实现应当尽快跟进。 > > 公测版的协议结构就这样了，正式版的服务端预计会长期同时支持它（我大概过年有空再实现 XUDP，也即 VLESS 正式版）。 对了，这一条是为了提醒这个 PR 的 UDP 格式需要跟上 VLESS 的新格式，不是催促合并，至少需要先修改，否则会出现问题

> > > 如果进行版本分发,请在分发时停止对上游的同步 需要修改 clash 的 license

@Ehco1996 有开新架构的计划，暂定 Xray-next VLESS 协议结构请搜索“VLESS BETA” VLESS 正式版计划扔掉 pb，五个指令：tun、xudp、tcp、xtls、smux（或者 xudp 也靠 smux）

已知此版本的 fallbacks xver 可能不会生效，https://github.com/XTLS/Xray-core/commit/8ffc43035179964e8472486339b220ffccafed29

我是 RPRX，对于 Anti-Censorship，我致力于不断将新颖、有趣的灵感付诸实践。 我客观地经历了整件事，基本认同 issue 所述的内容和观点。 一直以来，我注意到全球范围内，每天都在涌现新的代理工具，但是这些工具大多是研究型的，没有得到大规模应用、经历检验。 **而在中国，有很多行之有效且流行的代理工具，它们得到了难以想象的大规模应用，并且还在对抗中不断迭代、进化。** 与此同时，这带给了我们丰富的经验、敏锐的嗅觉与判断能力。 所以我想说的是，在 Anti-Censorship 领域，来自中国的研究人员的声音非常、非常、非常重要，这应当成为共识。 ---- Machine translation added by @wkrp: *I'm RPRX, and I'm committed to constantly putting new and interesting ideas...

And VLESS Protocol: https://github.com/v2ray/v2ray-core/issues/2636 https://www.v2fly.org/config/protocols/vless.html#fallbackobject https://github.com/v2fly/v2ray-examples/tree/master/VLESS-TCP-TLS-WS%20(recommended)

When working over TLS, VLESS protocol supports pure TLS, WebSocket, and even fake HTTP header at the same time. Also, when using WebSocket or fake HTTP header, users are able...

Another lightweight way is fake HTTP header, it's HTTP PATH can be recognized by VLESS when VLESS handling TLS at the server side.

https://www.v2fly.org/config/transport/tcp.html#httpheaderobject

感谢提供一个新颖的思路：某些情况下 TLS 会发送 Alert 但不关闭 TCP 连接。不过这种方式受到的限制也比较明显： 1. TLSv1.3 后续指令/数据均采用 data record 的标识符 23（即使是 Alert），且 TLSv1.3 允许 padding，这些都会干扰判断 2. 如标题所述，这种方式只针对 Origin 模式；如内容所述，Firefox 和 curl 才会受影响（但不确定其它 TLS 应用的行为） 3. 如内容所述，这种方式对 TLS...