Cloudflare: Connect Your Domain and Protect It from DDoS

Cloudflare protects a website from DDoS for free: all you need to do is change the domain’s nameservers to Cloudflare’s. After that all incoming traffic passes through Cloudflare’s infrastructure: attacks are filtered before they reach your server, static files are cached in the CDN and the server’s real IP is hidden. Connecting takes 15 minutes, and DNS propagation takes up to 48 hours.

Connecting Cloudflare: how it works

Cloudflare acts as a reverse proxy between the internet and your server. Visitors connect to the nearest Cloudflare point of presence (over 300 data centers worldwide), and Cloudflare then passes the request on to your server. Attacks are absorbed by the Cloudflare network, and nothing reaches the server.

At the same time Cloudflare caches static files (images, CSS, JS) and serves them from the node closest to the user, which speeds up the site even when there are no attacks.

What the free plan includes

Feature	Free	Pro ($20/mo)
DDoS protection L3/L4	Unlimited ✓	Unlimited ✓
DDoS protection L7	Basic ✓	Advanced ✓
CDN	✓	✓
SSL/TLS	✓	✓
WAF	Basic ✓	Full rule set ✓
Rate Limiting	Limited ✓	Detailed ✓
Bot Management	—	— (Enterprise)
Analytics	24 hours	72 hours

For most sites the free plan is enough. It includes unlimited DDoS protection at the network level and basic protection at the application level.

Connecting a domain to Cloudflare

Step 1: Add a site

Sign up at cloudflare.com and click Add a Site. Enter the domain name without www. Choose the free plan.

Step 2: Check the DNS records

Cloudflare automatically scans the domain’s existing DNS records and imports them. Check that all the needed records are in place:

• A record for the root domain and www: it must point to your server’s IP
• MX records for email: they must stay unproxied (grey cloud, more on that below)
• TXT records for domain verification and SPF: carry them over as they are

Step 3: Change the nameservers

Cloudflare gives you two nameserver addresses, unique for each account, for example:

aria.ns.cloudflare.com
bob.ns.cloudflare.com

Go to your domain registrar’s panel (where you bought the domain) and replace the current NS records with the ones Cloudflare gave you. After you save, DNS starts to propagate, usually from a few minutes to 48 hours. Cloudflare sends an email when everything is active.

Orange cloud and grey cloud: what is the difference

Every DNS record in Cloudflare has a cloud icon next to it. It is one of the most important settings.

Orange cloud (proxy on): traffic goes through Cloudflare. DDoS protection, CDN and WAF work. Your server’s real IP is hidden from visitors. This is the mode you need for the site’s A records.

Grey cloud (DNS Only): Cloudflare works only as a DNS resolver. No protection, no CDN, and the server’s real IP is visible to everyone.

An important rule: MX records (mail) must always stay grey. If you turn on the proxy for MX records, email stops working, because mail servers cannot work through Cloudflare’s HTTP proxy.

A critical SSL mistake: do not choose Flexible

The SSL/TLS settings have four modes, and this is where the most common mistake is made.

Mode	Chain	Security
Off	HTTP everywhere	None
Flexible	HTTPS → CF → HTTP to the server	⚠️ Dangerous
Full	HTTPS → CF → HTTPS to the server	Medium
Full (Strict)	HTTPS → CF → HTTPS + valid certificate	✓ Correct

Flexible SSL looks secure but is not. In this mode the user sees HTTPS in the browser, but the traffic between Cloudflare and your server travels over unencrypted HTTP. An attacker with access to the network between Cloudflare and your server (for example at the data center or hosting provider level) can read all of the traffic.

The right choice is Full (Strict). It requires a valid SSL certificate on the server, so install a free Let’s Encrypt certificate. Then switch the mode to Full (Strict) in the SSL/TLS section of the Cloudflare panel.

Also turn on Always Use HTTPS in the same section: it automatically redirects HTTP requests to HTTPS.

DDoS protection: security level settings

In Security → Security Level you can choose how aggressive the checks are:

• Essentially Off: minimal filtering
• Low: blocks only clearly malicious requests
• Medium: the recommended level for most sites
• High: stricter checks, false positives are possible
• I’m Under Attack!: the active-attack mode, described separately below

Medium suits an ordinary site that is not under attack. If the site works with API clients or automated systems, Low is better, because High can block legitimate requests.

Under Attack Mode: how to use it properly

I’m Under Attack turns on a JavaScript Challenge for every visitor: the browser must run a JavaScript task (about 5 seconds) before it gets the page. Bots without a full JS engine do not pass.

Turn it on only during a real attack. In normal operation it causes several problems:

