其实是这样的，半成品文章对比了 REALITY 与 ShadowTLSv2、Cloak、自签 insecure 等方式的差异，就像当初设计 VLESS 明确写了简化了 VMess 哪些部分，并与 Trojan 进行了对比，这些现有协议肯定要提及、对比的。

但如果你写个看起来比较正式的 spec，况且也不是没引协议，而是引了一些早期协议 SS、Trojan，然后断层，完全不提及、对比这两年众所周知的协议（况且你还用过），有一种发现新大陆的感觉，但一些关键点却高度相似，这观感就很有问题了。这就像写论文只引上个世纪的文章，当本世纪的研究不存在，明知却不引，一些关键点却高度相似，谁看了都会觉得有问题。

我觉得没必要进行更多的揣测。

下一个 XTLS 流控：xtls-rprx-switch

XTLS 的 0-RTT 已经预告几个月了，本来也是想保留神秘感，但既然前两天已经说出来了一部分，不妨全部说完。

最初我们有三个备选方案，一是预连接，二是连接复用，其实这两个都有人实现过，但都有缺点。所以我们选择先用 Mux 传输流量，同时新开个 TCP 连接，等新连接准备好后，像增强版 XUDP 一样把流量换轨到新连接。

相比于现有的各种 Mux，新流控的优点是 换轨后就是单独的 TCP 连接，没有子连接队头阻塞问题，也没有多合一连接限速问题，所以看视频、下载、测速等没有“反效果”，以及基本上没有加密套娃；缺点是连接数多。

相比于 Vision，新流控的优点是 延迟等同于 gRPC，且专门用一个 Mux 来处理 TLS in TLS 握手、新连接几乎是纯原始 TLS data record 的做法更利于抵抗各类 TLS in TLS 分析。

我们即将给 Vision 添加 Seed 支持，它可以自定义 padding 等参数，还可以设置是否开启 XTLS 模式，若不需开启，则可以配合 H2 / gRPC / WSS 等其它传输层使用，这样的能力也会加给 Switch。

不要指向 dl.google.com，会变得不幸

https://github.com/XTLS/Xray-core/discussions/2302#discussioncomment-6392766

今年 IPLC、中转也比较火，我说一下它们的本质以及风险。

先说 IPLC，首先企业能合法地买到专线，但是把它散售给普通个人绝对是违规的，是要被处理的。你现在能买到专线节点，只是因为一些企业给低级监管部门的某些人交了好处费，他们睁只眼闭只眼。注意这个好处费是交不到上级决策层的，人家不缺这点。一旦有人用专线机场干了啥事，那就不光是被拔线的问题了，利益相关人士有一个算一个都得进去。

普通中转也是类似的模式，机房都知道你在干啥，睁只眼闭只眼罢了。注意这些 IPLC、中转没有任何稳定性可言，他们脆弱到任何人打个举报电话就会被清退，只能跑路。

今年机场全是这些东西是有原因的，GFW 把机场常用协议都给封了，机场是没办法，就算成本高风险大也得上中转甚至 IPLC，导致有些小白认为这就是最终解，还有更白的会说机场也用 SS 都不封。那么问题来了，既然机场全是这些东西了，你觉得 GFW 会不会打击？几年后还有没有这些东西都是问题，即使有，价格也不是普通个人能承受的。

所以不要一对比什么就 IPLC、中转，它们根本没有资格和我们努力研发的各种 anti-censorship 协议相提并论。

听说 REALITY 被精准识别了 微软的 TLSv1.3 炸了 https://github.com/XTLS/Xray-core/discussions/2256#discussioncomment-6451722

Xray-core v1.8.1+ 增强版 XUDP 有多好玩？

协议：VLESS + ANY，无论有没有配置 Mux

常见误区：必须配置 xudpConcurrency？非必须，VLESS、Mux 默认就是增强版 XUDP

1. 执行 ./xray x25519，任选一串 base64
2. 设环境变量 XRAY_XUDP_BASEKEY 为它
3. 启动 Xray，用 NatTypeTester 测一下
4. 重启 Xray，再测，服务端出口端口不变
5. 连接手机热点，再测，UDP 仍保持映射

注：服务端无需配置，客户端设环境变量

其实最后一项（切换网络仍保持映射）不需设环境变量，例如，v2rayNG 1.8.5+ 默认启用

白话文：双端升级，啥都不做就有该功能

设环境变量只是为了重启 Xray 仍保持映射，例如，直连切到 CDN（落地服务端相同）

关于环境变量：有没有一种可能，Xray 将会允许你在配置文件中覆写环境变量

Update：1.不是重复造轮子 2.这么设计自然有一些考量（好处）在里面，不建议瞎猜

To FireFox：这个确实是当时的想法，我都忘了有没有公开过，看来可能是在群里画过饼

BTW，这位 浮躁 的发言咋这么抽象？搁别的群你早被 ban 了，要不我们也 ban 了

2023 上半年日常：REALITY 出了吗
2023 下半年日常：Switch 出了吗

最新的 commit 修复了 H2 偶尔会断流的历史遗留问题，请测试（gRPC 有类似问题吗？）

https://github.com/XTLS/Xray-core/issues/2355#issuecomment-1646156399

半年前 Project X Channel 的订阅数为 5K，短短半年，它翻倍到了 10K，感谢支持！

针对 X-UI 的安全建议

昨天看了个视频，发现这个问题比较严重：人们对 X-UI 的使用方式通常是 http://IP ，HTTP 是不加密的，传输内容一览无余，中间人可以直接看到你的对称密码（可用来离线解密）、非对称私钥（可用来中间人攻击）等。

所以对于配置，各个 X-UI 面板应默认关闭外网访问，并引导用户使用 SSH 转发端口。

此前在 别处 提过一句，昨天发现这个问题比想象中更严重，且必须从根源处解决掉。

补充：HTTP 的情况下“改端口和默认路径”对此并没有帮助，HTTPS 可以解决该问题。然而，那些想用“不需要证书”的协议的人，以及翻墙界基数最大的新手小白们并不会去配置证书，更不会其它骚操作，所以默认禁止明文的配置途径是非常有必要的。此外，HTTP 就是告诉 GFW 这里有 X-UI，套上 SSH 虽然不能解决时序特征问题，且连过 SSH 本身就是特征，但比明文强太多。操作系统都自带 SSH 客户端，端口转发也就一条命令，很简单了。