How to circumvent this block method?

[toorich]

Recently I found a block method of the GFW: Port 443 of the IP address is open, but can't establish a TLS connection (the connection will be reset or closed after about 2 minutes or longer). Some IP address with the above blocking method being blocked like 35.190.60.146, 35.241.11.240, 67.199.248.12, 67.199.248.13, 151.101.1.164 and 192.0.66.2. I want to know: is there a way to circumvent the blocking via Kkevsterrr/geneva or other censorship evasion tools? if so, I want to know what strategy or method can do it?

[computerscot]

Is this the same problem as Large scale blocking of TLS-based censorship circumvention tools in China?

[OnceUponATimeInAmerica]

Those IPs are probably being blocked at TLS handshake stage/level (as opposed to IP or TCP levels/layers/stages); If you really need access the same IPs, one temporary solution could be this. Basically, you somehow (e.g. via ClientHello fragmentation, etc.) hide the fact that you are conducting a TLS handshake with the banned host.

[wkrp]

Thanks for this news. It does sound somewhat different than anything discussed in #129.

These are some things you can try, to help diagnose what's happening.

• Try opening the TCP connection, waiting 10 seconds, then beginning to send data. Does the connection still get closed?
• Try opening the TCP connection, sending half the TLS client hello, waiting 10 seconds, then sending the other half.
• Does the same thing happen on other ports? What happens if you send an HTTP request to port 80? What happens if you send a TLS handshake on port 80 (https://35.190.60.146:80/)? Are there any other ports open on those IP addresses (nmap -n -Pn -v --min-rate 50 --reason 35.190.60.146 35.241.11.240 67.199.248.12 67.199.248.13 151.101.1.164 192.0.66.2)?
• Does the same thing happen with other nearby IP addresses, e.g. 35.190.60.147, 35.241.11.241, etc.?

If I may ask, what led you to discover that these specific IP addresses were begin affected?

Maybe @kkevsterrr or geneva@cs.umd.edu can help with running Geneva.

[RPRX]

这种情况就是之前我在 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 类主要是封端口。我们经常看到有人用 Trojan 或 WSS，隔天被封，一天换一个端口。所以这种新的阻断机制可能只是对 TLS 类的封锁形式的改变，从封端口变为实时阻断 TLS 握手，性价比更高，本质上还是你的 IP 黑了。

注：由于时间久远，且我们收到的信息很多，我忘了报告者有没有测试其它端口的情况（印象中换端口也没用），你可以试一试。

@chika0801 或许你记得

---

This is the case that I mentioned earlier in https://github.com/net4people/bbs/issues/254#issuecomment-1565308254 "as long as it is TLS it will be interrupted": GFW does not block your port or IP, but interrupts your TLS handshake in real time.

It's been around for at least a month, and we've been getting reports of it Tested, this blocking has nothing to do with SNI, it just interrupts any TLS handshake indiscriminately.

We have received reports mainly on Oracle, which as we all know is often used for jumping the wall, so we think it is a kind of IP blacklisting, and direct connection protocols like REALITY can't solve the problem of "IP already blacklisted", so in practice this situation won't fix. We will suggest users to change IP or service provider.

GFW blocking SS class is mainly to block IPs, and blocking TLS class is mainly to block ports. We often see people using Trojan or WSS, and they are blocked every other day and change a port every day. So this new interruption mechanism may just be a change in the form of blocking TLS classes, from blocking ports to real-time interruption of TLS handshakes, which is more cost-effective and essentially still your IP is blacked out.

Note: Due to the time and we received a lot of information, I forget whether the reporter has tested other ports (the impression that changing ports does not help), you can try.

@chika0801 maybe you remember

[RPRX]

我注意到 @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, you can refer to it for easy communication.

封锁/封: static, based on simple and crude database, such as blocking IP, blocking ports, no traffic can pass, should be translated as block

阻断: dynamic, based on relatively complex real-time analysis, such as analysis of the TLS handshake before interrupting, and not mindlessly blocking all traffic, should be translated as interrupt

[chika0801]

Is this the same problem as Large scale blocking of TLS-based censorship circumvention tools in China?

I think the phenomenon described by the owner, and the content in this link you provided. Not referring to a problem.

The phenomenon mentioned by the owner is mentioned in the link below. It appeared (posted to report to the public) around the beginning of March this year.

https://github.com/3andne/restls/issues/8 https://github.com/XTLS/Xray-core/discussions/1772

This phenomenon of blocking for 3 minutes was frequently asked about in Xray's telegram discussion group between February and March. One day, one of the group members, posted the following link.

https://github.com/XIU2/CloudflareSpeedTest/issues/217

The time point in this link is May 2022. We speculate that this blocking 3 minutes, around March this year, is more used for popular IP segments (e.g. Oracle Korea region, Japan region).

But now, from May to June, the number of people coming to the Xray telegram discussion group to ask about it is significantly less.

We are faced with questions that come to us when we encounter inquiries about this phenomenon and how to solve them.

Usually it is recommended that you do not use an Oracle-type VPS. buy a VPS from another vendor.

At the moment there is no other way.

[RPRX]

@chika0801 的确是这样，我想起来，在一个 Project X 周边项目的群里，两个月前我看到有一个人的甲骨文首尔用不了 REALITY，怎么配置都是这种阻断。后来同样是这个人，同样是甲骨文首尔，却用得生龙活虎（由于没有交流，我不知道他是否换过 IP）。

但在 Project X 的群里以及 GitHub 上，这种现象的确在以前报告、讨论得多，最近报告、讨论得少。看起来 GFW 是按计划小范围部署、测试了这种阻断方式，收集数据以评估表现，然后按计划部分撤回了这种阻断方式，不知道以后是否会有大规模部署。

就像互联网产品有灰度测试，GFW 也会小范围实际部署、测试新的封锁手段。然而由于我们的用户群体比较广泛且比较活跃，即使是小范围测试也会很快被我们抓到，也会收到不少报告，毕竟“用不了/被封了”的第一反应就是在群里问一问，向开发者反馈，开个大新闻 issue 之类的。像这种阻断方式，在这里它可能是个新闻，但在我们那里已经讨论过很多次了，这是一个值得注意的差异。

---

Indeed, I remembered that in a group of Project X peripheral projects, two months ago I saw a person who couldn't use REALITY with his Oracle Seoul, and how to configure it with this interruption. Then this same person, with the same Oracle Seoul, was using it alive and well (I don't know if he had changed IPs as there was no communication).

