One of the strongest privacy and security moves you can make on any hosting is putting Cloudflare in front of your origin server. Visitors connect to Cloudflare’s network; Cloudflare connects to us. Your real server IP never appears in public DNS, attackers can’t target it directly, and any DDoS traffic is absorbed by Cloudflare’s massive global network before reaching us. For anonymous hosting customers, this is essentially mandatory.
What origin protection actually does
- Hides your server IP. Public DNS shows Cloudflare’s anycast IPs. Anyone running
dig yourdomain.comsees only Cloudflare. - Absorbs DDoS traffic. Cloudflare’s network handles attacks that would overwhelm a single server.
- Blocks malicious bots. Their threat intelligence filters known bad IPs before they reach you.
- Provides a TLS layer. Even if your origin SSL is misconfigured, Cloudflare’s edge SSL serves visitors cleanly.
- Caches static content. Images, CSS, JS served from Cloudflare’s edge — your origin only handles dynamic requests. Massive load reduction.
For anonymous/offshore hosting, the IP-hiding aspect is particularly valuable. Without Cloudflare, anyone curious about where your site is hosted can trace it to our server’s specific IP — and from there, our network and approximate location. With Cloudflare in front, that trail dead-ends at Cloudflare.
Setting it up
Step 1: Create Cloudflare account and add your domain
- Sign up at cloudflare.com (free tier is sufficient for most use cases).
- Click Add Site, enter your domain.
- Choose a plan — Free is fine to start.
- Cloudflare scans your existing DNS records and presents them for confirmation. Verify everything’s there (A records, MX, TXT). Add any missing.
Step 2: Change nameservers at your registrar
Cloudflare gives you two nameservers (e.g. kate.ns.cloudflare.com, mark.ns.cloudflare.com). At your domain registrar:
- Find DNS / Nameserver settings for your domain.
- Replace existing nameservers with the two Cloudflare-provided ones.
- Save. Propagation takes a few hours typically, up to 48 hours worst case.
Cloudflare emails you when nameservers are active. From that moment, your DNS is managed at Cloudflare instead of at iWebVault.
Step 3: Enable the proxy (orange cloud)
In Cloudflare → DNS → Records, each record shows a cloud icon. Orange = proxied (traffic goes through Cloudflare). Grey = DNS only (direct to your IP).
Set to orange:
- A record for
@(root domain). - A record for
www. - Any subdomain that serves web traffic.
Keep grey (DNS only):
- MX records (mail can’t be proxied).
mailA record (for direct SMTP/IMAP).ftp,cpanel, or other non-HTTP services.
Configuring SSL correctly (critical step)
Cloudflare → SSL/TLS → Overview. Four modes:
| Mode | What it does | Use it? |
|---|---|---|
| Off | No SSL anywhere | Never |
| Flexible | Visitor↔CF is HTTPS, CF↔origin is HTTP | Never — insecure, causes redirect loops |
| Full | HTTPS everywhere, origin cert not validated | OK for testing |
| Full (strict) | HTTPS everywhere, origin cert validated | Recommended — always use this |
Set to Full (strict). Your iWebVault AutoSSL Let’s Encrypt cert satisfies the validation requirement automatically.
“Flexible” mode is a classic trap — visitors see HTTPS, but the Cloudflare → origin leg is HTTP. The origin sends back HTTP redirects to HTTPS, which Cloudflare then re-encrypts — infinite redirect loop. Use Full (strict).
Origin lockdown (advanced)
Once Cloudflare is fronting your site, the only legitimate traffic to your origin should come from Cloudflare. You can configure your origin firewall (CSF on iWebVault) to refuse connections from anywhere else.
Cloudflare publishes their IP ranges at cloudflare.com/ips. The cleanest implementation is to open a support ticket asking us to whitelist Cloudflare-only access for your account — we configure it at the server level safely.
Once enabled, even if someone discovers your origin IP, they can’t connect to it directly. Only Cloudflare’s IPs can reach your site.
Critical: prevent origin leakage
Cloudflare hides your IP from public DNS — but your IP can leak other ways. Hunt these down:
- Direct mail headers. Sending email from your server includes your server IP in headers. Use a mail relay or SaaS sender if total IP privacy matters.
- SSL certificate history. Sites like crt.sh log every SSL certificate ever issued. If your hostname has had certs issued for “
123-45-67-89.iwebvault.com“, the IP is forever public. - Historical DNS records. Tools like SecurityTrails archive DNS history. Your old A record from before Cloudflare is in there.
- Web app errors. Stack traces in error pages can include server hostnames revealing IPs.
- Outbound connections. Your server connects to other services (push notifications, webhooks, API calls). Each connection reveals your real IP to the destination.
Complete IP privacy is a research project, not a checkbox. For most customers, Cloudflare in front + a fresh domain is “anonymous enough”. For genuinely high-threat models, see our anonymous hosting deep dive.
Page rules and caching settings
Cloudflare → Caching → Configuration. Default “Standard” caching works for most sites. Adjustments worth making:
- Always Use HTTPS (Rules → Page Rules or SSL/TLS → Edge Certificates) — auto-redirect HTTP to HTTPS at edge.
- Auto Minify (Speed → Optimization) — strips whitespace from CSS/JS/HTML.
- Brotli — modern compression, on by default; verify enabled.
- Cache Level: Standard — caches everything Cloudflare considers safely cacheable.
Common Cloudflare issues
“Site shows infinite redirect after enabling Cloudflare.” SSL set to Flexible. Switch to Full (strict).
“AutoSSL fails after enabling proxy.” Let’s Encrypt’s HTTP-01 challenge hits Cloudflare first. Solutions in SSL guide.
“Site shows old version even after I update.” Cloudflare cache. Purge: Caching → Configuration → Purge Cache → Purge Everything.
“All visitors look like they’re from Cloudflare IPs in my logs.” True — visitor IPs are hidden behind Cloudflare. To see real IPs, install the mod_cloudflare equivalent or use the CF-Connecting-IP header. On WordPress, the “Cloudflare” plugin sets REMOTE_ADDR correctly.
“DDoS protection didn’t help when I got attacked.” Default DDoS protection works on Layer 3/4 attacks. Application-layer attacks (slow POST, login flooding) may need rate limiting rules — Security → Rate Limiting Rules.
What’s next
- Choosing between Cloudflare DNS and iWebVault nameservers: Cloudflare vs iWebVault DNS.
- Full anonymous hosting strategy: Anonymous hosting deep dive.
- SSH key authentication for management: SSH key setup.
Cloudflare in front of iWebVault is the right answer for almost every customer concerned about privacy, security, or performance. Twenty minutes of setup buys you DDoS absorption, IP hiding, edge caching, and free TLS — all on the free tier. Hard to do better for the price.
Was this helpful?
Thanks for your feedback!
