Cloudflare for Indian Websites — The Setup That Actually Pays Off

Verdict at the top: If you have a website with any meaningful Indian audience and your hosting is in Europe or the US (which includes Domain India hosting on Hetzner Germany — every shared, reseller, and VPS plan we sell), put Cloudflare in front of it. The free tier alone delivers 80-200 ms of latency reduction per request for cacheable content, eliminates the bulk of automated attack noise, and gives you origin SSL via Cloudflare Origin Certificates — all at zero cost. The paid tiers (Pro $25/month, Business $200/month) are worth it for specific use-cases this guide will name; if those don't apply, the free plan is genuinely sufficient.

The latency math, with real numbers

Domain India hosts in Hetzner Germany (Frankfurt, Falkenstein, Helsinki) — same data centres for shared cPanel, DirectAdmin, Plesk Windows, and our VPS infrastructure. From the perspective of an Indian user, that's a long network path:

For a typical WordPress page that has ~30 sub-resources (CSS, JS, images, fonts), the difference is significant. Without Cloudflare, every sub-resource pays the full 150 ms RTT — page reaches "interactive" at ~3-4 seconds on Indian broadband. With Cloudflare proxying, static sub-resources hit BOM PoP at ~12 ms — same page reaches interactive at ~1-1.5 seconds.

This isn't theoretical. It's the difference between "this site feels sluggish" and "this site feels fast" for Indian users — and it's the single biggest perceived-performance win you can apply without changing anything in your application.

Why this matters more for DI customers than for Vercel/AWS-Mumbai customers: if you were already hosting on AWS Mumbai or Vercel India edge, you'd start at ~15 ms RTT and Cloudflare would add little. Because we host in Germany, Indian latency is our biggest performance handicap and Cloudflare's biggest single fix.

What Cloudflare actually gives you on the free plan

• Global CDN — 330+ data centres worldwide, 6 in India: Mumbai (BOM), Chennai (MAA), Delhi (DEL), Bangalore (BLR), Hyderabad (HYD), Kolkata (CCU). Indian ISPs (Jio, Airtel, BSNL, ACT) peer with most of these via NIXI for predictable routing.
• Free Universal SSL — Cloudflare-managed certificate at the edge, auto-renewing, covers your apex + first-level subdomain. Plus Cloudflare Origin Certificates — a 15-year certificate you install on your origin server (free), so the origin → Cloudflare leg is also encrypted.
• Unlimited DDoS protection — Layer 3/4/7 mitigation. Famously, Cloudflare doesn't charge extra for this even on the free plan.
• Smart asset optimisation — Brotli compression, HTTP/3 (QUIC), automatic minification of CSS/JS/HTML.
• Basic WAF — managed rules covering common OWASP categories. Bot Fight Mode (free) blocks most automated scrapers.
• DNS — fast (1.1.1.1-backed), free, with dig-friendly API control.
• Analytics — requests, bandwidth, threat events, cache-hit ratio.
• Page Rules — 3 free; URL-pattern-based config (cache TTL, security level, page-level overrides).
• Workers — 100,000 requests/day free, then $5/month for 10M.
• Pages — static-site hosting with unlimited requests, free for non-commercial use.

The paid tiers add features many sites don't need:

• Pro ($25/month) — image resizing (Polish), mobile optimisation, image lazy-loading, 25 Page Rules, advanced WAF rules, US/EU data localisation. Worth it for sites with image-heavy traffic.
• Business ($200/month) — uptime SLA, custom WAF rules, prioritised support, advanced bot management. Worth it for revenue-critical sites.
• Enterprise — quote-based; full custom contracts, dedicated support engineers, regulatory compliance options. Out of scope for this article.

Setting it up — 30 minutes end-to-end

Step 1 — Add the domain to Cloudflare

1. Sign up at cloudflare.com (free).
2. "Add a Site" → enter your domain (e.g. yourcompany.com, no www).
3. Choose Free plan.
4. Cloudflare scans your existing DNS. This scan misses records sometimes — open your cPanel/DirectAdmin/Plesk DNS Zone Editor, compare every record, manually add anything missing. The most common omissions: _dmarc TXT, _acme-challenge TXT (if you use external SSL automation), MX records for non-default mail providers.
5. Cloudflare assigns two custom nameservers, e.g. alice.ns.cloudflare.com and bob.ns.cloudflare.com. Note them.

