Cloudflare can improve HTTPS, performance, and attack resistance, but a rushed DNS migration can interrupt the website, email, or APIs. This guide uses a safer sequence: inventory DNS, prepare the origin certificate, change nameservers, enable proxying, select Full (strict), activate DNSSEC, and validate services before tightening the firewall.
Where Cloudflare sits in the architecture
For a proxied web record, the browser establishes TLS with Cloudflare and Cloudflare creates a separate connection to the origin. Because there are two legs, a browser padlock alone does not prove that the Cloudflare-to-origin connection is encrypted and correctly authenticated. The SSL/TLS mode controls that second leg.
The goal is valid end-to-end HTTPS. Do not use Flexible as a long-term fix: traffic to the origin remains unencrypted and redirect configurations commonly create loops.
1. Prepare before changing nameservers
Confirm access to the domain registrar, current DNS provider, and web server. Export the zone or capture every existing record. Document the origin IP, email provider, subdomains, verification records, APIs, and webhooks.
- Test the site directly at the origin and confirm port 443 is open.
- Install a valid origin TLS certificate for the correct hostnames.
- Record A, AAAA, CNAME, MX, TXT, CAA, and SRV entries, especially SPF, DKIM, and DMARC.
- Lower TTL in advance when the current provider allows it.
- Define a monitoring window and rollback path.
Do not immediately delete the old DNS zone. Retain it for several days as a reference while caches and delegation update.
2. Add the domain and review every record
Add the domain to Cloudflare, choose the appropriate plan, and let it scan records. Treat the scan as a starting point and compare every entry with the original zone. Recreate anything missing before changing nameservers.
For website A, AAAA, and CNAME records, an orange cloud means traffic passes through Cloudflare. DNS only exposes the destination and clients connect directly. MX and TXT records are not proxied, and mail-server hostnames should remain DNS only.
- Usually proxy: HTTP/HTTPS sites that need CDN, WAF, or origin-IP protection.
- Usually DNS only: mail, SSH, FTP, unsupported ports, and services requiring direct connections.
- Evaluate first: APIs, webhooks, and WebSockets; proxy them only when protocol, upload, and timeout limits fit.
3. Change nameservers at the registrar
Cloudflare assigns two nameservers. Replace the registrar's current nameservers with those exact values. Do not add IP addresses or create them merely as NS records in the old zone. Wait for the zone to become Active, then query it from multiple networks.
dig NS example.com
dig A example.com
dig MX example.com
dig TXT example.comOn Windows, use nslookup -type=ns example.com. Cached answers can differ until their TTL expires. A missing web or email record, however, must be corrected in Cloudflare rather than solved by waiting.
4. Install TLS at the origin
Prefer a publicly trusted certificate such as Let’s Encrypt when the origin may need direct access. Cloudflare Origin CA works well when the origin is reachable only through Cloudflare's proxy, but browsers do not trust it when proxying is disabled or users connect directly.
The certificate must be unexpired, cover the correct hostname, and match its private key. Configure the virtual host to return the right certificate through SNI. Monitor an Origin CA certificate's expiry yourself because Cloudflare currently does not send expiry notifications for it.
openssl s_client -connect 203.0.113.10:443 -servername example.comThis command inspects the origin certificate chain. Never commit private keys, a Global API Key, or API tokens; use a secret manager and least-privilege tokens.
5. Select Full (strict) and avoid Flexible
Choose Full (strict) after the origin has a valid certificate. It encrypts both legs and checks that the origin certificate is current, matches the hostname, and was issued by a public CA or Cloudflare Origin CA. It should be the production default.
- Flexible: uses HTTP to the origin; unsuitable for sensitive traffic and prone to redirect loops.
- Full: encrypts the origin connection without validating its certificate.
- Full (strict): encrypts and validates the origin; failed validation commonly produces error 526.
Once strict mode works, redirect HTTP to HTTPS in one intentional place. Configure trusted proxy headers when the application sits behind a reverse proxy so it does not redirect indefinitely. Repair mixed content by serving resources over HTTPS.
6. Enable DNSSEC in the correct order
DNSSEC helps resolvers detect forged DNS responses. Enable it in Cloudflare, copy the DS information, and add the exact DS record at the registrar. Wait for confirmation and validate the signed delegation with a DNSSEC checker.
Do not leave an old DS record when changing authoritative DNS providers. A mismatched DS can make the domain fail for validating resolvers.
When moving away from Cloudflare later, follow both providers' DNSSEC transition procedure or remove the DS at the correct time instead of only changing nameservers.
7. Protect the origin after validation
A proxy cannot hide an origin IP that remains in DNS history, DNS-only subdomains, or a mail server sharing the same address. Separate web and mail where practical, audit old records, and avoid publishing the IP in application content.
After the site is stable, the origin firewall can allow web traffic only from Cloudflare IP ranges. Update that list automatically from the official source and retain a separate administration path. Authenticated Origin Pulls adds assurance that origin connections come from Cloudflare. Cloudflare Tunnel is another option that uses an authenticated outbound connection without exposing a public web port.
Check IPv4, IPv6, health checks, cron jobs, webhooks, and monitoring before enforcing rules. Authenticated Origin Pulls is not required for traffic already carried by Cloudflare Tunnel.
8. Apply caching and security carefully
Start by caching static images, CSS, and JavaScript. Do not indiscriminately cache sign-in pages, carts, dashboards, personalized content, or write APIs. Send explicit Cache-Control headers and purge affected objects after urgent deployments.
Minimum TLS Version, WAF, and rate limiting can be configured as the plan permits. Enable HSTS only after every affected site and subdomain works reliably over HTTPS. Incorrect includeSubDomains or preload settings can make HTTP-only subdomains inaccessible for a long time.
9. Test the website, email, and business flows
curl -I http://example.com
curl -I https://example.com
curl --resolve example.com:443:203.0.113.10 https://example.com/ -IConfirm that HTTP redirects once to HTTPS, canonical hostnames do not create chains, the certificate covers the domain, and the page has no mixed content. Test sign-in, forms, uploads, payments, APIs, webhooks, WebSockets, and background jobs.
Send and receive email both internally and externally. Verify MX destinations, ensure the mail hostname is not proxied, retain one valid SPF record, and confirm DKIM and DMARC survived the zone migration.
10. Diagnose common errors
- 521 Web server is down: the origin rejects connections, its web service is stopped, or a firewall blocks Cloudflare.
- 522 Connection timed out: the origin did not respond in time; inspect routing, server load, and firewall rules.
- 525 SSL handshake failed: origin TLS negotiation failed; inspect protocols, ciphers, SNI, and certificates.
- 526 Invalid SSL certificate: Full (strict) cannot validate the origin certificate; check expiry, hostname, and CA chain.
- Redirect loop: commonly caused by Flexible plus an origin HTTPS redirect, or an application that does not trust proxy headers.
- Email stopped: usually a missing MX/TXT record, a proxied mail hostname, or invalid SPF/DKIM.
Completion checklist
- The zone is Active and the registrar shows the assigned nameservers.
- Website, email, verification, and service records match the original inventory.
- The origin has a valid certificate and SSL/TLS uses Full (strict).
- HTTP reaches HTTPS without loops or mixed content.
- DNSSEC validates and the registrar's DS matches.
- Sending, receiving, SPF, DKIM, and DMARC all pass.
- Authentication, forms, APIs, webhooks, and uploads have been tested.
- Caches do not store private content and firewall rules do not block required services.
- Certificate expiry and 5xx errors are monitored.
Conclusion
A secure Cloudflare deployment is not about enabling every feature at once. Preserve DNS, prepare HTTPS at the origin, change nameservers, validate services, turn on Full (strict) and DNSSEC, and only then restrict origin access. Checkpoints between stages provide edge protection and CDN benefits without sacrificing availability.
No comments yet. Be the first to share your thoughts.