But it's true that this phenomenon has been reported and discussed a lot in the Project X group and on GitHub in the past, and less recently. It looks like GFW deployed this interruption method on a small scale as planned, tested it, collected data to evaluate performance, and then partially withdrew it as planned, so I don't know if there will be a large-scale deployment in the future.

Just like Internet products have grayscale testing, GFW also deploys and tests new blocking methods on a small scale in practice. However, because our user base is relatively wide and active, even small-scale testing will soon be caught by us, and will also receive a lot of reports, after all, "doesn't work / blocked" the first reaction is to ask in the group, feedback to the developers, open a big news issue and so on. Like this interruption method, here it may be a news, but in our place has been discussed many times, it is a noteworthy difference.

[wkrp]

@RPRX, @chika0801, thank you for the valuable information. @toorich, do @chika0801's links help explain what you are seeing?

我们收到的报告主要集中在甲骨文，而大家都知道甲骨文经常被用来翻墙，所以我们认为这是一种针对 IP 的黑名单

We have received reports mainly on Oracle, which as we all know is often used for jumping the wall, so we think it is a kind of IP blacklisting

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. I wonder why? There is nothing one can usefully send to port 443 other than TLS, no other useful traffic on that port that the GFW would want to preserve. As you say, it could be a test, a pilot to see if dynamic protocol detection is accurate enough, before deploying it more widely (or not).

