RPRX
workflows 也不要动吧
看起来不会损坏现有功能，先合了，感谢 PR
https://github.com/XTLS/Xray-core/issues/4778#issuecomment-2939912442 @yuhan6665 我觉得虽然 Vision Seed 有这个能力，但是交给它做不合适，并不是所有 REALITY 都是 Vision，第一层有可能是 XHTTP 总之 REALITY 自身需要更新代码来解决该问题，这将会是 REALITY 缓存 target 特征机制的开端 *I think that although Vision Seed has this capability, it is not appropriate...
@Fangliding 估计是都被 Go 的 TLS 实现带偏了，不过服务端一次性把话说完挺好的，等 `ClientFinished` 后再发剩下的有点没必要 *I guess we've all been influenced by Go's TLS implementation, but it's good that the server says everything at once. Waiting for...
https://github.com/XTLS/Xray-core/issues/4778#issuecomment-2939977944 3xy 3xy 125 应该是比较典型的 OpenSSL 行为，我们先探测出这个长度并发个版，然后再研究 CF *3xy 3xy 125 should be a typical OpenSSL behavior. We first detect this length and create a version, then study CF.*
@yuhan6665 XHTTP 传输层是在 Vision 流控外面的，所以有传输层时 Vision 就控制不了整体流量特征了 Anyway，你现在有空写个简单的代码去探测这个 3xy 3xy 125 吗，大概就是用 Go 的 TLS 请求一下，外面套个 conn，等 C 发消息，等 S 发消息，等 C 发消息，然后开始记录 S 的 TLS record 长度，等个五秒，如果第三个 record 是...
@yuhan6665 有空的话把上面那个写成一个函数 PR 到 REALITY 仓库的 tls.go，应该很简单，剩下的我来，明天就可以发个版 ~~我就说当初写 REALITY 时咋发现有些网站不发 `NewSessionTicket`，原来是放 `ClientFinished` 后面了~~ *If you have time, please write the above as a function and PR it to the tls.go...
感谢 @ban6cat6 的发现，~~直到有人在 Xray-core 发 issue 我才看到这个~~，[Xray-core v25.6.7](https://github.com/XTLS/Xray-core/releases/tag/v25.6.7) 已经初步解决了该问题 此外我们还发现了不同 CH 指纹会触发不同长度的 `NewSessionTicket`（尚未彻底解决），以及很多服务器会提前发 h2 settings 帧（已经可以模拟，但尚未解决长度变化的问题），详细讨论见 https://github.com/XTLS/Xray-core/issues/4778 ，下一步方向是 https://github.com/XTLS/Xray-core/issues/4788 *Thanks to @ban6cat6 for discovering this. ~~I didn't see this until...
REALITY 被设计于可以搭配任何内层协议，而绝大多数内层协议并没有处理流量特征这种功能，尤其是人们将 REALITY 用于非代理用途时（非 VLESS 等代理协议），所以对于客户端简单握手就能引发 server 发的几个包，特征过于明显，REALITY 服务端应当模仿，目前的想法是如果内层是 XHTTP 这种时可以把 h2 settings 帧 padding 一下，长远来看的话借助 TLSv1.3 的 padding 功能，在 REALITY 层面控制整体的流量特征以符合 target server 的典型流量特征也是可以做的事情，从而无需内层协议关心这件事 *REALITY is designed to be...
**Xray-core uses uTLS's Chrome fingerprint by default, including DoH querys.**