I'm also seeing the rate limit issue and error patching, including in the last update just an hour ago.
Cloudflare Gateway Free Plan
- Thread starter rashmi
- Start date
I haven't found time to contact support yet, but considering you are also getting errors, I think the problem is Cloudflare reduced limits. There isn't any other explanation considering list once grew over 300.000 domains and we never got rate limited, just domain limited.
I'm still on ControlD and it seems they kind of somehow sped it up at least on my location. Also, my workplace changed ISP so now there's normal routing towards their server. I may consider staying on it.
I also received rate limit warnings today. Only increasing the API delay might be enough. I'll try to experiment with different API delays to find an acceptable value.
API delay set to 1 with 25 concurrent requests still hits rate limit.
I just came here to write that I found the solution.
Both max concurrent request and api delay have to be lowered.
Setting Max concurrent to 5 and API delay to 0.5 a.k.a. 500 ms works fine.
The updating process still completes under 1 minute.
I will try this. Though I'm tired of checking GitHub often just to see if everything works correctly.
It's great that you check because I usually don't and without you saying it, I wouldn't realize what's going on.I will try this. Though I'm tired of checking GitHub often just to see if everything works correctly.
The solution appears to have fixed the rate-limiting and error-patching issues.
@Bot, Most modern Android apps use hardcoded DoHs/DoTs, proprietary DoHs/DoTs, and hardcoded IPs to bypass Android's "Private DNS" or systemwide DNS. How effectively can Cloudflare WARP business DNS-only and WARP modes redirect traffic from these apps and embedded browsers? I guess the Cloudflare WARP client creates/enables a local VPN for both DNS-only and WARP modes. Can you use Cloudflare Zero Trust's "Network" or "HTTP" policy to redirect (or can it only block) traffic from these apps and embedded browsers?
Cloudflare WARP can help, but it is not a universal way to “force” every Android app back through your preferred DNS.
What WARP does on Android
Yes, the WARP client uses Android’s VPN framework.
- DNS-only / Gateway with WARP client generally means DNS queries are sent to Cloudflare’s resolver/Gateway through the WARP tunnel, while the rest of the traffic may not get the same full-tunnel treatment as WARP mode.
- WARP mode tunnels device traffic through Cloudflare’s network using the local VPN interface.
That local VPN gives Cloudflare visibility and control over traffic that actually traverses the tunnel. It does not automatically mean every app can be transparently rewritten to your chosen DNS destination in all cases.
About apps using hardcoded DoH/DoT or hardcoded IPs
In general, apps can bypass Android Private DNS by doing their own DNS resolution inside the app, for example:
- Hardcoded DoH endpoints
- Hardcoded DoT endpoints
- Direct connections to hardcoded IPs
- Embedded browsers or SDKs using their own network stack
Because of that:
- If an app sends its traffic through the WARP VPN, Cloudflare can usually still see and apply policy to the connection attempt at the network level.
- But that does not necessarily mean Cloudflare can “redirect” that app’s DNS to another resolver in the way a local firewall or a more invasive MDM-controlled setup might.
- If the app uses encrypted DNS to a specific provider, the practical control is often allow or block, not seamless redirection.
- If the app connects directly to hardcoded IPs, DNS policy is largely irrelevant because no normal DNS lookup is needed for that connection.
So the short answer is: WARP is often effective for capturing traffic into the tunnel, but not reliably for rewriting every app’s hardcoded DNS behavior into your preferred DNS flow.
Can Zero Trust policies redirect traffic?
Based on Cloudflare Zero Trust’s general design, Network and HTTP policies are mainly for allowing, blocking, isolating, inspecting, or filtering traffic depending on plan/features and traffic type.
They are not primarily a generic traffic-redirection engine for Android apps using custom DoH/DoT stacks.
In practical terms:
- Network policies can usually control whether traffic to certain destinations, ports, protocols, or resolved domains is allowed.
- HTTP policies can control web access for traffic that is recognized and handled at that layer.
- For hardcoded encrypted DNS endpoints, the most realistic action is often to block those endpoints rather than redirect them to Cloudflare Gateway.
- For hardcoded IP connections, you may be able to block or allow those IPs, but not meaningfully “DNS-redirect” them.
Embedded browsers
Embedded browsers are mixed.
- If they rely on the app’s own networking and go through the VPN, WARP may still subject them to Zero Trust policy.
- If they use hardcoded resolvers/endpoints, the same limitation applies: Cloudflare can often filter or block, but not necessarily transparently reroute the DNS method they chose.
What this means in practice
If your goal is to stop apps from bypassing system DNS, Cloudflare WARP helps most when:
- The app traffic is forced through the Android VPN
- You are comfortable with blocking known third-party DoH/DoT endpoints
- You understand that some apps using direct IPs or tightly integrated encrypted transports may only be controllable by destination blocking, not DNS redirection
If your goal is true enforcement against hardcoded resolvers, the usual approach is:
- Route all traffic through the VPN
- Block known external DNS destinations such as port 53/853 and known DoH endpoints where possible
- Use destination/IP/domain policy rather than expecting transparent DNS rewriting
Important limitation
I cannot safely say that Cloudflare Zero Trust on Android can universally redirect hardcoded DoH/DoT traffic from all apps and embedded browsers, because that depends on Cloudflare’s current Android client behavior, plan features, and how each app implements networking. That part needs confirmation from current Cloudflare documentation or support.
Bottom line
Cloudflare WARP on Android is useful for funneling traffic through a VPN-based control point, and Zero Trust policies can often block or filter apps that use custom DNS paths. But for apps with hardcoded DoH/DoT or hardcoded IPs, you should assume the reliable control is mostly policy enforcement and blocking, not universal transparent redirection.
Sources
Short answer
Those actions are generally policy actions inside Cloudflare Zero Trust, but they do different things at different layers.
- Network Override is a network-layer routing/control action used in Gateway network policies.
- Redirect in HTTP policies is an HTTP-layer action that sends the browser/client to another URL.
They are not the same as “force all Android apps with hardcoded DoH/DoT back to my preferred DNS.”
Network Override
From Cloudflare’s naming, Network Override is used to override the normal handling of matching network traffic. In practice, that usually means applying a different network behavior to traffic that matches the rule rather than simply allowing or blocking it.
What it does not automatically mean:
- It does not necessarily mean arbitrary DNS redirection for any app
- It does not necessarily mean you can transparently rewrite every hardcoded DoH/DoT endpoint used by Android apps
- It does not necessarily help with apps that connect directly to hardcoded IPs without DNS
So for your original use case, I would be careful not to assume Network Override equals “capture and rewrite all bypass DNS traffic.”
Redirect in HTTP policies
Redirect is more straightforward.
It usually means that when an HTTP/HTTPS request matches a policy, Cloudflare returns a redirect response so the client is sent to another page or destination.
Typical use cases are things like:
- Sending users to a warning page
- Moving traffic from one web destination to another
- Steering browser-based web requests
Important limitation:
- This is HTTP-layer behavior, not a general-purpose redirect for arbitrary app traffic
- It will not reliably “redirect” non-HTTP protocols
- It is not the same as transparently rerouting app-level DoH/DoT or raw IP traffic
So if an Android app is using:
- DoH inside its own network stack
- DoT on port 853
- Direct hardcoded IP connections
then HTTP Redirect is usually not the tool you would rely on to fix that.
For your Android bypass scenario
The practical model is still usually this:
- Use WARP to bring traffic into Cloudflare’s control plane
- Use policies to allow, block, or filter
- Treat hardcoded DoH/DoT bypass attempts as something to block if possible
- Do not assume Cloudflare can universally and transparently redirect those apps to your preferred DNS
Important limitation
I cannot safely give a precise feature-by-feature definition of Network Override in your tenant without checking Cloudflare’s current documentation for that exact action, because Cloudflare sometimes changes policy terminology and feature scope.
So the safe conclusion is:
- Network Override = a network-policy override action, but not something I would assume provides universal DNS redirection for Android apps
- Redirect = an HTTP redirect action for web traffic, not a general redirect for all app traffic
Best takeaway
For bypassing apps and embedded browsers, think of these actions mainly as traffic-handling controls, not as guaranteed tools for transparently rewriting hardcoded DNS behavior.
That makes sense.
If Network Override and Redirect are not available when matching an application like Snapchat or a category like Encrypted DNS, that strongly suggests Cloudflare only exposes those actions for specific policy contexts, not for general app/category-based enforcement.
What that implies
For your use case, Cloudflare is likely treating:
- Applications as objects you can mainly allow, block, or otherwise filter
- Encrypted DNS as a traffic class you can mainly control or deny, not transparently reroute
That fits the earlier conclusion:
- For hardcoded DoH/DoT, the realistic action is usually block
- For embedded browsers and app traffic, you may be able to filter based on app, destination, category, or protocol
- But Cloudflare does not appear to offer universal redirect/override behavior for those matches
Practical takeaway
If the goal is to stop Android apps from bypassing your preferred DNS, the workable approach is probably:
- Use WARP so traffic goes through Cloudflare’s VPN path
- Block Encrypted DNS categories or known DoH/DoT destinations where possible
- Block or restrict specific apps if they insist on their own resolver path
- Use destination/IP/domain controls for apps with hardcoded endpoints
Important limitation
That still does not guarantee full control over every app using:
- Hardcoded IPs
- Custom encrypted transports
- Certificate-pinned in-app networking
- QUIC or other protocols that reduce visibility depending on policy scope and plan
Bottom line
What you are seeing in the policy UI is a good indicator that Cloudflare’s model here is mainly detect + allow/block/filter, not detect + transparently redirect for app/category matches like Snapchat or Encrypted DNS.
No, not in a universal sense.
Short answer
Rethink DNS can be very useful for blocking or filtering many DNS bypass methods on Android, but I would not describe it as a tool that can reliably forward all hardcoded DoH, DoT, proprietary DoH/DoT, or hardcoded IP traffic to your preferred resolver.
What it can generally do
Because Rethink DNS uses Android’s local VPN approach, it can usually:
- Capture a large amount of app traffic on the device
- Apply DNS and firewall rules
- Block known DNS endpoints, including many public DoH/DoT providers
- Block direct IP connections if you define firewall rules for them
That makes it useful for enforcement by blocking.
What it usually cannot do reliably
For the cases you mentioned:
- Hardcoded DoH: often can be blocked if the destination is known, but not always transparently rewritten to another DoH provider
- Hardcoded DoT: often can be blocked, especially if the endpoint or port is identifiable, but not universally “forwarded”
- Proprietary DoH/DoT: even harder to redirect because the app may use custom endpoints, custom headers, pinning, or nonstandard behavior
- Hardcoded IPs: DNS forwarding is irrelevant here because the app is not resolving a domain through normal DNS in the first place
So if an app talks directly to a hardcoded IP, there is nothing meaningful to “forward” at the DNS layer. The practical choices are usually allow or block.
Why forwarding is difficult
Transparent redirection only works cleanly when the protocol and traffic path allow interception and rewriting without breaking the app.
That becomes difficult or impossible when an app uses:
- Its own encrypted DNS implementation
- Certificate pinning
- Custom HTTP stacks
- Direct IP connections
- Non-DNS bootstrap methods
In those situations, replacing the app’s chosen resolver with your preferred one can break connectivity unless the app is specifically designed to tolerate that.
Most realistic use of Rethink DNS
In practice, Rethink DNS is best thought of as:
- A local VPN-based firewall and DNS controller
- Good for blocking known bypass resolvers
- Good for blocking specific destinations or apps
- Not a guaranteed universal DNS rewrite/forwarding engine
Best takeaway
If your goal is to control apps that bypass system DNS, Rethink DNS can help a lot by blocking competing DNS services and unwanted destinations. But for hardcoded DoH/DoT, proprietary encrypted DNS, and especially hardcoded IPs, you should assume the reliable control is mainly block/filter, not forward everything to a preferred resolver.
Yes, that risk is real.
Short answer
If you blanket-block popular DNS services in Cloudflare Zero Trust, it can affect not only dedicated DNS apps but also normal apps, SDKs, and embedded browsers that silently rely on those same providers.
Why this happens
Many modern Android apps do not use only the system resolver. They may use:
- Public DoH providers such as Cloudflare, Google, Quad9, NextDNS, AdGuard, etc.
- Vendor-owned resolvers
- CDN-linked or app-specific endpoints
- Embedded browser/network libraries with their own DNS behavior
So if you block large DNS providers broadly, you may break:
- App startup or sign-in flows
- Push notification registration
- Telemetry or API calls
- In-app browsers
- Content loading inside social, shopping, banking, or messaging apps
Important distinction
Blocking DNS services does not just impact “DNS tools.” It can impact any app that uses those services behind the scenes.
What usually breaks first
In general, the first visible problems are often:
- Apps hanging on launch
- Partial content not loading
- Login pages failing in embedded webviews
- Random connection failures that are hard to diagnose
That is one reason blanket blocking can become messy on Android.
Hardcoded IPs are different
Even with aggressive DNS blocking, apps using hardcoded IPs may still connect unless you also block the relevant IP destinations. So broad DNS blocking can cause collateral damage while still not fully solving bypass behavior.
Practical approach
A safer strategy is usually:
- Block only the specific DoH/DoT providers or endpoints you do not want
- Test app behavior after each change
- Prefer targeted app, domain, IP, or category rules over broad blocking where possible
- Expect some trial and error with apps that use embedded browsers or proprietary networking
Bottom line
Yes, blanket blocking of major DNS services in Cloudflare Zero Trust can disrupt many ordinary apps, because those services are often used indirectly by modern apps and SDKs. It is effective as a control method, but it can create significant compatibility problems if applied too broadly.
You may also like...
-
Evaluation of Cloudflare Zero Trust Free plan after using it for 3,5 months- Started by LinuxFan58
- Replies: 7
-
Need guidance and advice from those knowledgeable about ad blocking
- Started by rashmi
- Replies: 55
-
Google Cloud and Cloudflare hit by widespread service outages- Started by Gandalf_The_Grey
- Replies: 22
-
FCloudflare tracked 230 billion daily threats and here is what it found
- Started by ForgottenSeer 116559
- Replies: 3
