Investigation on Blocking of Reality in IRAN - Test Results

[Phoenix-999]

Before delving into the issue concerning the reality protocol, I would like to make a couple of notes.

• As we are aware, the Great Firewall (GFW) employs various techniques to detect and block proxy servers. This discussion specifically addresses recent events involving the blocking of the reality protocol in Iran, primarily by MCI ISP.

• The information provided below is our speculation and arises from several users experiencing similar test results, raising suspicions about GFW's techniques and methods for identifying the reality protocol.

• Additionally, this issue is a continuation of the previous conversation regarding the blocking of reality. If you are new to this topic, I recommend reading the previous issues, which can be found at the following links:

Link 1
Link 2
Link 3
Link 4

Now, let’s delve into the matter.

Over the last five months, most Iranian users have encountered challenging situations, given that the reality protocol was the only one functioning seamlessly in Iran. Most other protocols were easily detected by the Great Firewall (GFW). It's a challenging task but still a viable choice.

Now, in the last 10 to 15 days, we are experiencing new waves of blocking Reality, which seem a bit different and more aggressive compared to the blocking waves of the past couple of months. We recently observed something that has been discussed before and rejected by many. Still, we believe that GFW, operating under MCI command, might have found a way to block reality by analyzing heavy traffic. We are not 100% sure, but our test results strongly suggest that these new waves of blocking are due to traffic monitoring by GFW. This is how we think GFW might find reality.

Test Conducted:

• We created two fresh VPS servers, correctly set up with all security measures in place.
• Both servers had clean IP addresses in the same range, and SSH was done through VPN proxy to provide extra security.
• In both servers, the reality protocol was created using the same port (443) and the same whitelisted SNI.
•The only difference was that VPS number one was shared with only 5 to 7 people with low to medium traffic, while VPS number 2 was shared by more than 200 people, and heavy traffic was directed to it in a short period.

After about 2 hours, VPS number 2 was suddenly disconnected, and the CPU usage spiked to 100%, causing the server to temporarily disconnect. It then returned to normal percentage, but the IP was subsequently blocked by GFW.
The screenshot below illustrates exactly what we experienced while using the reality protocol with heavy traffic. Of course, we considered the possibility of it being accidental, so we tried it multiple times with different users, and the same thing happened consistently.

Although VPS number one survived for about two days, after reaching a certain traffic point, we realized it was also blocked by GFW. Additionally, we had VPS number 03, which we subjected to very low traffic with one to two users. After a week, it was still running and had avoided detection by GFW.
It's essential to mention that we took careful measures to implement security, blocking all domestic IPs and domains on the servers and bypassing them through VPN client applications. We used IP protection, random DNS switching, fragmentation, and many other techniques in our X-ray configuration to see if we could escape detection. However, every time the traffic reached a certain point within a specific period, GFW detected and blocked it.

After IPs are blocked by GFW, we can still conduct the SSH connection, as evidenced in the screenshots below. Additionally, even after MCI blocks reality, Shatel ISP follows suit; however, reality continues to function in some other ISPs. Once again, the above is our speculation, based on the same test results conducted by different users in various regions of the country.

While not certain, we offer some suggestions that might help reality withstand the GFW's new measures. Please forgive us in advance, as we might not be as technically proficient as many of the great people here. Consider utilizing advanced obfuscation techniques such as:

⚪ Decoy Traffic Ratio
⚪ Dummy Traffic Ratio
⚪ Traffic Padding
⚪ Adaptive Behavior
⚪ Dynamic Switching
⚪ Dynamic Switching Interval
⚪ Fingerprint Spoofing

We would be immensely grateful for any help, guidance, and suggestions from any of you.

🇮🇷 To all my fellow Iranians, we would greatly appreciate it if anyone could conduct the same test and share their results with us here for more clarity

@RPRX, we are eagerly and patiently awaiting your thoughts on this matter.

^{"Everything that has a beginning has an end. I see the end coming. I see the darkness spreading. I see death. And you are all that stands in his way."}

[Havard20009]

Nice job
Thank you

[MrVb0]

👍
@RPRX We look forward to your valuable comments. You always provide the best solutions. We appreciate you. ❤️

[irgfw]

Both servers had clean IP addresses...

The problem is that we couldn't know if that's correct!
Iran's GFW has a graylist containing many IP ranges from a year ago!

Did you have that IP address you stated clean from a year ago and did not implement obvious protocols like plain Wireguard, Shadowsocks, OpenVPN, and/or many other things other than Reality-tcp-vision ?

