Skip to main content

Cloudflare: Free CDN and DDoS Protection

Security · 01.10.2025 · 6 min read
Illustration for “Cloudflare: Free CDN and DDoS Protection”

Cloudflare provides a free CDN (acceleration through a global network of servers), DDoS protection and an SSL certificate. Setup takes 15 minutes.

Connecting Cloudflare

  1. Sign up at cloudflare.com
  2. Click Add a Site → enter your domain
  3. Choose the free Free plan
  4. Cloudflare scans your DNS records automatically
  5. Review the list of records, click Continue
  6. Copy the assigned NS servers (looking like aisha.ns.cloudflare.com)
  7. In your domain registrar's panel, replace the NS servers with Cloudflare's
  8. Wait 5-24 hours for propagation

Important settings after connecting

SSL/TLS

  • SSL/TLS → Overview → Full (strict) mode — if the server has a valid SSL certificate
  • Full — if SSL exists but is self-signed
  • Flexible — if there is no SSL at all (temporary)

SSL modes: how they differ and what they risk

ModeBrowser → CloudflareCloudflare → serverRisk
OffHTTPHTTPTraffic is not encrypted anywhere
FlexibleHTTPSHTTPThe Cloudflare-to-server leg is not encrypted
FullHTTPSHTTPS (any certificate)The server certificate is not verified, spoofing is possible
Full (strict)HTTPSHTTPS (trusted certificate)Minimal risk with correct setup

Flexible is a temporary mode for the period while the server has no certificate yet. It should not stay on permanently: the Cloudflare-to-server connection travels in plain text, and the visitor sees a padlock in the browser even though there is no real end-to-end encryption.

Caching

# Caching → Configuration:
Caching Level: Standard
Browser Cache TTL: 4 hours

# Caching → Cache Rules - exclude admin:
If: URI path contains /wp-admin
Then: Bypass cache

Speed

  • Auto Minify: enable CSS, JavaScript, HTML
  • Brotli: enable (better than gzip)
  • Rocket Loader: use with caution (can break JS)

Anatomy of common mistakes

Error 521/522/525 after enabling proxying

As soon as a record is switched to the "orange cloud" (proxied through Cloudflare), the server starts receiving requests not directly from visitors but from Cloudflare's IP addresses. If the server's firewall is too strict and does not allow those IPs, the visitor will see one of these errors:

Error 521: Web Server Is Down
# the server does not respond to the connection at all - usually a firewall block or the service crashed

Error 522: Connection Timed Out
# the server did not respond in time - network issue or overload

Error 525: SSL Handshake Failed
# the server could not negotiate TLS with Cloudflare - usually the Full/Full strict mode
# with a missing or invalid certificate on the server itself

The fix for 521/522 is to allow Cloudflare's IP ranges in the firewall for ports 80/443. The fix for 525 is to check that the server actually has a valid, non-expired certificate matching the chosen SSL mode.

Mistake: forgetting to enable proxying (grey cloud)

If a DNS record is left in "DNS only" mode (grey cloud), DDoS protection and the CDN do not work at all — Cloudflare simply answers DNS queries while all the traffic goes straight to the server's IP, which is now also publicly visible in the DNS record history.

Cloudflare Analytics

The Analytics section shows: request counts, traffic volume, blocked threats and visitor geography — all for free.

When Cloudflare is not a fit

  • You need the visitor's real IP with no extra setup — proxying hides the client's real address from the server unless you explicitly read the CF-Connecting-IP header in logs and the application.
  • The service runs on non-standard ports outside the list supported by the free plan — proxying covers a limited set of ports, anything else needs either a paid plan or a direct connection bypassing Cloudflare.
  • The application is sensitive to single-digit-millisecond latency to its own server — an extra hop through the CDN adds latency where caching does not help (for example, trading APIs with strict latency requirements).

Checking that everything is connected correctly

  1. Run dig NS your-domain — the response should show Cloudflare's NS servers, not the registrar's old ones.
  2. Request the site's headers: curl -I https://your-domain/ — the presence of a cf-ray header confirms the request passed through Cloudflare.
  3. Check the SSL mode with curl -I https://your-domain/ with no certificate errors, and make sure HTTPS is enabled on the server itself if Full or Full (strict) mode is chosen.
  4. In Security → Events, check that blocked requests are actually showing up — an empty list in the first few days just means filtering has not gathered statistics yet, not that it does not work.
💡 Cloudflare + a ZevsHost NVMe VPS = maximum speed. The CDN serves static assets from 300+ points around the world, the VPS handles dynamic content in <50ms.

What to do if the page shows a mixed content warning after connecting is covered in Mixed Content over HTTPS, and choosing the type of SSL certificate is covered in DV, OV and EV certificates.

Frequently asked questions

What can be done if an application needs the visitor's real IP while proxying is on?

The visitor's real address is not lost — it is passed in the CF-Connecting-IP header, and the application or web server needs to read that header explicitly instead of the standard connection address, which under proxying always points to Cloudflare's network. Without that change, logs and brute-force protection systems will only ever see Cloudflare's own addresses.

Is it safe to leave Flexible SSL mode on permanently?

No, Flexible is meant to be temporary, used only while the server has no certificate of its own yet. In that mode the Cloudflare-to-server connection travels in plain text, while the visitor sees a padlock in the address bar and assumes encryption, though there is no end-to-end protection. Switch to Full strict as soon as the server has a certificate.

Why did the site suddenly become unreachable with a 521 error after connecting Cloudflare?

Most likely the server's firewall is set too strictly and blocks connections from Cloudflare's own IP addresses, which is where all the traffic comes from once proxying is on. The fix is to allow Cloudflare's IP ranges through the firewall for the web ports; otherwise the server cannot respond to requests and shows that error, though the site keeps working.

Do old DNS records need to be deleted at the registrar after switching to Cloudflare's NS servers?

Deleting the old records at the registrar is not necessary: once the NS servers are changed, the registrar stops being responsible for that domain's DNS, and its own records stop being consulted even if they remain in its panel. All DNS management now happens in the Cloudflare dashboard, and that is where records need to be kept up to date.

Was this article helpful?
← Back to Knowledge Base Ask Support