RPRX

仅为 @nametoolong 的客观评论点赞，他所提到的一些问题也是我所提过的。For the record，我并不认为 Vision 是最好的方案，我也在尝试给它加更多的可能性、开发其它流控。Vision 和 Trojan 的区别就那些，我们可以从大量用户反馈的区别中得出 GFW 用了什么样的检测手段。 *Just to give credit to @nametoolong for his objective comment, some of the issues he mentioned are the...

这种情况就是之前我在 https://github.com/net4people/bbs/issues/254#issuecomment-1565308254 中提到的“只要是 TLS 都会被阻断”：GFW 不封你的端口或 IP，但实时阻断你的 TLS 握手。 它至少在一个月前就出现了，我们陆续收到了一些报告，**经测试，这种封锁与 SNI 无关，它只是无差别地阻断任何 TLS 握手。** 我们收到的报告主要集中在甲骨文，而大家都知道甲骨文经常被用来翻墙，所以我们认为这是一种针对 IP 的黑名单，而像 REALITY 这样的直连协议解决不了“IP 早已进了黑名单”的问题，所以实践上这种情况 won't fix，我们会建议使用者更换 IP 或服务商。 GFW 封 SS 类主要是封 IP，封 TLS...

我注意到 @wkrp 的翻译偶尔有错误或言不达意的地方，我解释一下我的用词习惯，大家可以参考一下，方便交流。 封锁/封：静态，基于简单粗暴的数据库，**比如封 IP、封端口，任何流量都无法通过**，应被翻译成 `block` 阻断：动态，基于相对复杂的实时分析，**比如分析出是 TLS 握手才会阻断，并没有无脑封所有流量**，应被翻译成 `interrupt` --- *I noticed that @wkrp's translation occasionally has mistakes or words that don't make sense, I'll explain my wording habits,...

@chika0801 的确是这样，我想起来，在一个 Project X 周边项目的群里，两个月前我看到有一个人的甲骨文首尔用不了 REALITY，怎么配置都是这种阻断。后来同样是这个人，同样是甲骨文首尔，却用得生龙活虎（由于没有交流，我不知道他是否换过 IP）。 但在 Project X 的群里以及 GitHub 上，这种现象的确在以前报告、讨论得多，最近报告、讨论得少。看起来 GFW 是按计划小范围部署、测试了这种阻断方式，收集数据以评估表现，然后按计划部分撤回了这种阻断方式，不知道以后是否会有大规模部署。 就像互联网产品有灰度测试，GFW 也会小范围实际部署、测试新的封锁手段。然而由于我们的用户群体比较广泛且比较活跃，即使是小范围测试也会很快被我们抓到，也会收到不少报告，毕竟“用不了/被封了”的第一反应就是在群里问一问，向开发者反馈，~~开个大新闻 issue 之类的~~。像这种阻断方式，在这里它可能是个新闻，但在我们那里已经讨论过很多次了，这是一个值得注意的差异。 --- *Indeed, I remembered that in a group of Project X...

@wkrp > Yes, it almost looks like the old familiar IP+port blacklisting, except that instead of blocking port 443, they are dynamically detecting TLS and blocking based on the protocol....

@toorich 感谢你的测试，这表明你遇到情况不是传统的 SNI 黑名单阻断，而是上面我们描述的那种针对 IP 的黑名单加 TLS 阻断。 麻烦你测试一下 @wkrp 列出的那些测试项目，以及向 443 端口发送非 TLS Client Hello，麻烦附上 WireShark 捕获的数据。 如果我是 GFW，对我来说，用阻断 TLS 取代封端口 / IP 有以下好处： 1. 我认为你在用 TLS 翻墙，政策不倾向于封 IP，但我封你端口，你一天换一个就能绕过，不如我阻断整个...

@free-the-internet > I wonder what will happen to a non-proxy service that somebody from China wants to deploy it on an effected infrastructure? e.g. a personal storage service to store...

