If you run a site behind Cloudflare and your origin lives on AWS, Google Cloud, Azure, or Oracle Cloud, you may have paid for a feature you were not actually getting. Smart Tiered Cache — Cloudflare’s most popular tiered-cache topology, free on every plan — is supposed to pick a single “upper tier” data center closest to your origin so cache misses concentrate in one place. But for cloud-hosted origins sitting behind anycast or regional unicast front ends, Cloudflare often couldn’t tell where your origin really was. The result was “hairpinning”: traffic routed to a far-away upper tier, fetched from an origin on another continent, and crossing the ocean twice.
On July 10, 2026, Cloudflare shipped Smart Tiered Cache for Public Cloud Regions (Cloudflare Blog, “Improving Smart Tiered Cache for Public Cloud Regions”), which lets you hand Cloudflare a cloud region hint so it can map your origin correctly. This guide walks through why the problem happens, how to set the hint, and how to confirm it’s actually helping.
Why cloud origins broke tiered caching
Smart Tiered Cache works by measuring latency from every Cloudflare data center to your origin’s IP address and pinning the lowest-latency one as the upper tier. That logic assumes your origin has a fixed, unicast IP that can be reliably probed.
Public cloud load balancers and ingress points usually don’t. They sit behind anycast or regional unicast networks, so the same origin IP can look equally “close” to a dozen Cloudflare data centers at once. Cloudflare even has a physics-based tell for this: it probes your origin from checkpoint data centers around the world, and if two paths are faster than light-in-fiber could physically allow for a single location, the origin must be answering from multiple places — i.e. it’s anycast.
When anycast is detected, Smart Tiered Cache plays it safe and falls back to multiple upper tiers. Caching still works, but you lose the concentrated hit ratio that made a single tier worth it, and in the worst case you get the Chicago-to-Singapore hairpin described above: hundreds of milliseconds of avoidable latency.
What the public-cloud region hint does
The new option lets you tell Cloudflare which cloud region your origin occupies (for example, ap-southeast-1 in Singapore, or us-east-1 in Virginia). With that hint, Cloudflare maps the public-cloud origin to the correct region and selects better primary and fallback upper tiers — even when the origin IP itself looks anycast or ambiguous. The fix covers origins on AWS, GCP, Azure, and Oracle Cloud.
This is the latest in a line of “understand the customer’s origin, then do the best thing automatically” improvements: Smart Tiered Cache for R2 (November 2024) and for Load Balancing (January 2025) preceded it.
How to set the region hint
The feature is configured per-origin (per-hostname behind your zone). The steps below reflect Cloudflare’s documented rollout; treat the dashboard labels as the source of truth and confirm against your own zone.
- Open the zone that fronts the cloud-hosted origin.
- Go to Caching → Tiered Cache (or Cache configuration depending on your dashboard build).
- Ensure Smart Tiered Cache is enabled. If you previously disabled tiered caching because of anycast hairpinning, re-enable it now.
- Under the origin/hostname settings, locate the Cloud region (or “Public cloud region hint”) field.
- Select your origin’s actual region from the provider list:
- AWS: the region your ALB/NLB/EC2 sits in (e.g.
eu-west-1). - GCP: the region of your external HTTP(S) load balancer’s backend (e.g.
us-central1). - Azure: the region of your Front Door / Application Gateway backend (e.g.
eastus). - Oracle Cloud: the region of your public load balancer (e.g.
us-ashburn-1). - Save. Cloudflare re-evaluates the upper-tier selection for that origin using the hint.
If you manage many zones, the same setting is exposed through the Cloudflare API and Terraform provider so you can apply it as code rather than clicking through dashboards.
How to confirm it’s working
A hint that points at the wrong region can be worse than no hint, so verify rather than assume:
- Watch upper-tier selection. After setting the hint, Cloudflare should pick a primary upper tier near your stated region. If your origin is in Singapore and the chosen upper tier is in Chicago, the hint is wrong or not applied.
- Measure origin fetches. In Cloudflare analytics, cache hit ratio on misses should improve and the number of connections to your origin should drop, because misses now funnel through one sensible data center instead of bouncing across continents.
- Test from the edge. Run a
curl -wtiming test from a client near your users before and after. The improvement shows up as lower time-to-first-byte on cache misses, not just on hits.
When you should not reach for this
The hint is for origins behind public-cloud anycast/regional-unicast front ends. If your origin has a fixed unicast IP (a bare VPS, a colo box, a single-region VM with a stable address), Smart Tiered Cache already picks the right tier on its own — you don’t need the hint, and adding one just adds a maintenance burden if you later move regions.
The takeaway
For anyone serving a cloud-hosted origin through Cloudflare, Smart Tiered Cache for Public Cloud Regions is a free, low-effort win — if you set the region hint correctly. The hard part was never the toggle; it was that Cloudflare couldn’t see through the anycast front end. Now that you can tell it where your origin lives, the hairpinning that quietly added hundreds of milliseconds to every cache miss goes away. Spend five minutes per zone, then measure.
Source: Cloudflare Blog, “Improving Smart Tiered Cache for Public Cloud Regions” (July 10, 2026).
