Xray-core v24.12.18

这是 2024 年最后一个版本，包含了大量重要更新：比如再次优化了 XHTTP packet-up 模式的上行，修好了 bug 的同时速率直追 stream-up，还会自动切换连接以避免超过单个连接 HTTP 累计请求数限制，主要利好 H3 及穿透无流式上行的 CDN。 更多的更新内容请看第三版 XHTTP: Beyond REALITY，还讨论了套 CDN 是否属于“滥用”的问题。

为了配合 XHTTP 对 TLS 的广泛使用，Xray-core 已将 "chrome" 设为默认指纹，防止手动输入配置时忘了选指纹。

请支持一个 REALITY NFT：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2

如果你有余力，请支持一个 Project X NFT：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1

一个新的 Xray 客户端正在开发中，持有 REALITY NFT 将获得早期内测资格。圣诞节会发布一篇 XUDP UoT Migration 的文章，并公布 Project X 2024 年度贡献者，颁奖一个 Project X NFT。2025.1.1 每个 Project X NFT 将获赠两个 REALITY NFT。

慢就加钱换线路，就是因为你的邻居们为了提速开始抢占带宽，导致你用不抢占带宽的协议一天比一天慢，最后你也开始抢占带宽，这就叫内卷，最后 GFW 再把抢占带宽的都给墙了

这属于是完全没懂啊，我早就说了抢占带宽的代价是别人更慢以及特征更明显，一个个都只考虑自己，不然我给 XHTTP/3 改个暴力发包方便一起爆炸，都是 QUIC 谁还不能暴力发包了

我还特意去看了 XHTTP 禁 mux cool 中的 TCP 有没有把反向代理也禁了，结论是没有，因为限制只加在 inbound，然后 mux cool 服务端会遵守，而反向代理的 mux cool 服务端在 outbound，刚好不受影响。至于他同样删掉的"XHTTP 把过 CDN 的能力给删了"纯粹就是搞笑，今天有个人到处发。然后就是激将法了，HTTP overhead 也就 1%，换来能放在 Nginx 和 CDN 后面有什么不值的，甚至我不需要改 Xray 的代码，只需要改 Nginx 的 QUIC 拥塞控制，还有群友测出 TCP-Brutal 对 CDN 也有提速作用也不知真假。

虽然我不懂为什么你的 even 移除的都是些没什么成本的 advantages，然而 XHTTP 复用后也是 0-RTT 的，其次能否换 QUIC 拥塞控制算法只是有没有写代码而已，并不是根本的协议设计问题，同样你想要多暴力也只是你写多少数值而已，并不是能不能实现的问题，最后我也觉得 native UDP 特性挺好的，我觉得 XHTTP/3 可以支持一下，反代软件以后可能也会支持它

还有， 我说的都不是 random theories，只是看你懂不懂各种网络协议的原理，懂的人都没说有问题，理解不了说明你仍需提升自身水平

不如看一下我引用的第一条消息的下文，有人说慢，自然会有人建议 brutal，这都快成宇宙第一定律了，不用看都能猜到

远没到这个频率，上次提还是四个月前辩论“滥用 CDN”，且几乎没说它

省流：gcp的防火墙都可以知道你在用hy
别的细节就不用讨论了

众所周知：
1. 我都不在群组里，没有权限 ban 人
2. disagree me 不会被 ban，会被拉到频道对线
3. 但如果你的发言过于离谱，连管理员都看不下去了才会 ban 你

这么问无非又是想暗示我不让人说话，恰恰相反，Project X 是最包容的地方，才会有这么多对线，换别的地方你对开发者说话态度不敬都会被 ban（像你和 Aa 这种），根本不会浪费时间跟你对线

并没有，其实我觉得在这方面我要向隔壁看齐了，尤其是我越来越发现总是有一些说英语的 end user 自己都没研究透，却态度很拽地跑来质问开发者，理这些人真的是很浪费时间

其实我一直在建议风扇，入群问题可以难些，但不要搞成纯靠运气，这对大家没有好处，我已经觉得没有看到什么新鲜血液了，并且群组不能僵化，应当每月给一两个新的管理员

💬 New comment on Xray-core#4226 Reality的设计思路似乎有漏洞
by @RPRX

我觉得你说的属于潜在的 weakness，因为现实情况比较多变，但是这并不是“Reality的设计思路似乎有漏洞”，而是“偷别人”这种行为固有的一些问题，REALITY 只是尽最大努力提供更好的实践，否则大家遇到封未知流量+SNI 白名单难不成直接躺平吗？

Reply to this message to post a comment on GitHub.

跨年 R佬 陪伴于 Xray 左右

太好了又是我最喜欢的翻墙协议大作战而且还发生在跨年夜

💬 New comment on Xray-core#4226 Reality的设计思路似乎有漏洞
by @RPRX

上述就是“现实情况比较多变”的一个例子

我的看法是“要不要偷别人”以及“要不要套 CDN”这类问题，等你被 GFW 逼到墙角了自然就知道要不要

Reply to this message to post a comment on GitHub.

这就是我要的氛围！没有男/女朋友的打扰一个人躲在卧室被窝里和网友狠狠讨论翻墙协议

💬 New comment on Xray-core#4226 Reality的设计思路似乎有漏洞
by @RPRX

~~群友想啥呢，谁跟你们一样宅，跨年我肯定出去玩的，跑了，明天再更新 XHTTP 的文章和 v24.12.31 的 release notes~~

Reply to this message to post a comment on GitHub.

## UoT Migration

要解决上文提到的问题，其实很简单：客户端重新连上时，服务端把原来的 UDP 端口还给它就行了。

类似 QUIC 的 Connection Migration，我提出了 UoT Migration 的概念，其最严格的定义为：

被代理的 UDP 来源二元组不变时，若客户端发了起新的 UoT 连接，服务端会将旧连接的下游资源转移给新连接，并关闭旧连接。

1. “下游资源”指的是服务端使用的 UDP 二元组或中转连接。若 UoT 连接断了，服务端需要等一段时间再释放下游资源。
2. 经测试，服务端不一定能及时获知“连接断开了”，所以必须允许新连接直接“抢走”下游资源，这也给了客户端更多的玩法。

可以看出，实现了 UoT Migration，才能真正实现稳定 FullCone。

甚至从某种程度上来说，这才是真正意义上的 FullCone，因为常规的 UDP NAT 并不会让映射关系依附于某条 TCP 的命运。

以上是去年写的其中一小段，我看了下去年还有 10% 就写完了，不过最近太忙了（忙着玩），明年一定

新的一年，v25.1.1 已 release，预计于明天设为 latest（现在的是 v24.12.31）。请 Telegram Premium 用户点一下 boost，以便本频道关闭强制性的 Telegram 广告，都是些野鸡 VPN 广告。