Cloudflare Setup: DNS Records, Proxy Status and SSL/TLS Modes

Most Cloudflare outages and redirect loops trace back to two settings made during onboarding: whether each DNS record is proxied, and which SSL/TLS encryption mode is selected. Both are quick to set and easy to get subtly wrong. This guide explains what each option actually does on the wire, which one to pick, and how to verify the result from the outside.

Cloudflare's dashboard layout and defaults change from time to time, so treat menu names here as a map and confirm them against Cloudflare's current documentation.

What Cloudflare does when you add a site

When you add a domain, Cloudflare scans for existing DNS records, then gives you two nameservers (they look like name.ns.cloudflare.com, and the pair is specific to your account). You update the nameservers at your registrar. From that point Cloudflare answers DNS for your domain. If you have not done a nameserver change before, read how to change nameservers without downtime first.

Two things follow from this:

• Cloudflare becomes the source of truth for your DNS zone. Any record that existed at your old DNS host but was not imported (commonly MX, TXT for SPF/DKIM, and subdomain records) stops resolving the moment the nameservers switch.
• A record can be either proxied or DNS only. That is the setting that decides whether Cloudflare sits in the traffic path at all.

Before switching, compare the imported zone against your old one. Use the DNS Checker or dig against the old nameservers for every hostname you care about.

dig +short A example.com @old-ns.example-dns.com
dig +short MX example.com @old-ns.example-dns.com
dig +short TXT example.com @old-ns.example-dns.com

Proxied vs DNS only

Each A, AAAA and CNAME record has a toggle: orange cloud (proxied) or grey cloud (DNS only).

Practical consequences:

• Only web traffic can be proxied on the standard plans. A record for mail.example.com that points at your mail server must be DNS only, or mail clients will try to reach a Cloudflare web edge and fail. The same applies to ftp, ssh, and direct database hosts.
• MX records are never proxied. They point at hostnames, and those hostnames must resolve to your mail host's real IP via a DNS only record.
• Proxied records change what dig returns. Running dig +short example.com shows Cloudflare addresses, not your server. Your origin IP lives in the Cloudflare dashboard and your host's panel. See the CDN Detector to confirm a hostname is served through Cloudflare.
• A grey-cloud record can leak your origin IP, which makes it possible for attackers to bypass Cloudflare by hitting the IP directly. If you proxy the main site, avoid leaving a DNS only record on a sibling hostname that points at the same origin, and consider restricting the origin firewall to Cloudflare's published IP ranges.

The four SSL/TLS modes

There are two separate TLS connections when a record is proxied: visitor to Cloudflare, and Cloudflare to your origin. The SSL/TLS encryption mode controls the second one. The visitor-facing certificate is handled by Cloudflare's Universal SSL by default.

Off

No encryption between visitor and Cloudflare for HTTP. Visitors using https:// get an error or no HTTPS service. There is almost no reason to use this today.

Flexible

• Visitor to Cloudflare: HTTPS.
• Cloudflare to origin: plain HTTP on port 80.

The padlock shows in the browser, but the leg across the internet to your server is unencrypted. This mode exists for origins that cannot serve TLS. It also causes the most common problem in Cloudflare setups: if your origin or CMS redirects HTTP to HTTPS, Cloudflare hits port 80, receives a redirect to HTTPS, follows it, and loops. See Cloudflare too many redirects.

Full

• Cloudflare to origin: HTTPS, but the origin certificate is not validated. A self-signed or expired certificate, or one for the wrong hostname, is accepted.

This protects against passive eavesdropping, not against someone impersonating your origin. It is a reasonable stepping stone if you already have a self-signed certificate on the origin and cannot replace it yet.

Full (strict)

• Cloudflare to origin: HTTPS, with validation. The certificate must be unexpired, match the hostname, and either chain to a publicly trusted CA or be a Cloudflare Origin CA certificate.

This is the recommended mode for any site you care about. A failure here shows up as Cloudflare error 526 (invalid certificate), covered in Cloudflare 520-526 errors explained.

Cloudflare also offers a stricter variant that requires the origin to accept only Cloudflare-originated connections (authenticated origin pulls) and an "Automatic SSL/TLS" feature that can pick a mode for you. Check the current dashboard for what is available on your plan.

Choosing the right mode

Moving from Flexible to Full (strict) is a three-step job: install a valid certificate on the origin, confirm HTTPS works on the origin directly, then change the mode.

# Test the origin's certificate without going through Cloudflare
curl -vI --resolve example.com:443:203.0.113.10 https://example.com/ 2>&1 | grep -E "subject:|issuer:|expire date|HTTP/"

# Or inspect the chain directly
openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

If the certificate comes from Let's Encrypt, make sure renewals still succeed behind Cloudflare. HTTP-01 challenges pass through the proxy normally, but a "redirect everything to HTTPS" or a firewall rule can break them. See how to renew an SSL certificate and automate it.

Settings that interact with the mode

• Always Use HTTPS redirects visitor HTTP requests to HTTPS at the edge. It is safe with Full or Full (strict). Combined with Flexible and an origin redirect, it contributes to loops.
• HSTS tells browsers to refuse HTTP for your domain for a set period. Enable it only after HTTPS works everywhere, including subdomains if you include them. Check with the HSTS Checker.
• Minimum TLS version at the edge controls which visitors can connect. Raising it blocks very old clients; verify with the TLS Version Checker.
• Automatic HTTPS Rewrites can fix some mixed content, but cleaning the source is better. See mixed content: how to fix it.

Verify from the outside

After any change, check what the world sees, not what your dashboard says.

# Is Cloudflare in front, and what does it return?
curl -sI https://example.com/ | grep -iE "^(server|cf-ray|cf-cache-status|location|strict-transport)"

# Does HTTP redirect once, cleanly?
curl -sIL http://example.com/ | grep -iE "^(HTTP/|location)"

A healthy response includes server: cloudflare and a cf-ray header. The redirect chain from HTTP should be one hop to HTTPS and end at a 200. The Redirect Checker shows the same chain graphically, and the SSL Checker validates the edge certificate.

Common mistakes to avoid

• Leaving the mail host proxied, which breaks webmail and SMTP clients.
• Deleting the old A record before the new one is live, producing a gap with no answer.
• Setting Flexible "temporarily" and forgetting it, leaving origin traffic unencrypted for years.
• Blocking Cloudflare IP ranges at the origin firewall, which causes 521 and 522 errors.
• Forgetting that DNSSEC at the old DNS provider must be handled before switching nameservers (see DNSSEC explained).

Next steps

• Compare your zone before and after with the DNS Checker and Nameserver Lookup.
• Confirm origin certificate health with the SSL Checker.
• Understand edge errors in Cloudflare 520-526 errors explained.
• Learn what the cache does in Cloudflare cache rules and purge.
• Get alerted when the site or its certificate breaks with the Uptime Monitor.

FAQ

Should I turn the orange cloud on for every record?

No. Proxy only web hostnames you want served through Cloudflare. Mail, SSH, FTP and other non-HTTP services need DNS only records.

Is Flexible SSL safe?

It encrypts visitor to Cloudflare but not Cloudflare to your server, so traffic crosses the internet in plain text. It is a stopgap for origins without TLS, not a long-term setting for sites with logins or payments.

What is the difference between Full and Full (strict)?

Full accepts any certificate on the origin, including self-signed and expired ones. Full (strict) validates the certificate, which protects against impersonation and is the recommended mode.

Will changing the SSL mode cause downtime?

Switching to a stricter mode will break the site immediately if the origin certificate does not pass validation, producing 526 errors. Test the origin certificate directly before changing the setting.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.