Before we buy a VPS IP address, maybe someone had Shadowsocks set up on the server! That would just put that IP address on the graylist.(or any other ancient and not safe proxies.)

And this is not solely just on Reality. if you set up a simple TLS proxy like vless-tcp-tls with flow=vision, it will be blocked if your IP address is on the graylist.

IRGFW has zoomed on TLS proxies now. all kinds of them. AND have a very large list of IP addresses (Gray List).

For example, we had many IP addresses that didn't have any traffic for 3 months on them but got blocked last week! and by traffic I mean the VPS server had no xray-core or panel or any VPN services...

---

By the way, the CPU usage report: It's interesting and others reported this! they are probably or likely Active-probes as we are investigating it. Did you check what was using the CPU? or strange IP addresses with many requests to the server?

[sambali9]

I think they are targeting the tls in tls features of the proxy flow (according to this paper)
In my experience different vps providers have different levels of censoring. For example IPs from microsoft azure and google cloud have the least censoring and interference whereas IPs from hetzner have a very high censoring and interference.

In the paper mentioned above if the GFW allows for more false positives they could detect more xtls-vision traffic and my theory is that IPs from hetzner are set to have a very high false positives and servers from GCP or azure are set to have very low false positives. So hetzner proxies are more likely to be detected and blocked rather than GCP or azure.

[Fangliding]

In fact, it is easy to easily block all connections of reality. Reality manifests as port forwarding (a relatively common service) to the outside. As long as GFW is willing to block all port forwarding, no reality connection can survive
I have a friend who works at the Chinese Academy of Sciences, and they are currently in this situation
In your country, it may not completely block all port forwarding, but rather judge based on the data traffic
This is no longer related to fingerprints, so unfortunately we have no way to deal with it

[gfw-report]

Hi @Phoenix-999 and @irgfw,

Your report and findings fascinating to us. We'd be happy to help with this concerning situation. We are a group of researchers that have experiences on revealing the censorship mechanisms, such as real-time traffic analysis and active probing by the GFW of China, in the past few years.

If you think it's a good idea, we'd be happy to help investigate this situation, together with Xray developers and other anti-censorship researchers. We'd like to establish a more private communication channel to exchange information, but we couldn't find your email addresses. Can you drop us an email? Our email address can be found on our Github profile page.

We can still use this thread for public communication for transparency and to let more people aware of the situation in Iran and our latest progress.

[gfw-report]

Both servers had clean IP addresses...

The problem is that we couldn't know if that's correct!
Iran's GFW has a graylist containing many IP ranges from a year ago!

Hi @irgfw , we agreed with you that we could not conclude that both servers have "clean" IP addresses without holding the IP addresses for a long long time; and there may be one thing to test:

Our understanding is that while @Phoenix-999's high-traffic volume server has been blocked, the low traffic-volumne server has not. @Phoenix-999 can now assign the low-traffic volume servers to more people to use. And if this server that hasn't been blocked for a while suddenly got blocked after getting high traffic volume, it shows evidence that traffic volume may indeed affect censors' blocking decisions.

We'd be happy to discuss more in detail and even help setup more controlled experiments.

[tobyxdd]

In fact, it is easy to easily block all connections of reality. Reality manifests as port forwarding (a relatively common service) to the outside. As long as GFW is willing to block all port forwarding, no reality connection can survive

But how do you detect port forwarding? One server forwarding (reverse proxying) another would look exactly like the original with no way for a third party to tell, or am I missing something?

[Fangliding]

In fact, it is easy to easily block all connections of reality. Reality manifests as port forwarding (a relatively common service) to the outside. As long as GFW is willing to block all port forwarding, no reality connection can survive

But how do you detect port forwarding? One server forwarding (reverse proxying) another would look exactly like the original with no way for a third party to tell, or am I missing something?

It's very easy
For example, if you are using the Hetzner server but your dest is apple.com, it is obvious that Hetzner does not provide network services for Apple
Other sites are similar, and there is evidence to suggest that Azure servers and Microsoft's CDN can also be distinguished, so don't have a lucky mentality

[sambali9]

overall I think Iran's gfw isn't really advanced , it's sh*t. all they can do is blocking as much IPs as possible from vps providers with high vpn traffic like hetzner. that's all they can do. their whole strategy is blocking most of these servers.

Reality on MCI is getting blocked on a large scale (having tested more than 10 reality servers with different configurations and SNIs) so GFW is advanced enough to block the Reality at least.

