Introduction

A site can move to a new server and still serve traffic from the old origin when Cloudflare Tunnel was not updated cleanly. DNS may already point the hostname at Cloudflare, the public URL may still load, and yet the tunnel connector or ingress rule is still forwarding requests to the retired backend. That makes the migration look partially successful while traffic keeps hitting the wrong server behind the tunnel.

Treat this as a tunnel target problem instead of a generic Cloudflare outage. The key is to find which tunnel connector and ingress rule still reference the old origin and then prove where requests are actually landing.

Symptoms

  • The hostname resolves through Cloudflare, but the old server still serves the site after migration
  • Traffic reaches stale content or the previous application state even after cutover
  • DNS checks look correct, but requests still behave as if the old origin is active
  • Only tunnel-backed hostnames are wrong while direct-origin tests hit the new server
  • Some routes work on the new server while others still go to the previous backend
  • The problem starts after moving the application to a new server or container host

Common Causes

  • The Cloudflare Tunnel ingress rule still points to the old local service, host, or port
  • The tunnel connector is still running on the old server instead of the new one
  • A copied tunnel config on the new server was not updated with the new origin target
  • Multiple connectors or replicated configs are causing requests to reach different backends
  • A fallback ingress rule is catching traffic and sending it to the wrong service
  • The new origin is ready, but the active tunnel instance was never moved cleanly

Step-by-Step Fix

  1. Confirm that the hostname is actually using Cloudflare Tunnel and not another origin path, because you need to isolate the traffic flow before changing tunnel settings.
  2. Check which server or container is currently running the active tunnel connector, because the old machine may still be the one maintaining the tunnel even after the application moved.
  3. Review the tunnel ingress rules and origin targets for the affected hostname, because stale service URLs, ports, or local upstream definitions are the most common reason traffic still lands on the old backend.
  4. Compare live content or response headers from the tunneled hostname with the new server directly, because that helps prove whether Cloudflare is still forwarding to the wrong origin instead of the new one.
  5. Look for duplicate connectors, old tunnel instances, or copied configs that survived the migration, because multiple active paths can make requests alternate between the new and old servers.
  6. Update the tunnel configuration so the affected hostname routes only to the new origin target, because partial edits or relying on fallback rules can leave stale paths active.
  7. Restart or redeploy the tunnel connector after the config change and verify the old connector is no longer serving traffic, because changing the file alone does not guarantee Cloudflare is using the updated target.
  8. Test every routed hostname and path that depends on the tunnel, because one ingress rule may be fixed while another host or path still points at the legacy backend.
  9. Remove or decommission the old tunnel-side origin path once traffic is confirmed on the new server, because leaving the retired backend reachable makes later routing mistakes much harder to spot.