Using Cloudflare in front of your Omega Digital site

Cloudflare's free plan gives you a global CDN, DDoS protection, and a solid DNS manager. Putting it in front of an Omega Digital hosting account is straightforward, but there are four configuration details that trip people up every week. This article walks through all of them.

Step 1: Add the site to Cloudflare

1. 01. Sign up at cloudflare.com and click Add a Site.
2. 02. Enter your domain and pick the Free plan.
3. 03. Cloudflare will scan your existing DNS. Review the imported records carefully. Anything missing needs to be added manually before you continue.
4. 04. Cloudflare assigns you two nameservers (e.g. evan.ns.cloudflare.com).
5. 05. At your registrar, replace the old nameservers with the two Cloudflare gave you.

Step 2: Configure records for Omega Digital

In the Cloudflare DNS tab, you need at minimum:

Type    Name    Content              Proxy status
A       @       198.51.100.42        Proxied (orange cloud)
A       www     198.51.100.42        Proxied (orange cloud)
A       mail    198.51.100.42        DNS only (grey cloud)  ← critical
A       ftp     198.51.100.42        DNS only (grey cloud)
A       cpanel  198.51.100.42        DNS only (grey cloud)
MX      @       mail.yourdomain.com  Priority 0

Step 3: SSL mode. Full (strict)

In Cloudflare → SSL/TLS → Overview, set the encryption mode to Full (strict). This means:

• · Cloudflare to browser: HTTPS with a Cloudflare certificate (automatic).
• · Cloudflare to your server: HTTPS using your Let's Encrypt certificate from Omega Digital.
• · Cloudflare validates your server's certificate, which prevents the classic misconfiguration where a proxy talks to an HTTP origin and pretends it's HTTPS.

If you haven't issued a Let's Encrypt certificate yet, do that first in cPanel. Flexible mode exists, but we don't recommend it. It leaves the hop from Cloudflare to your origin unencrypted.

Step 4: Keep AutoSSL working

AutoSSL in cPanel validates by HTTP. When Cloudflare proxies @ and www, it rewrites the response, which can confuse Let's Encrypt's validator. Two fixes:

1. 01. Temporarily grey-cloud the proxied records when running AutoSSL for the first time, then turn the proxy back on.
2. 02. Better: use Cloudflare's Origin CA certificate instead. Issue one under SSL/TLS → Origin Server, install it via cPanel → SSL/TLS → Manage SSL Sites. These certificates are valid only between Cloudflare and your origin, last 15 years, and avoid the validation loop entirely.

Caching rules worth setting

Default Cloudflare caching is conservative. A few Page Rules that actually help:

# Cache all static assets aggressively
URL:    yourdomain.com/wp-content/*
Rule:   Cache Level: Cache Everything
        Edge Cache TTL: 1 month

# Never cache WordPress admin
URL:    yourdomain.com/wp-admin/*
Rule:   Cache Level: Bypass

# Never cache logged-in sessions
URL:    yourdomain.com/wp-login.php
Rule:   Cache Level: Bypass

Getting the real visitor IP in your logs

With Cloudflare proxying, server logs will show Cloudflare IPs instead of real visitors. Install mod_cloudflare, or (on modern cPanel stacks) enable the Cloudflare IP restoration setting in WHM. For WordPress, the Cloudflare plugin handles this automatically and exposes real IPs to security plugins.

Common gotchas

• · Proxying mail subdomains. Mail will stop working within minutes. Grey cloud everything mail-related.
• · SSL set to Flexible. Looks like it works. Breaks mixed-content detection and leaves origin traffic in plaintext.
• · Forgetting the root A record. Cloudflare does not automatically flatten CNAMEs at the apex unless you create the record. Add an A record or use Cloudflare's CNAME flattening.
• · Caching wp-admin. Users get each other's dashboards. Always bypass cache for admin paths.

Still stuck?

Email [email protected] and mention that you're using Cloudflare. It changes most of the debugging steps.