Cloudflare provides a free CDN (acceleration through a global network of servers), DDoS protection and an SSL certificate. Setup takes 15 minutes.
Connecting Cloudflare
- Sign up at cloudflare.com
- Click Add a Site → enter your domain
- Choose the free Free plan
- Cloudflare scans your DNS records automatically
- Review the list of records, click Continue
- Copy the assigned NS servers (looking like
aisha.ns.cloudflare.com) - In your domain registrar's panel, replace the NS servers with Cloudflare's
- 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
| Mode | Browser → Cloudflare | Cloudflare → server | Risk |
|---|---|---|---|
| Off | HTTP | HTTP | Traffic is not encrypted anywhere |
| Flexible | HTTPS | HTTP | The Cloudflare-to-server leg is not encrypted |
| Full | HTTPS | HTTPS (any certificate) | The server certificate is not verified, spoofing is possible |
| Full (strict) | HTTPS | HTTPS (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-IPheader 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
- Run
dig NS your-domain— the response should show Cloudflare's NS servers, not the registrar's old ones. - Request the site's headers:
curl -I https://your-domain/— the presence of acf-rayheader confirms the request passed through Cloudflare. - 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. - 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.
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.