How to Set Up Cloudflare for Your Website: Step-by-Step Guide

Putting Cloudflare in front of an existing website changes two important boundaries: Cloudflare becomes the authoritative DNS provider for the domain, and web requests for proxied records pass through Cloudflare before reaching the origin server. That can enable Cloudflare caching, TLS, analytics, and security features, but it does not guarantee a faster, safer, cheaper, or more available website.

This guide covers Cloudflare's full DNS onboarding path for a site that is already online. You will inventory the existing DNS zone, onboard the apex domain, change nameservers, configure TLS and caching, and verify the result. Keep a rollback record throughout the change; the outcome depends on your DNS accuracy, proxy status, selected Cloudflare plan, cache eligibility, and origin configuration.

Last checked: 11 August 2026.

What is Cloudflare and why use it?

Cloudflare can act as both the authoritative DNS provider and a reverse proxy for a website. When an eligible A, AAAA, or CNAME record is set to Proxied, web traffic for that hostname goes through Cloudflare. A record set to DNS only returns its origin value without sending the connection through Cloudflare's proxy.

For proxied web traffic, Cloudflare can serve cache-eligible content from its network, terminate visitor TLS connections, apply plan- and configuration-specific security controls, and forward requests to the origin. Email and other non-web services require their own DNS records and are not automatically proxied.

You do not move the website files to Cloudflare during this process. The existing server remains the origin, and you remain responsible for the Cloudflare account, DNS records, TLS mode, cache rules, origin firewall, application, and recovery path.

What Cloudflare can provide

• Caching: Cloudflare can cache eligible responses for proxied hostnames. Actual cache behavior depends on Cloudflare's defaults, Cache Rules, cache keys, response headers, cookies, and the application.
• TLS at the edge: Cloudflare can present edge certificates to visitors. The SSL/TLS mode separately controls encryption and certificate validation between Cloudflare and the origin.
• DDoS mitigation: Cloudflare attributes DDoS mitigation to its proxied network traffic. This is a Cloudflare capability, not a Virtarix feature or a guarantee that an application cannot become unavailable.
• Origin-load reduction: Cache hits and blocked requests may reduce traffic reaching the origin. Measure origin requests and bandwidth before and after the change instead of assuming a fixed saving.
• Analytics: Available dashboards can show request, cache, and security data. The available views and retention depend on the Cloudflare plan.
• Bot controls: Cloudflare offers bot-related controls, but availability and behavior depend on the selected plan and rules.

Virtarix provides self-managed VPS/VDS infrastructure. It does not configure, operate, certify, or guarantee Cloudflare, the customer application, security controls, availability, or performance. Treat Cloudflare as a customer-managed third-party service and verify its behavior against your own workload.

Prerequisites

Before you begin, make sure you have:

• A Cloudflare account
• The apex domain you want to onboard, such as example.com
• Access to the domain registrar's nameserver and DNSSEC settings
• An export or complete written inventory of the current DNS zone, including A, AAAA, CNAME, MX, TXT, CAA, SRV, and verification records
• The current origin IPv4/IPv6 addresses and a working origin TLS certificate if you plan to use Full (strict)
• The current nameservers and DNSSEC state recorded as a rollback point
• A way to monitor the website, DNS, and any external email service during the change

Step 1: create or sign in to your Cloudflare account

Create a Cloudflare account if you do not already have one, or sign in to the dashboard. Use a strong password and enable multi-factor authentication before adding a production domain.

The dashboard is where you will manage DNS records, proxy status, SSL/TLS settings, Cache Rules, analytics, and security controls for the domain.

Step 2: onboard your domain

In the Cloudflare dashboard, open Domains, select Onboard a domain, enter the apex domain (for example, example.com rather than www.example.com), choose how to add DNS records, and select Continue. Then choose a plan based on Cloudflare's published feature and pricing documentation.

Cloudflare may offer to scan the current DNS zone, but its onboarding documentation says the scan is not guaranteed to find every record. Do not continue from a scan result alone: compare every imported record with the zone inventory you created in the prerequisites.

Step 3: review and verify DNS records

Review the imported DNS table record by record before changing nameservers.

• A records: Map a hostname to an IPv4 address
• AAAA records: Map a hostname to an IPv6 address
• CNAME records: Map one hostname to another hostname
• MX records: Publish the external email provider's mail-exchange targets and priorities
• TXT records: Publish provider verification, SPF, DKIM, DMARC, and other text values
• CAA records: Restrict which certificate authorities may issue certificates for the domain