Step 2 — Change nameservers at Domain India

1. Log in: https://domainindia.com/client
2. Domains → My Domains → click the domain.
3. Nameservers tab → "Use custom nameservers".
4. Replace existing NS (often ns1/ns11.crystalregistry.com or ns60/ns61.crystalregistry.com) with the two Cloudflare NS.
5. Save.

Propagation: 4-48 hours typical, usually under 2 hours for .com and .in. Cloudflare emails when the domain is active.

Before changing nameservers — copy down your originals. If anything goes wrong, you need to be able to revert.

Step 3 — Configure SSL (the most-misconfigured step)

Cloudflare offers four SSL modes:

Always use Full (strict). Two ways to get a valid origin cert:

Path 1 — Domain India's free Let's Encrypt (works on cPanel, DA, Plesk by default). Pre-existing on every account; no action needed.

Path 2 — Cloudflare Origin Certificate (recommended). In Cloudflare → SSL/TLS → Origin Server → Create Certificate. Generates a 15-year wildcard cert that's only trusted by Cloudflare (not by the public internet). Install it on your origin server. Why this is better than Let's Encrypt: 15-year validity (no renewal flakes), and the cert can't be used by an attacker who finds your origin IP because it's not chained to a public CA.

Then enable, in SSL/TLS → Edge Certificates:

• Always Use HTTPS = On
• Automatic HTTPS Rewrites = On
• Minimum TLS Version = TLS 1.2 (or 1.3 if all your visitors are modern browsers)
• HSTS — enable carefully, with a 6-month max-age first; once confirmed all subdomains have certs, ramp to 12 months + preload.

Step 4 — Tune caching

Cloudflare caches static assets (images, CSS, JS) by default. HTML is not cached unless you tell it to.

For brochureware / blog sites (mostly cacheable HTML):

