Back to blog

Testing Cloudflare WAF from Mobile IPs: Fixing False Positives

2026-02-18
Testing Cloudflare WAF from Mobile IPs: Fixing False Positives

A practical guide for Cloudflare site owners: how to detect WAF/bot false positives, read Security Events, apply safe exceptions, and test rules on real Ukrainian mobile network traffic.

Why you should test WAF and bot protection from mobile networks

Cloudflare sits between your visitors and your origin and decides what to do with each request: allow, log, challenge (JS/CAPTCHA), or block. For a site owner, this is convenient because core protection is configured in the dashboard.

However, mobile traffic behaves differently. Mobile operators often use carrier‑grade NAT (CGNAT), so many subscribers can share the same public IP. Add frequent IP rotation, different ASNs, mixed IPv4/IPv6 paths, and mobile WebViews, and you get a common outcome: false positives—legitimate users being challenged or blocked.

Testing Cloudflare WAF from mobile IPs is therefore a QA task: validate that rules do not break real customers coming from Ukrainian mobile networks.

Cloudflare security layers you should distinguish

  • WAF Managed Rules: Cloudflare (and partners) provide managed rulesets with rule IDs and categories.
  • Custom rules: your own expressions and actions (Block, Challenge, Log, Skip, etc.).
  • Bot protection: Bot Fight Mode / Super Bot Fight Mode / Bot Management depending on your plan.
  • Rate limiting and DDoS: separate controls for request bursts and attacks.

A key point: a false positive can come from any layer. Turning off “WAF” may not help if the issue is caused by bot controls or rate limiting.

How false positives typically show up

  • Users report “it fails on mobile”, while Wi‑Fi works.
  • The issue is operator‑specific (for example, only lifecell).
  • It started after rules changed or managed rules updated.
  • Only certain paths break: /login, /checkout, /api/*, /graphql, etc.

With CGNAT, a single IP can represent many people, and reputation can be influenced by other subscribers. The goal is not to “blame the operator”, but to identify the exact rule and fix it safely.

Where to find the root cause in the dashboard

Start with Security / Security Center → Events (Security Events). For each event you usually see:

  • Action (Block/Challenge/Log/Allow),
  • the source (Managed rules, Custom rule, Bot, Rate limiting),
  • Rule ID and rule name,
  • Ray ID (request identifier),
  • client IP, ASN, country, user agent, host, URI, method.

If a user hits a Cloudflare error page, ask for the Ray ID. It is the fastest way to locate the exact request in logs.

Why mobile networks trigger more false positives

  • CGNAT: higher request density behind one IP.
  • IP changes: during sessions or between calls.
  • Non‑standard clients: in‑app browsers, old devices, unusual headers.
  • IPv6/IPv4 differences: different paths and reputation signals.
  • API patterns: frequent POSTs, parallel calls, missing referrers.

How mobile proxies help QA your protection

Mobile proxies from Ukrainian operators let you reproduce real customer conditions and capture evidence (timestamp, Ray ID, event details, rule ID). In practice, they help you:

  • test different Ukrainian mobile ASNs,
  • compare “home broadband vs mobile” for the same flow,
  • verify that an exception is narrow and does not create a security hole.

Use them for testing and validation, not as a way to “bypass” your own controls in production.

A repeatable workflow to find and fix a false positive

Step 1. Collect minimal artifacts

  • URL/endpoint and method (GET/POST).
  • Incident time (±10 minutes).
  • Ray ID if available.
  • Operator/network (lifecell/Vodafone/Kyivstar), app vs browser, VPN usage.

Step 2. Reproduce via the operator’s mobile proxy

Switch to the target operator’s mobile IP and replay the flow (login, checkout, API calls). If it reproduces, capture Ray ID or exact time.

Step 3. Locate the event in Security Events

Filter by host, URI, action (Block/Challenge), and Ray ID if you have it. The objective is to identify the layer responsible (managed/custom/bot/rate).

Step 4. Understand what exactly fired

  • Is it a managed WAF rule (rule ID in a managed ruleset)?
  • Is it your custom rule?
  • Is it bot protection behavior?
  • Is it rate limiting?

Step 5. Apply the smallest safe change

  • Start by switching the rule to Log (temporary safety valve).
  • Add a narrow exception for the specific URI/method/content type/ASN if needed.
  • Only then consider lowering sensitivity or disabling a rule globally.

How to build safe exceptions

For managed rules, the safer approach is an Exception / Skip targeted to a specific endpoint rather than a broad allowlist. A good exception condition can include:

  • host (if you have multiple subdomains),
  • path (/api/* or a specific endpoint),
  • method (often only POST is affected),
  • content type (JSON vs form data),
  • ASN (when the issue is operator‑specific).

Avoid overly broad rules like “Allow UA country” or “Allow all mobile ASNs” without path constraints. Also avoid relying only on user agent.

Case study: lifecell customers blocked by a WAF rule

A common scenario for dashboards, logins, and APIs:

  • Support receives reports: “lifecell users cannot log in / checkout”.
  • Wi‑Fi works, other operators work.
  • The issue started after enabling stricter WAF or after a managed rules update.

Reproduction and validation

  • The team uses a lifecell mobile proxy.
  • They replay the login flow (POST /api/auth/login or /login).
  • They capture Ray ID and locate the event in Security Events.

Fix

  • Temporarily set the offending rule to Log for that endpoint.
  • Create a narrow Skip/Exception for POST /api/auth/login (keeping other protections active).
  • Add backend validation to maintain security at the origin.

Verification

  • Re‑test via lifecell proxy: no blocks.
  • Confirm in Security Events that events are logged rather than blocked.
  • Run negative tests to ensure you did not open an attack surface.

What else to monitor

  • origin logs (did the request reach your server),
  • application logs (auth/session issues can look like WAF problems),
  • traffic drops by URL/ASN after changes,
  • 4xx rates and conversion impact caused by challenges.

Prevention tips

  • test changes on multiple Ukrainian mobile networks before rollout,
  • increase strictness gradually (Log → Challenge → Block),
  • separate policies for /api, /admin, /checkout,
  • keep strong server‑side validation, especially for auth endpoints,
  • review blocks by mobile ASN on a schedule.

Checklist

  • Run critical user flows (home/search/login/forms/checkout/key APIs).
  • Repeat via 2–3 Ukrainian operators (different ASNs).
  • Capture Ray ID for any anomaly.
  • Identify the layer and rule in Security Events.
  • Fix minimally: Log → narrow exception → negative testing.
  • Validate metrics after deployment (blocks, 4xx, conversion).

Conclusion

Ukrainian mobile networks are a core part of real user traffic. If you use Cloudflare, testing WAF and bot rules from mobile IPs helps you find false positives early and tune protections precisely—without weakening security globally.