m_x25519_aes-128-gcm.

谁他妈再说普通 ss aead 好用我杀了他，我刚他妈换 ss 用不到五秒就给我墙了

Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.15

Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.16

Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.17

我都分不清这人是来引战的还是

最近的一些协议隔壁没有跟进，比如 SplitHTTP、HTTPUpgrade 0-RTT、gRPC Authority、TLS Client Hello Fragment、XUDP UoT Migration，以及 REALITY 近一年多的更新等等，1.9 的 VLESS encryption 以及 Vision seed 也不一定会跟进

此外，Xray-core 一直在按顺序做认为该做的事情，不会被不必要的因素影响节奏，我觉得保持这样的状态挺好的，而且我给 yuhan 说过代理软件百花齐放是好事，虽然吵过架并且以后还会吵，但哪天硕果仅存了反而会高处不胜寒

Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.18

💬 New comment on Xray-core#3547 建议 Xray 支持 Hysteria 协议
by @RPRX

之前有人建议加 Hysteria 时我说得很清楚是 [还需观望](https://github.com/XTLS/Xray-core/issues/2635#issuecomment-1761217856)，并且给出了两点理由：

一是作为主流代理软件的 Xray 一加，大家一用 Brutal，公网会炸，而且大家都用了就是无意义内卷体验比现在还差并没有利好谁，仅此而言就不应当加 Brutal。我觉得责任感还是比市占率更重要，Xray 不会为了市占率而抛弃作为主流代理软件的责任感去加这样的东西，后来好像是 TCP 作者之一也在推上表达了类似的观点。本质上是这么多年了绝大多数人对协议还是只能看到一时爽而不会去思考大规模铺开的后果，~~我一直有这样的思考是经常当预言家的原因之一~~，就像我经常给伊朗人说不要看到个能用的协议就奔走相告恨不得人人都用上，会凉得很快，~~反正他们也没听过劝就成现在这样了~~。

~~以防有人说：什么责任感？ray 系没用 CDN 吗？我想说这是为了 anti-censorship，这本来就是这些代理软件存在的根本原因。~~

二是当时并不清楚 GFW 会如何对 QUIC 动手，不妨等 GFW 开始封锁、协议迭代后再加一个真正能 anti-censorship 的协议，不然我们刚加一个协议就被 GFW 封了也是挺浪费时间精力的。昨天 GFW 开始大规模封锁 UDP 类代理，看了一些讨论是 UDP 流量一大就会被封且不仅限于 Hy，~~这下和第一条对上了又预言上了，所以在这个时间点又建议加 Hy 是怎么想的，really？~~

我看到你的理由包括“让我很烂的 VPS 也可以在晚上发挥作用”，但你大概没有想过这样的代价其实是其它协议、其它流量在晚高峰的体验更差，并且最后一个坚守的软件 Xray 加了 Brutal 后晚高峰就等着一起爆炸，你的这个理由就不复存在。

最后你附上了 Hy 作者的 回应 说法存在些问题，只是当时出于正好没空、~~社区和谐~~等原因没有再回复，现在评价一下：

首先是 Hy 文档 QA 中也存在的偷换概念问题，“运营商承诺的带宽”并不等于“从你家到境外 VPS 的带宽”，我说这个应该秒懂，**本地运营商最多给你签本运营商的带宽，到境外 VPS 那么复杂的线路可不全是他家的，你一用 Brutal 就是针对整条链路这合适吗？** 即使是本地带宽，要求运营商按签给你们的带宽乘以人头去实际扩容放那里也不现实，因为除了晚高峰它们就是闲置，这是对资源的严重浪费，**何况运营商签给你的普通家宽本就不是长时间拉满独占，所以并不是没有破解限速就是合理的行为，这就是滥用。**

其次就算 BBR 也是在"弱化 Cubic 的体验"，它也懂得退让，所以大家能一起换到 BBR、一起提升体验，而大家一起 Brutal 就会炸。Brutal 并不是传统的拥塞控制，本质上是抢占带宽，至于“联机游戏” UDP 没有拥塞控制，人家又不是为了抢占带宽，流量也不大。

最后就是，我之前提到的“和普通 QUIC 的不同”，就比如 Brutal，GFW 完全可以发现这样的东西就无脑封，~~虽然现在更暴力，UDP 流量一大就封~~。总之以上只是技术性讨论，我认为 QUIC 类代理还是有出路的，并且最终我们会有一些长期可用的 QUIC 类代理。

Reply to this message to post a comment on GitHub.

Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.19

💬 New comment on Xray-core#3543 (uncompleted) SpiltHTTP: Client Support HTTP/3
by @RPRX

> 这下 Xray 不小心也有了基于 HTTP/3 的 QUIC 类代理

而且还能套 CDN，~~前无古人，遥遥领先，总之就是赢！麻了~~

Reply to this message to post a comment on GitHub.

https://t.me/projectXray/3776566

？为什么我套 cf 的 h3 能跑到三百兆
而且 gfw 似乎不封 cf 的 quic 端口

https://t.me/projectXray/3776627

SplitHTTP 的下行很纯粹，原理上速度应该差不多，但 H2 是多路复用会被单 TCP 连接限速，所以多线程测速不如 WSS，而 H3 取决于运营商的 UDP 策略，我这边 H3 似乎比 WSS 快很多，并且 WSS 有时会被阻断。

https://t.me/projectXray/3776732

有没有一种可能 SplitHTTP 的下行并没有什么限制性，我这边套 cf 的 h3 确实能跑到三百兆，有的运营商就是 quic 比 tcp 更快，有的则相反，总之希望各位自己实测一下

Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.20

splithttp h3的测速

Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.21

SplitHTTP for HTTP/3, the last hope of *ray's QUIC

总之，SplitHTTP H3 是第一个完全基于标准 H3、支持套 CDN 的 QUIC 类代理，亦可用反代、Browser Dialer 来隐蔽自身。

毫无疑问，SplitHTTP H3 已经开启了一个崭新的时代。