bbs
bbs copied to clipboard
net4people
Cloudflare's Update Cripples Iranian VPNs
Recently, for about two weeks, Cloudflare has been blocking domains that use CDN traffic to tunnel VPN traffic, such as v2ray. After contacting Cloudflare, their support team confirmed that the issue stems from their newly updated firewall. This change has already caused widespread issues for Iranian users, as many VPNs relied on Cloudflare to bypass censorship. With IRGFW (Iranian Great Firewall) heavily blocking and detecting IPs, Cloudflare was one of the few viable options for secure access.
IRGFW couldn't block Cloudflare’s IPs outright due to potential collateral impact, but other CDNs like Fastly are easily blocked. Moreover, alternatives to Cloudflare are neither as accessible nor as affordable. Now, Iranians are on the brink of a digital crisis, as Cloudflare’s systems increasingly flag v2ray traffic as HTTP DDoS attacks, leading to more frequent disruptions.
Iranians are effectively trapped between two firewalls: the IRGFW and restrictions from international datacenters that don’t service Iranians, compounded by a lack of payment options for most platforms. With these barriers in place, accessing free internet and media is becoming nearly impossible.
You say the Cloudflare system is detecting V2Ray traffic as DDoS. Does it happen only when one V2Ray server is accessed by many clients? Is it something about the protocol that is being detected, or is it the large number of clients?
Is the Cloudflare system that is wrongly detecting DDoS configurable by the owner of the Cloudflare account? Or is it "global" and not configurable?
Cloudflare’s systems increasingly flag v2ray traffic as HTTP DDoS attacks, leading to more frequent disruptionss
What is your V2ray setup? Would enabling connection multiplexing help (so that there aren't that many TCP connections)?
You say the Cloudflare system is detecting V2Ray traffic as DDoS. Does it happen only when one V2Ray server is accessed by many clients? Is it something about the protocol that is being detected, or is it the large number of clients?
Is the Cloudflare system that is wrongly detecting DDoS configurable by the owner of the Cloudflare account? Or is it "global" and not configurable?
Cloudflare's identification of V2Ray traffic as potential DDoS activity does not seem tied to the number of clients, as the issue has been observed even with minimal usage. It appears that detection relies heavily on analyzing packet headers. While altering headers can sometimes bypass this detection, it’s not a lasting fix, as VPN traffic typically exhibits identifiable 1-to-1 patterns, which may also be leveraged for detection in the future.
To disable the security features blocking such traffic, Cloudflare typically requires an Enterprise plan. However, some users on Cloudflare's Discord server have reported temporary resolutions after upgrading to the Pro plan and submitting support tickets.
One response from Cloudflare support mentioned:
The team has removed the blocks but if the zone is running v2ray or some other sort of VPN, it is likely that these rules will auto-apply in the future.
Even if the problem is solved with this, we will be restricted again due to the support announcement.
Cloudflare’s systems increasingly flag v2ray traffic as HTTP DDoS attacks, leading to more frequent disruptionss
What is your V2ray setup? Would enabling connection multiplexing help (so that there aren't that many TCP connections)?
We tested all protocols like WS, gRPC, HTTP upgrade with TLS and non-TLS, and even users with mux were restricted too, so I don't think this is a solution.
I didn't use my server because it was too slow, but now it's dead in every protocol
Responds to pings, can proxy directly, but blocked from proxying through CF
CDN Abuse era is gone, other CDNs will follow soon, just like how they ended domain fronting We can't be mad at them to not let us abuse their service It's time to switch to direct and domestic relay proxying
Or you can ask proxy cores developers to make their protocols and transports bypass CDN firewalls too
Has anyone in Iran tried the suggestion of @RPRX from https://github.com/XTLS/Xray-core/pull/3955?
比如，你可以 XHTTP-H3-CDN 上行，结合 XHTTP-H2-REALITY 下行，给 GFW 整点麻烦 🎃，这下又开启了一个崭新的时代
For example, you can use XHTTP-H3-CDN upstream and combine it with XHTTP-H2-REALITY downstream to cause trouble to GFW 🎃. This has opened a new era.
Actually, you can actually add an exclusion policy in cloudflare dashboard to whitelist this type traffic:
- Log into your cloudflare account in dashboard.
- Click the domain you are using.
- Find Rules-Page Rules-Create Page Rule
- Enter the full URL you used on v2ray on the URL selection, such as example.com/abcd.
- On pick a setting search and click disable security.
- Click save and deploy page rule.
Once that's done you should be able to reconnect again.
Actually, you can actually add an exclusion policy in cloudflare dashboard to whitelist this type traffic:
- Log into your cloudflare account in dashboard.
- Click the domain you are using.
- Find Rules-Page Rules-Create Page Rule
- Enter the full URL you used on v2ray on the URL selection, such as example.com/abcd.
- On pick a setting search and click disable security.
- Click save and deploy page rule.
Once that's done you should be able to reconnect again.
Cloudflare rules have first priority.
Cannot confirm it.
Have just set up a webtunnel bridge behind Cloudflare, it's also HTTP Upgrade. And everything is OK.
Just set up a webtunnel bridge behind Cloudflare, it's also HTTP Upgrade. And everything is OK.
What's webtunnel bridge? Have you tested it?
What's webtunnel bridge? Have you tested it?
https://blog.torproject.org/introducing-webtunnel-evading-censorship-by-hiding-in-plain-sight/
Yes, it's online and working from Tor Metrics and myself usage.
[redacted]
I've sent the bridge line to your gmail.com address, test it in Tor Browser.
Emm... Is this new security policy specifically targets to Iranian clients?
Emm... Is this new security policy specifically targets to Iranian clients?
I can't find anything about china or Russia
I don't rely on CF too much, but i use it too This problem happened for me multiple times even after disabling security for the proxy path But after switching to VMESS+WS without early data trick (?ed=N) problem didn't happened anymore (i also added some normal browser-like headers and whitelisted proxy path too)
All Protocols and Transports or Tricks that made by Xray-core exposes the server to GFW(if used without TLS) and CDNs(obviously with or without TLS) It's VLESS Protocol does not support any encryption, unlike VMESS or SS It's tricks like early data(?ed=N) header is always "Sec-WebSocket-Protocol", and it has no option to change it It's new XHTTP (SplitHTTP) Transport is also detectable by a 100% detection rate it even does not cost a single CPU cycle for GFW or CDNs to detect them And it's funny that it's dev is saying proxy panel developers are GFW agents lol
I have the problem you mentioned when setting up my domain name. Is there any way to solve it?
I have been using a websocket ( and recently httpUpgrade ) proxy over CF for a very long time, and I have neither got banned from CF nor had my domain detected by the GFW. The traffic usage is not significant, around 10 15 GB per day on one domain, on another around 20 GB to 40 50 GB per day, but there are claims that usage is not a factor here. So if the usage is not a crucial factor here, most likely the reason for being detected is not the 'protocol' itself, but how you employ it.
See Cloudflare's updated Terms: https://www.cloudflare.com/terms/ on December 3, 2024. Last edition is May 10, 2023.
**2.2.1 Restrictions**
Unless otherwise expressly permitted in writing by Cloudflare, you will not and you have no right to:
...
+ (j) use the Services to provide a virtual private network or other similar proxy services.
FYI, These might help a bit
Free CDN services
https://www.cloudns.net/ https://www.duckdns.org/ https://desec.io/ https://www.noip.com/
Are you kidding? How would that help abusers? It only serves static files.
Are you kidding? How would that help abusers? It only serves static files.
Check the table bro, i told you it might help .. it is not going to be Cloudflare mate
Check the table bro, i told you it might help .. it is not going to be Cloudflare mate
The op is asking about VPN, he apparently doesn't need an ordinary CDN service.
@UjuiUjuMandan [@wkrp: cut uncollegial phrase] try this mate, you can use ClouDNS in conjunction with an external certificate authority (CA) to set up and secure your domain with SSL/TLS. https://www.cloudns.net/
FYI
https://developers.cloudflare.com/bots/reference/javascript-detections/
Check the table https://github.com/net4people/bbs/issues/429#issuecomment-2578231140 Free CDN services
By the look of it none of those services except Cloudflare provide actual CDN services. They are mostly DNS namerservers providers, aren't they?
@Kiya6955 Could you provide the original server config you was using that triggered the first block from Cloudflare. I suspect that cloudflare is not applying the same blocking rule to all accounts as I was unable to reproduce the issue you are encountering.
可能是只针对伊朗
对于 APT-ZERO 提的那些问题，为了防止他继续在别处散播他的错误逻辑，我简单说明一下：
- VLESS 本来就是被设计于搭配 TLS、REALITY 等安全传输层使用的，或者说 TLS、REALITY 就是 VLESS 的 encryption，你去掉它们然后说能被 GFW 检测，这合理吗？况且你提出的 SS、VMess 等自带的全随机数加密早就被 GFW 封死了
- 浏览器转发只支持设置 Sec-WebSocket-Protocol，~~或者放 path~~
- 即使 XHTTP 没有 x_padding，CDN 也一定能检测出来你在跑代理流量，这些特征是消除不完的，只有等 CDN 动手后、我们知道 CDN 针对了哪项特征后再行动才合适，我们提前行动的话，CDN 为了保证封锁的覆盖范围只会转而针对你仍然存在的其它特征
It may be just for Iran
In response to the questions raised by APT-ZERO, and to prevent him from continuing to spread his flawed logic elsewhere, I will briefly explain:
- VLESS was originally designed to be used with secure transport layers such as TLS and REALITY. Or TLS and REALITY are the encryption of VLESS. Is it reasonable to say that you can be detected by the GFW if you remove them? Moreover, the fully randomized encryption that comes with SS and VMess, etc., which you proposed, has long been blocked by the GFW
- Browser forwarding only supports setting Sec-WebSocket-Protocol, ~~or setting the path~~
- Even if XHTTP does not have x_padding, the CDN will definitely detect that you are running proxy traffic. These characteristics cannot be completely eliminated. It is only appropriate to wait until the CDN takes action and we know which characteristics the CDN is targeting before taking action ourselves. If we take action in advance, the CDN will only turn to targeting other characteristics that you still have in order to ensure the coverage of the blockade.
