Reaching the old server after migration does not always mean your DNS change failed. Your browser might use a different address, a local override, or a proxy with an outdated origin. Old content alone cannot identify which server handled the request.
This guide focuses on proving the destination after a hosting move. The goal is not simply to confirm that a DNS dashboard looks correct. Instead, trace one affected request from the device to the server that actually serves it.
First, Prove Whether the Old Server Handles Requests
Record the exact hostname and page that show the problem. Treat the bare domain and its www name separately. Note the time, network, VPN state, and whether other devices show the same result.
Choose a harmless page that differs between the two hosts. A temporary static marker can help if you control both deployments. Use a unique filename, avoid confidential details, and remove it after testing.
- Open browser developer tools and inspect the main document request.
- Record its remote address, redirects, response headers, and final hostname.
- Check access logs on both hosts for that request and timestamp.
- Compare a normal browser request with a separate command-line request.
A remote address may identify a proxy rather than the hosting server. Likewise, cached responses might never reach either origin. Correlate logs and content before concluding that traffic still reaches the previous host.
If the new server logs the request but returns old pages, investigate its deployment and application cache. That is a different problem from incorrect DNS routing.
Check the Delegated Authoritative Nameservers
An authoritative nameserver publishes a domain’s DNS records. A registrar’s delegation tells the public DNS system which nameservers to ask. Editing records at another provider will not change that public path.
Confirm the registrar’s nameserver settings, then compare them with the live delegation. The following examples use example.com as a placeholder. Replace the hostname and nameserver with your actual values.
dig +trace example.com A
dig @ns1.example.com example.com A +norecurse
dig @ns1.example.com example.com AAAA +norecursedig is a DNS query tool. Availability varies by operating system. Trace mode follows delegation, but network filtering can prevent it from completing.
Query every delegated authoritative server. Look for the authoritative-answer flag, matching addresses, and consistent zone data. A stale secondary can intermittently return the previous address. If you operate secondary servers, follow the secondary DNS synchronization checks.
Also inspect any CNAME record, which points a hostname to another hostname. Follow that target until you find its address records. For background on the roles involved, see Cloudflare’s explanation of DNS resolution.
Separate Recursive Cache From Published DNS
A recursive resolver looks up answers for clients and caches them. Its cached answer can differ from the authoritative answer during a change.
Compare the affected device’s configured resolver with the authoritative servers. Record the answer, query time, and TTL. TTL means time to live: the period a resolver may normally retain a DNS record.
dig example.com A
dig example.com AAAA
dig @RESOLVER_IP example.com AReplace RESOLVER_IP with an approved resolver’s address. The default query may use a local forwarding service, not the same resolver your browser uses.
Lowering TTL after a change does not shorten copies already cached under the previous TTL. Some resolvers can also serve stale answers during upstream failures. Avoid promising a universal deadline for every client.
If authoritative answers are new but one resolver still returns the old address, document that difference. Flush only the relevant cache when you control it and understand the impact. Repeatedly changing correct records can make the evidence harder to interpret.
Inspect Local Overrides and Browser Resolution
When only one computer reaches the old server after migration, check its hosts file. This local file can map a name directly to an address, overriding ordinary DNS lookup.
- On Windows, inspect
C:\Windows\System32\drivers\etc\hosts. - On Linux and macOS, inspect
/etc/hosts. - Look for both the bare domain and the
wwwhostname. - Check browser secure-DNS settings and any configured web proxy.
Read and back up the file before editing it. Do not remove unrelated entries or assume every override is accidental. A technician may have added one for migration testing.
Browsers can use encrypted DNS through a separate resolver. They may also retain DNS answers or reuse existing connections. An operating-system DNS query therefore does not always prove the browser’s destination.
Capture the browser’s remote address before clearing anything. Then test a fresh browser session and compare results. Private browsing alone does not guarantee a separate DNS cache or connection path.
Check Whether IPv6 Still Reaches the Old Server
An A record supplies an IPv4 address. An AAAA record supplies an IPv6 address. Updating only the A record can leave IPv6-capable visitors reaching the previous host.
Check both record types for every hostname in the request path. That includes redirect destinations and CNAME targets. Different networks may select different address families.
Where available, use these read-only HTTP checks:
curl -4 -I https://example.com/
curl -6 -I https://example.com/These commands request response headers over IPv4 or IPv6. They still generate traffic and may trigger logging or security controls. The IPv6 test requires working IPv6 connectivity.
A failed IPv6 test does not prove a stale AAAA record. However, different content or redirects across successful tests deserve investigation. Confirm the intended IPv6 address with the hosting provider before changing it.
Do not disable IPv6 across the business network as a shortcut. Fix the relevant record or hosting configuration once the evidence identifies the mismatch.
Trace CDN and Reverse-Proxy Origins After Migration
A content delivery network, or CDN, can sit between visitors and your host. A reverse proxy similarly accepts requests and forwards them to a backend server. Public DNS may correctly point to either layer.
Check the configured origin address, origin hostname, and any backend pool. A proxy can continue contacting the old server after migration even when all public DNS answers are correct.
Inspect origin hostname resolution, health checks, and cached content separately. Purging cached pages will not fix an outdated backend destination.
With authorization, you can test a known new origin while preserving the website hostname:
curl --resolve example.com:443:NEW_ORIGIN_IP -I https://example.com/Replace NEW_ORIGIN_IP with the verified origin address. This test preserves the HTTP hostname and TLS server name. TLS secures the HTTPS connection.
The origin may intentionally accept traffic only from the CDN. A failed direct test therefore does not establish a hosting fault. Do not weaken access controls or disable certificate checks to force success.
Follow redirects separately. A correct origin can redirect visitors to another hostname that still points elsewhere. For broader availability checks, use the authoritative-path and web-binding guide.
Compare Internal, VPN, and Public DNS Views
Split-horizon DNS means a name returns different answers depending on the requesting network or resolver. Businesses often use it to route internal users to private services.
An internal DNS zone may still contain the previous website address. Public lookup tools cannot reveal that private answer.
- Compare the hostname on office Wi-Fi and an approved external connection.
- Repeat the test with the VPN connected and disconnected, where policy permits.
- Record each device’s resolver and returned address.
- Check internal zones, conditional forwarding rules, and VPN DNS policies.
Do not replace business DNS settings with public resolvers merely to hide the symptom. That can break internal names and bypass required controls. Use the VPN DNS resolution workflow when the difference follows tunnel status.
Correct the Proven Layer, Then Verify Again
Match each finding to a targeted action. Correct stale authoritative data, allow legitimate cache expiry, remove an obsolete local override, or update the proxy origin. Change one layer at a time.
Repeat the same hostname, page, network, and address-family tests afterward. Confirm requests in the new host’s logs. Keep the old host available until you have verified the cutover and protected any remaining data.
If the website still reaches the old server after migration, collect timestamps, DNS answers, redirect headers, and host logs. Tech Rescue Ops LLC can provide remote assistance when multiple providers or private network policies make the path difficult to trace.