honestly I think reality is working fine. the issue is, so many Iranians were using speedtest.net as dest.(because it was the only site that worked fine with reality on some servers) and using this site as dest is very suspicious because when you do a speedtest it connects you to a sever within Iran , not outside Iran . so when the gfw sees the traffic of this site is going to a server for example in Germany, they can easily find out that sever is a vpn server.

www.speedtest.net is a website and anyone wanting to use it has to connect to cloudflare IPs outside of Iran, it doesn't matter if you test your speed with a server in Iran because you first connect to www.speedtest.net to get the server information and then connect to a different server with a different domain (most likely ending in ooklaserver.net) to test the speed.

[sambali9]

my question: did you have a sever that got blocked even though you(or the person who owned the IP before you) HAD NEVER used speedtest.net as dest on that server?

I used different SNIs (nixos.org, www.speedtest.net, my own domain etc..) all got blocked on MCI network

[Saleh-Mumtaz]

Hi, i don't know if you would answer because this topic was for months ago, but when you used your own domain, was there a website running with it?

[MrVb0]

my question: did you have a sever that got blocked even though you(or the person who owned the IP before you) HAD NEVER used speedtest.net as dest on that server?

I used different SNIs (nixos.org, www.speedtest.net, my own domain etc..) all got blocked on MCI network

me too !
I tested different dest and sni on different servers, but the servers were blocked (within 2.3 days).

[sambali9]

did you use speedtest.net as dest on those servers? doesn't matter when , just tell if you have used it or not.

I used www.speedtest.net only for the server with www.speedtest.net SNI and used other servers with other dests relating to their respective SNIs. I have not used www.speedtest.net as an SNI or dest for other servers.

[irgfw]

Hi @Phoenix-999 and @irgfw,

Your report and findings fascinating to us. We'd be happy to help with this concerning situation. We are a group of researchers that have experiences on revealing the censorship mechanisms, such as real-time traffic analysis and active probing by the GFW of China, in the past few years.

If you think it's a good idea, we'd be happy to help investigate this situation, together with Xray developers and other anti-censorship researchers. We'd like to establish a more private communication channel to exchange information, but we couldn't find your email addresses. Can you drop us an email? Our email address can be found on our Github profile page.

We can still use this thread for public communication for transparency and to let more people aware of the situation in Iran and our latest progress.

Hi @gfw-report. great to hear from you. We are actively investigating new Iran's firewall behavior, especially in one of the operators named MCI (mci.ir)
You can see some of our works here: https://github.com/GFW-knocker
Also, I contacted you via email.

Hope we hear from you soon...

[shakibamoshiri]

Please do ask questions on this thread for configuration, etc
just share your test, there are other issues people asked but there is no thread for sharing tests

---

Guys do not zoom in to just X-Ray or Reality!

The targeted zone by MCI is not realty, it is any kind of SSL-VPN including

• OpenCoonect
• AnyConnect
• OpenVPN
• SSTP
• V2Ray if TLS is used
• X-Ray if TLS is used
• etc

which they have two key features in common

1. TLS
2. port 443

Here are what we know so far (TESTED)

• If you run WireShard it simply shows that TLS Handshake never completes (TCP RTO)
• a blocked IP while port 443 cannot be accessed the port 80 is fine
• since SSH no need for TLS it is fine even if the IP is blocked

how a server is detected (best guess)

• traffic pattern (VPNs traffic are close to 1-to-1 == symmetrical while normal sites are asymmetrical, 1-to-3, 1-to-10, etc)
• a website popularity (if it is a well-known, it is/should bot be blocked)

Clients (TESTED - Android)

Xray

OpenConnect

Client Pro

OpenVPN + obfs

SSTP

affected area (TESTED)

Those provinces protected more

• Kurdistan
• Tehran
• Zahedan

The Kurdistan MIC Phone numbers start with 0918--* and Ardabil starts with 0914-- . At the moment of this witting 0918- cannot access a server that is blocked while 0914 can access . So the issue/throttle differs from City to City.

[realartin]

i guess it's better to read this article that is from @uoosef (https://github.com/uoosef) twitter post :
link : https://t.co/r4DZtNQPG7

