MCI is blocking REALITY servers in Iran

[WatchDogsDev]

Discussed in https://github.com/XTLS/Xray-core/discussions/2450

^{Originally posted by **WatchDogsDev** August 16, 2023} Hi, First thanks for your great work. I had servers with clean IP using the recommended latest protocol **VLESS+TCP+RPRX-VISION+REALITY** for 2 month and everything was fine. Recently (about 4 days ago) the biggest internet operator in Iran known as **MCI** started blocking reality server IPs **under 24 hours.** I have used many less known server providers to get clean IP but it got blocked under 24 hours with around 70 users. Any ideas how we can handle this? Or how is it detected ?

[RPRX]

如果是 4 天前开始的广泛封锁，那么早就应该有报告，但目前除了 你们，并无其他人报告这个情况 GFW 当然在不断增强自己的能力，但若只封了你，基本上可以确定是和你自己的配置有关，至少你应当把配置贴上来 我们不喜欢被封后发贴不附上具体配置且标题为“XX 被识别了”的人，更不喜欢被这样的东西到处刷

但我暂时不会点 Close，看有没有更多报告

[SaintShit]

如果是 4 天前开始的广泛封锁，那么早就应该有报告，但目前除了 你们，并无其他人报告这个情况 GFW 当然在不断增强自己的能力，但若只封了你，基本上可以确定是和你自己的配置有关，至少你应当把配置贴上来 我们不喜欢被封后发贴不附上具体配置且标题为“XX 被识别了”的人，更不喜欢被这样的东西到处刷

但我暂时不会点 Close，看有没有更多报告

