动态 · 第 8 页

由于我的 Blog 原始文件托管在 GitHub pages 上，推送到个人仓库后上一篇文章立即被相关人士扩散并引发争议，并被指出内容存在错误。
事后，我与该作者进行了交流，也重新分析了相关协议，所以我在这里分享我的改正的对 VLESS 协议的新的理解。
由于有好事者盯着我的个人仓库看，我已经将其转为 private，且也不会删除上一篇文章，留作参考。
我上一篇文章写：
Xray 对 UUID 使用了 ReadFull，这意味着 VLESS 可能并没有与 Trojan 相同的探测保护，向其发送 1+15
字节后停止，服务器长时间等待将会成为特征。
但这是错误的，由于我简易检查时忽略了 Xray 代码的复杂度，没有发现外部再次嵌套了缓冲区再次进行了处理，这也是他在频道中唯一反驳我的。
关于 VLESS 的设计，我曾以为如此设计必然不会主动宣传，然而我确实在文档中发现了作者对此的解释。

我要指出的是，这项研究没有涉及现实世界的 GFW 行为，且没有证据证明 GFW 应用了此类机器学习识别。

距离 sing-box 1.0 发布将满一年，star 数量也来到了 4k，我想这是一个值得庆祝的日子。

大多数服务器的行为会导致错误。
目前没有一个代理协议规定了向服务器发送具有域名的 UDP 包后，服务器应如何处理响应中的地址。实际上，大多数代理程序服务器，如
Shadowsocks 官方实现 和 V2Ray，在响应中只返回 IP 地址。
当代理程序向服务器发送域名时，它并不知道该域名对应的 IP 地址。当服务器在响应中发送 IP
地址时，该地址可能与客户端发起连接的目标地址不匹配。如果客户端验证该地址，该连接将失败。
因此，像 Clash 和 Xray 这样支持 fake-ip 的透明代理客户端会强制在发起 UDP 代理连接之前将域名解析为 IP 地址。因此，实际上你几乎不能这样做。