How does the new filtering system of Hamrah Aval (a mobile operator) work?
This system consists of two components:
1- The active part, responsible for checking the first 1.2 to 17 kilobytes of each connection initiated outside the country. This system examines predefined signatures in the initial packets of each stream; for example, it checks if the first packet starts with 0x16 0x3, indicating a probable TLS type. It then looks for the SNI extension in this packet, which starts with 0x1 along with the packet length. After identifying the SNI, it checks whether the SNI is in its filtering hashtable. If the packet is not of the TLS type, the system looks for other signatures such as SSH and HTTP. Regarding HTTP, the system searches for the Host header. Previously, the system was case-sensitive and sensitive to extra spaces but has been updated to remove all spaces. It seems that this active signature checking is done on specialized ASIC processors due to their high processing load, but even with powerful processors, delays and increased ping occur. This is because in the afternoon, people return home, turn on their VPNs, causing the filtering system to become congested.

It's worth noting that the active part's operators differ from each other, each having their own bugs, indicating that the system is not entirely consistent.

2- The passive part:
Before the recent update, the DPI (Deep Packet Inspection) system was entirely active, and if you could deceive it, it wouldn't bother you anymore. However, with the latest update, Hamrah Aval randomly samples some connections of each person, capturing patterns of circumvention in a passive manner. These patterns include TLS in TLS, authentications, and headers of well-known VPN packets. For example, when using v2ray with vless, vless sends a small authentication packet for each connection before sending the main stream, ensuring that the client is legitimate. Additionally, when establishing a new VPN connection with another TLS connection, the passive filtering system looks for repeating patterns in the small packets with TLS or v2ray patterns. If found, it flags the IP addresses and domains, which are then reported to the filtering system every 8 hours and either throttled or completely blocked.

The solution:
The solution is to disrupt these patterns, making it challenging for the server to be filtered. Simply manipulating the codes of these patterns can prevent filtering. Multiplexing to reduce the number of connections and injecting random packets, especially at the beginning of each stream, can decrease the chances of being sampled. Additionally, injecting random packets into authentication packets, breaking them into several packets with different sizes and paddings, can help.

The effectiveness of filtering relies on the absence of an easy way to modify existing protocols and share the results of modifications among users. The purpose of the Bypass SDK is to simplify this process.

A final note regarding VPS:
When setting up a tunnel to Iran, it is advisable to have a noise generator on your server, sending requests to IPs other than your filtering server to avoid detection. Using an Iranian server for a tunnel should be considered a last resort, as it may contribute to strengthening filtering efforts.

translated by chat gpt 3.5

[realartin]

i invite @uoosef to this article about irgfw and if he decide to help xray community with his idea it would be very appreciated

[RPRX]

@realartin @uoosef 感谢你们，其实我们正计划在中国春节期间发布 Xray-core v1.9.0，为 Vision 加上 Seed 支持，它允许用户自定义 Vision 的一些 padding 参数等，并支持与其它传输方式比如 H2、gRPC、WS 等结合使用，到时你们可以测试一下

[realartin]

@realartin @uoosef 感谢你们，其实我们正计划在中国春节期间发布 Xray-core v1.9.0，为 Vision 加上 Seed 支持，它允许用户自定义 Vision 的一些 padding 参数等，并支持与其它传输方式比如 H2、gRPC、WS 等结合使用，到时你们可以测试一下

tnx for your great work sir , you save a lot of people from censorships ❤️🙏
i guess if you and @uoosef share your thoughts together the final results are going to be extraordinary

[karimi12]

Dears

I had two tests with a domain.

1. I used a domain on Cloudflare and then started downloading a static file from it. after three days and downloading less than 170 GB my domain was banned.

My hypothesis:

1. Iranian GFW don't use machine learning their goal this ban access to the internet. so this reason they ban every unknown server or domain (they don't care about the consequences)

2. Because VPN connections are a point to point. they can capture traffic and find the final IP or SNI because Xray sends all traffic to a server (in my test all of the traffic got from a site (point). my suggestion for this action create fake traffic and send it to a list of site

[irgfw]

@RPRX Good. That "may" help for this situation in Iran. as any combination of VLESS/VMESS/Trojan is blocked within 4 hours or 4 days or 2 weeks in Iran. There is something in these combinations that they could "possibly" fingerprint or DPI the packets of them.
BTW can we have some contact with you? we can share some private info about Iran's GFW for this matter and you could get more context about this problem. you can contact us at irgfw@proton.me .

[irgfw]

1. I used a domain on Cloudflare and then started downloading a static file from it. after three days and downloading less than 170 GB my domain was banned.

Yes. we can confirm this. many normal websites are blocked without any reason we tested this (downloading and refreshing from a normal webserver) and they were blocked after 4 days of constant traffic and downloading. (the VPSs were located at Hetzner/Linode/DigitalOcean/Vultr)

1. Iranian GFW don't use machine learning their goal this ban access to the internet. so this reason they ban every unknown server or domain (they don't care about the consequences)

