Cloudflare Proxy DNS updates and origin transition latency

Confirmed facts

• When the proxy (orange‑cloud) is active, the edge node resolves the DNS record at the moment a request is processed; the client’s own DNS TTL does not affect the transition.
• An already‑established TCP/TLS connection between the edge and the origin continues to use the IP address that was resolved when the connection was opened, so pending requests finish against the old origin.
• The cf-cache-status header reflects whether the response was served from the edge cache (HIT, REVALIDATED) or fetched from the origin (MISS, DYNAMIC). It does not change simply because the origin IP or CNAME target has been updated.

Likely explanation for the transition moment

• After you update the DNS record (or CNAME target) in Cloudflare, the edge’s internal DNS cache is refreshed almost immediately (typically within a few seconds). New requests that arrive after that refresh and that are not satisfied by a valid edge cache entry will cause the edge to resolve the new origin and fetch from it.
• If the object is still cached at the edge with a valid TTL, the edge will return the cached copy and cf-cache-status will remain HIT (or REVALIDATED if the cache is stale but revalidated). The origin change is invisible until the cache expires or is purged.
• Thus, the observed latency for users is governed by the edge‑cache TTL of the specific resources, not by DNS propagation.

Steps to verify and complete the migration without downtime

1. Identify the Cache‑Control / Expires headers (or Edge TTL) for the resources you are moving. This determines how long the old origin may still be served from cache.
2. Update the DNS record (or CNAME target) in the Cloudflare dashboard while the proxy remains orange‑clouded.
3. Monitor a few requests with curl -I https://example.com/resource and look at cf-cache-status. Expect HIT until the cache expires, then MISS followed by DYNAMIC (or MISS if the request is not cacheable).
4. Use the Cloudflare Cache Trace tool (Network → Cache Trace) to confirm which origin IP the edge is contacting after the record change.
5. If you need to cut over faster, purge the specific URLs (or perform a purge‑everything) after the DNS update; this forces the edge to fetch from the new origin on the next request.

Missing diagnostic detail that could change the recommendation

What is the current effective edge‑cache TTL (or Cache‑Control max‑age) for the objects you are migrating? Knowing this tells you how long the old origin may still be served from cache and whether a manual purge is required to meet your downtime‑free goal.