For eligible A, AAAA, and CNAME records, Proxied (orange cloud) sends supported web traffic through Cloudflare. DNS only (gray cloud) returns the record value without proxying the connection. MX and TXT records do not carry proxied web traffic. Review Cloudflare's proxy-status documentation before choosing a status.

How to add missing records

Open the domain's DNS Records page and select Add record. Choose the record type, enter the exact name and value from the authoritative provider documentation, set TTL/priority where applicable, and save it.

Proxy only web hostnames that should pass through Cloudflare. Keep service-verification records and non-web services DNS-only. Do not invent a record value from the website hostname or origin address.

External email records

Your MX records must match the records published by your external email provider. Copy the provider's required MX priorities and SPF, DKIM, DMARC, and verification values exactly. Cloudflare's email-record documentation confirms that the values depend on the email provider.

Virtarix VPS/VDS do not support mail-server workloads and email ports are blocked. This guide does not configure the Virtarix VPS as an SMTP server, relay, or email host.

Step 4: update your nameservers

Before changing nameservers, save the previous nameservers, DNS export, and DNSSEC state. If DNSSEC is enabled at the registrar, follow Cloudflare's DNSSEC migration guidance before the change. Cloudflare warns that changing nameservers while an incompatible DS record remains active can make the domain unreachable.

Cloudflare assigns two authoritative nameservers to the domain. At the registrar, replace the current nameservers with both values shown in the Cloudflare dashboard. The labels and confirmation flow vary by registrar, so use the registrar's current documentation.

Wait for Cloudflare to show the domain as Active, then confirm that authoritative DNS lookups return the expected records. Do not treat a saved registrar form as proof that the delegation is complete.

Rollback if validation fails

If critical records are missing or the site becomes unavailable, restore the previously recorded nameservers and DNSSEC state using the registrar and previous DNS provider's documented procedure. Keep the old DNS zone available until the Cloudflare zone, website, and external email service have all passed verification.

Restrict direct origin access only after validation

Restricting ports 80 and 443 to Cloudflare's published IP ranges can reduce direct access to the origin, but a mistake can also lock out legitimate traffic. Apply this firewall rule only after the domain is Active, both HTTP and HTTPS paths have been tested, every published Cloudflare IPv4/IPv6 range is allowed, and you have preserved administrative or console access for rollback.

Review Cloudflare's range list whenever you maintain the firewall. Do not assume the published ranges will never change.

Restore real visitor IP addresses safely

By default, an origin behind the proxy sees Cloudflare source addresses. Cloudflare adds the original visitor address in CF-Connecting-IP. Follow Cloudflare's original visitor IP instructions for the actual web server:

• Apache: Configure mod_remoteip with RemoteIPHeader CF-Connecting-IP and trust only Cloudflare proxy ranges
• Nginx: Configure the real_ip module with current set_real_ip_from ranges and real_ip_header CF-Connecting-IP
• Application/proxy layer: Use the platform-specific trusted-proxy mechanism

Never trust CF-Connecting-IP from arbitrary direct connections. Restrict trusted proxies to Cloudflare's ranges or an attacker can spoof the header and corrupt logs or IP-based controls.

Step 5: configure SSL/TLS encryption

Open SSL/TLS → Overview. Cloudflare may show Automatic SSL/TLS or custom modes depending on the zone. The selected mode controls the visitor-to-Cloudflare connection and the Cloudflare-to-origin connection.

Encryption modes

• Flexible: Visitor traffic can use HTTPS, but Cloudflare connects to the origin over HTTP. Use it only as a temporary compatibility mode while you add origin TLS; it does not provide encryption from Cloudflare to the origin.
• Full: HTTPS visitor requests use HTTPS to the origin, but Cloudflare does not validate the origin certificate. A self-signed or otherwise invalid origin certificate can therefore be accepted.
• Full (strict): Cloudflare uses HTTPS and validates the origin certificate. Use this when the origin has a valid certificate from a public CA such as Let's Encrypt or Cloudflare Origin CA.

Cloudflare strongly recommends Full or Full (strict) when the origin supports TLS. Test the origin certificate and hostname coverage before selecting Full (strict), and keep a rollback path to the last working mode while you correct certificate problems.

HTTPS settings

After the origin and proxy paths work over HTTPS, review SSL/TLS → Edge Certificates:

