RPRX
> without any processing on the browser side, reaching its theoretical maximum performance 是因为用了流式 API 吗？~~话说如果只考虑 Chrome 的话 stream-up 也可以兼容了~~
XHTTP 的 header padding 只有在外层是 TLS/REALITY 时才有意义，不然都被看光了，padding 与否没区别 不过随着 VLESS 出了 Encryption，这个话题可以继续，reopen 作为默认禁止公网未加密流量的 reminder，2026 就禁吧
我知道，但 2026 默认禁了公网未加密流量后，https://github.com/XTLS/Xray-core/issues/4875#issuecomment-3049602566 提到的“这东西不安全”就不存在了 只要内层是 VLESS Encryption，攻击者去改外层明文 XHTTP 也不会影响被代理的数据的安全
伊朗自有国情在，限速 TLS 却不管明文 HTTP，就是逼着你用，再加上伊朗有对时问题（我也不太理解这是个什么问题，好像因为默认采用什么计时标准导致时间戳差半天？@gfw-killer ），用不了需要对时的加密，结果都用明文 VLESS 了 我的意思就是以前开放的话会有很多人开始用 XHTTP h2c + plain VLESS，不安全，但是出了 Encryption 并禁了公网未加密流量就好了
不应当由 Xray-core 定义什么是 “online”，应当返回所有用户的最后在线时间以及最近几个 IP、流量统计，一个命令解决所有问题
不过这个是基于 onlineMap 吗，我还没看那个是什么，总之这个 PR 不急着合并，流量统计本身就能定义是否 online
不会支持 Clash API，因为其它支持的软件也并没有取代了 Mihomo 成为 Clash UI 的默认内核 但是你提的功能可以有，还有每个连接的状态啥的，早就想做了，只是目前重点不在这块
@0x3mp7y 我看了那个 issue，我感觉是那个运营商针对了 Vision 现有代码中的 padding 参数，你可以自行修改它们并编译、测试 不会改的话也没关系，Seed 月底就出了，并且我在考虑下个版本要不要同时修改一下默认 padding 参数，它们已经三年了
> I tried disabling flow what so ever on tests, but without adding a MUX that wouldn't help. So not sure about that. Mux 不仅能减少连接数，还有混淆流量特征的效果，再加上你在原帖中的描述，所以我是那么猜的 > The bad thing that...
不算是 uTLS 的问题，~~虽然可以弄个参数把 X25519MLKEM768 关掉但感觉没必要，支持的网站会越来越多~~