jguillaumesio
cloudflaresecurityinfrastructuredevopsnetworking

Cloudflare under the hood: how it works and how attackers try to get around it

What actually happens when a request hits a Cloudflare-protected site, how Turnstile distinguishes bots from humans, and the techniques attackers use to find the origin server behind the proxy.

Most developers know Cloudflare as “the thing that sits in front of your site and blocks bots.” That description is accurate but incomplete. Understanding how it actually works changes how you configure it, and how you think about the gaps it leaves open.

This article covers three things: what Cloudflare does at the network level, how Turnstile works under the hood, and the techniques attackers use to find origin servers and bypass bot protection. The last section is framed defensively: if you know how the attacks work, you know what to close.

1. What Cloudflare actually is

Cloudflare is not a reverse proxy running on one server somewhere. It is a globally distributed edge network with over 300 points of presence (PoPs). When you put your domain behind Cloudflare, you are routing all traffic through that network before it ever reaches your server.

The mechanism is anycast routing. Cloudflare announces the same IP address from every PoP simultaneously. When a user sends a request to your site, BGP routing automatically directs it to the closest PoP, not to your origin server. From there, Cloudflare decides what to do with it.

User in Tokyo
   |
   | (anycast routes to nearest PoP)
   v
Cloudflare Tokyo PoP
   |-- cached? → serve from edge, origin never touched
   |-- blocked? → return 403, origin never touched
   |-- challenge? → run Turnstile, origin never touched
   |-- clean? → forward to origin, return response
   v
Your origin server

TLS termination happens at the edge PoP, not at your origin. Cloudflare holds the certificate, decrypts the request, inspects it, then re-encrypts it for the leg to your origin (assuming you have SSL between Cloudflare and origin enabled, which you should).

This is why Cloudflare can inspect HTTPS traffic for WAF rules without a man-in-the-middle attack: you are explicitly delegating that decryption to them.

2. The layers between a request and your server

A request arriving at a Cloudflare PoP passes through several decision layers in order:

DDoS mitigation runs first, before anything else. Cloudflare maintains a real-time global view of attack traffic. Volumetric floods (UDP amplification, SYN floods) are absorbed at the network layer. HTTP floods are identified by rate, pattern, and reputation.

IP reputation and geofencing checks the source IP against Cloudflare’s threat database. IPs from known botnets, Tor exit nodes, or datacenter ranges are scored. You can set rules to challenge or block based on that score.

WAF (Web Application Firewall) inspects the HTTP layer: headers, path, query params, body. Cloudflare maintains a managed ruleset covering OWASP Top 10 plus known CVEs. Custom rules let you match on anything.

Bot management (Turnstile is the visible part of this) assigns each request a bot score from 1 to 99. Score 1 is almost certainly a bot. Score 99 is almost certainly human. You write rules that act on that score.

Cache is the last layer before origin. If the response is cacheable and a fresh copy exists at the PoP, Cloudflare serves it without touching your server.

Only requests that clear all of these reach your origin.

3. How Turnstile works

Turnstile is Cloudflare’s CAPTCHA replacement. Unlike reCAPTCHA v2, it has no image challenge: the goal is to verify a visitor is human without making them solve anything visible.

When a page loads Turnstile, this is what actually happens:

1. The widget loads a JavaScript challenge from Cloudflare’s edge. The script itself is different per request: it is not a static file you can cache or analyze once.

2. The script collects passive signals about the browser environment:

  • Timing: how long did each JS operation take? Real browsers have consistent, slightly variable timing. Headless browsers running at full CPU speed have suspiciously uniform timing.
  • Interaction: did the mouse move before the form was submitted? Did keystrokes have natural inter-key delays?
  • Browser fingerprint: canvas rendering, WebGL renderer, installed fonts, audio context output. Each real browser has a unique fingerprint. Headless browsers without spoofing tend to look identical.
  • Environment: are dev tools open? Are there automation-specific JS properties exposed (window.webdriver, navigator.webdriver)?

3. The script sends these signals to Cloudflare, which runs them through a model trained on billions of requests. If the request looks human, it issues a short-lived, signed token.

4. Your frontend submits that token with the form. Your backend calls Cloudflare’s siteverify API to validate it.

POST https://challenges.cloudflare.com/turnstile/v0/siteverify
{
  "secret": "your-secret-key",
  "response": "token-from-widget"
}

If the token is valid and unused, Cloudflare returns success: true. If your backend does not make this call, the protection is entirely client-side and trivially bypassed by anyone who just skips the form submission step.

Turnstile modes:

  • Managed: Cloudflare decides whether to show a visible checkbox. Most users see nothing.
  • Non-interactive: no challenge shown ever. If the signals are not convincing enough, it fails silently.
  • Invisible: same as non-interactive but embedded in an existing element.

4. Finding the origin server behind Cloudflare

This is the most important section from a defensive perspective: if an attacker finds your origin IP, they can bypass Cloudflare entirely by sending requests directly to that IP. Your WAF, DDoS protection, and bot management all disappear.

Here are the techniques commonly used, in order of how often they succeed.

SSL certificate history

Before you put a domain behind Cloudflare, it had a certificate issued directly to the origin. Certificate transparency logs record every certificate ever issued for a domain, and they are public.

https://crt.sh/?q=example.com

If the origin IP appeared in a certificate Subject Alternative Name before Cloudflare was enabled, it is in the log forever. This catches the majority of small sites that migrated to Cloudflare after they were already live.

DNS history