• Always use HTTPS: Redirects HTTP requests to HTTPS. Enable it only when every required hostname can serve HTTPS; avoid duplicating conflicting redirects at the origin.
• Automatic HTTPS rewrites: Can rewrite some HTTP resource URLs when an HTTPS version is available. It does not fix every mixed-content reference, especially URLs loaded by JavaScript or CSS.
• Minimum TLS version: Choose a baseline that matches your security requirements and verified client compatibility; do not raise it without testing required clients.

Treat HSTS as a separate risky change

Do not enable HSTS during the initial cutover. First prove that HTTPS works for every hostname you intend to cover. Cloudflare's HSTS documentation warns that removing HTTPS, switching proxied records to DNS-only, moving nameservers, or applying includeSubDomains/preload incorrectly can make a site inaccessible for the configured max-age. Enable HSTS only with a written rollback plan and do not enable preload casually.

Verify TLS

Test the apex domain and every proxied hostname in a browser, verify the certificate chain and hostname, check HTTP-to-HTTPS redirects, and inspect the browser console for mixed content. An external scanner such as Qualys SSL Labs can provide another view, but a letter grade does not replace application testing.

Step 6: configure caching deliberately

Cloudflare can cache eligible content only for proxied hostnames. Default behavior and origin cache headers may be sufficient for some sites; others need explicit Cache Rules.

Open Caching → Cache Rules, select Create rule, and define the match conditions before changing cache eligibility or TTL. Cloudflare's Cache Rules documentation notes that response cache-control headers can still affect eligibility.

Use the application behavior to design each rule:

• Cache versioned static assets such as images, CSS, and JavaScript when their URLs change with the content
• Respect short freshness requirements for frequently updated public pages
• Bypass personalized pages, authenticated sessions, carts, account areas, and responses containing private data
• Bypass API responses unless the API has an explicit, safe cache contract
• Define how deployments purge or version changed assets before increasing TTL

Measure instead of promising an outcome

Record a baseline before the change: origin requests, cache-hit ratio, response times at the origin and edge, error rate, and bandwidth. Compare the same measurements after the rule has seen representative traffic. A low cache-hit ratio can be correct for a dynamic application; do not increase caching at the cost of stale or user-specific responses.

Cloudflare cannot fix slow database queries or application processing on cache misses. Profile and optimize the origin separately. On Virtarix, the website, web server, database, caching stack, Cloudflare integration, updates, monitoring, and recovery remain customer-managed.

Step 7: common issues and troubleshooting

Domain remains pending or DNS answers are wrong

Confirm the registrar has exactly the two Cloudflare-assigned nameservers, check that old nameservers were removed, and verify that no stale DNSSEC DS record conflicts with the new zone. Compare authoritative lookups with the saved DNS inventory. Cloudflare status should be Active before you rely on its proxy or application services.

SSL/TLS errors or redirect loops

Confirm the origin is listening on the protocol/port required by the selected mode and presents the expected certificate. Flexible can create loops when the origin independently forces HTTPS; prefer a working origin certificate and Full (strict). Change one redirect layer at a time and keep the last working mode recorded.

External email problems

Your MX records must match the records published by your external email provider. Confirm the required MX priorities and SPF, DKIM, DMARC, and verification records are present exactly as documented. To investigate delivery, check the external email provider's documented diagnostics. Do not configure email delivery on the Virtarix VPS.

Cache behavior is unexpected

Inspect Cloudflare's cache status and rule matches for representative URLs. Check cache-control headers, cookies, custom cache keys, bypass rules, and whether the DNS record is actually proxied. Use Cloudflare Trace where available instead of assuming that a rule matched.

Origin errors (520, 521, 522)

• 520: Cloudflare received an empty, unknown, or malformed response from the origin. Inspect origin error logs, headers, and application crashes.
• 521: The origin refused Cloudflare's connection. Confirm the web server is running, listening on the mode's required port, and not blocking Cloudflare ranges.
• 522: Cloudflare timed out contacting the origin. Verify the DNS origin address, firewall/rate limits, server load, and network reachability.

Use Cloudflare's current 520, 521, and 522 documentation for the required evidence and next checks. Virtarix provides self-managed infrastructure; application, Cloudflare, DNS, firewall, TLS, and software troubleshooting remain the customer's responsibility.

Conclusion

A correct Cloudflare cutover is a controlled DNS and reverse-proxy change, not an automatic performance or security upgrade. Keep the previous nameservers and zone inventory until the domain is Active and the website, external email records, TLS, cache behavior, logs, and origin access have all passed verification.

After activation, compare measured results with the baseline and adjust one setting at a time. Keep Cloudflare and origin changes documented, review the provider's current documentation before future UI or policy changes, and test the rollback procedure before treating the configuration as production-ready.