The life of a request on Cloudflare

Every time you open a web page, a single HTTP request leaves your browser and travels through a chain of stops before an answer comes back. On Cloudflare that chain is: DNS finds the address, Anycast routes you to the nearest edge data center, the WAF checks the request is safe, the cache tries to answer instantly, and only if needed does a Worker run your back-end code and read storage. Then the response retraces its steps home.

Here is the whole path on one diagram. Read it left to right: the browser starts the trip, the edge PoP does the heavy lifting (WAF then cache then Worker), storage sits at the far end, and the response flows back.

Six stops make up the journey. Each one has a single job, and each one can short-circuit the trip — for example, the cache can answer before the request ever reaches your code.

Now the same trip as a time-ordered sequence. Notice the branch: a cache HIT answers in one short hop, while a cache MISS has to wake the Worker and reach storage before it can reply — and then it saves the result so the next visitor gets a HIT.

Inside that one edge PoP, a few yes/no questions decide the rest of the request's fate: is it malicious, is it already cached, and does a route send it to a Worker? Following the arrows shows every possible path the request can take.

A Worker is just a fetch handler that Cloudflare runs at the edge PoP — after the WAF, and only when the cache could not answer. Here is a sketch that mirrors the diagrams above: try the cache first, run back-end logic and read storage on a MISS, then save the response for next time.

export default {
  // Cloudflare runs this at the edge PoP, AFTER the WAF and a cache MISS
  async fetch(request, env, ctx) {
    const url = new URL(request.url);

    // 1) Try the edge cache first
    const cache = caches.default;
    let response = await cache.match(request);
    if (response) {
      return response; // cache HIT - the fastest path home
    }

    // 2) Cache MISS - run back-end logic and read storage
    if (url.pathname === "/api/profile") {
      const user = await env.DB.prepare(
        "SELECT name FROM users WHERE id = ?"
      ).bind(url.searchParams.get("id")).first();
      response = Response.json(user);
    } else {
      const html = await env.ASSETS.get("index.html");
      response = new Response(html, {
        headers: { "content-type": "text/html" },
      });
    }

    // 3) Save to the edge cache for the next visitor, then return
    response.headers.append("Cache-Control", "max-age=60");
    ctx.waitUntil(cache.put(request, response.clone()));
    return response;
  },
};

1. See which PoP you reached

   The cf-ray header ends with a 3-letter airport code — that is the edge data center that served you.

   bashcontent_copyCopy

   curl -sI https://example.com | grep -i cf-ray
   # cf-ray: 8a1f...-LHR   (LHR = London)

2. Watch cache HIT vs MISS

   Run it twice. The first call is often MISS; the second is usually HIT, served straight from the edge.

   bashcontent_copyCopy

   curl -sI https://example.com/logo.png | grep -i cf-cache-status
   # cf-cache-status: HIT

3. Confirm the Worker ran

   Add a custom header in your Worker (for example response.headers.set('x-served-by', 'worker')) and look for it in the response to prove your code was the one that answered.

• The whole chain (DNS, edge, WAF, cache) only kicks in when your DNS record is proxied — the orange cloud in the dashboard.
• Static files (images, CSS, JS) cache beautifully; dynamic, personalized responses usually should not.
• A cache HIT never runs your Worker, so it costs no Worker requests and adds no latency.
• cf-ray identifies the PoP and the exact request; keep it when filing a support ticket.
• Read the chapters on DNS, CDN, WAF, and Workers next — each one is a single hop in this diagram.