Xray-core v24.9.16: https://github.com/XTLS/Xray-core/releases/tag/v24.9.16

💬 New comment on Xray-core#3823 xmux for grpc and h2
by @RPRX

大概就是建议迁移至 xhttp 和 xgrpc，2025 移除 h2 和 grpc

Reply to this message to post a comment on GitHub.

💬 New comment on Xray-core#3816 REALITY: Unblock SplitHTTP transport
by @RPRX

@mmmray 你研究下 chrome 支持的 streaming request，支持 browser dialer，把 SplitHTTP 重命名为 XHTTP，加个参数 mode，现在的两种分别为 splitupload 和 normalupload，结合 REALITY 时默认后者否则默认前者，我写一下可以在 path 中配置这些参数

Reply to this message to post a comment on GitHub.

Xray-core v24.9.19: https://github.com/XTLS/Xray-core/releases/tag/v24.9.19

💬 New comment on Xray-core#3823 xmux for grpc and h2
by @RPRX

~~我是觉得有时候你们想得太多或想得不够多~~

先说下 h2 传输层，v5ray 已经删了，REALITY 救了它一命，不然用的人不会比 QUIC 传输层多多少，且跨代理软件时人们更喜欢用 grpc 传输层。XHTTP streaming request 就跟 h2 传输层差不多，分离的请求与响应以支持 chrome（browser dialer）和那些反代软件，加了 header padding，我觉得 h2 传输层实在没必要留下来对比，此外支持 xmux，~~话说 xmux 好像还没考虑 browser dialer~~

然后是 grpc 传输层，毫无疑问 xgrpc 经过设置一定能兼容现有的 grpc，我只是想改个名~~以避免名称滥用（虽然当初是我建议的但那才符合 v2 的习惯）~~，也能一目了然让大家知道这是 Xray 的增强版 grpc，因为真的加了好多东西，有些配置参数我也想顺便改得更合理，但 grpc 的用户比较多、需要时间迁移配置，所以可以推迟到 v26 再移除，~~至于 h2 传输层我觉得下个版本就可以移除~~

Reply to this message to post a comment on GitHub.

💬 New comment on Xray-core#3823 xmux for grpc and h2
by @RPRX

@mmmray So the plan is:

1. Merge SplitHTTP and HTTP into XHTTP, with header padding and xmux support, don't forget @yuhan6665's h3. Forget about steaming request for now as it is only for browser dialer, we can add it later.
2. Translate SplitHTTP as XHTTP, HTTP as XHTTP with the normal mode. Mark them as deprecated and will be deleted in v25.
3. When XHTTP is combined with REALITY, use the normal mode by defaul, otherwise use the splitiupload mode by default.

~~喝晕了只会打英文了懒得翻译成中文了卧槽，将就着看一下~~

Reply to this message to post a comment on GitHub.

https://t.me/projectXray/3952600

成长，生命，幸福，和APT-ZERO

世界!

https://t.me/projectXray/3952666

目前没有把 NFT 发布在其它平台上的计划，有计划发价格低一些的 REALITY NFT，不过数量也会更多，然后 VLESS NFT 可能就十个

https://t.me/projectXray/3952667
https://t.me/projectXray/3952669
https://t.me/projectXray/3952670

“这就是r佬说的收藏价值和升值空间，这不就来了吗”
“不要小看xray的受众和信徒”
“遍及世界！”

🗿墙掉全世界所有IP

💬 New comment on Xray-core#3823 xmux for grpc and h2
by @RPRX

I'm waiting for XHTTP, and I will not release the next version of Xray-core until XHTTP is ready, ~~or there will be no next version.~~

Reply to this message to post a comment on GitHub.

提醒：价格为 0.1ETH 的 Project X NFT 仅剩一个，此后价格为 0.15ETH 起步

这就叫共识

https://github.com/XTLS/Xray-core/discussions/3633

💬 New comment on Xray-core#3819 Transport: Add HTTP3 to HTTP
by @RPRX

请大家测试一下新的直连 H3 传输层的可用性，~~并且我们有计划给它加上不那么 brutal 的增强~~

Reply to this message to post a comment on GitHub.

💬 New comment on Xray-core#3851 求大哥拉我入tg群啊，回答错误了4次问题
by @RPRX

这种bt的问题已经存在几年了，其实最开始我觉得风扇设置的这些问题~~严重限制了群人数的增长~~，但后来我觉得人不在多而在精，入群考验的是独立查找答案的能力~~以及一点点运气~~，只有这样才能保证群的高质量交流，~~以及珍惜留在群里的资格不要违反群规~~

