CDNShark vs Cloudflare: Architecture, Protocols and Real Pricing

Most "X vs Cloudflare" posts compare feature checklists. This one compares request paths, protocol support, and the actual numbers on both pricing pages — including the places where Cloudflare is straightforwardly the better choice.

The two request paths are not the same shape

This is the difference everything else follows from. Cloudflare runs one unified anycast network: a single IP announced from every location, and the PoP that answers is the PoP that terminates TLS, runs the WAF, checks the cache, and — if you use Workers — executes your code. One hop.

CDNShark splits routing from serving across two anycast layers:

Two consequences worth being blunt about. First, your TLS handshake completes at the edge, not at the anycast node that accepted the TCP connection — so the handshake pays the distance to the edge, not the distance to the router. Cloudflare terminates at the first hop. Second, on port 443 CDNShark does not route strictly to the nearest edge. The traffic router passes TCP through at layer 4 to an nginx upstream pool with least_conn and static distance weights:

edge within  500 km of the router  ->  weight 10
edge within 2000 km                ->  weight  7
edge within 5000 km                ->  weight  4
anything further                   ->  weight  1
                     (max_fails=3, fail_timeout=30s)

With 11 edges, a meaningful share of HTTPS connections are deliberately placed on a non-nearest edge. That is a load-distribution and failure-tolerance choice, not an accident — but it does mean CDNShark trades some tail latency for spread. Per-request nearest-edge Haversine selection currently applies to plain HTTP (port 80) only.

Protocol support: the honest table

These are verified against the live edge, not read off a datasheet.

HTTP/2 reached CDNShark's edges in August 2026, so request multiplexing is no longer a difference between the two. Brotli and HTTP/3 still are. On a media-heavy page with dozens of subresources, Brotli's smaller text payloads and QUIC's faster recovery on lossy mobile networks both favour Cloudflare, and anyone telling you those gaps do not matter for that workload is selling you something.

Where the architectures genuinely diverge in CDNShark's favour

Configuration is data in Redis, not a control-plane API call

Every CDNShark edge holds its own Redis master — no cross-region replication of config state. Site configuration is a single JSON document per hostname:

site:{host} -> {
  "origin":     "http://203.0.113.10:80",
  "cached":     true,
  "geo_mode":   "block",       "geo_codes":  "RU,CN",
  "ip_mode":    "allow",       "ip_list":    "198.51.100.0/24",
  "rate_mode":  "strict",      "waf_mode":   "strict",
  "hotlink_mode": "block",     "hotlink_domains": "example.com",
  "cache_rules": [{"match_type":"ext","match_value":".mp4",
                   "action":"ttl","ttl":86400}],
  "edge_rules":  [{"match_type":"prefix","match_value":"/old/",
                   "action":"redirect","redirect_status":301}]
}

The edge Lua reads that key on every request, with a control-plane API call as fallback if Redis is unreachable. A reconciler re-syncs every 15 minutes and a healer runs every 5. The practical effect is that an edge keeps serving correctly with the control plane completely down, because the config it needs is already local.

The bot challenge is stateless and inspectable

CDNShark's JS challenge issues a proof-of-work: the browser must find a nonce where SHA-256 of the challenge has a required number of leading zero bits.

A served challenge must be solved within 120 seconds. The clearance cookie is HMAC-signed and carries no server-side state — it is verified by signature, expiry, client IP prefix, and a hash of the user agent, so the clearance hot path never touches Redis. Verified-bot exemptions (Googlebot, Bingbot) are opt-in per zone and checked against a daily-refreshed IP range allowlist, never on user agent alone. Only HTML navigations are challenged; assets and API calls pass through.

Everything about that is written down and checkable. Cloudflare's managed challenge is more sophisticated and draws on far more signal — but it is also opaque, and you cannot reason about why a given visitor got challenged.

A note on the WAF

CDNShark's WAF is a custom Lua pattern engine running in the edge's access phase, with basic and strict modes. It is not OWASP ModSecurity Core Rule Set and we do not describe it as such. It is a smaller, faster, less comprehensive ruleset than Cloudflare's managed rules. If your compliance requirement literally names CRS, CDNShark does not satisfy it.

Pricing: different models, so compare carefully

Cloudflare's paid plans are per zone — per domain. CDNShark's plans are per account, with domains included. That distinction dominates the maths for anyone running more than one site.

Figures as of August 2026; check both pricing pages before committing.

Read that table honestly and Cloudflare's free plan wins outright on raw bandwidth: it is unmetered, and CDNShark's free tier is not. Where CDNShark's model pays off is breadth per account — ten domains with real cache rules, WAF modes, geo blocking, and origin tunnels for $9.99 total, versus $20/month each.

Limitations, stated plainly

• 11 edge PoPs — Fremont, Kansas, Beauharnois, London, Gravelines (×2), Limburg, Warsaw, Delhi, Sylhet, Singapore. There is no South American, African, Japanese, Korean, or Australian edge. If your audience is there, your latency will show it.
• No HTTP/3 or Brotli at the edge today. HTTP/2 is live; QUIC is not, and gzip is the only compression offered.
• No edge compute. There is no Workers equivalent. Edge rules cover redirects, cache TTLs by extension or prefix, CORS, and header manipulation — not arbitrary code.
• DDoS capacity is not comparable. CDNShark has per-IP (100 r/s) and per-domain (1000 r/s) rate limiting, a global IP blacklist fed by threat feeds, geo and ASN blocking, and a shield tier. It does not have Cloudflare's scrubbing capacity, and no amount of Lua substitutes for absorbing a multi-terabit flood.
• The control plane is single-region. Edges survive its loss; the portal and API do not.

Who should pick which

Stay on Cloudflare if you need HTTP/3, edge compute, the managed WAF ruleset by name, a genuinely global footprint, or headroom against large volumetric attacks. For a single hobby domain on the free plan, Cloudflare's unmetered bandwidth is very hard to argue with.

Consider CDNShark if you run several domains and per-zone pricing has become the dominant line item; if you want CDN, anycast DNS, S3-compatible storage, video, and private origin tunnels billed as one account rather than five products; or if you want to be able to read exactly how the routing, caching, and challenge logic work rather than trusting a black box.

Those are different products for different problems, and the comparison table only tells you which one fits yours if it includes the parts that do not flatter us.