Cloudflare’s free plan delivers real value for personal sites and small services. The problem is that most setup guides don’t tell you the correct order. If you get the order wrong, your site might get faster, but your visitor analytics will show everyone coming from the exact same IP, and the security tools protecting you from brute-force login attempts will be quietly disabled.
That’s why this post focuses on the step-by-step workflow rather than just listing features.
What You Get (and Don’t Get) with the Free Plan
Let’s set realistic expectations first.
What’s included — Global CDN caching, free SSL certificates, basic firewall rules, DDoS mitigation, Brotli compression, HTTP/3, and unlimited bandwidth.
What’s not included — Automatic image optimization (Polish), advanced cache rules, image resizing, granular firewall rules, and real-time logs.
In short, “delivering files closer to users” is free, while “making the files themselves lighter” is mostly paid. It is better to handle image optimization, such as WebP conversion, directly on your origin server.
Step 1: Connecting Nameservers and Enabling the Proxy
When you register a domain with Cloudflare, you will be prompted to change your nameservers. Once you update them to Cloudflare’s nameservers at your domain registrar, they will become active within a few minutes to a few hours.
Before making the switch, make sure all your existing DNS records have been migrated. While Cloudflare imports them automatically, some can occasionally be missed. In particular, if mail-related records (MX, SPF, DKIM) are missing, you won’t receive emails. We highly recommend taking a screenshot of your current DNS settings before switching.
Next is the cloud icon.
- Grey cloud — DNS-only. Traffic does not go through Cloudflare, so you get no CDN or protection.
- Orange cloud — Proxied. Traffic goes through Cloudflare, enabling the CDN, SSL, and firewall.
Only enable the orange cloud for web service records like A, AAAA, and CNAME. Leave mail server records grey. Mail traffic should not be proxied.
Step 2: Restoring Original Visitor IPs ⚠️
There is a reason this section is placed early on. This is a task you must perform immediately after enabling the proxy.
When the proxy is enabled, visitor requests route through Cloudflare to your server. Consequently, the connection IP your server sees is not the visitor’s, but Cloudflare’s IP. This leads to the following issues:
- Visitor analytics record all traffic under the same IP range, breaking unique visitor tracking.
- Security tools like fail2ban see all brute-force attempts coming from a single IP. In worst-case scenarios, they might ban Cloudflare’s IP, taking your entire site offline.
- Geographic traffic statistics become completely meaningless.
The real visitor IP is passed in the CF-Connecting-IP header. You just need to configure your web server to trust this header. For Nginx, it looks like this:
# Cloudflare IP 대역에서 온 요청에 한해 CF-Connecting-IP 를 진짜 IP 로 인정
set_real_ip_from 173.245.48.0/20;
# ... Cloudflare 공식 IP 목록의 나머지 대역도 모두 추가
real_ip_header CF-Connecting-IP;
It is crucial to restrict the IP ranges using set_real_ip_from. If you trust the header without this restriction, anyone can spoof their IP by forging the header. Since Cloudflare publishes its official IP ranges, you should use those exact ranges.
You can achieve the same result using mod_remoteip in Apache, or by configuring trusted proxies in your application framework.
Step 3: Cache Rules
By default, static files like images, CSS, and JS are cached. We will tweak two things here.
Increasing static file cache duration — Setting a longer Browser Cache TTL speeds up load times for returning visitors. If you use a build system that appends hashes to filenames, setting a long duration is perfectly safe.
Excluding paths that should never be cached — This is even more important.
- Admin panels (
/wp-admin/*,/admin/*) - Login and authentication paths
- API endpoints
- User-specific pages like shopping carts and checkout screens
What happens if you cache admin pages? An admin’s logged-in page could be cached and served to other visitors. This can lead to critical security incidents like session leaks, making it the very first thing you should verify when configuring cache rules.
Step 4: SSL Mode and Compression
Make sure to verify your SSL/TLS encryption mode. This setting is located under the SSL/TLS Overview tab.
- Flexible — Encrypts traffic only between the visitor and Cloudflare; traffic between Cloudflare and your server is sent in plain text. Do not use this. While the padlock icon appears, half of the connection is exposed, and this is a common cause of infinite redirect loops.
- Full — Encrypts end-to-end but does not validate the server’s certificate.
- Full (strict) — Encrypts end-to-end and enforces certificate validation. This is the correct choice.
If your server does not have a valid certificate, issue one via Let’s Encrypt or install a Cloudflare Origin Certificate, then set the mode to Full (strict).
Enabling compression and optimization features is generally beneficial. Turn on Brotli compression, HTTP/3, and “Always Use HTTPS” to automatically redirect unencrypted traffic.
Measuring Results After Setup
Don’t rely on perception; verify with hard numbers.
- Measure performance before applying changes using PageSpeed Insights or WebPageTest. Without this, you won’t have a baseline for comparison.
- After applying the changes, test again using the same tool, same page, and same conditions.
- Since the cache needs time to warm up, it is more accurate to test a day later rather than immediately after setup.
The key metrics to watch are TTFB (Time to First Byte) and LCP (Largest Contentful Paint). The impact of the CDN will show up first in your TTFB.
⚠️ The features and UI layout of the free plan are accurate as of August 2026 and are subject to change. Cloudflare’s IP ranges are also updated periodically, so please check their official page for the latest list.
Frequently Asked Questions
Is the free plan enough?
Yes, it is more than enough for personal blogs or small sites. It includes unlimited bandwidth, CDN, SSL, and basic protection. You only need a paid plan if you require automatic image optimization, need to write many complex cache or firewall rules, or need detailed real-time logs.
Does this apply to WordPress?
Yes, it does. However, make sure to configure cache exclusion paths. You must not cache /wp-admin/, /wp-login.php, or any requests containing login cookies. This prevents logged-in screens from being cached and served to other visitors.
Can it actually slow down my site?
Yes, it can. If most of your visitors and your origin server are located in the same country (e.g., South Korea), routing traffic through an overseas edge server can actually increase latency. Additionally, if your site relies heavily on dynamic pages that cannot be cached, the benefits will be minimal. Test your site before and after with the same tool to make an informed decision.
Leave a Reply