I'd say that to some extent he's talking right, not exactly about "REALITY being detected", but about the fact that they're failing to work in the recent days. the way that MCI had been blocking IPs before, was to limiting upstream to suspicious destinations, but now, they're interrupting downstream. so, if you perform an URL test, you see a success result ( as it's only a 204 response and small amount of bytes to transfer ). but when it comes to using the proxy, it fails to work.

The way that I'm testing my REALITY servers is to make an http request with 2 seconds timeout and check if it gets the response completely or not, as limited IPs have a long delay in receiving

curl -v --max-time 2 --resolve www.example.com:443:123.123.123.123 https://www.example.com

[nursery01]

@SaintShit So how do isp determine illegal ip?

According to the list of legal IPs obtained from DNS？

https://github.com/XTLS/Xray-core/issues/2407

[randomguy-on-internet]

I've been using reality + Hiddify panel for 2 months without any ip bans!

but last 3-4 days, every day around 4 PM and 11 pm, my reality configs gets blocked but the ip still has ping + i can access it with nmap -p443 IP so i assume its TLS handshake Blocking and it only happens in one provider, MCI !

I use multiple SNI's, speedtest.net , www.theverge.com , cdn.discordapp.com and 2 more, that are whitelisted in MCI isp.

so after getting blocked 2nd day, i disabled speedtest sni and changed reality keys, cuz i thought they are banning ips based on that sni particularly but still i get banned and im so frustrated.

i'm using Linode VPS provider, their ips used to be whitelisted as it would work with any sni.

[SaintShit]

@SaintShit So how do isp determine illegal ip?

According to the list of legal IPs obtained from DNS？

2407

maybe by the sudden traffic they get? seems that IPs that had REALITY running and they had been working for a long time, are not about to be limited. but about IPs that have recently become active in the network, there is a high chance that they'll be limited after a few hours. no matter which port or which SNI you're using.

[SaintShit]

I've been using reality + Hiddify panel for 2 months without any ip bans!

but last 3-4 days, every day around 4 PM and 11 pm, my reality configs gets blocked but the ip still has ping + i can access it with nmap -p443 IP so i assume its TLS handshake Blocking and it only happens in one provider, MCI !

I use multiple SNI's, speedtest.net , www.theverge.com , cdn.discordapp.com and 2 more, that are whitelisted in MCI isp.

so after getting blocked 2nd day, i disabled speedtest sni and changed reality keys, cuz i thought they are banning ips based on that sni particularly but still i get banned and im so frustrated.

i'm using Linode VPS provider, their ips used to be whitelisted as it would work with any sni.

Actually I've tested it and handshakes are all done, there's no problem with it

[Argo160]

I am having the same issue. My reality servers are also getting blocked by MCI since 4 or 5 days ago. no matter what SNI i use or what flow to be set. even i tried to use different known ports, ... and no different. at the end of the day they are getting blocked.

[RPRX]

I'd say that there are too many possible & available ways to recognize & block your proxy servers. We've discussed many of them here over the past few months (not on my subjective purpose), the problems that we can not solve yet, if you noticed.

maybe by the sudden traffic they get? seems that IPs that had REALITY running and they had been working for a long time, are not about to be limited. but about IPs that have recently become active in the network, there is a high chance that they'll be limited after a few hours. no matter which port or which SNI you're using.

Maybe it's the key.

[mortada-jafar]

ISP Unableed to detect Reality, only popular SNI has been blocked recently (www.speedtest.net), and only white SNI now is www.theverge.com and working on MCI. However, the question remains: how can we discover the whitelisted SNI?

@RPRX

[nursery01]

seems that IPs that had REALITY running and they had been working for a long time, are not about to be limited. but about IPs that have recently become active in the network, there is a high chance that they'll be limited after a few hours. no matter which port or which SNI you're using.

Is there a possibility that the old IP is on the white list?So it can be used for a long time.

[nursery01]

how can we discover the whitelisted SNI?

Use go http client to access sni and point to a random Web IP. If you can receive 403, it means that this sni maybe a whitelist.

[Phoenix-999]

If it was a widespread blockade that started 4 days ago, it should have been reported long ago, but no one else has reported this except you GFW is of course constantly increasing its own capabilities, but if it only blocks you, it is basically sure that it is It is related to your own configuration, at least you should post the configuration We don’t like people who post without specific configuration after being banned and the title is “XX is recognized”, and we don’t like being brushed around by such things

But I won't click Close for now to see if there are more reports

Just a quick update to let you know that I can confirm the recent happenings. In the past four days, MCI has been on a spree, closing down servers and throwing up IP blocks. And they're not holding back – we've even had cases where servers got the boot just a couple of hours after firing up, without any serious traffic.

Now, I've got a hunch this isn't your typical random IP-blocking gig from GFW. It seems like they've figured out a way to pinpoint those VPS servers that are actually in action, or maybe they've cracked the code on spotting real activity through SNI.

But here's the kicker – it's not just a wild goose chase. We've been hearing from folks all over the place, from different cities, and it's clear that this MCI onslaught is widespread.

[mortada-jafar]

Thank you, @nursery01, In our current scenario, we are utilizing www.theverge.com, which operates behind the Fastly CDN infrastructure. The associated IP address for this site is 151.101.41.91. I undertook a thorough comparison with other domains that share similar attributes, including SSL certificates and CDN IPs. However, it's noteworthy that my findings diverged from those observed with The Verge.

when we use The Verge with dirty IP it's working!

[lilcheti]

Guys I created this telegram group for Persian people to join and discuss the ways to connect https://t.me/howisuconnected

[RPRX]

如果这次的封锁主要是基于流量特征，那么还有解决的余地，我们有一些计划。如果主要是基于 IP，比如说 MCI 已经将更多的 IP 列入了“不可轻信”名单，那么现有的协议解决不了，只能用一些魔法，但我不是很想用。

[nursery01]

如果这次的封锁主要是基于流量特征，那么还有解决的余地，我们有一些计划。如果主要是基于 IP，比如说 MCI 已经将更多的 IP 列入了“不可轻信”名单，那么现有的协议解决不了，只能用一些魔法，但我不是很想用。

中國人做的代理百花齊放，如果站在中國gfw和伊朗isp的角度來看，成本比較低的方式就是升級基於ip的審查系統，並且ip很難造假後還能正常使用，如果是每個協定都識別過去還聽麻煩的

[RPRX]

ISP Unableed to detect Reality, only popular SNI has been blocked recently (www.speedtest.net), and only white SNI now is www.theverge.com and working on MCI. However, the question remains: how can we discover the whitelisted SNI?

@RPRX

www.speedtest.net 是一个 Cloudflare 网站，后者的 IP 段似乎是公开的，想封它并不难。 你们那里能直接上 Google，我好像没有见过你们租谷歌云的服务器并使用 www.google.com 作为 dest？

[SaintShit]

www.speedtest.net 是一个 Cloudflare 网站，后者的 IP 段似乎是公开的，想封它并不难。 你们那里能直接上 Google，我好像没有见过你们租谷歌云的服务器并使用 www.google.com 作为 dest？

Google cloud services are completely blocked in Iran due to sanctions

[SaintShit]

ISP Unableed to detect Reality, only popular SNI has been blocked recently (www.speedtest.net), and only white SNI now is www.theverge.com and working on MCI. However, the question remains: how can we discover the whitelisted SNI?

@RPRX

That's interesting, so I'm thinking of that they have both IP and SNI whitelist.

I just made a quick test with a server that it's IP had been limited 2 days ago

{
    "listen": "0.0.0.0",
    "port": 443,
    "protocol": "vless",
    "settings": {
        "clients": [
            {
                "id": "57fd57d8-2a52-4315-8bc2-ab01dcd06168",
                "flow": "xtls-rprx-vision"
            }
        ],
        "decryption": "none"
    },
    "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
            "dest": 9443,
            "xver": 1,
            "serverNames": [
                "www.speedtest.net",
                "www.theverge.com"
            ],
            "privateKey": "aLdhim1sD8StYH88yLGGtV7Ew9eTS7G6ayuxrBG_Wmg",
            "shortIds": [
                ""
            ]
        }
    }
}

