RPRX

> “泉州白名单”相关事件至少是存在的，但是它的范围、机制、程度都是有争议的，也有人汇报完全没有发现相关现象。上面文章给出的也只是用户反馈这个级别的引用，没有直接数据，是很弱的证据为基础的一种开头。 我只说事实： 1. 在活跃的 Project X 万人群，我们长期收到泉州白名单的报告，并且没有人报告人在泉州且不是白名单 2. 由于经常看到有人说泉州可以用 SS 类，并且前天群里有讨论，所以前天晚上我在频道发起了三次投票想要收集 **SNI 白名单地区 IPv4 TCP 是否不封锁 SS 的信息**，但数据均明显异常，比如不可能有那么多人，后来我直接发频道消息询问，结果如下： - 有三名来自泉州的群友表示他们是白名单但 IPv4 TCP 不封锁 SS 类 - 有一名来自福州的群友表示他是白名单但 IPv4 TCP不封锁...

> 假设确实存在所谓SNI白名单式阻断策略，也无法由此推断出它与降级攻击有关，因为其他一些不使用域名的并且具有完善加密栈的VPN协议也会被放行，而这些协议并没有被记录和后期解密的可行性。 **这个说法并没有考虑到现实情况**，现实情况是，绝大多数用户就是在 SS 类、TLS 类之间转来转去，前者不行了用后者，后者不行了试前者，我相信你是清楚的。用户本来用着 TLS，结果被白名单了，去用 VPN 的是极少数，绝大多数人发现 SS 能用就会用。当然由于有 REALITY 的加入，还会有人用 REALITY 类，但 REALITY 是近期才开始流行的，并且此前 ShadowTLS 并不流行（即使流行，它本质上也是 SS），所以 SNI 白名单+不封锁全随机数裸协议这种组合策略的原本预期就是希望 TLS 类滑向 SS 类，即降级攻击。 你可以看到我非常关注“IPv4 TCP”，因为其它地区经常有报告 IPv4 TCP...

[XTLS Vision](https://github.com/XTLS/Xray-core/discussions/1295) 不支持内层 TLSv1.2 裸奔，该 issue 所提及问题均已消失（已修复）

旧版 XTLS 早已被弃用，新版 XTLS，即 [XTLS Vision](https://github.com/XTLS/Xray-core/discussions/1295) 仅支持内层 TLSv1.3 非 `TLS_AES_128_CCM_8_SHA256` 裸奔，谢谢你提到它

首先，暂不论该方法有没有用，**若想让 TLS 服务端不断循环，有更通用的方法、对任何 TLS 服务端均生效，根本不需要这么麻烦**。 事实上，**循环的代码到处都是，包括操作系统的网络栈本身，按你的标准岂不都算是漏洞了**？有必要只揪着这里的循环不放吗？ 其次，之前我没有理你，**是因为你写的东西中基础错误都非常多，基础错误又推出层层错误**，我实在没有时间浪费在你身上。 我只能给你说几个关键点： > 是不是233数据解密一定会失败？ ```go case aead: if len(payload) < explicitNonceLen { return nil, 0, alertBadRecordMAC } nonce := payload[:explicitNonceLen] if len(nonce) == 0...

https://github.com/XTLS/Xray-core/issues/1501#issuecomment-1375293435

https://github.com/XTLS/Xray-core/issues/1539#issuecomment-1386573605 https://github.com/XTLS/Xray-core/issues/1472#issuecomment-1382683509

请使用 v1.7.2+ https://github.com/XTLS/Xray-core/releases/tag/v1.7.2

感谢你提交的详细错误报告，请使用 v1.7.2+ https://github.com/XTLS/Xray-core/releases/tag/v1.7.2

> 试了替换掉在用的二进制，感觉比现有的略慢耶 （是错觉）