Reply to this message to post a comment on GitHub.

🔌 New pull request Xray-core#3852 Transport: Add RAW as an alias of TCP
by: @RPRX

几年前就想这么干了，这下顺眼多了，新版发布后文档应作出对应修改，只写 raw 和 rawSettings

Reply to this message to post a comment on GitHub.

💬 New comment on Xray-core#3819 Transport: Add HTTP3 to HTTP
by @RPRX

> > 请大家测试一下新的直连 H3 传输层的可用性，~并且我们有计划给它加上不那么 brutal 的增强~
>
> 感谢 测试了一下可以正常使用~ 不过测速表现可能比以前的 quic 稍差一点 因为复用同一链接的关系 如果连续测速跟 quic split 一样会有明显降速的情况 （可能跟我测试线路有关）

多了一点点数据头，~~理论上会比直接的 QUIC 慢 1%~~，实际上几乎没差，它和 SplitHTTP 合并为 XHTTP 后就有 xmux 能限制复用了

外层都是 quic-go 的特征，感觉暂时不适合 fallbacks 或 REALITY，实际部署应放在 Nginx 后面，改它的 QUIC 拥塞控制就能提速

所以我觉得现阶段多加一点点数据头换来能放在反代软件后面是很值得的，这也是 XHTTP 和 Hysteria / TUIC / Juicity 的最大区别

Reply to this message to post a comment on GitHub.

💬 New comment on Xray-core#3819 Transport: Add HTTP3 to HTTP
by @RPRX

> NGINX 的 stream 模块不支持quic，测试版是支持的，正式版就删除了。好像没法通过sni分流 https://github.com/nginx/nginx/issues/146

~~Nginx 支持 QUIC 只是时间问题~~，鉴于可预见的未来内暂无服务端 QUIC 特征伪装方案，Xray 放在反代软件后面是非常有必要的

我重来，才看清说的是 stream，我还纳闷 Nginx 咋会还不支持 H3，然而 Xray 用到的不是 stream 而是 H3 反代（变为 H2/H1）

根据 H2 传输层的 [文档](https://xtls.github.io/config/transports/h2.html)，它可以被 Nginx 中转，但似乎未经测试（这也是我最初希望上下行分离的原因之一），可以测试一下 Nginx 支持这种全双工吗？不过我现在决定即使 Nginx 不支持，XHTTP 也会支持这种经典的全双工模式

Reply to this message to post a comment on GitHub.

Xray-core v24.9.30: https://github.com/XTLS/Xray-core/releases/tag/v24.9.30

💬 New comment on Xray-core#3819 Transport: Add HTTP3 to HTTP
by @RPRX

> nginx貌似只能反代grpc的h2流量，没有h2c的反代功能。其实只要xray传输层的http支持http1.1就行了？nginx接收h3流量用http/1.1反代给后端xray。

这两天我和 @yuhan6665 也在研究这件事，Nginx 暂不支持 h2c 回源，所以 H2 传输层的文档写 Nginx 是错的，应该写 Caddy。以前缺乏 Web 伪装大概也是 H2 传输层几乎没人用的原因之一（另一个原因是 v2 有断流 bug），就像此前被删掉的 QUIC 传输层。

HTTP/1.1 的流式上行也需要 chunked encoding，还没测 Nginx 是否支持把 h3/h2 转译成它，然后还有些问题需要研究。

Caddy 或许还支持把 h3 转译成 h2c，正在测试，但那样又成 quic-go 了，~~感觉 Caddy 像玩具~~，能用主流的 Nginx 更好。

> 另外测了下裸奔的vless+h3+tls，性能符合预期能跑满，但不如hy2，除了qos限流外，好像还会断流要重启客户端才行。还有就是没有伪装功能

目前只推荐放在反代软件后面，我们计划修改 Nginx 的 QUIC 拥塞控制代码，就像其它协议改 quic-go，但不会那么 brutal。

至于断不断流，盲猜代码应该没那种断流 bug，可能是运营商给你 Q 没了，需要换本地端口，以后也支持 xmux 就能自动换了。

总体上还是 SplitHTTP 比较成熟，基本上什么都支持什么都有了，即使上行 Split 也问题不大，毕竟通常上行流量很少。打算把 v24.9.30 标为 latest，下个版本可能 xmux 会有默认值以及 path 也能设置参数，XHTTP 是合并还是单独指代直连还在考虑。

Reply to this message to post a comment on GitHub.