haproxy.cfg:

defaults
    mode tcp
    timeout client 30s
    timeout connect 4s
    timeout server 30s

frontend tls_handshake_front
    bind *:9443 ssl crt /self-signed.crt accept-proxy
    mode http
    http-request return status 204

so it accepts both www.speedtest.net and www.theverge.com, and requests with first SNI has no downstream. second one, works great.

[Phoenix-999]

If this blockade is mainly based on traffic characteristics, then there is still room for resolution, and we have some plans. If it is mainly based on IP, for example, MCI has included more IPs in the list of "not to be trusted", then the existing agreement cannot solve it.~Can only use some magic, but I don't really want to use it.~

Just wanted to shed some more light on this situation. Fired up a couple of brand-new VPS servers with clean IPs, and just to be extra safe, I threw in a CDN certificate for good measure. And to top it off, I went ahead and blocked all IR domains and IPs directly on the server.

No big traffic spikes here, just a handful of small video files being sent back and forth for a legit speed test. And to keep things interesting, I've got the VPN running on a couple of devices as well.

Rest assured, all the devices are locked down tight. Our client apps and software are up-to-date and set up perfectly. I've only used "Reality" on 443 port and I've got us covered with whitelisted SNI, and I've gone the extra mile to implement every possible security measure to the best of my understanding.

Out of the three VPS instances, one got the Blocked within just 4 hours, while the other two managed to hold on for about a day before they were also blocked.

The second and third VPS instances started acting up with erratic and unusually high ping, causing a significant slowdown in speed. After a few hours of this instability, they eventually ended up completely blocked. It's starting to look like a potential DDoS attack on the servers.

I hope the information above sheds some light on the subject.

[Phoenix-999]

Iran's GFW is indeed upgraded. it's now detecting actively blocking reality/tls/xtls/tcp IP addresses.

https://twitter.com/AminAnvary/status/1691575510436909122

[Phoenix-999]

In recent days, widespread reports have emerged regarding MCCI's swift blocking of Reality-based VPNs within just hours and with minimal traffic. Additionally, even WS + TLS VPNs utilizing CDNs like Cloudflare are struggling to maintain functionality. This holds true even for domestic CDNs such as Arvan Cloud, which typically enjoy access to a less restricted Internet environment.

Here are a few observations I've made:

According to Netreach, connectivity to previously unrestricted websites remains unchanged. This suggests that the new system is adept at pinpointing specific protocols rather than causing widespread disruption.