In this case, none of the IP addresses in the original post are not in Oracle address ranges. Instead, they are:

IP address	ASN	AS name	netname	reverse DNS
35.190.60.146	15169	GOOGLE, US	GOOGLE-CLOUD	146.60.190.35.bc.googleusercontent.com
35.241.11.240	15169	GOOGLE, US	GOOGLE-CLOUD	240.11.241.35.bc.googleusercontent.com
67.199.248.12	396982	GOOGLE-CLOUD-PLATFORM, US	BITLY	cname.bitly.com
67.199.248.13	396982	GOOGLE-CLOUD-PLATFORM, US	BITLY	cname.bitly.com
151.101.1.164	54113	FASTLY, US	SKYCA-3
192.0.66.2	2635	AUTOMATTIC, US	AUTOMATTIC

Perhaps noteworthy, 151.101.1.164 is an IP address for nytimes.com. @toorich, do you see the same TLS blocking behavior for some other nytimes.com IP addresses?:

• 151.101.129.164
• 151.101.193.164
• 151.101.65.164

[chika0801]

@wkrp

GFW used to mean China's network firewall when communicated between us (mainland China) internet users. I don't know if by GFW the owner means the firewall in his location. I guess he may not be in mainland China.

Maybe you can ask the owner about his specific situation (like where is his region). Assuming he is not in mainland China. Is he from one of the countries in the Middle East now?

The main thing is that now the word GFW has become a generic term for network audit firewall. The phenomenon described in my reply above was observed in mainland China.

[toorich]

@wkrp

GFW used to mean China's network firewall when communicated between us (mainland China) internet users. I don't know if by GFW the owner means the firewall in his location. I guess he may not be in mainland China.

Maybe you can ask the owner about his specific situation (like where is his region). Assuming he is not in mainland China. Is he from one of the countries in the Middle East now?

The main thing is that now the word GFW has become a generic term for network audit firewall. The phenomenon described in my reply above was observed in mainland China.

I'm Chinese and I'm in mainland China, just because that this is an English-based forum so I'm speaking in English.

[toorich]

Perhaps noteworthy, 151.101.1.164 is an IP address for nytimes.com. @toorich, do you see the same TLS blocking behavior for some other nytimes.com IP addresses?:

• 151.101.129.164
• 151.101.193.164
• 151.101.65.164

YES.

[toorich]

这种情况就是之前我在 #254 (comment) 中提到的“只要是 TLS 都会被阻断”：GFW 不封你的端口或 IP，但实时阻断你的 TLS 握手。

它至少在一个月前就出现了，我们陆续收到了一些报告，经测试，这种封锁与 SNI 无关，它只是无差别地阻断任何 TLS 握手。

我们收到的报告主要集中在甲骨文，而大家都知道甲骨文经常被用来翻墙，所以我们认为这是一种针对 IP 的黑名单，而像 REALITY 这样的直连协议解决不了“IP 早已进了黑名单”的问题，所以实践上这种情况 won't fix，我们会建议使用者更换 IP 或服务商。

GFW 封 SS 类主要是封 IP，封 TLS 类主要是封端口。我们经常看到有人用 Trojan 或 WSS，隔天被封，一天换一个端口。所以这种新的阻断机制可能只是对 TLS 类的封锁形式的改变，从封端口变为实时阻断 TLS 握手，性价比更高，本质上还是你的 IP 黑了。

注：由于时间久远，且我们收到的信息很多，我忘了报告者有没有测试其它端口的情况（印象中换端口也没用），你可以试一试。

@chika0801 ~或许你记得~

本人上面所说的IP全部都是用于Web网站的，不是用来翻墙的。

The IPs I mentioned above are all used for Web sites, not for wall climbing.

[chika0801]

@toorich

谢谢你的报告。

Thank you for your feedback

[RPRX]