• A 5-second delay for every new visitor
• Blocking of API clients that do not run JS
• Problems with search engine crawlers (although Googlebot usually passes)

To turn it on: Security → Security Level → I’m Under Attack!

When the attack is over, be sure to set the level back to Medium.

Firewall Rules: blocks and challenges

In Security → WAF → Custom Rules you can create your own rules. Examples of useful rules on the free plan:

Block traffic from specific countries (if the site is not meant for them):

• Field: Country
• Operator: is in
• Value: pick the countries you need
• Action: Block

Block suspicious User-Agent headers:

• Field: User Agent
• Operator: contains
• Value: sqlmap (or another attack tool)
• Action: Block

Show a CAPTCHA for the admin login:

• Field: URI Path
• Operator: equals
• Value: /wp-admin or /admin
• Action: Managed Challenge

The real IP problem in server logs

After you connect Cloudflare, the server starts to see Cloudflare’s IP addresses instead of the visitors’ real IPs. Your Nginx logs fill up with addresses like 103.21.244.x, which are Cloudflare IPs, not your users’.

Cloudflare passes the client’s real IP in the CF-Connecting-IP header. To make Nginx see real IPs, add this to the configuration:

real_ip_header CF-Connecting-IP;

Also list the Cloudflare IP ranges as trusted sources (the current list is always at cloudflare.com/ips):

set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
real_ip_header CF-Connecting-IP;

After adding it, reload Nginx: sudo systemctl reload nginx.

What Cloudflare does not hide: IP leaks

A common misconception is that Cloudflare fully hides the server’s real IP. In practice the IP can leak through several channels:

Old DNS records. If your IP was public before Cloudflare, search engines and services like Shodan have already indexed it. Changing NS does not erase history.

Unprotected subdomains. If mail.example.com or ftp.example.com are set up with a grey cloud (DNS Only) and point to the same IP, it is visible.

Certificate Transparency. All SSL certificates are logged publicly. If a certificate was issued for your domain before Cloudflare, the IP from that certificate may be in the databases.

Mail headers. If email is sent directly from the server, the Received: headers contain the real IP.

If hiding the real IP is critical, then after connecting Cloudflare configure the server firewall to accept connections on 80/443 only from Cloudflare’s IP addresses.

Caching in Cloudflare and purging the cache

Cloudflare automatically caches static files (images, CSS, JS) and serves them from the CDN. After you update the site, you need to purge the cache by hand.

Purge the whole cache: Caching → Configuration → Purge Everything

Purge a specific URL: Caching → Configuration → Custom Purge, then paste the file’s URL.

If the site shows an old version after a deploy, purge the Cloudflare cache first.

Frequently asked questions

Does the free Cloudflare protect against DDoS?

Yes, the free plan includes unlimited DDoS protection at the network level (L3/L4) and basic protection at the application level (L7). Cloudflare absorbs attacks of hundreds of gigabits per second, enough traffic to take down any data center, but not Cloudflare’s infrastructure.

Why should I not choose the Flexible SSL mode in Cloudflare?

Flexible SSL creates an illusion of security: the user sees HTTPS, but the traffic between Cloudflare and your server goes over unencrypted HTTP. That makes the CF→server leg open to man-in-the-middle attacks. Use Full (Strict): it requires a valid SSL certificate on the server (for example Let’s Encrypt) and encrypts the whole chain.

How long should I wait after changing nameservers?

Officially up to 48 hours. In practice most providers update NS in 15-60 minutes. Cloudflare sends an email when the domain is activated. You can check with dig NS example.com: when Cloudflare’s NS servers appear, the switch is done.

Why do my Nginx logs show only Cloudflare IPs and not real ones?

When Cloudflare proxies traffic, the server sees the connection coming from a Cloudflare IP. Cloudflare passes the client’s real IP in the CF-Connecting-IP header. Add set_real_ip_from directives with the Cloudflare IP ranges and real_ip_header CF-Connecting-IP to the Nginx configuration, and the logs will show real addresses.

Does Cloudflare affect SEO and site speed?

Positively. The CDN speeds up static content for users worldwide, which improves Core Web Vitals. Cloudflare also offers automatic HTML/CSS/JS minification and HTTP/2 with no extra setup. No search engine penalizes the use of Cloudflare.

Cloudflare stops most attacks before the traffic reaches the server. But for maximum protection you need a reliable VPS with a fast link as the foundation. At UFO.Hosting virtual servers are connected to a network with ports of up to 10 Gbit/s, which keeps them stable even under peak load.

Official documentation: developers.cloudflare.com