The commonly used SNI for Reality connections among Iranian users, specifically speedtest.net, is encountering difficulties. However, some of these issues are resolved by switching to new SNIs.

Irancell, another major provider, still supports the use of WS + TLS via the Arvan Cloud CDN. This implies that the breakdown of WS + TLS connections on MCCI could be linked to the connection between the user's device and the CDN's servers. It's important to note that direct WS + TLS connections have been noticeably unstable over the past six months.

Looking ahead, the question arises: what are our next steps? As this new system expands to encompass all major providers in Iran, our options may become increasingly limited. Relying on a domestic relay, be it a CDN or server, was typically considered a last-resort solution to circumvent censorship.

Stay informed @RPRX

[Phoenix-999]

Just an Update

These serverless methods continue to function with MCI. ✔️ Workers + Fragment ✔️ Warp app by changing endpoints IP

Here's an example of what I'm currently using. The ping seems fine, but I've observed occasional stutters and lag during data transfer and while using certain apps.

ServerLess_TLSFrag_Xray_Config.txt

Special thanks to Ali/dxdydz for coming up with the solution.

[WatchDogsDev]

@RPRX Here is a sample of server configuration with coinmarketcap.com sni. I have also servers using discord.com / github.com / canva.com / brave.com etc.

{
    "listen": "0.0.0.0",
    "port": 18299, // Random port
    "protocol": "vless",
    "settings": {
        "clients": [
            {
                "id": "some-uuid",
                "flow": "xtls-rprx-vision"
            }
        ],
        "decryption": "none"
    },
    "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
            "show": false,
            "dest": "coinmarketcap.com:443",
            "xver": 0,
            "serverNames": [
                "coinmarketcap.com"
            ],
            "privateKey": "some-x25519-private-key",
            "publicKey": "some-x25519-public-key",
            "minClientVer": "",
            "maxClientVer": "",
            "maxTimeDiff": 0,
            "shortIds": [
                "da793ad1bf"
            ]
        }
    }
}

And here is the sample client config :

vless://some-uuid@example.myservers.com:18299?type=tcp&security=reality&flow=xtls-rprx-vision&fp=chrome&sni=coinmarketcap.com&pbk=some-public-key&sid=da793ad1bf#Client

[ghost]

The IR regime definitely upgraded their internet restriction system, since a week ago my REALITY servers stopped working one by one!

It seems they have shifted from "blocking" methods to "throttling", leaving the server open to SSH and every connection but significantly throttled and prone to high packet loss and it is exhibited on all ISPs not just MCI.

Here's a bandwidth test to one of my detected servers with iperf3 in TCP mode:

Client:

[  5] local 192.168.1.100 port 33362 connected to X.X.X.X port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  70.7 KBytes   579 Kbits/sec    2   1.36 KBytes       
[  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.36 KBytes       
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    1   1.36 KBytes       
[  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    0   1.36 KBytes       
[  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.36 KBytes       
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.36 KBytes       
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    1   1.36 KBytes       
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   1.36 KBytes       
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   1.36 KBytes       
^C[  5]  10.00-212.77 sec  0.00 Bytes  0.00 bits/sec    0   21.8 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-212.77 sec  70.7 KBytes  2.72 Kbits/sec    5             sender
[  5]   0.00-212.77 sec  0.00 Bytes  0.00 bits/sec                  receiver

Server:
Accepted connection from Y.Y.Y.Y, port 33360
[  5] local X.X.X.X port 5201 connected to Y.Y.Y.Y port 33362
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  8.16 KBytes  66.8 Kbits/sec                  
[  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  10.00-10.13  sec  0.00 Bytes  0.00 bits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.13  sec  8.16 KBytes  6.60 Kbits/sec                  receiver

As shown above, only a few KBytes of data reached the server in 6Kbits/sec! Changing the port does not change the result.

And here's the same test with UDP:

[  5] local 192.168.1.100 port 60358 connected to X.X.X.X port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec   129 KBytes  1.06 Mbits/sec  95  
[  5]   1.00-2.00   sec   128 KBytes  1.05 Mbits/sec  94  
[  5]   2.00-3.00   sec   128 KBytes  1.05 Mbits/sec  94  
[  5]   3.00-4.00   sec   128 KBytes  1.05 Mbits/sec  94  
[  5]   4.00-5.00   sec   128 KBytes  1.05 Mbits/sec  94  
[  5]   5.00-6.00   sec   128 KBytes  1.05 Mbits/sec  94  
[  5]   6.00-7.00   sec   129 KBytes  1.06 Mbits/sec  95  
[  5]   7.00-8.00   sec   128 KBytes  1.05 Mbits/sec  94  
[  5]   8.00-9.00   sec   128 KBytes  1.05 Mbits/sec  94  
[  5]   9.00-10.00  sec   128 KBytes  1.05 Mbits/sec  94  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec  0.000 ms  0/942 (0%)  sender
[  5]   0.00-10.77  sec   302 KBytes   229 Kbits/sec  5.572 ms  715/937 (76%)  receiver

Only 300Kb of a total of 1Mb data reached the server resulting in a whooping 76% data loss, and sometimes it even reaches 96%!

Detection methods are still a mystery, maybe it's amount total data sent and received over a certain time range (one of my servers was detected after two days with only 16GB of data transfer) or maybe the have implemented a SNI vs. IP verification check, and they purposefully keep a rotating SNI whitelist to minimize further collateral damage to the IT businesses or keep a certain demography connected (government bodies, state actors, trusted entities or others who are kept in the loop with the whitelist changes, not sure just a theory!) and we get lucky to find one.

A few observations so far:

• [.ir] SNIs and SNIs that are hosted on the Iranian INTRANET did not work for me.
• SNIs with certain keywords such cdn do not work or result in a swift detection of the server.
• SNIs that are hosted on the same network subnet as the server did not help in bypassing this throttling.

[Phoenix-999]

It's possible that these solutions and suggestions could offer some help!

If you decide to try any of these options, please consider sharing your results and data with us. This way, we can gain a clearer understanding of the situation at hand.

[NikolajHansen23]

如果这次的封锁主要是基于流量特征，那么还有解决的余地，我们有一些计划。如果主要是基于 IP，比如说 MCI 已经将更多的 IP 列入了“不可轻信”名单，那么现有的协议解决不了，~只能用一些魔法，但我不是很想用。~

I have a strong hunch that it's mainly based on traffic characteristics. Here is some of the evidence:

1. According to Netreach, connection to previously unrestricted websites is unchanged. This probably means the new system is good at detecting VPNs, not just sending blind noise to disrupt all connections.
2. Users who take advantage of domestic servers as relays for their Reality VPNs are also experiencing this. Since the new system is only deployed on MCCI, I guess they should be using some traffic characteristics.
3. IPs that stopped working with speeedtest.net SNI often work with other new SNIs (such as www.theverge.com). However, I'm not sure if changing the SNI would reduce the chance of detection or not.

See here: https://github.com/net4people/bbs/issues/277

[Phoenix-999]

Update - Thu 17 Aug - 13:50

Multiple reports from various locations across Iran indicate a common issue: encountering notable throttling, severe disruption, and substantial fluctuations on different ISPs. This scenario strongly suggests the possibility of a coordinated attack, potentially orchestrated by MCI.

We speculate that the recent events and peculiar behavior exhibited by ISPs in Iran could be indicative of some form of preparation or demonstration of power, potentially in anticipation of the upcoming commemoration of Mahsa Amini and other brave individuals who tragically killed and murdered during last year's uprising against the dictatorial regime.

As a wise man once said: "We can never forget that no matter how much it hurts, how dark it gets, or how far we fall, we are never out of the fight." ✌🏾

[ghost]

One more observations is that, once a server is detected, changing the SNI, the shortIDs, or uTLS fingerprints is useless! You have to wait out a period of 2~3 days, then limits are partially lifted, meaning you can try a new working SNI.

I observed this experimenting with my servers, server A and B were running with the same SNI, server A was detected and throttled while server B was working flawlessly (server B had far less data transmitted and occasionally used)!

Until we can figure out the detection methods, we're shooting in the dark...

[Phoenix-999]

Recent reports have surfaced, indicating that specific individuals have received warning messages from domestic VPS providers. These notifications inform them that their VPS IP addresses have been blocked due to the detection of VPN or proxy services on their servers. Additionally, they are advised not to generate any traffic for the next 72 hours.

Here some an example of warning messages

Has anyone else encountered the same problem?

[us254]

seems that IPs that had REALITY running and they had been working for a long time, are not about to be limited. but about IPs that have recently become active in the network, there is a high chance that they'll be limited after a few hours. no matter which port or which SNI you're using.

Is there a possibility that the old IP is on the white list?So it can be used for a long time.

This observation strongly implies that the REALITY protocol might evade detection, as otherwise, functional older servers would have undoubtedly been targeted and blocked.

[nursery01]

This observation strongly implies that the REALITY protocol might evade detection, as otherwise, functional older servers would have undoubtedly been targeted and blocked.

那反過來說，如果用檢測新伺服器的那些手段來檢測舊伺服器，那就可以讓它能夠在某些層面被檢測出來，因為新的REALITY已經躺下了

but about IPs that have recently become active in the network, there is a high chance that they'll be limited after a few hours. no matter which port or which SNI you're using.

至於舊伺服器是因為白名單ip還是其它原因我是有疑問的

[ghost]

Additionally, they are advised not to generate any traffic for the next 72 hours.

This is in line with what I experienced with one of my servers, I shut it down for 3 days and the restrictions were lifted. This was a good clue and now the waiting time is confirmed as 72 hours.

I inspected my logs and found out that before my server was throttled I had a few strange visits from Iran and once the throttling started they didn't come back! I found the originating networks as "AS48715 Sefroyek Pardaz Engineering PJSC", "AS48551 Sindad Network Technology Ltd." and "AS58224 Iran Telecommunication Company PJS".

While previously probing checks all came from China and well-known VPS providers, the current evidence suggests the IR regime has developed their own native probing tool. I'm setting up a tcpdump capture on a new server to honeypot this f!@#er! Will post updates.

[RPRX]

感谢你们的讨论，请做一个测试，步骤如下：

1. 使用 dokodemo-door 转发服务端的 80 和 443 端口至 www.speedtest.net
2. 将 hosts 设为自己的 IP，浏览器访问几次，看会不会被封
3. 重复 1，但使用 iptables 进行转发，看会不会被封

这有助于确定 MCI 是否针对 www.speedtest.net 设置了 traffic characters 白名单

[aaomidi]

Some Iranian apps have a built-in VPN reporting mechanism. E.g. if you have the the app for a bank installed, the bank app can listen to the VPN connection event and report it back.

The only real way of defending against this attack vector is to move the VPN to a router level, rather than the phone level - or not to have Iranian government apps on the phone you're running a VPN out of.

[hawshemi]

Discussion: https://github.com/XTLS/Xray-core/discussions/2450

[us254]

1. Blocking Behavior:

   • MCI and TCI ISPs in Iran throttle DL/UL speeds after high-traffic usage.
   • IPs are blocked after 2-3 days of heavy traffic.
   • Non-VPN servers (normal websites) are not affected due to whitelisting.

2. Graylisting and IP Whitelisting:

   • IPs are 'graylisted' unless whitelisted in a specific database.
   • Blocking occurs in waves or batch operations after data collection.

3. Data Collection and Blocking Mechanism:

   • Monitoring SNIs with high traffic to collect destination IPs.
   • Batch resolving SNIs to find real IPs for blocking.
   • Throttling based on observed connection counts for IP+SNI tuple.

4. Mitigation Strategies:

   • Fragmenting TLS header to hinder SNI detection and increase load on filters.
   • Changing IP and fingerprint to bypass GFW blocking.

5. Cloud Service Providers (CSPs) Status:

   • GCP blocked due to sanctions; IPs from Google are inaccessible.
   • Azure throttles IPs after using REALITY on MCI/TCI.
   • AWS IPs work with varied success across ISPs; frequent FP changes help.

[nursery01]

Short version

Whether the ip is clean and the sni whitelist

Data usage

[WatchDogsDev]

I think the new limit is based on connection count. I tried on many servers using SSH tunnel, Everything works fine without being detected ! The number of connections with REALITY is about 1000 on my servers and SSH Tunnel is about 1/20 (around 50 to 100) with same number of connected users.

[quackerd]

I think the new limit is based on connection count. I tried on many servers using SSH tunnel, Everything works fine without being detected ! The number of connections with REALITY is about 1000 on my servers and SSH Tunnel is about 1/20 (around 50 to 100) with same number of connected users.

How much traffic are you pushing thru the tunnel? If you are just doing sysadmin work maybe the firewall doesn't care.

[randomguy-on-internet]

Today, i started scanning for whitelisted domains using my tool, first thing that i encountered was that my HTTP post requests were dropping to server and i was getting timeouts, so i checked server and requests were arriving after 3-4 mins, so i changed the requests header to this:

headers = {'User-Agent':'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0','SNI':'www.theverge.com','Host':f'{server_ip}'}

still couldnt connect to server but i started capturing these requests all of a sudden from 118.123.105.93 which is from china so im guessing these are active probing right?

[WatchDogsDev]

I think the new limit is based on connection count. I tried on many servers using SSH tunnel, Everything works fine without being detected ! The number of connections with REALITY is about 1000 on my servers and SSH Tunnel is about 1/20 (around 50 to 100) with same number of connected users.

How much traffic are you pushing thru the tunnel? If you are just doing sysadmin work maybe the firewall doesn't care.

Around 30GB per day. No there are connected users using it as VPN.

[quackerd]

I think the new limit is based on connection count. I tried on many servers using SSH tunnel, Everything works fine without being detected ! The number of connections with REALITY is about 1000 on my servers and SSH Tunnel is about 1/20 (around 50 to 100) with same number of connected users.

How much traffic are you pushing thru the tunnel? If you are just doing sysadmin work maybe the firewall doesn't care.

Around 30GB per day. No there are connected users using it as VPN.

this may indicate that it's not traffic based. But what about this comment? https://github.com/net4people/bbs/issues/277#issuecomment-1683887714

[WatchDogsDev]

I think the new limit is based on connection count. I tried on many servers using SSH tunnel, Everything works fine without being detected ! The number of connections with REALITY is about 1000 on my servers and SSH Tunnel is about 1/20 (around 50 to 100) with same number of connected users.

How much traffic are you pushing thru the tunnel? If you are just doing sysadmin work maybe the firewall doesn't care.

Around 30GB per day. No there are connected users using it as VPN.

this may indicate that it's not traffic based. But what about this comment? net4people/bbs#277 (comment)

This is the point I think they are limiting based on number of connections and some traffic characteristics not the traffic amount.

[quackerd]

I think the new limit is based on connection count. I tried on many servers using SSH tunnel, Everything works fine without being detected ! The number of connections with REALITY is about 1000 on my servers and SSH Tunnel is about 1/20 (around 50 to 100) with same number of connected users.

How much traffic are you pushing thru the tunnel? If you are just doing sysadmin work maybe the firewall doesn't care.

Around 30GB per day. No there are connected users using it as VPN.

this may indicate that it's not traffic based. But what about this comment? net4people/bbs#277 (comment)

This is the point I think they are limiting based on number of connections and some traffic characteristics not the traffic amount.

Then we need more data to confirm the behavior.

not the traffic amount

If so this https://github.com/net4people/bbs/issues/277#issuecomment-1683887714 shouldn't be banned then. I assume they test with only one connection

[RPRX]

说几个关键点：

1. 伊朗 GFW 正在严格审查 TLS，但给 SSH 开绿灯，但如果使用 SSH 的人多起来，它同样会被严格审查。此前 有很多人建议给 Xray-core 加 SSH，我是不愿意加的，道理很简单，这么明显的协议，一加，一推广，伊朗 GFW 一封，反而更麻烦。说起来，我在 Project X Channel 提过 连过 SSH 是一个明显特征，伊朗 GFW 也有可能是看到了我的消息于是给实装了。

2. 对于 REALITY，这几天的讨论多次提到换用其它 SNI 可行，说明是 www.speedtest.net 受到了额外的审查，同样，这是因为在此之前你们都说这个域名可用，导致很多人集中在该域名，这必然会招致额外的审查。我知道你们可选的域名没那么多，但请尽量自己去寻找、分散开（就像中国人的做法一样），否则这样的事情还会再次发生。

3. 像上面这些东西，今年已经说过很多次了，但你们就是不听，看到一个能用的方法就希望所有人都用上。比如，若不是 Xray 对推广 TLS 分片这件事保持克制（加了功能但没加分享链接以抑制传播），这么明显的方法也很难活到现在供你们备用。

4. 请测试 https://github.com/XTLS/Xray-core/issues/2451#issuecomment-1683115799 ，这样我们才能知道 www.speedtest.net 受到的额外审查主要是针对 IP 还是 IP 以外的特征（记得测试时勿直连 SSH，详见 1 的链接），进而决定下一步的开发、放不放魔法。

[quackerd]

1. 说起来，我在 Project X Channel 提过 连过 SSH 是一个明显特征

这次伊朗不像用了这个特征，否则换SNI应该没有用。更像SNI被针对对比ip。话说SSH这种上古翻墙方法为什么一直能活到现在。

2. 对于 REALITY，这几天的讨论多次提到换用其它 SNI 可行，说明是 www.speedtest.net 受到了额外的审查

https://github.com/net4people/bbs/issues/277#issuecomment-1685032963 里面提到换到同ASN的SNI也不work，虽然也有人说换theverge.com可以。现在各种report没有一个统一的指向，很有可能是多管齐下的结果。

还有一种可能是对于某些小站的SNI，因为规模较小没有特别多IP直接就实装dns-ip对比了。而大站speedtest.com, theverge.com之类的由于ip巨多所以没办法直接实装。

[randomguy-on-internet]

1. Speaking of which, as I mentioned on Project X Channel , connecting to SSH is an obvious feature

Iran does not seem to have used this feature this time, otherwise it would be useless to change SNI. More like SNI is targeted vs ip. Let’s talk about why the ancient method of overcoming the wall, SSH, has been able to survive until now.

2. For REALITY, the discussion in the past few days has repeatedly mentioned that it is feasible to switch to other SNIs, indicating that www.speedtest.net has received additional scrutiny

net4people/bbs#277 (comment) mentioned that switching to SNI with the same ASN does not work, although some people say that switching to threverge.com will work. Now there is no unified direction for various reports, and it is likely to be the result of a multi-pronged approach.

Another possibility is that for the SNI of some small sites, because the scale is small and there are not many IPs, we directly install dns-ip for comparison. And big sites like speedtest.com, threverge.com cannot be installed directly due to the huge number of IPs.

The reason, people switched to theverge.com sni is becuz 2 months ago, they were using whitelist, meaning only certain sni had un-throttled upload speed and were working instead of current method. So i ran a flask server on VPS, then started sending sni to web server, changed configs and ran reality configs to test the upload speed. After testing a few thousands of domains as sni, i found 4 working domains beside speedtest.net and i made www.theverge.com public.

Thats why its working, it was whitelisted before this new system deployment.

[us254]

感谢你们的讨论，请做一个测试，步骤如下：

1. 使用 dokodemo-door 转发服务端的 80 和 443 端口至 www.speedtest.net
2. 将 hosts 设为自己的 IP，浏览器访问几次，看会不会被封
3. 重复 1，但使用 iptables 进行转发，看会不会被封

这有助于确定 MCI 是否针对 www.speedtest.net 设置了 traffic characters 白名单

Testing Results: Someone tested, None of Three Methods Blocked.

Test results show that the GFW did not block your connection to www.speedtest.net when you used the reality method with different port forwarding methods. This suggests that the GFW did not detect the reality method’s traffic characteristics, such as the protocol, encryption method, or packet pattern. So, it seems that the GFW is blocking your servers based on their IP addresses, not the reality method’s traffic characteristics.

[ghost]

I wonder if finding a white SNI is the main issue, then shouldn't the method discussed in these issue and discussion work with no problem.