Originally published at: Recommended Cloudflare Performance and Security Settings (Guide)
Cloudflare stands out as an impressive ally in the pursuit of optimal website performance and security. Known for its robust suite of tools designed to enhance website performance and bolster security, Cloudflare has become an essential component in the toolboxes of web developers and IT professionals alike. However, harnessing the power of Cloudflare isn’t without…
That’s a really nice post, there’s a lot of settings and it can be super overwhelming for new people, over time you just get a feel for which ones are important.
I would mention a few things though:
Page Rules are dead (or dying)
https://blog.cloudflare.com/future-of-page-rules
There’s a bunch of new rules like Cache Rules, Config Rules, Redirect Rules, etc. You get more of them conbined, and they have more options and better matching. They can be a bit complex to use at first, as they don’t support wildcards and use the ruleset engine for expressions, but it’s totally worth it with how flexible they can be in matching and more options
Most of the WAF Tools are old, super old. IP Access rules may be useful at times, although you can just do that in the WAF or with account IP Lists, but for allowing they’re no where near as granular as custom rule skips. Use CF Access rather then zone lockdown, allowlisting by IPs is annoying and outdated when you can use CF Access and sign in via Github/Google/etc for free to verify your identity.
If you can disable all of the features like Automatic HTTP Rewrites you can prevent Cloudflare from needing to decompress and recompress your html: Content compression | Brotli · Cloudflare Speed docs
I haven’t tested the performance difference but I’m assuming there’s some latency savings, plus a lot of a fair amount of issues/incidients have came from those tools like Automatic HTTPS Rewrites, Rocket Loader, etc. In my opinion if you don’t have any insecure links on your page that need to be rewritten (which you shouldn’t, you can always change them at your host), I would disable that, as well as most features which rewrite html.
For SSL/TLS, Full (Strict) is the only secure option, it’s the same security as web browsers have. Full is accepting any certificate, even self-signed as it mentions, so if someone MITM’d the connection to your origin they could just serve any certificate and all you’d acheive is encrypting the request to the attacker…
Cloudflare under SSL/TLS → Origin Server offers Certificates trusted by the Cloudflare Proxy, which work with Full (Strict) and last up to 15 years, no excuse for not using Full (Strict)!
Argo Smart Routing is super cool and gives you “Enterprise like” inbound routing and faster outbound routing to your origin. The inbound part can help in regions like Asia-Pacific where you may not otherwise be routed to some cf locations on free or pro.
Anyway nice post!
If there’s one thing I hope someone new to Cloudflare would learn, it’s to not use Flexible, Full (Strict) with Origin Cert or publicly trusted like Let’s Encrypt via Certbot. By far the #1 wrong security thing I see, and it’s so easy to mess up since Cloudflare defaults to Flexible 
1 Like
Hi @Chaika I recognized your username immediately from Cloudflare Community. I’m pretty sure you have helped me there more than once in the forums.
I do appreciate the feedback! Reading through it now…
Your above comment will be posted right below the blog post itself, so it will be useful for others as well, I’m sure.
Noted on page rules. I’ve become so used to them over the years that I definitely have been slow with the change, or rather the upgrade. I will convert my rules and then update the article.
Oh! This is interesting! I did not know that. I’m also using Rocket Loader. Do you think the performance gained by disabling Automatic HTTPS Rewrites and Rocket Loader will be more than the -200 ms improvement with Rocket Loader enabled? I guess there’s only one way for me to find out eh. 
Will do, yes there is no insure/http stuff via origin. I’ve tried to config Nginx to be close to CF. So not sure why I didn’t think of disabling.
Noted. Was not aware of this either.
Its great, requires no config either. If one can keep their data transfer sizes down its really of good value.
1 Like
Hey! Happy to help
If it genuinely shaved off 200ms then no way would the latency savings from not recompressing beat that. Rocket loader is an iffy one though, it has some compatibility issues and is a tool for “the old web”. It’ll help in cases where sites have a ton of non-dependent scripts, and/or stuff could be deferred/async. But you could do that yourself, and in cases of modern javascript framework builds like React/Vue/etc, they’ll do that as much as they can for you already and Rocket Loader can only slow them down/break things.
It’s not even part of Cloudflare’s new Speed Tab recommendations anymore
Yea the new rules are super cool! Writing your own expressions rather then using the Expression Builder enables you to do a lot as well, the Ruleset Language they use is based on the Wireshark filter language.
You can do a lot more with one of the new rules then with a single Page Rule, ex:
I would always break down your expressions at much as possible and avoid using the larger fields like URI Full, less fragile and easier to change in the future that way.
There’s docs on each field here: Fields reference · Cloudflare Ruleset Engine docs
2 Likes
I’ll note it here for anyone else using WAF for added WordPress security. After reading docs I’ve updated the rules to:
– Block requests that are attempting to access various sensitive WordPress paths like xmlrpc.php, wp-admin, and others. But excludes (does not apply the rule) if the referer is your own site (in this case, “linuxblog.io”):
(http.request.uri.path in {"/wp-register.php" " /wp-admin/" "/install.php" "/theme-editor.php" "/wp-config.php" "/backup/" "/wp-backup/" "/upgrade.php" "/xmlrpc.php"} and not http.referer contains "linuxblog.io")
Something is also setup on the local server which will block locally and then add the IP to Cloudflare WAF as well.
For the country filtering:
(ip.geoip.country in {"XX" "XX" "XX"} and cf.threat_score ge 5) or (http.request.uri.path contains "/wp-login.php")
(ip.geoip.country in {“XX” “XX” “XX”} and cf.threat_score ge 5) or (http.request.uri.path contains “/wp-login.php”)
Replace “XX” with the country or countries you require and set threat score based on this.
I know fail2ban isn’t the most eligant solution, but using Fail2Ban with Cloudflare API to add server blocks to Cloudflare:
1 Like