• Caching → Configuration → Browser Cache TTL = 4 hours
• Page Rule: *yourcompany.com/* → Cache Level: Cache Everything, Edge Cache TTL: 2 hours
• Mandatory — second Page Rule: *yourcompany.com/wp-admin/* (or your admin path) → Cache Level: Bypass. Without this, logged-in admins see stale content and wonder what's wrong.

For dynamic sites (e-commerce, dashboards, anything with sessions):

• Leave HTML uncached. Let Cloudflare cache only static assets (its default).
• Use Cache-Control headers in your application code for fine control.
• Consider Cache Rules (the modern replacement for Page Rules) for path-based exceptions.

Step 5 — DNS records — what to proxy and what not to

In Cloudflare DNS, each record has an "orange cloud" (proxied through Cloudflare) or "grey cloud" (DNS-only).

Orange cloud (proxy on):

• @ (apex) → your origin IP, proxy on
• www → your origin IP, proxy on
• Any subdomain serving HTTP/HTTPS to end users (e.g. app.yourcompany.com)

Grey cloud (DNS only — proxy off) — these break things if proxied:

• mail.yourcompany.com — IMAP/SMTP traffic isn't HTTP; Cloudflare can't proxy it.
• cpanel.yourcompany.com, webmail.yourcompany.com — control panel access; Cloudflare's 100 MB upload limit on free plan breaks file uploads, and cookies behave oddly.
• mx/mx1 records — mail servers don't speak HTTP.
• FTP / SFTP / SSH endpoints (e.g. ssh.yourcompany.com) — non-HTTP protocols, Cloudflare can't help.
• _dmarc, _acme-challenge, SPF (TXT records) — these are DNS-text records anyway; "proxy" doesn't apply.
• Subdomain pointing to a different host you don't want exposed via Cloudflare.

The most common mistake we see: customer enables Cloudflare, all DNS records get auto-orange-clouded, mail stops flowing because the MX target host (mail.yourcompany.com) is now behind a Cloudflare proxy that doesn't handle SMTP. Symptom: "my email broke after I enabled Cloudflare". Fix: grey-cloud the mail-related A/AAAA records.

Common mistakes — the recurring shape of the support ticket

We see the same Cloudflare-related tickets monthly:

Mistake 1: Origin IP leaked via subdomain.

Customer proxies www and apex through Cloudflare, but leaves cpanel.yourcompany.com or direct.yourcompany.com pointing directly at the origin IP. Attacker scrapes subdomain DNS → finds origin IP → bypasses Cloudflare entirely → DDoS hits the origin directly. Fix: orange-cloud all subdomains that don't need to be unproxied, or use a separate, never-published hostname (e.g. srv1.yourcompany-internal.com) for direct origin access, and use Cloudflare WAF rules to block requests to your origin IP that don't carry Cloudflare's CF-Connecting-IP header.

Mistake 2: Flexible SSL with origin redirect to HTTPS.

Origin sees an HTTP request from Cloudflare, redirects to HTTPS → Cloudflare receives the HTTPS redirect, follows it back to origin via HTTP → origin redirects again → infinite loop. Symptom: "my site shows ERR_TOO_MANY_REDIRECTS after I enabled Cloudflare." Fix: Set SSL mode to Full (strict). Done.

Mistake 3: Cache too aggressive on dynamic content.

Customer creates a "Cache Everything" Page Rule, suddenly customers see each other's logged-in dashboards. Fix: never cache pages that have user-specific content. Either bypass cache for authenticated paths, or use Cloudflare's Cache Reserve with proper Cache-Control: private headers from your app.

Mistake 4: DDoS attack survives because attacker found origin IP via old DNS history.

Tools like SecurityTrails and DNSdumpster archive historical DNS records. If your origin IP was ever public (it usually was, before Cloudflare), the attacker can find it. Fix: change your origin IP after enabling Cloudflare. On Domain India shared hosting, this requires opening a ticket — we can move you to a different server IP. On a VPS, you can request an IP change from us.

Mistake 5: Cloudflare Workers used for things that should be on the origin.

Workers tempt people into stuffing application logic at the edge. For login flows, payment, anything stateful — that's almost always wrong. Workers shine for: redirects, A/B test routing, header manipulation, simple authentication checks (with KV-stored tokens), edge caching of API responses. They don't shine for: complex business logic, anything that needs a real database, anything with multi-step transactions.

A real DDoS pattern we've handled

Anonymised from a 2024 incident: a customer running a small e-commerce site on our shared cPanel hosting was hit by a Layer-7 DDoS — not the largest we've seen, but enough to saturate the account's PHP worker pool and make the site unresponsive. The attacker was hitting the cart page with valid-looking requests at ~2,000 RPS, which our shared-hosting CSF/LFD couldn't fully filter at that rate without also blocking legitimate users.

What we did: emergency-enabled Cloudflare in front of the customer's site (free plan). Within 15 minutes of nameserver propagation, the DDoS traffic was absorbed at the Cloudflare edge — the customer's origin saw less than 50 RPS, of which the legitimate users were roughly 35. The attacker spent a few more days trying alternate vectors (different user-agents, different IP ranges) before giving up; Cloudflare's bot-detection caught most of them automatically, and we added two custom WAF rules to block the rest.

The lesson: don't wait for an attack to enable Cloudflare. Set it up in advance; it costs nothing on the free tier and the protection is sitting there ready when you need it.

Workers, D1, R2, Pages — the 2026 platform play

Cloudflare has expanded beyond CDN into edge compute. Worth knowing what each is:

Workers — JavaScript/TypeScript code running at all 330+ Cloudflare edge locations. Free tier: 100,000 requests/day, 10ms CPU each. Paid: $5/month for 10M requests + 30s CPU. Use for: redirects, A/B testing, edge caching, simple API gateways.

D1 — Cloudflare's SQLite-on-edge database. Free tier: 5 GB storage, 5M row reads/day, 100k writes/day. Useful for: small datasets, edge-cacheable lookups, multi-region read replicas. Don't use for: anything write-heavy, anything needing transactions across many rows.

R2 — S3-compatible object storage with no egress fees. Free tier: 10 GB storage, 1M Class A requests/month, 10M Class B/month. Significantly cheaper than S3 for bandwidth-heavy use cases (image hosting, video on-demand). Use for: media storage when you'd otherwise pay AWS for egress.

Pages — static-site hosting with build pipeline (works with Next.js, Astro, Hugo, plain HTML). Free for non-commercial; integrates with GitHub/GitLab CI. Cleanest path for documentation sites, marketing splash pages, static blog migrations.

Hyperdrive — caching pooler in front of your existing Postgres/MySQL, reducing connection overhead from Workers. Useful when Workers need to hit a relational DB and you don't want to migrate to D1.

For a Domain India customer, the practical upgrade path is: start with free Cloudflare for CDN/SSL/DDoS in front of your existing hosting, then optionally use Pages for static documentation, R2 for image hosting, Workers for redirects. D1/Hyperdrive are advanced tooling — fine to ignore unless you have a specific use case.

The Tier-1 ISP / NIXI peering reality

Indian internet routing has historically been fragmented — different ISPs taking different international paths, with significant peering inconsistencies. NIXI (National Internet Exchange of India) coordinates peering across major Indian ISPs at exchange points in Mumbai, Chennai, Delhi, Kolkata, Bangalore, and a few other cities.

Cloudflare peers extensively with Indian ISPs via NIXI, which is the practical reason most Indian visitors see consistent low latency to Cloudflare's BOM/MAA PoPs regardless of their ISP. From Jio, Airtel, BSNL, ACT, Hathway — broadly similar 5-15 ms RTT to BOM. This makes Cloudflare's Indian PoPs a uniformly-good destination, not "depends on your ISP" like some CDNs.

You don't need to do anything to take advantage of this — it's automatic. But it's worth knowing if you're comparing CDN options: not every CDN has equivalent NIXI peering, and Indian routing for a non-NIXI-peered CDN can be erratic (sometimes via Singapore, sometimes via Europe, depending on ISP-of-the-day).

Performance settings worth turning on

Under Speed → Optimization:

• Auto Minify — enable JS, CSS, HTML.
• Brotli — On (better compression than gzip; near-universal browser support in 2026).
• Early Hints — On (HTTP 103 responses for faster paint).
• Rocket Loader — Off for most sites. Defers JS execution which sounds good but breaks WordPress and many third-party widgets in subtle ways. Turn on only after testing.
• Polish (Pro plan) — auto-compresses images, optionally converts to WebP/AVIF.
• Mirage (Pro plan) — image lazy-loading on slow connections.

Under Speed → Image Optimization:

• Resizing (Pro plan) — generate multiple sizes per image, serve appropriate one based on user device.

Under Network:

• HTTP/3 (with QUIC) — On.
• 0-RTT Connection Resumption — On (faster handshakes for returning visitors).

When Cloudflare is NOT enough

• Streaming media at scale — Cloudflare Stream is a separate paid product; don't try to serve large video files via the CDN free tier (you'll hit the 100 MB single-file limit and consume bandwidth abnormally).
• Real-time / low-latency gaming or chat — Cloudflare adds 5-15 ms of edge processing per request. For most sites, that's invisible; for low-latency apps, native WebSocket origins are better.
• Services needing a fixed origin IP — Cloudflare's IP pool changes; if your client requires a stable IP for whitelisting, set up a dedicated subdomain DNS-only-routed to a fixed bastion.
• Apps where you control both ends and don't need a CDN — internal tools behind a VPN, B2B APIs with known clients in fixed regions.

For most consumer-facing Indian websites with a Domain India hosting backend, Cloudflare free is a clear win.

Verifying everything works

From your laptop:

# Check nameservers resolve to Cloudflare
dig NS yourcompany.com +short
# Should return two *.ns.cloudflare.com entries

# Check Cloudflare is in front
curl -sI https://yourcompany.com | grep -i cf-ray
# Should return: cf-ray: <random-id>-XXX
# (XXX is the airport code of the PoP serving you)

# Check cache (run twice — second request should be HIT)
curl -sI https://yourcompany.com/logo.png | grep -i cf-cache-status
# First call: MISS or DYNAMIC
# Second call: HIT

# Check SSL
curl -sIv https://yourcompany.com 2>&1 | grep -E "subject:|issuer:"
# Should show Cloudflare's cert issuer

# Latency from your location
curl -w '%{time_namelookup} %{time_connect} %{time_starttransfer} %{time_total}\n' \
     -o /dev/null -s https://yourcompany.com/
# Indian users on home broadband: total should be ~0.05-0.15s for cached pages

Frequently asked questions

Bottom line

Every Indian-audience website hosted at Domain India (and most other Hetzner/AWS-EU/AWS-US-hosted sites) should be running Cloudflare in front. Free tier alone gets you the latency win, the DDoS protection, the free SSL, and the basic WAF. Set up takes 30 minutes; the rollback path is one nameserver change away.

If you want help with the migration — particularly identifying mail-DNS records to grey-cloud, or installing a Cloudflare Origin Certificate on your VPS — [email protected] handles this as part of standard hosting support.