Introduction

A server migration can move the application successfully while Cloudflare still sends traffic to the old origin because an Origin Rule override was never updated. DNS may already point at Cloudflare and the new backend may be healthy, but one ruleset can keep matching the hostname or path and force requests toward the previous origin.

Treat this as a Cloudflare routing problem instead of a generic DNS issue. Start by confirming whether the affected hostname uses any Origin Rule or origin override, because that layer can bypass the origin you expect from the normal DNS and proxy setup.

Symptoms

  • Traffic still reaches the old backend after server migration even though DNS looks correct
  • Some hostnames or paths hit the new server while others still serve old content
  • Direct tests to the new origin succeed, but Cloudflare traffic behaves as if the old server is active
  • The issue appears only for requests covered by a specific hostname or path pattern
  • The migration looked complete until Cloudflare-routed requests exposed the old backend
  • Only proxied traffic is wrong while origin-side tests look healthy

Common Causes

  • A Cloudflare Origin Rule still overrides the hostname to the old origin
  • The rule match pattern is broader than expected and still catches migrated traffic
  • A newer backend was deployed, but the previous origin override was never removed
  • Multiple Cloudflare rules interact and hide the real origin path in use
  • Another hostname or path inherited the old origin override during migration
  • Cutover validation checked DNS and origin health but missed Cloudflare ruleset logic

Step-by-Step Fix

  1. Confirm that the affected hostname or path is actually proxied through Cloudflare and not reaching the origin directly, because Origin Rule problems exist only on the Cloudflare-routed path.
  2. Review the current Cloudflare Origin Rules and identify any override applied to the affected hostname or route, because one stale rule can keep sending traffic to the previous backend after migration.
  3. Compare the rule match conditions with the requests that still behave incorrectly, because a broad hostname or path pattern may be catching more traffic than you intended.
  4. Check the destination origin host, port, or override target configured in the rule, because migrations often update the backend itself while leaving the rule pointed at the old server.
  5. Look for overlapping rules, redirects, or other Cloudflare routing logic that interact with the Origin Rule, because layered rulesets can make the live origin path harder to spot.
  6. Update or remove the stale origin override and retest the exact hostname and path that were failing, because normal DNS fixes will not change traffic still controlled by Cloudflare rules.
  7. Compare Cloudflare-routed responses with direct tests to the intended new origin after the rule change, because matching behavior across both paths confirms the old override is gone.
  8. Re-test every hostname or path that depends on a custom origin rule, because one rule may be fixed while another inherited override still points at legacy infrastructure.
  9. Document all Cloudflare origin overrides used in the environment after recovery, because ruleset-driven origin routing is easy to miss during future server migrations.