Twenty parts deep. If you've been following this series from the beginning, you've built a working mental model of how Cloudflare operates at every layer: DNS, SSL, caching, Zero Trust, tunnels, and the policy engine that ties all of it together. Part 20 covered Cloudflare's analytics and logging tools, the part of the platform that tells you what's actually happening in your traffic rather than what you assume is happening. That was about visibility.
This part is about what happens when visibility reveals a problem you created yourself.
Cloudflare is genuinely easy to get started with. That's not a complaint. But "easy to start" and "hard to misconfigure" are not the same thing, and the platform's approachable interface masks a significant amount of complexity underneath. Settings that look harmless have edge cases that will ruin your day. Defaults that work fine for a simple static site will quietly break a dynamic application. And the worst part is that most of these mistakes don't announce themselves immediately. They show up under load, after a DNS change propagates, or the moment a real attack tests your defenses and finds the gap you didn't know was there.
This article covers six categories of mistakes that appear constantly across beginner and intermediate Cloudflare users: SSL mode misconfiguration, broken email DNS, aggressive caching that corrupts dynamic apps, exposed admin panels, and tunnel setup errors. None of these require deep expertise to fall into. All of them are fixable once you know what to look for.
Why Cloudflare Mistakes Are So Easy to Make
The Power-and-Complexity Trade-Off
Cloudflare's dashboard is genuinely well-designed. Dropdowns are labeled. Toggles have descriptions. Most settings include a short explanation of what they do. That polish is exactly what makes misconfiguration so common. When a control looks simple, users treat it as simple. They flip a toggle, move on, and don't think about the edge cases the tooltip didn't mention.
The platform handles DDoS mitigation, SSL termination, DNS resolution, identity-aware access control, reverse proxying, and caching simultaneously. Those are not simple systems. They interact with each other in ways that aren't always obvious from the dashboard, and a change in one area can produce unexpected behavior in another. Turning on a cache rule affects how authenticated sessions behave. Changing your SSL mode affects how your origin server receives requests.
How Defaults Can Mislead You
Cloudflare's defaults are tuned for a general case: a straightforward website, publicly accessible, with a single origin server. That covers a lot of deployments. It doesn't cover all of them, and when your setup diverges from that general case, the defaults stop being helpful and start being a liability.
The six mistake categories this article covers span SSL, DNS, caching, access control, and tunnel configuration. They're not obscure edge cases. They're the things that trip up users who read the documentation, set things up carefully, and still get something wrong because the interaction between two settings wasn't obvious until it broke.
Mistake #1: Using Flexible SSL When You Shouldn't
What Flexible SSL Actually Does
Cloudflare offers three SSL encryption modes: Flexible, Full, and Full (Strict). The names suggest a spectrum of security, which they are, but the gap between Flexible and the other two is larger than most users realize.
Flexible SSL encrypts the connection between your visitor's browser and Cloudflare's edge. That part works exactly as advertised. The problem is what happens next. Traffic between Cloudflare and your origin server travels over plain HTTP. Unencrypted. Your visitors see the padlock. Your server receives unencrypted data.
Full SSL encrypts both legs of the connection but doesn't validate the certificate on your origin server. A self-signed certificate satisfies it. Full (Strict) encrypts both legs and validates that the origin certificate is legitimate, either from a trusted CA or from Cloudflare's own Origin CA.
Why Flexible SSL Is a Security Risk
The false sense of security is the real danger. Sensitive data, including login credentials, form submissions, and session tokens, travels unencrypted between Cloudflare and your server. Anyone with access to that network path can read it.
There's also a practical failure mode that catches beginners off guard. If your origin server is configured to force HTTPS redirects, and Cloudflare is sending HTTP requests to it under Flexible mode, you get an infinite redirect loop. Cloudflare sends HTTP. The server redirects to HTTPS. Cloudflare follows, sends HTTP again. The browser eventually gives up and shows an error. This is one of the most common SSL-related support questions in the Cloudflare community forums.
Flexible SSL Is Not Secure for Most Use Cases
If your site handles any user data, including login forms, contact forms, or payment flows, Flexible SSL is not an acceptable configuration. Switch to Full (Strict) before you go live.
How to Switch to Full (Strict) SSL
In the Cloudflare dashboard, navigate to your domain, then go to SSL/TLS in the left sidebar. The current mode is displayed at the top of the Overview tab. Switching to Full (Strict) takes one click, but it requires that your origin server has a valid certificate installed.
If your origin doesn't have one, Cloudflare's Origin CA service solves this for free. Go to SSL/TLS > Origin Server and generate an Origin CA certificate. Install it on your web server. This certificate is trusted by Cloudflare's edge and satisfies Full (Strict) validation. It doesn't cost anything and takes about ten minutes to configure on most common server stacks.
Mistake #2: Breaking Email With Misconfigured MX Records
The Proxied vs. DNS-Only Distinction for Email
Cloudflare's orange cloud proxy is one of its most valuable features for web traffic. For email, it's a problem. MX records must never be proxied through Cloudflare. Email delivery protocols don't route through Cloudflare's HTTP proxy, and if your MX records are set to proxied (orange cloud), mail servers trying to deliver to your domain will connect to Cloudflare's edge, fail to establish a proper mail connection, and bounce the message.
The correct setting for every MX record is DNS-only, indicated by the grey cloud in the Cloudflare DNS dashboard. This is also true for any A record or CNAME that an MX record points to. If your MX record points to mail.yourdomain.com, and that hostname is proxied, the real IP is hidden and mail delivery fails.
Common MX Record Errors and Their Symptoms
The most common errors break down into three categories. First, accidentally enabling the proxy on an MX record, which Cloudflare actually prevents directly but users sometimes work around by proxying the A record the MX points to. Second, omitting SPF, DKIM, and DMARC records entirely, which causes legitimate outbound email to land in spam or get rejected by strict receiving servers. Third, misconfiguring the SPF record syntax, such as using +all instead of ~all or -all, which either grants permission to every server on the internet to send as your domain or produces unpredictable results across different mail providers.
Symptoms of broken email DNS include bounced outbound messages with 550 or 554 error codes, inbound messages that never arrive, and outbound messages that consistently land in spam.
Test Before You Trust
After making any DNS changes that affect email, verify your configuration using MXToolbox (mxtoolbox.com) or run dig MX yourdomain.com from a terminal. Don't assume a record saved correctly. Check it.
How to Audit and Fix Your Email DNS Setup
In the Cloudflare DNS dashboard, filter your records by type. Every MX record should show a grey cloud. Every A record that an MX record references should also be grey. Your SPF record is a TXT record on the root domain and should look something like v=spf1 include:yourmailprovider.com ~all. DKIM is a TXT record on a subdomain provided by your mail service, typically formatted as selector._domainkey.yourdomain.com. DMARC is a TXT record at _dmarc.yourdomain.com and should at minimum read v=DMARC1; p=none; rua=mailto:[email protected] to start collecting reports before you enforce a stricter policy.
Email is not a system that tolerates quiet failures. A broken MX record means missed invoices, missed client messages, and missed opportunities. Fix it before it costs you something.
Mistake #3: Caching Dynamic Pages and Breaking Your App
How Cloudflare's Cache Works by Default
By default, Cloudflare caches static file types: images, CSS, JavaScript, fonts, and similar assets. It does not cache HTML responses by default. That's the safe baseline. The problem starts when users add cache rules to improve performance without fully accounting for which parts of their application are dynamic.
Cache Rules (the current system) and Page Rules (the legacy system) both allow you to tell Cloudflare to cache everything matching a given pattern. "Cache Everything" is a legitimate setting for fully static sites. For sites with any dynamic functionality, it requires careful bypass rules or it will serve cached versions of pages that should never be cached.
What Gets Cached That Shouldn't
The consequences range from annoying to catastrophic. A cached login page means users see a stale form. A cached checkout flow means orders don't process. A cached admin dashboard means configuration changes appear to have no effect. The most alarming scenario is a cached page that includes user-specific session data getting served to a different user. That's not just a bug. It's a data exposure incident.
This happens because Cloudflare sees the URL, not the session context. If two users hit /dashboard and the first response gets cached, the second user gets the first user's cached page. Cache-Control headers from your origin server are supposed to prevent this, but aggressive Cloudflare cache rules can override them.
Cache Rules and Page Rules to the Rescue
The fix is explicit bypass rules for every dynamic path in your application. In Cache Rules, create rules that match your dynamic paths and set the cache behavior to Bypass. The paths you should almost always bypass include /wp-admin/*, /wp-login.php, /account/*, /checkout/*, /cart/*, /api/*, and any path that serves personalized or session-dependent content.
In the Cache Rule editor, set the field to URI Path, use the starts with operator, and enter each path. Set the cache status to Bypass. Order matters in Cache Rules: more specific rules should come before broader ones. If you're using the legacy Page Rules system, the same logic applies. Create a rule matching your dynamic paths with the Cache Level set to Bypass. Add these rules before you enable any "Cache Everything" configuration, not after. Retrofitting bypass rules into an already-broken caching setup is harder than building it correctly from the start.
Mistake #4: Exposing Admin Panels to the Public Internet
Why Admin Panels Are High-Value Targets
Every WordPress site has /wp-admin. Every Laravel Nova installation has /nova. Every cPanel server has port 2083 or a management subdomain. Attackers know this. Automated scanners probe these paths constantly, around the clock, regardless of how small or low-traffic your site is.
A strong password helps. It doesn't stop credential stuffing attacks that cycle through millions of previously breached username and password combinations at machine speed. It doesn't stop brute force tools that methodically test common passwords faster than any rate limit you manually configure. Keeping admin panels publicly reachable is one of the leading causes of site compromise, and it's a problem that Cloudflare can solve without touching a single line of your application code.
Public Admin Panels Are a Liability
If your admin panel is reachable by anyone with your domain name and a keyboard, you're relying entirely on your password to stop an attack. That's not a security posture. That's a single point of failure.
Using Cloudflare Access to Lock Down Admin Routes
Cloudflare Access, part of the Zero Trust platform, lets you put an identity gate in front of any URL or subdomain. Before a request reaches your origin, Cloudflare checks whether the user has authenticated through your chosen identity provider. That provider can be Google, GitHub, Microsoft, Okta, or a one-time PIN sent to an email address. No code changes required on your application.
To set this up, go to Zero Trust > Access > Applications and create a new application. Set the application type to Self-hosted, enter the domain and path you want to protect (for example, yourdomain.com/wp-admin), and configure a policy that requires authentication from your chosen identity provider. Anyone who hits that path without a valid session gets an Access login page, not your admin panel.
"The best admin panel security is one where attackers can't even see the login form."
IP Allowlisting and WAF Rules as a Second Layer
For deployments where you always access the admin panel from known IP addresses, WAF custom rules offer a simpler but effective alternative. In Security > WAF > Custom Rules, create a rule that matches requests to your admin path and blocks all traffic except from your allowlisted IP ranges. The rule logic looks like: URI path contains /wp-admin AND IP source address is not in [your IP list], action: block.
Rate limiting rules add another layer. Configure a rule that limits login attempts to /wp-login.php to five requests per minute per IP. This doesn't stop all attacks, but it makes brute force attempts slow enough to be impractical. Combine Access, WAF rules, and rate limiting and you've built a defense that most automated attacks will abandon in favor of easier targets.
Mistake #5: Misconfiguring Cloudflare Tunnels
The Most Common Tunnel Configuration Errors
Cloudflare Tunnels are one of the most useful tools in the platform, and they have enough sharp edges to frustrate beginners who set them up without understanding how the pieces connect.
The first common error is pointing the tunnel ingress to the wrong local address or protocol. If your service runs on port 8080 but your tunnel ingress is configured for port 80, requests fail silently. If your local service uses HTTPS but your tunnel ingress uses http://localhost:8080, you may get certificate errors or connection resets. Get the protocol and port right in the ingress configuration. They need to match exactly what your local service expects to receive.
The second error is running `cloudfl
Mistake #6: Forgetting Backup Access and Getting Locked Out
How Lockouts Happen With Cloudflare
Lockouts don't announce themselves. You make a change, hit save, and then discover the change applies to you too.
The most common version: you create a Cloudflare Access policy that restricts your admin panel to specific email domains or identity providers, test it in one browser, and then realize your second browser session is blocked. The policy worked. It just worked on you. A close second is a WAF custom rule written too broadly, something like blocking all requests from countries outside your own, only to find your VPN was routing you through Amsterdam.
Then there's the account-level lockout. You lose access to the email address tied to your Cloudflare login. No backup owner on the account means no recovery path. Cloudflare support can help, but it's slow, and the process requires proving ownership in ways that take time you may not have during an outage.
The Worst-Case Scenario
A misconfigured firewall rule that blocks all traffic, including your own admin IP, combined with a Cloudflare Access policy that locks out your identity provider, is genuinely difficult to recover from without prior preparation. Both layers block you simultaneously, and there's no backdoor.
Protecting Yourself Before You Need It
Prevention here is straightforward. Do it before you need it.
Add a second Super Administrator to your Cloudflare account before making any major Access or WAF changes. Use a different email address, ideally one tied to a separate identity provider. Enable two-factor authentication on every account that has login access. Keep your registrar login separate and accessible at all times. If everything else fails, you can update your nameservers away from Cloudflare at the registrar level and restore access to your origin while you sort out the mess.
Document your tunnel token and store it somewhere secure outside of Cloudflare itself. Losing the token doesn't break the tunnel immediately, but recreating a tunnel means updating every service that references it.
Recovery Options When You Are Already Locked Out
If you're already locked out, start with Cloudflare's audit log. It records every configuration change with a timestamp and the account that made it. That tells you exactly which rule fired and when, which is the first step toward reversing it. If you still have account access but can't reach your site, temporarily pausing Cloudflare for the zone bypasses all proxy-level rules and lets your origin respond directly. If you've lost account access entirely, your registrar is your last resort. Pointing nameservers elsewhere buys you time to recover the account through Cloudflare support.
Bonus Mistakes Worth Watching: Smaller Errors With Big Impact
Orange-Clouding Records That Should Stay Grey
Not every DNS record belongs behind Cloudflare's proxy. SMTP records for email delivery, FTP records, and any service that doesn't speak HTTP or HTTPS will break silently if you orange-cloud them. The connection attempts fail, but nothing in Cloudflare's dashboard screams at you about it. Your email just stops working and you spend an afternoon wondering why.
The rule is simple: if it's not HTTP or HTTPS traffic, it should be a grey-cloud DNS-only record. MX records, mail-related A records (like mail.yourdomain.com), and FTP hosts all fall into this category. Cloudflare cannot proxy those protocols, and trying to do so doesn't produce a clean error. It produces a silent failure that looks like a hosting problem.
DNSSEC belongs in this section too. Moving to Cloudflare DNS and not enabling DNSSEC leaves your domain vulnerable to DNS spoofing attacks. It takes about ninety seconds to enable in the Cloudflare dashboard, and most registrars accept the DS record Cloudflare generates automatically.
Ignoring Analytics and Security Events
The Security Events tab exists for a reason. If you never look at it, you're running a security tool blind. Active attack patterns, bot floods, and rules firing on legitimate traffic all show up there. Ignoring it for weeks means you miss the moment a rule starts blocking real users.
The same applies to Health Checks and Notifications. Cloudflare can alert you when your origin goes down, when error rates spike, or when a tunnel drops. None of that happens automatically unless you configure it. Beginners set up the infrastructure and never configure the alerting layer, which means outages go undetected until a user complains.
Leaving Development Mode On
Development Mode disables caching for three hours. That's the intended behavior. The problem is beginners enable it to troubleshoot a caching issue, fix the issue, and then forget to turn it off. Three hours later, Development Mode expires automatically. Except sometimes they turn it back on again the next day for another test, and the pattern repeats.
Check your caching settings before you assume a performance problem is a hosting problem. Development Mode being active is one of the most common causes of unexpectedly slow Cloudflare-proxied sites, and it's invisible unless you know to look for it.
How to Audit Your Cloudflare Setup Right Now
A Section-by-Section Dashboard Review
A proper audit takes about twenty minutes if you know where to look. Work through each major section in sequence.
SSL/TLS: Confirm your mode is set to Full (Strict). Anything lower is a security compromise. Check that your origin certificate is valid and not within thirty days of expiration. If you're using a Cloudflare Origin Certificate, verify it's installed correctly on your server.
DNS: Review every proxied record and confirm it should be proxied. Look for MX records, mail subdomains, or FTP records wearing an orange cloud. Fix them immediately.
Caching: Check whether Development Mode is active. Review your Cache Rules for any patterns that are too broad. Confirm that dynamic paths like /api/, /checkout/, and /wp-admin/ are explicitly excluded.
Security: Open the Security Events tab and look at the last seven days. Are any rules firing on traffic that looks legitimate? Are there patterns you don't recognize?
Access and Tunnels: Open the Zero Trust dashboard. Review every Access policy and confirm the identity providers and email rules are current. Check tunnel configurations for any ingress rules pointing to services that no longer exist.
Tools to Validate DNS, SSL, and Cache Behavior
Don't rely only on Cloudflare's own interface. External validation catches things the dashboard won't surface.
SSL Labs (ssllabs.com/ssltest) gives you a full certificate chain analysis and grades your SSL configuration. An A+ rating confirms Full (Strict) mode is working correctly end-to-end. Anything below A is worth investigating.
MXToolbox validates your email DNS records. Run your domain through the MX lookup and the DMARC, SPF, and DKIM checks. Missing or malformed records are easy to spot and easy to fix once you see them.
Cloudflare's own DNS Checker confirms record propagation across global resolvers. After making DNS changes, use it to verify the new values are visible worldwide before assuming propagation is complete.
Your Cloudflare Mistake-Prevention Checklist
Run through this list before making any major changes, and run through it again after. Most of the mistakes covered in this part are invisible until they cause a problem. The checklist makes them visible first.
What's Coming in Part 22
Six mistakes. SSL mode confusion, email DNS misconfigurations, caching dynamic content, Access policy gaps, tunnel reliability failures, and backup access failures. Each one is common, each one is fixable, and each one becomes obvious in hindsight. The pattern across all six is the same: Cloudflare's defaults are not always safe defaults, and the platform rewards users who understand what they've configured and why.
Small misconfigurations here have outsized consequences. A single wrong SSL mode setting breaks your entire site. A single proxied MX record silently kills email delivery. The power of Cloudflare scales with how carefully you use it.
Before you move on, run through the checklist above. Don't skim it. Actually open your Cloudflare dashboard and verify each item against your live configuration. If you find something that doesn't match, fix it now rather than during an incident.
Part 22 moves into advanced territory: building a production-grade Cloudflare architecture that combines Zero Trust, Tunnels, and DNS into a single coherent security layer. If Part 21 was about avoiding mistakes, Part 22 is about building something that makes most of those mistakes structurally impossible. If you've run into Cloudflare errors that aren't covered here, drop them in the comments. Real-world edge cases make this series better for everyone.
