If the conversion from mobile traffic has suddenly dropped, and the registration or payment form returns a 403 error for real clients, the culprit is likely not a hacker, but your own WAF. The firewall sees thousands of requests from a single mobile carrier IP address and interprets this as a DDoS or brute force attack. In reality, behind this IP are hundreds or thousands of ordinary people — this is CGNAT technology. We will explore how to detect and fix this without leaving a hole for real attacks.
What is CGNAT and why does it create a problem
CGNAT (Carrier-Grade NAT) is a technology that mobile carriers use due to the shortage of IPv4 addresses. Instead of assigning each subscriber a unique public IP, the carrier "hides" thousands of users behind one or several shared addresses. For a website, this looks like traffic from hundreds of different people coming from a single IP at the same time — different devices, different browsers, different behaviors, but the same external address.
For a regular web server, this is not a problem — it simply processes requests. But for security systems that count requests per unit of time from a single IP, this appears as an anomaly. Imagine: in one minute, 200 requests come to the login page from one address. For WAF, this is a classic pattern of brute force or scraping. In reality, these could be 150 real clients of one mobile operator in your region who simply opened the site at the same time after a promotional email or social media post.
The problem is particularly acute in countries with high mobile internet density — operators aggregate a huge number of subscribers behind a minimal number of external IPs. That’s why testing the website’s behavior should be done not from a regular data center IP, but specifically from mobile proxies that actually pass through the operator's CGNAT infrastructure — only this way can you reproduce the same picture that WAF sees for live users.
Why WAF sees a threat in CGNAT
Most WAF solutions — Cloudflare, AWS WAF, Imperva, built-in Nginx/ModSecurity modules — use rate-limiting by IP address as a basic mechanism for protection against bots and DDoS. The logic is simple: if more than N requests come from one IP in T seconds — block or show a captcha. This rule works well for classic attacks from a single device, but completely breaks down with CGNAT traffic.
There are several typical scenarios where this backfires:
- Rate-limiting by IP. A limit of "100 requests per minute from one IP" is normal for data center traffic but catastrophic for a mobile region with a million subscribers behind one address.
- Behavioral scoring. If the system accumulates "reputation" for an IP based on request history, then one "bad" user behind CGNAT can ruin the reputation of that address for thousands of subsequent honest clients.
- Geographical heuristics. WAF sometimes marks an IP as suspicious if it sees sharp spikes in activity that are atypical for an "ordinary" user — and the behavior of a CGNAT address is precisely that: peak loads during audience activity hours.
- Block by operator ASN. Some WAF rules ban entire ranges of mobile operators' ASNs if attacks have previously originated from those ranges — all clients of the operator in the country get caught in the crossfire.
The bottom line: the stricter the WAF is configured "out of the box," the higher the chance that it is banning not bots, but your real mobile audience — especially if the business is focused on countries with developed mobile internet and a high share of CGNAT traffic.
What it means for business: lost clients and revenue
The problem of CGNAT blocks is rarely visible in standard analytics. Google Analytics and Yandex.Metrica simply do not record those who received a 403 error at the WAF level — such visits often do not even reach the counter. As a result, the marketer sees a drop in conversion but does not understand the reason and starts optimizing creatives and landing pages, while the problem lies in the infrastructure.
Real consequences for different business segments:
- E-commerce. A buyer from mobile internet cannot complete the order — the payment form returns an error, the cart is lost. Direct revenue losses, especially noticeable after launching ads on TikTok Ads or Facebook Ads, where the main traffic is mobile.
- SaaS and registrations. A user tries to register or log into their account, encounters a captcha at every step or gets blocked — they leave for a competitor.
- Content and advertising. Advertising traffic from mobile devices massively "drops off" on the landing page, the advertising budget is spent, but there are no conversions — algorithms of advertising platforms interpret this as low audience quality and increase the cost per click.
- Customer support. The number of inquiries like "your site won't open," "I can't register" increases — but support does not see the problem because they access from a desktop via office Wi-Fi without CGNAT.
The most unpleasant part is that such blocks are difficult to diagnose post-factum because the WAF log shows one "suspicious" IP with a huge number of requests, and the administrator sees this as confirmation of the correctness of the block rather than a false positive.
6 checks with mobile IPs to find the problem
To understand if your WAF is banning honest mobile clients, you need to reproduce real CGNAT conditions — that is, test the site from actual mobile IPs of different operators and regions. Here is a practical checklist of 6 checks.
Check 1: Mass access from one mobile IP
Set up several parallel sessions through the same mobile IP (this is natural for proxies with the operator's CGNAT) and perform 50-100 normal actions — opening pages, adding to the cart, navigating between sections. If a captcha or 403 starts appearing after a certain threshold — this is the first signal of a problem.
Check 2: Change User-Agent from one IP
One CGNAT address serves different devices — iPhone, Android, different browsers. Run requests with different User-Agent strings through one IP and check if the WAF rule "suspicious variability of devices from one address" is triggered.
Check 3: Test on critical forms
Go through the full customer journey — registration, authorization, order placement, payment — specifically through the mobile IP of the operator. Often, WAF is more aggressively configured on forms with data input (login, payment), where the risk of brute force is higher, and this is the first place where real clients are lost.
Check 4: Testing with different operators and regions
CGNAT behavior differs among different operators and in different countries — somewhere 50 subscribers are hidden behind one IP, while somewhere else it could be 5000. Test the site with mobile IPs from several operators in key business geos to understand if there are regional specifics of blocking.
Check 5: Analyze server response by codes and headers
Record not just the fact of blocking, but the exact HTTP code and response headers (for example, cf-mitigated: challenge from Cloudflare). This will help understand which specific protection mechanism was triggered — rate-limit, bot detection, or geographical rule.
Check 6: Long-term monitoring of IP reputation
Repeat the test from the same mobile IP over several days. If access deteriorates over time without visible reasons on your part — it means the cumulative scoring system is "ruining" the reputation of the address due to the activity of other subscribers behind the same CGNAT, and this is a systemic, not a one-time problem.
It is important to understand:
For such tests, you need real mobile IPs, not data center or regular residential addresses — only traffic that has passed through the operator's infrastructure accurately reproduces the CGNAT pattern that your WAF sees on real users.
How to configure WAF to avoid banning honest clients
After diagnosing, you need to adjust the protection rules so as not to lose the level of security while stopping the banning of real mobile users. Here are the main approaches.
| Problem | Solution in WAF |
|---|---|
| Strict rate-limit by IP | Increase the limit for known mobile operator ASNs or switch to session/cookie-based limits instead of pure IP |
| Cumulative scoring of IP reputation | Reduce the "memory" time of reputation for CGNAT ranges, add a whitelist for known operator ASNs |
| Block by geo/ASN entirely | Replace full blocking with a soft challenge (JS check) instead of 403 |
| Strict captcha on login forms | Enable captcha adaptively — only when there are real signs of brute force (multiple failed attempts from one account), not just based on CGNAT-IP |
A good practice is to maintain your own list of known mobile operator ranges for your key geos and apply separate, more lenient rules compared to regular internet traffic. This requires time for setup but drastically reduces the number of false blocks.
Tools for testing with mobile proxies
For regular audits of website protection, it is convenient to use a combination of anti-detect browsers and mobile proxies. Anti-detect browsers (Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) allow you to create isolated profiles with different device fingerprints, while mobile proxies provide real CGNAT traffic from operators.
A step-by-step approach to testing:
- Create several profiles in the anti-detect browser with different device parameters (different User-Agent, screen resolution, timezone).
- Connect each profile to mobile proxies of the required region and operator — this will provide real CGNAT behavior.
- Go through key user scenarios: registration, login, adding to cart, payment.
- Record all instances of captchas, 403s, and other blocks, and correlate them with WAF settings.
- Repeat the test using residential proxies for comparison — this will help determine if the problem is specific to mobile traffic.
For parallel testing in different geos, residential proxies are also useful — they help assess how similarly aggressive the WAF is for regular home traffic and mobile CGNAT. If you plan load tests from server infrastructure without operator binding, you can connect data center proxies for control checks without CGNAT effects — they will provide a clean baseline without distortions typical of mobile networks.
This comprehensive approach — mobile, residential, and data center IPs in one test — provides a complete picture: you can clearly see where exactly the protection is triggered and for which type of traffic, rather than guessing based on indirect signs in the logs.
Frequently Asked Questions
Can CGNAT ranges be completely excluded from WAF rules?
It is not recommended — this will reduce protection against real attacks that can also come through mobile networks. It is better to soften the thresholds and switch to a soft challenge instead of a hard block.
How often should such checks be conducted?
At least once a month and definitely after any changes to WAF rules or launching a new advertising campaign targeting a mobile audience.
Does this affect SEO?
Yes — if search bots or real users from mobile devices receive 403 errors, it increases the bounce rate and can negatively impact behavioral metrics for ranking.
Conclusion
CGNAT is not a threat, but a feature of mobile internet that almost any business with a mobile audience faces. The problem is not with the technology itself, but with the fact that standard WAF settings do not initially account for its specifics and penalize honest users for behavior typical of regular mobile networks. The six checks from this article will help quickly diagnose whether you are losing clients due to false blocks, and precise adjustment of WAF rules can restore conversion without compromising security.
If you plan to regularly test the behavior of your site and advertising funnels as real mobile clients see it, we recommend using mobile proxies — they provide real CGNAT traffic from operators and allow you to identify false blocks before your clients do.