@beavailable 看起来你对 GFW 有一些刻板印象，我知道有不少人是这样，正好借此机会纠正、科普一下。 > 不合理之处1：GFW 要处理的是全国的流量，仅在少数城市实施 SNI 白名单并迫使人们使用随机数裸协议没有太大的用处。 **GFW 并不是全国统一的，而是分散在各个地区，类似于边缘计算。且不同地区、不同运营商都有不同的策略，当然也经常试点。** > 不合理之处2：监控流量可能是 GFW 的一个用处，但我相信 GFW 的主要目的还是阻止访问，而不是监控。 **GFW 这个词只是对审查者的一个模糊统称，实际功能、情况非常复杂。我们曾收到某供应商“内鬼”消息称他们开发了监控功能。** **客观事实是，中国无法承担完全封锁“翻墙”流量的代价，只能退而求其次选择监控：https://github.com/XTLS/Xray-core/discussions/1811#discussioncomment-5997939** > 但你观察到的现象确实很反常，我的猜测是在少数城市实施 SNI 白名单，确实可以迫使人们使用随机数裸协议，但这可能只是手段，而不是目的。 审查者迫使人们使用随机数裸协议的目的是什么？我认为他们可以因此收集到更多、更准确的翻墙流量信息，这可能有助于审查者开发更精准的封锁技术，从而应用到全国。 **这一说法不成立，因为对于全随机数裸协议，GFW 早就有能力精准封锁：https://gfw.report/publications/usenixsecurity23/zh/** --- *It looks...

顺便评价一下这篇论文：它记载了 GFW 已经精准封锁全随机数裸协议的事实，但是探测出 GFW 的省钱规则、再造 SSR 这条路，我觉得大可不必，早在三年前就说了 https://github.com/v2ray/v2ray-core/issues/2523#issuecomment-636548331 （内容被折叠，需手动展开）。 这篇论文没有明确指出的是，全随机数裸协议这条路确实是已经走到头了，围绕这类协议曾有过大量的攻防研究，围绕“无特征是否就是最大的特征”也曾有过争议，但现在 GFW 已经认定你就是翻墙。依附于 TLS 这样的常见协议切实提高了封锁成本，[最近几个月伊朗是想封死所有翻墙，它干扰 UDP，且 TCP 上只留 TLS 这样的常见协议，还是 SNI 白名单，只剩 REALITY 这类协议能用。](https://github.com/net4people/bbs/issues/253) 最后，我觉得这篇论文不应该接受来自美国政府的资助，这给了“境外势力”说法之口实，况且这些研究即使没有被资助也可以做。 --- *By the way, comment on...

> 这个我知道，但这解释不了这个不合理性：只在若干城市实施监控并没有太大的用处。 关于这种 SNI 白名单+不封锁全随机数裸协议的组合策略，如果你能看得懂刚刚我说的 **试 点** 这两个字是什么意思。 我把话说得清楚一些，最初这种东西只在泉州有，后来福州也有了，它是在小范围测试，不排除继续推广，有一天就到你家了。 此外，并非“只在若干城市实施监控”，其实你早就被监控了（但是 SS 这类更利于监控），看下一段： > 我还是认为 GFW 的主要功能是封锁，监控只是次要功能，GFW 建立之初就是为了阻止国人接触国外的部分信息（从而威胁专制政权），如果阻止不了国人访问国际互联网，那监控也没有太大的意义。 关于你所说的“客观事实”甚至都不是公认的结论，更谈不上事实了。如果你说中国无法承担封锁所有境外流量的代价我还能相信，完全封锁翻墙流量，如果技术上能实现、成本也足够低的话，早就封了，并不会有什么代价，不要忘记还可以使用白名单。 再说了，封锁有代价，监控就没有代价吗？我觉得相比封锁，监控整个城市甚至整个国家的翻墙流量是更不现实的事。 这是 GFW 的作用之一，但它只是想阻止普罗大众接触到这些信息、实时交流，提高翻墙门槛，仅一部分人能翻，而不是封死。 **你不知道 GFW 早就知道你在翻墙，只是以前不封你而已，标记个情商，匹配一下 tg 发消息时间、长度，顺着网线抓个人。** 以上是两三年前来自“内鬼”的消息，你搞经济、搞科研、写代码，没问题，你要上什么大什么，就危险了，这就是监控的意义。 我也常说，精准封锁绝大部分翻墙流量，真的不难，成本也不高，但总是有人不信，是不是要我写一堆 [Trojan-killer](https://github.com/net4people/bbs/issues/250)...