How one request travels through Cloudflare
Use a single request path to understand DNS, proxying, edge rules, Workers, and your origin.
Edited and verified by Orange Book Editorial Team ·
Once a hostname is proxied through Cloudflare, visitors usually no longer connect directly to your origin. This path is the foundation for correct caching, security, and Workers decisions.
Request path
Visitor → DNS → Cloudflare edge → security and cache rules → Worker (optional) → originThe orange cloud does not mean every response is cached
Proxy status controls whether traffic passes through Cloudflare. Caching still depends on the request, response, and cache rules.
What each layer owns
| Layer | Main responsibility | First question |
|---|---|---|
| DNS | Direct the hostname | Is the record correct and proxied? |
| Edge security | TLS, WAF, rate limiting | Should this request be allowed? |
| Cache | Reuse cacheable responses | Can this response be cached, and for how long? |
| Worker | Run edge code | Do you need rewriting, authorization, or service composition? |
| Origin | Produce the final response | Can the origin respond when the edge misses? |
Checkpoint
You should now be able to place a 522, a certificate error, and a cache miss in the most likely layer.
Next: follow the first complete application growth path, or go directly to deploying your first Worker.
Primary sources
Did this page help you complete your goal?
Beta feedback is generated in this browser and is never uploaded automatically.