Closed WatchDogsDev closed 5 months ago
I think it's being detected easily because you all are using TCP on 443, Your traffic is not like a browser's traffic So you must use H2 or WS, H2 is great But as there is too much packet loss in Iran's internet Then you must use websocket But REALITY does not support WS, because @RPRX does not like it https://github.com/XTLS/Xray-core/issues/2105
I think it's being detected easily because you all are using TCP on 443, Your traffic is not like a browser's traffic
FYI browsers use 443 for TLS/TCP traffic and REALITY coupled with uTLS fingerprints tries to imitate normal browsing traffic AFAIK.
But REALITY does not support WS, because @RPRX does not like it https://github.com/XTLS/Xray-core/issues/2105
REALITY and Websockets both are based on TCP and similar in nature, once cannot support another per se and does not need to either, since REALITY is not an underlying network standard!
However if you'd like to chain these two and use one inside the other, I suggest you read the documentation and maybe adopt a more positive tone.
3. 像上面这些东西,今年已经说过很多次了,~但你们就是不听,看到一个能用的方法就希望所有人都用上~。比如,若不是 Xray 对推广 TLS 分片这件事保持克制(加了功能但没加分享链接以抑制传播),这么明显的方法也很难活到现在供你们备用。
You're making a valid point here and I agree but as you may know, there's a movement going on in Iran and we need access to uncensored internet to spread the news and organize the protests, that's why GFW is in hell mode here in the first place.
For some of the methods we share publicly we're sure it will be detected and blocked soon but we go ahead with sharing it anyway because otherwise we will go in total darkness!
Anyway I have yet to test your suggested Dokodemo-door
setup since all my server nodes are blocked for the next days, but I had one node left with Hysteria
running on a non-443 UDP port that had never Xray or other TCP-based proxies on it and I have been pulling a lot of intentional traffic through it just to test the "traffic volume" theory, but so far it is still up and running.
If no issues come up, it may dismiss the traffic volume theory and further suggest that the traffic characteristics of REALITY are the culprit here. Another good experiment in my opinion would be to deploy only the traditional protocols (WS, gRPC, H2) on another server with a working HTML fallback to further isolate the cause and see if REALITY is subject to feature analysis.
I'm thinking out loud here. Let's say they can't detect Reality's traffic characteristics. Then they get suspicious of a connection and put it into a "further analysis" bucket.
Let's say they have a list of whitelisted non-Iranian domains? Then they'd like to do some form of reverse lookup to check if that IP indeed belongs to the SNI that was sent with it. How do they do this?
Do they check the DNS ptr record? Do they access the IP to see where it'll finally redirect to? Do they use something like certificate common names (CN)?
Understanding this would be the key to making Reality almost undetectable for now.
According to the tests I did, I found that the function is similar to filtering That is, after I used Reality and it was limited, it was also limited with other protocols. It has ping but it doesn't work
Other than sni white list
So, it seems that the GFW is blocking your servers based on their IP addresses, @us254
If the server is getting blocked by GFW then why changing the sni, makes it work again?
@us254 感谢测试,有两个问题,一是 "Connect via SSH to Ubuntu server" 是否是本地直连 SSH?如果是的话请挂代理,因为理论上伊朗 GFW 可以针对 部署过程 这一特征,且从上面一些“静置 IP”的讨论可以看出伊朗 GFW 有长期观察你的 IP。甚至“开放 SSH 端口”也可以算作特征,如果你想偷的网站只开放 TCP/80、443 的话。再引申出 QUIC,假如说 www.speedtest.net 一定支持它,若你的服务器不支持则是特征,所以 UDP/443 也要转发。总之,和目标服务器开放完全一样的端口、服务才算做得比较彻底。
第二个问题是你发的测试结果和你得出的结论似乎是矛盾的,请重新阐述一下。
此外对于 REALITY,实际上它是有一定的流量特征以及一些可被主动探测的方法(偷别人时),如果测试表明伊朗 GFW 不是主要针对 IP,那我们就修复这些问题,否则我就放一些什么 ADSL 魔法之类的
@us254 感谢测试,有两个问题,一是 "Connect via SSH to Ubuntu server" 是否是本地直连 SSH?如果是的话请挂代理,因为理论上伊朗 GFW 可以针对 部署过程 这一特征,且从上面一些“静置 IP”的讨论可以看出伊朗 GFW 有长期观察你的 IP。甚至“开放 SSH 端口”也可以算作特征,如果你想偷的网站只开放 TCP/80、443 的话。再引申出 QUIC,假如说 www.speedtest.net 一定支持它,若你的服务器不支持则是特征,所以 UDP/443 也要转发。总之,和目标服务器开放完全一样的端口、服务才算做得比较彻底。
第二个问题是你发的测试结果和你得出的结论似乎是矛盾的,请重新阐述一下。
I always SSH into my servers through Tor, never directly but then again my REALITY servers were detected! For my fellow Iranians I even wrote a guide on how to SSH to your servers inside a Tor tunnel here, the gist is:
ssh
command:ssh -v -o "ProxyCommand=nc -X 5 -x PROXY_IP:PROXY_PORT %h %p" USER@SERVER_IP
In the case of Tor, that would be ssh -v -o "ProxyCommand=nc -X 5 -x 127.0.0.1:9050 %h %p" root@x.x.x.x
.
So REALITY would only take care of 443/tcp and we have to manually take care of forwarding other ports. Also correct me if I'm wrong, the target SNI should return a 200 HTML response when doing a curl
or it doesn't matter?
Here's the curl
command I use to find if a target SNI will work, care to add to it any missing details if you please:
curl -Iv --tlsv1.3 --http2 --curves X25519 https://YOUR_SNI 2>&1 | grep -E "SSL\ connection\ using|ALPN|^HTTP/2
At first, I thought the Reality Protocol would automatically handle port forwarding for open ports. However, it now seems that we have to do it manually using iptables
.
Is my understanding correct?
destination IP:
dest
: www.example.com:443
Obtain the IP address by pinging this domain name on the VPS.
You can use the following command to find network interface names (like eth0, eth1,enp1s0 and so on):
ip addr
This command will display information about network interfaces, including their names.
To forward TCP/80 and UDP/443 traffic, follow these steps:
# Forwarding TCP/80 and UDP/443
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.d/ip_forward.conf
sysctl -p /etc/sysctl.d/ip_forward.conf
# Install iptables-persistent if not already installed
apt install -y iptables-persistent
# Set up port forwarding for TCP/80
iptables -t nat -A PREROUTING -i enp1s0 -p tcp --dport 80 -j DNAT --to-destination <destination_IP>:80
# Set up port forwarding for UDP/443
iptables -t nat -A PREROUTING -i enp1s0 -p udp --dport 443 -j DNAT --to-destination <destination_IP>:443
# Apply NAT masquerade
iptables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE
# Save iptables rules
netfilter-persistent save
# List NAT rules with line numbers for verification
iptables -t nat -nL --line-numbers
- 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.
- 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.
Actually It may not be a whitelist. I Think they can't have a complete list of all IPs available for speedtest.net , So the connection will go through. More then anything they may be improving their firewall by monitoring the vps behaviour after being limited.
此外对于 REALITY,实际上它是有一定的流量特征以及一些可被主动探测的方法(偷别人时),如果测试表明伊朗 GFW 不是主要针对 IP,那我们就修复这些问题,~否则我就放一些什么 ADSL 魔法之类的~
@RPRX, after we encountered that massive block, I did these and I did not get blocked since now (from 3/4 days ago) while people are still reporting they are getting blocked:
serverNames
and I set dest
to my API server IP (I did not steal others' SNI, I used my own SNI), after 1TB of traffic usage and a few days pass I still did not get blocked and it's working at full speed.Note that, compared to SNI speedtest.net that I was previously using the upload speed is like 30% less than my own SNI. Using my own SNI only worked for MCI/Shatel and for ISPs like TCI or Irancell did not work. Plus, I did not forward 80 to anything and port 80 is unused currently.
Hope this helps,
I think it's being detected easily because you all are using TCP on 443, Your traffic is not like a browser's traffic
FYI browsers use 443 for TLS/TCP traffic and REALITY coupled with uTLS fingerprints tries to imitate normal browsing traffic AFAIK.
Firewalls like GFW can detect shits like TLS in TLS, but you think they can't check if your connection is Raw TCP or HTTP ? uTLS will not change packets pattern
But REALITY does not support WS, because @RPRX does not like it https://github.com/XTLS/Xray-core/issues/2105
REALITY and Websockets both are based on TCP and similar in nature, once cannot support another per se and does not need to either, since REALITY is not an underlying network standard!
However if you'd like to chain these two and use one inside the other, I suggest you read the documentation and maybe adopt a more positive tone.
Stop talking nonsense please @kyochikuto
"The second question is that the test results you posted seem to be contradictory to the conclusions you have drawn. Please elaborate again."
- @rprx
In reevaluating test outcomes, it appears that MCI ISP's blocking of Reality protocol is not related to IP/address or protocol traits. Dokodemo-door and iptables forwarding seem ineffective. Blockage likely hinges on distinct criteria. Further investigation needed.
- my VPN server IP and my API server IPs are in the same data center but not same location, two different cities of a country
- I've used the SNI that I owned for
serverNames
and I setdest
to my API server IP
@amir-devman Did you point your SNI to the IP of the reality server or the API server?
- my VPN server IP and my API server IPs are in the same data center but not same location, two different cities of a country
- I've used the SNI that I owned for
serverNames
and I setdest
to my API server IP@amir-devman Did you point your SNI to the IP of the reality server or the API server?
@us254 serverNames
ip is to SNI of API server (api.domain.com), dest
is pointed to the IP of API server (xxx.xxx.xxx.xxx:443).
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
I also can confirm that. I had a VPS with a clean IP. I used VLESS+TCP+RPRX-VISION+REALITY plus a SNI that is in white list GFW. The vless link work in all ISPs as well but it's not working in MCI operator. I get TLS handshake error on that config on MCI and on social media like Telegram I get updating error messages Meaning that the VPN is connected and disconnected and again. It's seems MCI firewall updated and detect VPS IP. I tried to change SNI on my vless config but didn't make any changes and It seems that the restriction has been imposed on the server's IP address.
It's been an hour since MCI removed its restrictions. hopefully, this problem won't happen again.
It's been an hour since MCI removed its restrictions. hopefully, this problem won't happen again.
You know that it will happen again soon with all of the ISPs in Iran, right?
(Although just MCI lifted, but other ISPs like TCI,Shatel,ParsOnline
are still limiting and blocking)
It's been an hour since MCI removed its restrictions. hopefully, this problem won't happen again.
Yes, but nothing is known whether this is temporary or will return again.
Update:
It appears that the previously affected Domain/Subdomains that were Filtered & Blocked are now up and running again, and they've been unblocked!
We're a bit puzzled about the reasons behind these behavior, and We suspect that this might be in preparation for the anniversary of MAHSA AMINI and the people's uprising against the dictator regime from last year, but as of now, it's all speculation.
It's possible that The Iranian regime are conducting tests on the new system for a wider rollout. While we can't definitively pinpoint the cause, this turn of events is undoubtedly positive.
It would be greatly appreciated if someone could confirm these changes.
It appears that the previously affected Domain/Subdomains that were Filtered & Blocked are now up and running again, and they've been unblocked!
I don't understand why people say the servers are unblocked! Yes, the "Domains" are unblocked but the IP addresses of the VPS are limited by Upload speed and high jitter! No matter what config as long as you are using some sort of TLS function, they just limit the Upload speed to 0.1 mb/s. So nothing has changed...
Right now MTN(Irancell & followers like TCI,Shatel,ParsOnline,Zitel,...
) are limiting the upload speed of the "greylist" IP addresses (which contain almost all IP ranges from famous providers!)
I don't understand why people say the servers are unblocked! Yes, the "Domains" are unblocked but the IP addresses of the VPS are limited by Upload speed and high jitter! No matter what config as long as you are using some sort of TLS function, they just limit the Upload speed to 0.1 mb/s. So nothing has changed... Right now MTN(
Irancell & followers like TCI,Shatel,ParsOnline,Zitel,...
) are limiting the upload speed of the "greylist" IP addresses (which contain almost all IP ranges from famous providers!)
I completely agree; there's a possibility that they are planning something even more worst!
I've come across a new and rather strange issue that I wanted to share with you all. Just in case anyone else is experiencing the same phenomenon or perhaps has a reasonable explanation for it.
I've created a new VPS server using a clean IP
, carried out my usual setup and configuration routine, and generated the Reality configuration with a clean and whitelisted SNI
on port 443
. (VLESS+TCP+Reality
)
Everything appeared to be in order until I conducted tests across various ISPs and in different cities to ensure that everything is functioning correctly as it should. The client app and software are identical and up-to-date with the latest version.
Interestingly, the same configuration that was functioning flawlessly in cities like Tabriz, Isfahan, and Shiraz is no longer operational in Tehran, the capital city. This issue is observed across multiple ISPs in Tehran.
I've attempted various whitelisted SNI options, but the outcome remains the same, BUT when I’ve changed the port number from 433 to any 4 or 5 digit number the same config with the same SNI working in Tehran as well as other cities with consistent and decent upload and download speeds.
Has anyone else encountered a similar issue?
Yes. this issue was intense like a year ago. but it was smoothened across the country after a month but it's not completely gone now. sometimes it happens for config to work in another city with a different port
or SNI
.
我持续关注伊朗 GFW 的动向,看起来上周它不仅撤回了这个 issue 所讨论的严格过滤,还开放了 QUIC 协议与很多 Cloudflare 的 IP,我也想知道为什么它的做法会 180 度大转弯,有任何内幕消息吗?
@RPRX
I continue to follow the trend of Iran GFW. It seems that last week it not only withdrew the strict filtering discussed in this issue, but also opened up the QUIC protocol and many Cloudflare IPs. I also wonder why it made a 180-degree turn in its approach. Some Any insider tips?
Our speculation is that the Iranian regime has uses various types of psychological techniques and mind games on numerous occasions in the past same as we are witnessing now.
They intentionally downplay restrictions and limitations, while saturating the dissemination of false news through national TV channels and all government websites. This is aimed at creating a false sense of hope and positivity, ultimately leading the general public to believe that things are returning to normal. Of course, by employing these tactics, they effectively deter technical individuals from devising new strategies and solutions in case of a complete blackout of the internet.
If you're wondering why they are implementing these measures at this particular time when about 2 weeks ago we witness the Large scale blocking of Reality!
We believe that this could be linked to the upcoming anniversary of MAHSA AMINI's death and many others and the events surrounding the people's uprising against the dictatorial regime, which resulted in bloodshed last year. The regime might be aiming to prevent any potential gatherings, online discussions, or movements that could gain momentum during this sensitive time.
Exactly, it appears that the Iranian regime is taking preemptive measures to prevent people from organizing and developing new methods to bypass internet filtering and censorship ahead of the anniversary. By implementing these measures now, they aim to disrupt any potential plans or strategies that could emerge closer to the anniversary date. This way, they hope to maintain control over the flow of information and prevent the spread of news or discussions that could challenge their authority.
We must remain vigilant and prepared. A storm is approaching, and we need to have alternative options in place in case of a complete blackout of free internet.
Exactly.
Now MCI and TCI know how to block IP addresses of VPSs that have v2ray/xray servers (soon all other ISPs do this). And they know most VPNs use UDP. They don't want to deal with other protocols and ways other than these common ones.
Therefore every time they want to shut off the Foreign Bandwidth, they just turn the switch on and BOOM...
@RPRX
我持续关注伊朗 GFW 的动向,看起来上周它不仅撤回了这个 issue 所讨论的严格过滤,还开放了 QUIC 协议与很多 Cloudflare 的 IP,我也想知道为什么它的做法会 180 度大转弯,有任何内幕消息吗?
@NimaQazi The President of the Electronic Commerce Association's Board of Directors.
Aug 21
Following the release of the Electronic Commerce Association's report on "Internet Quality in Iran," numerous meetings were convened at the Ministry of Communications and Infrastructure Company. During these meetings, we presented several practical proposals aimed at enhancing the quality of Iran's internet. Among these proposals, four were submitted to the Ministry of Communications for consideration.
Based on assessments conducted by the Internet and Infrastructure Commission of the Association, the issues previously causing disturbance and listed on the gray list have been resolved as of today (21th). Notably, the high levels of packet loss, retransmissions, and disconnections in international connections, even for destinations that were not whitelisted, have been successfully addressed. Additionally, restrictions on the HTTP/3 protocol have been lifted for internet service providers.
As an example of the positive impact, the usage of the HTTP/3 protocol in MCI has surged from 0% earlier today to nearly 20%, and any download and upload issues related to Cloudflare have been eliminated.
We extend our gratitude to Minister Mr. Zarepour and CEO of Infrastructure Mr. Jafarpour for their diligent follow-up and support. Our commitment to rigorously testing and reporting on internet quality persists. We are actively pursuing our requests with various institutions, with the aspiration of improving internet quality in Iran.
In forthcoming reports to be published in the coming months, the E-Commerce Association will meticulously document all changes, actions, improvements, and identified weaknesses, ensuring a comprehensive overview of developments in the realm of internet quality.
@us254 This is one of their techniques that I mentioned on my previous message to deceive the public.
Do not trust whatever any member of the government telling you.
This is just the distraction and cover up for what's about come.
i know its not the best option and we are on xrays github page but anyone tried dnstt, kcp with "dns" header? I got past my ISP firewall with above methods. Also somone mentiod that port 443 does not work but atoher random ports do, i think it possible to use xray so that it changes ports randomly.
我持续关注伊朗 GFW 的动向,看起来上周它不仅撤回了这个 issue 所讨论的严格过滤,还开放了 QUIC 协议与很多 Cloudflare 的 IP,我也想知道为什么它的做法会 180 度大转弯,有任何内幕消息吗?
I think it's will be great if Reality support QUIC Transport too beside TCP Because it seems there is an Intentional disturbance on packets on Irancell Operator when we ping some IP addresses and we can see 1 packet loss in 6 icmp request and this will be repeating(5 successful request and 1 packet loss in CMD). and Due to the guarantee of the TCP protocol in the order of arrival of the packets, even the packets that were sent earlier, it must wait for the retransmission of the packets that get loss by GFW. the QUIC protocol (which is designed on the UDP protocol) can completely solves this problem, so if we have a request (stream) with packet loss like what happening in Irancell Operator, it causes the rest of the requests cannot be left pending. In theory, the presence of such a protocol on the Iranian network such as Irancell Operator can be very helpful.
@MrSaeid007 本来以为 Go 1.21 的 QUIC 已经 ready,但它没有,等 Go 官方代码再完善些会给 REALITY 加 QUIC
但 QUIC 支持连接迁移会造成麻烦,这会允许 GFW 100% 确认你这个服务器是偷别人来翻墙,所以我并不推荐大家偷别人的 QUIC
In addition to my previous comment https://github.com/XTLS/Xray-core/issues/2451?notification_referrer_id=NT_kwDOBRzCpbM3NDAxMDc4Mjc0Ojg1NzcwOTE3#issuecomment-1685743051 I tested some new things which are followings:
I've my Reality config fallback to a WordPress website which has my own certificate on it.
Note that these are things that are happening after restrictions are less.
In addition to my previous comment #2451 I tested some new things which are followings:
1. MCI and almost all ISPs except Irancell and + a few other IPSs work with my own SNI. 2. Irancell still works with [www.speedtest.net](http://www.speedtest.net) SNI and it's not good with my own SNI. 3. MCI is also not good with [www.speedtest.net](http://www.speedtest.net) but works perfectly with my own WNI. 4. Looks like there are no gray-list IP ranges (maybe I'm wrong, at least I didn't find any gray-listed IPs recently). 5. No IP has gotten blocked by using reality. 6. It looks like we have two categories for ISPs that work well in two different ways. 7. UDP protocols like mKCP are working perfectly on both Irancell and MCI. 8. I had an IP that was gray-listed, now working with my SNI perfectly on MCI but not Irancell but it's good with [www.speedtest.net](http://www.speedtest.net) for Irancell; which wasn't the case before restriction removal.
I've my Reality config fallback to a WordPress website which has my own certificate on it.
Note that these are things that are happening after restrictions are less.
what do u mean by saying "my own SNI", are u using steal'yourself 's method?
@randomguy-on-internet Yes
As I mentioned in my previous comments Buckle up your seat belt because the storm is about to start. 6 days left to anniversary of MAHSA AMINI**
⚠️Netblocks Confirmed: An internet disruption has been registered in #Iran for the second night in a row from ~1:00 am local time; Network data show connectivity falling down to 71% of ordinary levels 📉
And struggle continues
Netblocks Confirmed: Live metrics show a significant disruption to internet connectivity in Zahedan, #Iran; the incident continues the weekly pattern of regional internet shutdowns targeting anti-government protests, and comes on the eve of the anniversary of Mahsa Amini's death
2023-09-23
Confirmed: An internet disruption has been registered in #Iran for the third time this month from ~1:00 am local time; Network data show connectivity falling down to 82% of ordinary levels 📉
@MrSaeid007 本来以为 Go 1.21 的 QUIC 已经 ready,但它没有,等 Go 官方代码再完善些会给 REALITY 加 QUIC
但 QUIC 支持连接迁移会造成麻烦,这会允许 GFW 100% 确认你这个服务器是偷别人来翻墙,所以我并不推荐大家偷别人的 QUIC
Hi @RPRX Recently, MCI(Mobile operator in Iran) Filtering system is blocking Reality protocol. So the Reality vless config traffic will be blocked after some times(depending maybe 15 minutes or more) So I guess in MCI the traffic will be detected by MCI System. The good news is that other operators are fine right now.
@MrSaeid007 All IP addresses that were graylisted from a year ago, are blocked by MCI now. This is not on Reality itself.
@MrSaeid007 All IP addresses that were graylisted from a year ago, are blocked by MCI now. This is not on Reality itself.
ofc that's not the case rn. if we use a new clean ip with reality, it takes 15 min to get banned over MCI again.
ofc that's not the case rn. if we use a new clean ip with reality, it takes 15 min to get banned over MCI again.
If that's the case, the IP address was not clean at all at the first place.
ofc that's not the case rn. if we use a new clean ip with reality, it takes 15 min to get banned over MCI again.
If that's the case, the IP address was not clean at all at the first place.
"EVEN IF YOU USE BRAND NEW CLEAN IP, IT GETS BANNED AFTER 15 MIN OF USING REALITY"
"EVEN IF YOU USE BRAND NEW CLEAN IP, IT GETS BANNED AFTER 15 MIN OF USING REALITY"
'Brand new' ip address does not mean anything! Maybe last owner had wireguard or simple shadowsocks vpn on that IP!
Clean IP is an IP address that is not graylisted since last year!!! Do you own an IP address for a year and only used updated and modern protocols with reality+vision flow ? I doubt that.
如果是 4 天前开始的广泛封锁,那么早就应该有报告,但目前除了 你们,并无其他人报告这个情况 GFW 当然在不断增强自己的能力,但若只封了你,基本上可以确定是和你自己的配置有关,至少你应当把配置贴上来 我们不喜欢被封后发贴不附上具体配置且标题为“XX 被识别了”的人,更不喜欢被这样的东西到处刷
但我暂时不会点 Close,看有没有更多报告
The SNI Should be Whitelisted we create a reality config with a clean IP but it takes less than 24H to stop Working on MCI but some founded some SNI's Which called whitelist Even The IP That have been Blocked Start To work Again ? is there Any SNI Checker Working between Server And Client ?
It always starts with MCI then goes to other operators/providers the replaced ip only took 20 minutes to get blocked any suggestion dear @RPRX ?
@MrSaeid007 本来以为 Go 1.21 的 QUIC 已经 ready,但它没有,等 Go 官方代码再完善些会给 REALITY 加 QUIC
但 QUIC 支持连接迁移会造成麻烦,这会允许 GFW 100% 确认你这个服务器是偷别人来翻墙,所以我并不推荐大家偷别人的 QUIC
Hi @RPRX Recently the Reality protocol will be detected in all operator in Iran and being blocked 🚫 the config I used is: vless+tcp+reality+white list sni(speedtest.net) plus flow: xtls rprx vision The experience I had this time was that if we use the vless Reality for personal use, it's won't be blcok by GFW but if we use the Reality for more people like 3 or 4 users, our server will be blocked by GFW, the error we received is http: tls handshake time out. please note that even if we change the sni, our server will still not be connected on our config so changing SNI is useless anyway.
So, I advise the people who read this to DO NOT USE Reality to connect more than 2 or 3 people and only use your server for personal use on Reality, otherwise your Server(VPS) IP address will be flagged by GFW and your server ip address may not be useful after. So be careful guys.
@MrSaeid007
As we are testing, these blockings have nothing to do with XRAY/V2RAY/Trojan/ShadowSocks or other protocols. So this has nothing to do with Reality
itself.
There are some other factors for Iran's Firewall.
Discussed in https://github.com/XTLS/Xray-core/discussions/2450