Correct.

[RPRX]

net4people/bbs#327 (comment)

[RPRX]

BTW can we have some contact with you? we can share some private info about Iran's GFW for this matter and you could get more context about this problem. you can contact us at irgfw@proton.me .

我有个邮箱，但我基本上不看，我经常通过 telegram 和 @yuhan6665 聊天，你可以发给他，他会把这类信息转发给我

[Mahdi-zarei]

I had a rather interesting observation lately that I would like to share. I had a trojan and TUIC config running with a tunneled configuration and it has been running on the same IP for almost 9 10 months now.
A night ago the mentioned configuration nearly stopped working, and while ssh and ping were allowed, iperf and traceroute showed some bizarre behavior, for example in the iperf test, an initial rush of data was permitted from the Iran VPS to the foreign one, but it was quickly stopped, and even though the reverse iperf was working at nearly full speed, traceroute could only complete from the Iran side!
Now what had changed in the last few days? I had setup a very simple website on this same IP which served some really simple statistical data and I was directly accessing it! From what I have experienced the past few month and that my configuration did not get blocked by ANY of the blockage waves, I can strongly guess that they simply throttle or ban ANY TLS based traffic that doesn't comply to some of their parameters, could be initial packet sizes or the amount of data transferred, or count of TLS handshakes a certain client does to the server as normal websites usually do not need a lot of it ( I was refreshing my site a lot ).
So given this observation I believe simply mimicking websites is no longer a way to bypass the firewall as they tend to ban real websites too, maybe if we could extend the REALITY protocol so that at the beginning of a connection a certain amount of data (let's say 1MB) was requested by the client from the website we are using as the dest, so before we even begin acting as the proxy, we serve the dest website and this way the characteristics of the initial packets of the connection would practically be identical to that of the dest website, this could pose an immense amount of pressure on the firewall as analyzing an entire connection is practically almost impossible ( by making the amount of data served configurable at the client side, we could really make the task hard ).
Do you thing a method like this could prove useful @RPRX ?

[irgfw]

Thanks for your information. It certainly will help.

For everyone who has some test results and technical information about Iran's GFW, please email me at irgfw@proton.me

[mkh1364]

[Perlover]

Hi,

Don't you think that identifying the IP address where X-Ray is running or which is the actual public server (www.microsoft.com and etc) - can be easily determined by reverse IP address resolving?

That is, the GFW monitors TLS traffic. It checks first of all addresses with high traffic volume, and then does rozolving (PTR record, in Linux you can use dig -x IP command) and by reverse domain identify. For example, for real www.microsoft.com addresses we see a following pattern:

$ dig a microsoft.com

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> a microsoft.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10807
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;microsoft.com.			IN	A

;; ANSWER SECTION:
microsoft.com.		3030	IN	A	20.112.250.133
microsoft.com.		3030	IN	A	20.231.239.246
microsoft.com.		3030	IN	A	20.76.201.171
microsoft.com.		3030	IN	A	20.70.246.20
microsoft.com.		3030	IN	A	20.236.44.162

;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Mar 04 11:30:10 CET 2024
;; MSG SIZE  rcvd: 122

$ dig -x 20.112.250.133

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> -x 20.112.250.133
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51594
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;133.250.112.20.in-addr.arpa.	IN	PTR

;; AUTHORITY SECTION:
250.112.20.in-addr.arpa. 218	IN	SOA	ns1-02.azure-dns.com. azuredns-hostmaster.microsoft.com. 1 3600 300 2419200 300

$ dig -x 20.231.239.246

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> -x 20.231.239.246
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43046
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;246.239.231.20.in-addr.arpa.	IN	PTR

;; AUTHORITY SECTION:
239.231.20.in-addr.arpa. 84	IN	SOA	ns1-09.azure-dns.com. azuredns-hostmaster.microsoft.com. 1 3600 300 2419200 300

;; Query time: 8 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Mar 04 11:30:30 CET 2024
;; MSG SIZE  rcvd: 142

Here we can see the pattern that for IP addresses of real microsoft.com at least there is a pattern - SOA record has email (ns1-09@azure-dns.com) & primary DNS (azuredns-hostmaster.microsoft.com) from microsoft.com zone. Wherever you bought a VPS, it is hard to fake these SOA records by pointing them to microsoft.com servers as well. Often VPS providers, if they allow you to change the PTRs, they only allow you to change them to domain names that also resolve back to the same IP addresses. But in this example, there are no PTR records, but there is a SOA record for the entire reverse zone.

So, if your VPS responds only to port 443, pretending to be a public server www.microsoft.com, then if somebody set a simple task for GFW - find out if this IP really belongs to a pool of Microsoft servers, it will be easy to do it by reverse resolving, just by analyzing SOA and PTR records for the IP or reverse zone of the address block. To this method you can also add a whois query to the same address block.

UPDATE: example about www.speedtest.net:

$ dig a www.speedtest.net

www.speedtest.net.	289	IN	CNAME	www.speedtest.net.cdn.cloudflare.net.
www.speedtest.net.cdn.cloudflare.net. 289 IN A	104.18.202.232
www.speedtest.net.cdn.cloudflare.net. 289 IN A	104.18.203.232

Here I got real IP addresses of SpeedTest. Let's see resolved IP addresses:

$ dig -x 104.18.202.232

18.104.in-addr.arpa.	893	IN	SOA	cruz.ns.cloudflare.com. dns.cloudflare.com. 2288625505 10000 2400 604800 3600

$ dig -x 104.18.203.232

18.104.in-addr.arpa.	757	IN	SOA	cruz.ns.cloudflare.com. dns.cloudflare.com. 2288625505 10000 2400 604800 3600

Same pattern here: although IP addresses are not resolved back to any domain names, the reverse zones themselves have a SOA that clearly has a pattern: email & primary DNS from the cloudflare.com zone. To have the same pattern, you need to have access to the reverse DNS zone where the VPS is purchased. But even if you write a dummy SOA with the same data as cloudflare, the following checks will fail:

$ dig -x 104.18.203.232

18.104.in-addr.arpa.	757	IN	SOA	cruz.ns.cloudflare.com. dns.cloudflare.com. 2288625505 10000 2400 604800 3600

It says which immediate upper zone is responsible for return addresses. Let's find the authoritative DNS for this zone:

$ dig ns 18.104.in-addr.arpa.

18.104.in-addr.arpa.	21600	IN	NS	cruz.ns.cloudflare.com.
18.104.in-addr.arpa.	21600	IN	NS	kevin.ns.cloudflare.com.

Now let's imagine that, for example, the address 8.8.8.8 (I took the public Google DNS example just as an example - you can use your own IP) is pretending to be a www.speedtest.net server, and GFW has a simple task - can the IP address 8.8.8.8 be a www.speedtest.net address (let's hypothetically imagine that Google has prescribed SOA or PTR records for 8.8.8.8 that also point to the cloudflare.com server to be similar to it as much as possible). A simple query to cloudlfare DNS on behalf of GFW will get a response:

$ dig @cruz.ns.cloudflare.com. -x 8.8.8.8

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @cruz.ns.cloudflare.com. -x 8.8.8.8
; (6 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 14800
                                                         ^^^^^^^^^^^^^^^^
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
                                                  ^^^^^^^^^^^^^^^^^^^^^^^
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 20 (Not Authoritative)
^^^^^^^^^^^^^^^^^^^^^^^^^^
;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.		IN	PTR

Now compare that to requesting an IP address from his responsibility:

$ dig @cruz.ns.cloudflare.com. -x 104.18.203.232
; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @cruz.ns.cloudflare.com. -x 104.18.203.232
; (6 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35797
                                                   ^^^^^^^^^^^^^^^^^^^^^^^^^
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
                                                                  ^^^^^^^^^^^^^^^^
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;232.203.18.104.in-addr.arpa.	IN	PTR

;; AUTHORITY SECTION:
18.104.in-addr.arpa.	3600	IN	SOA	cruz.ns.cloudflare.com. dns.cloudflare.com. 2288625505 10000 2400 604800 3600

Conclusion: no matter how X-Ray server pretends to be any server via SNI, there is a simple way to check its IP address via reverse resolving, and if it is not there - then through analyzing SOA records and queries to DNS responsible for the reverse zone.

If you look at the first post - it may very well be that the increased traffic triggers a check that was performed in a similar manner. This is just as an idea.

[neo2enigma]

Guys
Have you ever managed to check this video:
https://www.youtube.com/watch?v=By1DflMboUc&t=2801s
It describes why GFW is getting powerful because of TLS leak in Iranian panels!

[irgfw]

@neo2enigma Yes.
This is irrelevant. Those exposed panels are from old versions without SSL domains or panel path.
Our tests are without panels and just pure xray-core with ufw and the results were consistent with or without panels.