@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. I wonder why? There is nothing one can usefully send to port 443 other than TLS, no other useful traffic on that port that the GFW would want to preserve. As you say, it could be a test, a pilot to see if dynamic protocol detection is accurate enough, before deploying it more widely (or not).

还是有区别的，如果把 443 封死，你连 TCP 握手都无法完成。如果阻断 TLS，GFW 可以看到你正在尝试访问的 SNI，进行记录。

@toorich 你可以测试一下改变 SNI、不发 SNI（https://IP ）是否能成功握手，如果可以，则它还与 SNI 黑名单、白名单有关。

There is still a difference, if you block 443, you can't even complete a TCP handshake. If TLS is interrupted, GFW can see the SNI you are trying to access and log it.

@toorich you can test whether changing the SNI, or simply not sending the SNI (https://IP), results in a successful handshake. If it does, then it is also related to an SNI blacklist/whitelist.

[toorich]

@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. I wonder why? There is nothing one can usefully send to port 443 other than TLS, no other useful traffic on that port that the GFW would want to preserve. As you say, it could be a test, a pilot to see if dynamic protocol detection is accurate enough, before deploying it more widely (or not).

还是有区别的，如果把 443 封死，你连 TCP 握手都无法完成。如果阻断 TLS，GFW 可以看到你正在尝试访问的 SNI，进行记录。

@toorich 你可以测试一下改变 SNI、不发 SNI（https://IP ）是否能成功握手，如果可以，则它还与 SNI 黑名单、白名单有关。

不能。如果能的话我大概率不会发这个issue。

I cannot. If I could, I probably would not have posted this issue.

[RPRX]

@toorich 感谢你的测试，这表明你遇到情况不是传统的 SNI 黑名单阻断，而是上面我们描述的那种针对 IP 的黑名单加 TLS 阻断。 麻烦你测试一下 @wkrp 列出的那些测试项目，以及向 443 端口发送非 TLS Client Hello，麻烦附上 WireShark 捕获的数据。

如果我是 GFW，对我来说，用阻断 TLS 取代封端口 / IP 有以下好处：

1. 我认为你在用 TLS 翻墙，政策不倾向于封 IP，但我封你端口，你一天换一个就能绕过，不如我阻断整个 IP 的 TLS，效果更好
2. 造成线路畅通的假象，它的作用之一是，我可以记录你的 TLS Client Hello，包括客户端 TLS 指纹、你正在尝试访问的 SNI 等
3. 记录 SNI，监控是一方面，另一方面，IP 会易主，我可以根据大量 SNI 来决定是否继续实行 TLS 阻断，这种解封机制更精准

总体上，我觉得这套新系统的开发是始于封翻墙，发现它有种种好处后，GFW 正尝试用它覆盖旧系统的作用，比如封锁一些知名网站等，未来可能更加精细，因为它也要实现对 CDN 的 SNI 黑名单阻断。现在 TLS 已经成为最大的问题，以前对 TLS 的审查、封锁等，系统、代码比较分散，所以现在它们正在被抽离，组成一个统一、独立的专门处理 TLS 问题的新系统，这是我的看法。

这套新系统的可插拔性较好，把它放到路径上，它只管 TLS，其它流量不归它管，所以不是封端口 / IP，这就是我们看到的表象。

---

@toorich thanks for your tests, which indicate that you are not experiencing a traditional SNI blacklist interruption, but rather the kind of IP-specific blacklist plus TLS interruption we described above. Could you please test those tests listed by @wkrp, as well as sending a non-TLS Client Hello to port 443, and could you please attach the WireShark capture?

If I were GFW, for me, replacing port/IP blocking with TLS interruption would have the following benefits:

1. If I think you are using TLS to climb the wall, the policy tends not to block the IP, but just the port, which you can change once a day to bypass; but if I interrupt TLS on the entire IP, the effect is better.
2. To create the illusion of an open line. One of the effects is that I can record your TLS Client Hello, including the client TLS fingerprint, what SNI you are trying to access, etc.
3. One the one hand, monitoring and recording SNI, on the other hand, if the IP changes ownership, I can decide whether to continue to implement TLS interruption based on a large number of SNIs. This unblocking mechanism is more accurate.

In general, I think the development of this new system was started to block wall-climbing, found it has various benefits, GFW is trying to use it to replace the role of the old system, such as blocking some well-known sites, in the future it may be more refined, because it is also to achieve CDN SNI blacklist interruption. Now TLS has become the biggest problem. In the past, the system and code for TLS censorship, blocking, etc. were more scattered, so now they are being extracted to form a new system that is unified and independent specifically to deal with TLS issues.

This new system is more pluggable: put it in the path, it only cares about TLS, other traffic is not under its control, so it is not blocking ports/IP, this is what we see on the surface.

[free-the-internet]

@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. I wonder why? There is nothing one can usefully send to port 443 other than TLS, no other useful traffic on that port that the GFW would want to preserve. As you say, it could be a test, a pilot to see if dynamic protocol detection is accurate enough, before deploying it more widely (or not).

还是有区别的，如果把 443 封死，你连 TCP 握手都无法完成。如果阻断 TLS，GFW 可以看到你正在尝试访问的 SNI，进行记录。

@toorich 你可以测试一下改变 SNI、不发 SNI（https://IP ）是否能成功握手，如果可以，则它还与 SNI 黑名单、白名单有关。

There is still a difference, if you block 443, you can't even complete a TCP handshake. If TLS is interrupted, GFW can see the SNI you are trying to access and log it.

@toorich you can test whether changing the SNI, or simply not sending the SNI (https://IP), results in a successful handshake. If it does, then it is also related to an SNI blacklist/whitelist.

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 images. Anyway, interruption of TLS has the same destructive effect as IP blocking. After all GFW will make a legit service or a proxy unusable considering that most of them using TLS nowdays. So, here the question is: If we assume the destructive effect is the same for IP blocking and TLS interruption, how they differentiate proxy traffic from normal traffic? Could it be the number of semi-identical ClientHello packets that counted for a fixed or adaptive period of the time?

FYI: Some users in Iran experiencing similar thing: a WhatsApp call disconnects every N*30mins (approximately; and N>1), looking at proxy status shows that it is the VLESS TLS traffic which was interrupted. But, a disconnect and reconnect works right after.

[OnceUponATimeInAmerica]

There might be several reasons for them employing TLS-level blocking instead of the plain old ip/tcp level blocking.

One possibility is that the involved tools are new and are designed specifically for detection and enforcement in this particular level.

Another possibility might be that many connectivity test tools and even admins are used to simple ICMP and tcp-ping tests and might become confused as to the new situation: the connectivity test tool continues to report Connectivity test OK and the admin refrains from replacing the server for some time (thus causing prolonged disruption in service to their users). In effect, multiple blocking strategies (ip, tcp, tls, etc.) are employed to cause confusion and delay in migration to other working solutions thus slowing down this cat and mouse game (and also to reduce side effects).

This TLS blocking strategy is most effective (causes less side effects) when coupled with a IP/SNI whitelist for known servers/IPs (e.g. for known domestic sites and big companies using servers overseas). Any unknown, stranger IP/SNI that also triggers some other filtering criteria (e.g. too many concurrent connections or a too much outbound traffic) will trigger this ruthless TLS disruption, without much side-effects (at least of the kind that such states might worry about).

[wkrp]

I got a report privately with some pcaps and analysis. Some of these points may be slightly erroneous, but my interpretation is:

• The detection pattern is something like ^\x16\x03...; that is, at least 5 bytes at the beginning of the stream, starting with \x16\x03.
• The detection works even if the signature is broken into multiple packets; i.e., sending \x16 and \x03 in separate packets, a few seconds apart, still results in blocking.
• Packets are blocked in the client→server direction only. The client can still receive e.g. ACK packets from the server while the temporary block is in effect.
• Streams that do not match the pattern (e.g. test) are not affected, though because they are not TLS they result in the server sending an alert and/or closing the connection.
• Sending the signature (e.g. \x16\x03\x01\x00\x00) on port 80 does not result in blocking (though it of course causes the server to send a "400 Bad Request" response).

[RPRX]

@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 images. Anyway, interruption of TLS has the same destructive effect as IP blocking. After all GFW will make a legit service or a proxy unusable considering that most of them using TLS nowdays.

首先，中国的法律、法规并不允许你把网站、服务部署在境外。如果你要合法地开网站，应当部署在境内服务器并备案，否则随时有可能被封，而且境内的大型网站、服务并不会接纳你，因为你连备案号都没有。但是，备案只是允许你放静态网页，若你想放其它类型的内容，还有很多许可证要办。比如，如果你要开个论坛，需要 ICP 许可证，有一定规模的企业才能申请，个人无法申请。比如，如果你要播个视频，需要视听许可证，行情价上亿人民币，除非你是国有控股企业。如果你的网站、APP 上出现了当权者不喜欢的言论、视频等，你必须按要求把它们删掉/隐藏并交出发布者的个人信息，否则你会被吊销许可证、注销备案，让你变非法。在中国，公平法治有但不多，因为方便人治、选择性执法的法律、法规已经渗透了各行各业各个领域。有些国家的法律是限制政府权力的无限扩张，有些国家的法律是赋予政府无限的权力、到处留口袋。严格立法，普遍违法，选择执法，你法我笑......off-topic。

所以你明白的吧，在境外部署面向境内的“a personal storage service to store images”这件事本身就是“违法”的，你应当计划把它部署在境内，取得备案、许可，并按要求接入审查系统以便图片随时被 404。若你把它部署在境外，肯定要找未被封的 IP，或者套个 CDN，但现在 Cloudflare 也经常被干扰了。即使你的域名没有因为“翻墙特征”被封，若有了一定的影响力，也会被手动拉黑。

中国 GFW 主要是黑名单机制，即封锁一些境外网站，导致“翻墙”流行，所以还要封锁“翻墙”，偶尔会误伤原本没被封的境外网站。对于 TLS 翻墙，从优先封端口（而不是 IP）到仅阻断 TLS，可以看出上级给 GFW 的任务是“精准封锁”、尽量减少误伤。

So, here the question is: If we assume the destructive effect is the same for IP blocking and TLS interruption, how they differentiate proxy traffic from normal traffic? Could it be the number of semi-identical ClientHello packets that counted for a fixed or adaptive period of the time?

目前中国 GFW 主要针对了 TLS 指纹和 TLS in TLS 特征，后者包括内层 TLS 握手特征和加密套娃的一些特征。Trojan 未处理 TLS in TLS 握手特征，我随手写了一个非常简单的 Trojan-killer 就能精准识别它，效果见 https://t.me/projectXtls/84 ，以后还会有更新。至于加密套娃的一些特征，也有人觉得不好检测，其实除了已被公开的，我还掌握着一处特征，也是很简单的精准识别。

关于 TLS Client Hello，如果我们认为浏览器是“normal”，它限制了对同一个域名的最大并发连接数（但若不同的网站 AJAX 请求同一个域名，不能复用也不能等待，所以没有该限制？）。如果你多开了几个浏览器，或者 IPv4 NAT 后面有几十、上百台电脑手机等，很容易就能对同一个域名产生更高、极高的并发数。所以靠这个来判断其实不是很靠谱，我猜它在中国 GFW 内的权重不高，但伊朗 GFW 不在乎误伤，就可以把它的权重拉很高。权重：GFW 最终决定封锁某个网站肯定基于加权求和，而非仅凭单一特征。不过，现在我们对 uTLS 的使用方式，包括 uTLS 本身确实是存在一些问题，在把它们修复之前，我倾向于不说出来。

FYI: Some users in Iran experiencing similar thing: a WhatsApp call disconnects every N*30mins (approximately; and N>1), looking at proxy status shows that it is the VLESS TLS traffic which was interrupted. But, a disconnect and reconnect works right after.

能造成这种情况的可能性太多，但它专门针对 WhatsApp over VLESS 的可能性不大。我觉得比较有可能的是，某些运营商的策略就是定时掐一些非下载的长连接（我遇到过大约 10 秒没数据就掐连接的移动网络运营商）。浏览网页的连接一般坚持不了 30 分钟，而且即使掐了浏览器或其它 APP 的长连接，人也很难感知到，但是打语音、视频的话，断一下就很明显。如果不是 P2P 还好，是 P2P 的话长连接被掐就挺坑的，还好 Xray-core v1.8.1+ 的 VLESS 有新 XUDP 的 UoT Migration，断线重连也能保持 FullCone。

---

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 images. Anyway, interruption of TLS has the same destructive effect as IP blocking. After all GFW will make a legit service or a proxy unusable considering that most of them using TLS nowdays.

First of all, Chinese laws and regulations do not allow you to deploy your website and services outside of China. If you want to open a website legally, you should deploy it on a domestic server and file it, otherwise it may be blocked at any time, and large websites and services in China will not accept you, because you do not even have a record number. However, the record only allows you to host static web pages; if you want to put other types of content, there are many permits required. For example, if you want to open a forum, you need an ICP license, only enterprise of a certain size can apply, individuals can not apply. For example, if you want to broadcast a video, you need an audio-video license, the market price of which is hundreds of millions of yuan, unless you are a state-controlled enterprise. If you have statements, videos, etc. on your website or app that the powers that be don't like, you must delete/hide them and surrender the publisher's personal information as required, or you will have your license revoked, your filing cancelled, making you illegal. In China, there is rule of law but not much, because laws and regulations that facilitate the rule of people and selective enforcement have permeated all fields of all walks of life. Some countries have laws that limit the unlimited expansion of government power, and some countries have laws that give the government unlimited power and leave pockets everywhere. Strict legislation, universal violation of the law, selective enforcement, "you say law, I laugh"... off-topic.

So you understand, it is "illegal" to deploy "a personal storage service to store images" outside the country, you should plan to deploy it inside the country. If you deploy it outside the country, you must find an unblocked IP, or set a CDN, but now Cloudflare is often interfered with. Even if your domain name is not blocked because of "wall jumping characteristics", if there is a certain influence, it will be manually blacklisted.

China GFW is mainly a blacklisting mechanism, that is, blocking some foreign sites, resulting in the popularity of "wall jumping", so also block "wall jumping", occasionally will not be blocked by the original foreign sites. For TLS wall jumping, from giving priority to blocking ports (instead of IPs) to only interrupting TLS, we can see that the task given to GFW by superiors is to "block" accurately and minimize collateral damage.

So, here the question is: If we assume the destructive effect is the same for IP blocking and TLS interruption, how they differentiate proxy traffic from normal traffic? Could it be the number of semi-identical ClientHello packets that counted for a fixed or adaptive period of the time?

Currently the Chinese GFW mainly targets TLS fingerprints and TLS-in-TLS features, the latter including the inner TLS handshake features and some features of nested encryption. Trojan does not deal with TLS-in-TLS handshake features, I wrote a very simple Trojan-killer to accurately identify it, the effect is available at https://t.me/projectXtls/84 and will continue to be updated. As for some ciphersuite features, some people also think it is not good to detect, in fact, in addition to what has been made public, I also have a feature, which is also very simple to identify accurately.

About TLS Client Hello, if we consider the browser is "normal", it limits the maximum number of concurrent connections to the same domain (but if different sites AJAX request the same domain, connections can not be reused and do not wait, so there is no such limit?). If you have several browsers open, or dozens or hundreds of computers and phones behind IPv4 NAT, etc., you can easily generate a higher, extremely high number of concurrent connections to the same domain. So relying on this is actually not very reliable. I guess it doesn't have high weight in the Chinese GFW, but the Iranian GFW doesn't care about false positives, so it can set its weight very high. Weight: GFW's final decision to block a site must be based on a weighted sum, not just a single feature. However, there are some real problems with the way we use uTLS now, including uTLS itself, and I'm inclined to keep them to myself until they're fixed.

FYI: Some users in Iran experiencing similar thing: a WhatsApp call disconnects every N*30mins (approximately; and N>1), looking at proxy status shows that it is the VLESS TLS traffic which was interrupted. But, a disconnect and reconnect works right after.

There are so many possibilities that could cause this, but it's unlikely that it specifically targets WhatsApp over VLESS. I think it's more likely that some carriers' strategy is to throttle long non-download connections at regular intervals (I've encountered mobile network carriers that throttle connections after about 10 seconds of no data). Web browsing connections usually don't last 30 minutes, and it's hard for people to notice even if the long connection to the browser or other apps is throttled, but if you play voice or video, the disconnection is obvious. If it's not P2P, it's not bad, but if it's P2P, then the long connection is throttled, so it's a good thing Xray-core v1.8.1+ VLESS has the new XUDP UoT Migration, which keeps the disconnection and reconnection FullCone.

[testcaoy7]

有些IP地址似乎更容易受到干扰。 我最近部署了“ss2022 over 裸gRPC”的服务器，遇到了一个很奇怪的现象 实例部署于AWS，直连时工作稳定 我同时为它开启了Global Accelerator服务，但是当通过Accelerator的IP地址连接时，就会间歇性闪断

Some IP addresses seem to be more susceptible to interference. I recently deployed a server with "ss2022 over bare gRPC" and encountered a very strange phenomenon The instance is deployed on AWS and works fine when directly connected I have also enabled Global Accelerator service for it, but when connecting through the Accelerator IP address, it flickers off intermittently

[us254]

If the [TLS handshake] is interrupted by the (GFW), it may be possible for Hysteria to establish a connection while Reality cannot.

[li5269990]

楼主有没有尝试通过运行geneva等规避工具发现新的有效规避策略

Has the owner tried to find new effective circumvention strategies by running geneva and other circumvention tools

[ross30311]

位于大陆，为什么我最近在使用iOS手机端Orbot通过snowflake 连接网桥时总是显示连接在50%并保持不变，似乎卡在了这里，在这里正在寻求解决方案。

Located on the mainland, why is it that when I use Orbot on iOS mobile to connect to the bridge via snowflake recently it always shows the connection at 50% and stays there, seems to be stuck here, looking for a solution here.

[wkrp]

位于大陆，为什么我最近在使用iOS手机端Orbot通过snowflake 连接网桥时总是显示连接在50%并保持不变，似乎卡在了这里，在这里正在寻求解决方案。

@ross30311 I'm not seeing any unusual change in the the number of Snowflake users from China in the past week.

If it reaches 50%, it means that rendezvous with the Snowflake broker was successful and the client was able to exchange some traffic with a temporary proxy. Most likely the temporary proxy was disconnected shortly after being assigned, but it is hard to say without any logs. What version of Orbot is it?

In some cases bootstrap problems can be fixed by deleting the tor state file. I don't know how to do that on iOS, but you can probably do it by reinstalling the app.

You might get better support by posting an issue to the Snowflake developers directly:

https://snowflake.torproject.org/#bugs

If you encounter problems with Snowflake - whether you're using it or running it -, please consider filing a bug report. There are two ways to file a bug report:

1. Request an account at the Tor Project GitLab, then open a new issue in the Snowflake project.
2. File an anonymous ticket by generating an identifier and logging in with it. Then, find the Snowflake project in the List of all projects and create a new issue.