New Cloudflare Limits and Changes

Introduction

Cloudflare has recently implemented changes that have affected a large portion of users. These changes began with throttling Workers, and soon extended to simple proxies behind the CDN such as WebSocket and gRPC. For MahsaServer, the result was an unprecedented jump in traffic volume, heavy pressure on non-Worker configurations, and a rise in Abuse reports against domains.

How it started: Worker limits

Cloudflare Workers are a lightweight edge layer that many use to build and automatically distribute V2Ray/Xray configurations in admin panels. To bypass the free daily Worker quota, it was common to use a custom domain instead of the default workers.dev so the cap would fill more slowly. Cloudflare has now curtailed this path. With either the default domain or a custom domain, Workers quickly hit daily caps and momentary rate limits and effectively go offline. The result is clear: automated build and distribution of proxy configs is disrupted and traffic is forced onto non-Worker paths.

Traffic surge and strain on MahsaServer infrastructure

On a typical day, total data exchanged was about 350 to 400 TB. One day after the new limits took effect, this figure exceeded 750 TB, nearly a twofold jump with direct consequences:

• Non-Worker configurations pushed to the edge of capacity
• Higher latency and noticeable degradation in connection quality
• Complete outages for some users during certain periods

Successful connections chart

The figure below shows the number of successful daily connections to MahsaServer over the past year.

Each successful connection transfers on average 100 to 200 MB. When daily connections reached about 5 million, total data approached roughly 750 TB.

These metrics explain why traffic doubled after Cloudflare’s limits. Given the filtering pressure on the internet in Iran, they also show that MahsaServer has remained one of the primary stable access routes despite the constraints.

Limits broadened to CDN proxies

It did not stop with the Workers. As load shifted to non-Worker paths, Abuse reports started to arrive:

• Proxies using WebSocket or gRPC became more prone to blocking.
• Abuse emails are extremely brief and vague; they simply say a domain was reported with no technical details.

• Even such minimal notice can be enough to degrade or fully block user connectivity.

New limit on WebSockets

Users report that Cloudflare has recently introduced a fresh limit for WebSockets. The Cloudflare dashboard now shows the following message:

Concurrent connection guidelines for your plan: low

This means concurrent WebSocket connections are tightly constrained. Key points:

• This rule appears to be newly added and was not present before.
• No official explanation or supporting documentation has been published.
• Only this one line appears in the dashboard, so users must infer the details by trial and error.

This indicates Cloudflare is tightening not only on Workers but also on real-time protocols such as WebSocket.

Possible reasons for these policies

Several scenarios could explain these limits:

• Financial pressure and reporting cycles: reducing free usage and nudging users to paid plans can improve reported profitability.
• Pressure on specific data centers, especially in Germany: due to Iran’s routing, a large share of traffic transits German data centers. Around the anniversary of Mahsa Amini, with intensified filtering in Iran, a surge of traffic likely concentrated on Cloudflare and the same German facilities, prompting stricter controls.
• More Abuse reports: higher volumes of abuse complaints can trigger faster throttling of high-traffic or suspicious domains.
• Segregating free from paid resources: like many large providers, Cloudflare may be revising its policy to keep free resources for light workloads only.
• Legal, security, and sanctions compliance: as a US company, Cloudflare must follow US laws, including sanctions. Abnormal increases in traffic from countries like Iran can lead to stricter enforcement of heavy services.
• Changes in how limits are computed: counting methods may have changed, so there is no longer a difference between custom domains and the default domain.

Impacts

The consequences are not only technical; they also have social and human dimensions:

• Additional pressure on users in Iran who already face severe filtering.
• Fewer stable paths to the open internet and greater difficulty maintaining secure connectivity.
• Greater reliance on fragile configurations and higher risk of widespread outages.

Conclusion

Cloudflare’s recent changes mark a turning point for users of Workers and simple proxies. Custom domains and ordinary CDN paths can no longer be treated as durable solutions. Pressure on data centers, more Abuse reports, the new WebSocket constraint, and legal or financial drivers together indicate Cloudflare is actively restricting free usage and steering users to paid plans. For users in Iran, the impact goes beyond technical policy and intensifies the existing pressure created by filtering and other limitations.