The Cloudflare network
Trace the reverse proxy path
Follow a request from a browser through Cloudflare to an origin and back without confusing the edge with the host.
Cloudflare sits in front of your server as a reverse proxy. The browser never talks to your server directly. It connects to Cloudflare, and Cloudflare either answers from the edge or opens its own connection to your origin and relays the response.
So every request has two legs. Browser to Cloudflare, then Cloudflare to origin. When something breaks, my first question is always: which leg failed?
How your request finds Cloudflare
Cloudflare uses anycast. The same IP addresses are announced from many locations at once, and internet routing carries each visitor to a nearby data center. A user in Tokyo and a user in Milan resolve the same hostname but land on different machines.
You can see which data center answered you:
curl -s https://flaviocopes.com/cdn-cgi/trace | grep colo
# colo=MXP
/cdn-cgi/trace is a diagnostic endpoint Cloudflare exposes on every proxied hostname. colo=MXP means the Milan data center handled my request.
Read the evidence in the headers
Request a proxied page and look at what comes back:
curl -I https://flaviocopes.com
# HTTP/2 200
# server: cloudflare
# cf-ray: 95a2c81f4e2a39d1-MXP
server: cloudflare tells you the response passed through the proxy. The cf-ray header is a unique ID for this one request, and its suffix repeats the data center code. Save it. Support and log searches use it to find one request among millions.
The origin is still the origin
Cloudflare answered fast, but who produced the page? Your origin did, unless the response came from cache or you replaced the origin with Workers or Pages. The origin remains the system that produces uncached application responses.
Check the application log on the origin side:
203.0.113.7 - - [03/Aug/2026:10:14:22 +0200] "GET / HTTP/1.1" 200
Notice the client address. It belongs to Cloudflare, not to the visitor, because Cloudflare opened this connection. The real visitor IP travels in the CF-Connecting-IP header instead.
Logging the connecting address as “the user” is the classic mistake on this path. Your analytics collapse into a handful of Cloudflare IPs and you can’t tell visitors apart. Read the header, or configure your web server to restore the real IP from it.
Try this: request a proxied page, record the cf-ray, then find the matching line in your application logs and note which address appears there.
Lesson completed