* * deny — ~/lab/cloudflare-edge

Lab: how Cloudflare sees your request

Two parts. The first one is real — a small read-only function at the edge shows you exactly what your request looked like when it arrived here, a minute ago. The second simulates what happens when a request skips the edge and knocks on the origin server directly.

what is live and what is not

Part A is live. It calls a read-only function on this site that reads a fixed list of headers off your request and hands them straight back to you. Nothing is stored, nothing is logged by it, nothing is sent anywhere else, and it sends no CORS headers, so no other site can read it either. Cookie and Authorization are not on the list it can read, so they can never come back out of it.

Part B is simulated. Nothing leaves your browser for it. It draws the two paths from a small state machine so you can run the bad one without needing a victim.

For the record: this site runs on Cloudflare Pages, so its files are deployed onto Cloudflare's own network instead of to a server I run. There is no origin server sitting behind it on a public IP, so there is nothing here for Part B to protect. Part B is a real, common pattern for anyone running a traditional origin behind Cloudflare — plenty of you do — but it is not a description of what this site does.

Part A — your actual request

Cloudflare's edge is a reverse proxy. Your browser's connection ends there, at whichever data centre answered, and a fresh request goes on from there to wherever the content lives. Along the way the edge adds headers of its own. Here are the ones on your request, right now.

Nothing has been requested yet. Press the button and the lookup runs once.

The one to be suspicious of

CF-Connecting-IP is set by the edge, from the address it saw the connection arrive from. X-Forwarded-For is a different kind of value: a comma-separated list that proxies add to as a request travels. Cloudflare documents what it does with it: if the request arrives without one, the edge sets it to the connecting IP; if one is already there, the edge appends the connecting IP to the end and leaves the rest of the list alone.

So the last entry is the edge's own measurement. Anything to the left of it was already in the list when the request arrived — a proxy the client chose, or the client itself typing whatever it liked.

So a header can tell you where a request came from, or where it claims to have come from, and the two look identical in a log. That raises the uncomfortable question: what if a request reaches your origin without passing through your edge at all?

Part B — skipping the edge

Cloudflare's edge IPs are shared. Every proxied zone on the platform answers on the same anycast ranges, and the origin's own IP is not in DNS any more. But it still exists, and it is still reachable — dropping it from DNS does not change that.

Pick a route and an origin posture, then send a request.

route
origin posture
client your browser Cloudflare edge WAF, rules, bot rules origin 203.0.113.10 the edge is not in the path

    How this is actually done

    The shared secret in the simulation is not a Cloudflare feature with a name. It is two real things used together:

    Cloudflare's own official mechanism for the same problem is Authenticated Origin Pulls, which is mTLS: the origin demands a client certificate and Cloudflare presents one. It is stronger than a header both parties agree on, and it is a real named product feature, which the shared-secret pattern is not. (Cloudflare docs)

    The other half of the job is at the network layer: restrict the origin's firewall so it only accepts connections from Cloudflare's published IP ranges. That is not sufficient on its own: Cloudflare's own docs say plainly that those ranges are shared by all proxied hostnames, so "came from a Cloudflare IP" is not the same as "came through your zone." That's why it pairs with one of the two mechanisms above instead of replacing them.

    None of this is exotic — it's the same shape of problem as the forward-proxy work a lot of this audience already does: a control point only controls the traffic that goes through it. Cloudflare's edge is itself a reverse proxy, which is what the other lab in this section covers.

    Terms, in case any are new

    origin
    The server that actually holds your site, sitting behind the CDN or proxy. If you run one, it has a real IP address and that address is reachable from the internet unless you stopped it.
    reverse proxy
    A proxy deployed by the site owner, in front of the server. Visitors do not configure it and mostly do not know it is there. A forward proxy is the opposite arrangement: deployed by the client side, in front of the user.
    anycast
    The same IP address announced from many locations at once, so a packet lands at whichever one is closest on the network. It is why one Cloudflare address answers you in Frankfurt and someone else in Singapore.
    colo
    Cloudflare's word for one of its data centres. The three letters at the end of a Ray ID identify it. Cloudflare's own docs describe that code as the three-letter IATA airport code of the data center that the request hit. Turning that code into a city name is this lab's own lookup, going by convention rather than by anything Cloudflare publishes.
    Ray ID
    Cloudflare's per-request identifier. If you ever open a support ticket about a blocked request, this is the value they ask for.
    Transform Rule
    A Cloudflare rule that rewrites parts of a request or response at the edge — including adding a request header before it is sent on to the origin.