Introduction

A migration can move public DNS and visible routing correctly while backend requests still carry the wrong Host header to the origin. From the outside, the domain may look cut over, but the origin keeps serving the old site, the wrong virtual host, or a default backend because the proxy layer still identifies requests using the previous hostname.

Treat this as an upstream request-header problem instead of a simple DNS problem. Start by checking whether your CDN, reverse proxy, or load balancer overrides the origin Host header, because backend routing often depends on that value even after the public hostname has already been updated.

Symptoms

  • Public DNS points to the new platform, but the origin still serves the old site or wrong application
  • Direct origin tests work with one host header, but proxied traffic behaves differently
  • Only proxied requests reach the wrong backend after migration
  • The origin responds with a default site, old tenant, or unexpected virtual host
  • SSL and DNS may already be correct, but backend content is still wrong
  • The problem started after changing proxies, CDNs, load balancers, or origin mappings

Common Causes

  • The proxy still sends the old domain or backend hostname in the origin Host header
  • An explicit host-header override was set during coexistence and never removed after cutover
  • The new backend expects the public hostname, but the proxy still identifies requests as the old environment
  • Virtual host routing on the origin depends on Host, and the override now selects the wrong site
  • One migration step changed DNS and origin IPs but left request-header behavior unchanged
  • Backend hostname, SNI, and host-header settings were updated unevenly across the same route

Step-by-Step Fix

  1. Identify the exact proxy, CDN, or load balancer sending requests to the origin and confirm whether it overrides the origin Host header, because you need to know which layer is naming the backend request.
  2. Compare a normal proxied request with a direct origin request using the expected host header, because that quickly shows whether the wrong backend appears only when the proxy is in the path.
  3. Review origin rules, host-header overrides, backend definitions, or reverse proxy settings for any value that still references the old hostname, because one leftover override can keep the origin on the wrong virtual host after migration.
  4. Confirm what hostname the new backend expects for correct virtual host matching, because some origins need the public hostname while others require a specific internal name.
  5. Check related TLS settings such as origin SNI or certificate validation if they are configured separately, because mismatched host-header and TLS hostnames often create mixed symptoms during the same migration.
  6. Update the origin host-header setting to the correct value and retest the exact hostname that exposed the problem, because backend routing issues often affect only one route, pool, or zone.
  7. Verify repeated requests from the live edge path after the change, because stale behavior at one proxy layer can make the old backend appear intermittently even after the main override is fixed.
  8. Confirm the old backend stops receiving misaddressed requests in its logs, because the dashboard view should match what the servers themselves are seeing.
  9. Document the final origin hostname, host-header behavior, and TLS expectations for the route, because backend identification settings are easy to miss during future proxy or origin migrations.