If you are an online store owner, marketer, or traffic specialist, and your conversion from mobile traffic has suddenly dropped — the problem may not lie in the creatives or the landing page. The issue is the CAPTCHA that appears for some mobile users simply because they accessed the site from an IP address of a mobile operator. Let's explore why this happens, how many real customers are lost, and how to check it yourself in 15 minutes.
Why Mobile Users See CAPTCHA More Often: The Reason is CGNAT
Most mobile operators — MTS, Beeline, MegaFon, Tele2, and their counterparts in other countries — use CGNAT (Carrier-Grade NAT) technology. This means that thousands, and sometimes tens of thousands, of real subscribers are simultaneously "behind" the same external IP address. For your site and for bot protection systems (Cloudflare, reCAPTCHA, custom WAF rules), it appears as if an abnormally high number of requests are coming from a single IP in a short period of time.
The anti-bot system cannot distinguish between "500 different people from the same area accessing the site via mobile internet" and "one bot making 500 requests per minute." Therefore, protection is triggered, and the entire range of IPs receives an increased level of suspicion — CAPTCHA, throttling, and sometimes even a complete block of access.
Additionally, mobile IP addresses are periodically reassigned among different subscribers (the operator assigns them dynamically), and the reputation of a specific address can be "tainted" by a previous user — for example, if a parser or spam bot recently operated from that IP. The next subscriber who inherits this IP will carry over the bad reputation and will receive CAPTCHA without even realizing why.
How Many Customers You Lose Due to CAPTCHA on Mobile
According to several UX and conversion studies, each additional check in the user's path (CAPTCHA, SMS confirmation, "please wait, checking browser") reduces the completion of the target action by 15–40%. On mobile devices, this effect is amplified: small screens, inconvenient text input with distorted images, unstable connections — and some users simply close the tab.
For an online store, this means a direct loss of revenue: a customer adds a product to the cart, proceeds to checkout, and the protection system considers their traffic suspicious precisely because they accessed it through a mobile operator with a shared pool of IPs. They are not a bot, a parser, or a fraudster — just an ordinary person who decided to pay for an order from their phone while on the subway or in a taxi.
This is particularly painful in segments with a high share of mobile traffic: food delivery, marketplaces, tickets, service bookings. If 60–70% of your orders come from mobile devices, and part of this traffic is "cut off" by CAPTCHA at entry or during payment — you are losing money unnoticed, because in analytics it simply appears as "abandonment on the payment page," without a note that "CAPTCHA is to blame."
What Signals Cause Anti-Bot Systems to Show CAPTCHA
To understand why your site shows CAPTCHA to mobile customers, it is useful to know what signals modern protection systems respond to:
| Signal | How It Affects Mobile Users |
|---|---|
| Request Frequency from One IP | CGNAT combines hundreds of subscribers — the threshold is exceeded without bots |
| IP Reputation (Blacklists) | The address was previously used by a spammer or parser, and the reputation carries over to the new subscriber |
| Geolocation vs Device Time Zone | During roaming or base station changes, discrepancies trigger checks |
| Lack of Cookies/Session History | A new user without visit history automatically appears more suspicious |
| Sudden IP Change During Session | Switching between the operator's base stations changes the external IP on the fly |
An important point: these signals equally affect both regular customers and those testing ads or managing multiple business accounts. Therefore, understanding the logic of anti-bot protection is useful not only for website owners but also for arbitrageurs who set up campaigns in Facebook Ads and TikTok Ads and encounter similar checks on the advertising platforms' side.
How to Check Your Site Through the Eyes of a Mobile Customer
The most reliable way to find out if your real customers see CAPTCHA is not to guess based on analytics but to replicate their experience. To do this, you need to access the site from an IP address similar to the one that real mobile users are using. Here’s a step-by-step plan:
- Open the site from a regular Wi-Fi connection and note whether CAPTCHA appears during checkout, authorization, or when entering the site.
- Connect a mobile proxy with an IP from your target region's operator — for example, from the MTS or MegaFon range if your main audience is from Russia.
- Repeat the same user journey: click through from an ad, add a product to the cart, proceed to checkout, and make a payment.
- Compare the results: if CAPTCHA appears only through the mobile proxy and not through regular Wi-Fi or data center IP — the problem lies specifically in the CGNAT ranges of the operators.
- Test different operators and different regions — sometimes CAPTCHA triggers only for the IP of a specific operator that has a particularly "dirty" pool of addresses.
For such tests, mobile proxies are best suited — they use real IP addresses from mobile operators, meaning you will see the site exactly as a real customer would from a phone on a mobile network, rather than through home Wi-Fi or a data center server IP.
Testing Tools: Proxies and Anti-Detect Browsers
To ensure the test is accurate and repeatable, it is convenient to use a combination of an anti-detect browser and a proxy. Anti-detect browsers — Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser — allow you to create separate isolated browser profiles with different device parameters, time zones, and IP addresses. This is convenient if you want to test the site simultaneously with several "virtual customers" from different regions and operators without the need to constantly clear cookies and change settings.
The algorithm is simple: create a new profile in Dolphin Anty or AdsPower → in the profile settings, specify the type of proxy (SOCKS5 or HTTP) → insert the login, password, host, and port of the mobile proxy → select the desired region and operator → open the profile and navigate to your site, replicating the path of a real customer. This way, in 15–20 minutes, you can check 5–10 combinations of "region + operator" and see exactly where CAPTCHA appears.
For comparison, it is also worth testing the site through residential proxies — these are IPs of regular home users, which in some cases are also behind NAT, but with less aggressive blocking patterns than those of mobile operators. The difference in CAPTCHA behavior between mobile and residential IPs helps to better understand which specific anti-bot logic is triggered on your site.
| Proxy Type | What It Mimics | When to Use for Testing |
|---|---|---|
| Mobile Proxies | IP addresses of mobile operators, CGNAT | Checking the experience of customers using a phone on a mobile network |
| Residential Proxies | IP addresses of home providers | Checking the experience of users from home Wi-Fi |
| Data Center Proxies | Server IPs | Control group — usually CAPTCHA rarely appears or appears for another reason |
CAPTCHA Diagnosis Checklist
Before drawing conclusions, go through a short checklist — it helps distinguish the real CGNAT problem from other causes of CAPTCHA appearance:
- CAPTCHA appears only with mobile proxies, but not with residential or data center ones — a sign of the CGNAT effect.
- CAPTCHA appears equally across all types of IPs — the problem is likely in behavioral triggers (click speed, lack of mouse movement on the desktop version, navigation patterns).
- CAPTCHA appears more frequently with one specific operator — check the reputation of their IP ranges in services like AbuseIPDB or in your WAF/CDN panel.
- CAPTCHA appears only during checkout, not on the homepage — likely due to the payment gateway or anti-fraud system settings, not the overall site protection.
- CAPTCHA disappears after a repeated request within 1–2 minutes — a classic sign of rate-limiting by IP, which is typical for CGNAT.
How to Reduce CAPTCHA for Legitimate Customers
If the test confirms that the problem lies in mobile CGNAT ranges, there are several practical steps to discuss with the developer or agency managing the site:
- Review rate-limit thresholds. If the request limit from one IP per minute is too strict, increase it for ranges belonging to known mobile operators.
- Use behavioral analysis instead of pure IP filtering. Modern protection services (Cloudflare Bot Management, custom anti-fraud systems) can analyze mouse movement, form filling speed, and tap patterns on the screen — this is more reliable than just request frequency from IP.
- Add a "soft" CAPTCHA instead of a hard one. Invisible reCAPTCHA or one-click verification reduces friction for real users while maintaining protection against automated bots.
- Set session and device exceptions. If a user has already passed the check once, do not show CAPTCHA again within the same session, even if the IP changed due to switching base stations.
- Regularly test through mobile and residential proxies after each update of anti-fraud rules — this allows you to track whether things have gotten worse after another "security adjustment."
These steps are especially important for e-commerce projects where mobile traffic accounts for a large portion of orders. Losing even 5–10% of customers at the payment stage due to unnecessary checks directly impacts revenue, and such losses rarely appear in standard web analytics reports as a separate reason for abandonment.
Conclusion
CAPTCHA on the site does not always indicate bot activity — often it is a side effect of mobile operators' CGNAT, causing thousands of real customers to share a single IP address and be perceived by anti-bot systems as suspicious traffic. To understand the scale of the problem on your site, you don't need to guess based on graphs in analytics — simply replicate the customer journey through a real mobile IP and compare the result with a regular connection.
If you want to test how your site appears to customers from mobile networks of different operators and regions, we recommend trying mobile proxies — they provide an accurate representation of what the real audience encounters and help quickly identify the cause of unnecessary blocks before it affects revenue.