DNS records are cached and archived by multiple services. Before Cloudflare, your A record pointed directly to your origin. Those old records are stored in:

  • SecurityTrails
  • DNSDumpster
  • ViewDNS.info

Search for your domain and look at the “historical” tab. Old A records pointing to your origin IP are usually there, often with timestamps showing exactly when you switched to Cloudflare.

Subdomains not behind Cloudflare

The Cloudflare dashboard has an orange cloud icon next to each DNS record. Grey cloud means not proxied: requests go directly to that IP. Many teams proxy www and the apex domain but leave others grey by accident.

Common culprits:

  • ftp.example.com: legacy, often points to origin
  • mail.example.com or smtp.example.com: mail servers are usually on the same network
  • dev.example.com, staging.example.com: internal environments added to DNS and forgotten
  • Direct API subdomains: api.example.com sometimes bypasses the proxy for latency reasons

A subdomain enumeration pass (tools like subfinder, amass, or just checking common names) reveals which subdomains exist and which ones resolve to a non-Cloudflare IP.

MX records

Mail servers cannot be proxied through Cloudflare. Your MX record points directly to a mail server, and that server is often hosted on the same provider account, same IP block, or even the same machine as your web server.

dig MX example.com
# Returns: mail.example.com
dig A mail.example.com
# Returns: 203.0.113.42 (your origin IP block)

Even if the mail server IP itself is not the web server, knowing the IP block narrows the search significantly.

SPF records

SPF records list every IP authorized to send email on behalf of your domain. They often include your origin server or your hosting provider’s IP ranges.

dig TXT example.com
# Returns: v=spf1 ip4:203.0.113.0/24 include:sendgrid.net ~all

Scanning with Cloudflare’s certificate fingerprint

Cloudflare issues origin certificates (the certs for the Cloudflare-to-origin leg). If your origin is using a self-signed cert or a Cloudflare origin certificate, its fingerprint is the same across plain IP access. Shodan and Censys index TLS certificates across the entire IPv4 space: search for your cert fingerprint and you may find the raw IP.

HTTP headers and error pages

Some origins leak their IP in HTTP response headers or error pages:

  • X-Powered-By: Express on a specific port
  • Error pages from a framework with a default template unique enough to match
  • Server: nginx/1.18.0 (Ubuntu) with a specific build fingerprint
  • Internal redirect headers pointing to http://10.0.0.1/ (private IPs in misconfigured proxies)

5. Bypassing Turnstile

Turnstile is meaningfully harder to bypass than reCAPTCHA v2 because there is no image challenge to crowdsource. The signals it collects are behavioral, not visual.

Solving services

Services like 2captcha, Anti-Captcha, and CapSolver have human workers who solve challenges in real time. For Turnstile, they run a real browser session, solve the challenge, and return the token. This works but is slow (seconds per token) and costs money per solve. At low volume it is practical; at scraping scale it becomes expensive.

Headless browser spoofing

Tools like Playwright and Puppeteer can be combined with stealth plugins (e.g., playwright-extra with puppeteer-extra-plugin-stealth) that patch the automation-detectable properties:

  • Sets navigator.webdriver to undefined
  • Spoofs canvas fingerprint
  • Adds realistic mouse movement and timing jitter
  • Loads with a full Chrome user agent

A well-configured headless browser can pass Turnstile at a reasonable rate. Cloudflare’s model is continuously updated to catch these setups, but it is an arms race.

What actually stops most bots

The visible Turnstile widget is not the main line of defense. Cloudflare’s bot score, built from network-level signals (IP reputation, ASN, request rate, TLS fingerprint) catches far more traffic than the JS challenge does. A request coming from AWS Lambda with a clean browser User-Agent still has a datacenter ASN: that alone raises the bot score significantly before any JS runs.

The combination of network-level scoring plus behavioral JS analysis is what makes Cloudflare effective. Turnstile alone, validated only client-side, is weak.

6. How to actually protect your origin

Given everything above, here is what actually closes the gaps.

Use Cloudflare Tunnel. This is the only approach that fully hides your origin IP. Cloudflare Tunnel (cloudflared) opens an outbound connection from your server to Cloudflare’s network. Your server has no open inbound ports. There is no IP to find, no certificate to scan, no DNS record pointing at it.

cloudflared tunnel create my-tunnel
cloudflared tunnel route dns my-tunnel example.com
cloudflared tunnel run my-tunnel

If you cannot use Tunnel, firewall your origin to Cloudflare IPs only. Cloudflare publishes its full IP range:

https://www.cloudflare.com/ips-v4
https://www.cloudflare.com/ips-v6

Allow only those ranges on ports 80 and 443. Drop everything else. This does not hide your IP but makes it useless: direct connections get rejected.

Proxy every subdomain. Do a full audit of your Cloudflare DNS records. Every A and AAAA record for every subdomain that should be proxied must have the orange cloud enabled. Grey-cloud records that point to your origin are a bypass by design.

Keep mail on a separate IP. Your mail server should not be on the same IP or IP block as your web server. Use a dedicated mail provider or at minimum a separate VPS.

Validate Turnstile server-side, always. The token must be verified by your backend against Cloudflare’s siteverify endpoint on every form submission. Client-side-only Turnstile is decoration.

Check your certificate history now. Run your domain through crt.sh and SecurityTrails. If your old origin IP is visible, you have two options: move to a new IP (and use Tunnel going forward) or accept that IP is known and rely entirely on the firewall approach.

Cloudflare is genuinely excellent protection, but it is not a black box you enable and forget. The gaps are well-known, systematically exploited, and all closeable with the steps above.