Why Your Domain Points to the Wrong Server

You've pointed your domain at a new server, but the site that loads is wrong — it's showing old content, a parked page from a previous host, or a completely different website. Or you've set up a new server and your domain still resolves to the old one.

This is one of the more disorienting DNS problems because everything seems to be working (the domain resolves), just not correctly. Here's a systematic guide to diagnosing it.

The Most Common Causes

1. Stale DNS Cache (Your End)

The most frequent explanation: your DNS records are correct and pointing to the right server, but your local machine or network is still using a cached answer from before the change.

DNS resolvers cache answers for a period defined by the TTL (time to live) on the record. If your A record had a TTL of 86400 (24 hours), anyone who looked up your domain in the last 24 hours will continue getting the old answer until their cache expires.

Diagnose it:

# Check what DNS server you're currently using
# macOS
scutil --dns | grep nameserver | head -5

# Check the actual DNS record (bypasses your local cache)
dig yourdomain.com @8.8.8.8 A
dig yourdomain.com @1.1.1.1 A

If dig @8.8.8.8 returns the correct IP but your browser shows the wrong site, your local cache is stale.

Fix it:

# Flush DNS cache — macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Flush DNS cache — Linux
sudo systemd-resolve --flush-caches

# Or simply: wait for TTL to expire, or switch to a different DNS server temporarily

2. The DNS Record Was Changed But Not Saved

This happens more than you'd think — you edit the DNS record in your registrar or DNS provider's dashboard, navigate away, and the change was never saved. The UI returned to the edit view without confirmation.

Diagnose it:

# Check what the authoritative nameservers say
dig yourdomain.com A +short
dig yourdomain.com @ns1.yourdns-provider.com A +short

If the authoritative nameserver returns the old IP, the change wasn't saved.

Fix it: Log back into your DNS provider and re-make the change, confirming it was saved (most providers show a success message or updated record in the zone).

3. The A Record Points to the Right IP, But the Web Server Doesn't Serve Your Site

The domain resolves to the correct IP, but the web server at that IP isn't configured to serve your domain — it serves a default page, a different virtual host, or returns an error.

This is common when migrating to a new server where Nginx/Apache virtual hosts haven't been configured yet.

Diagnose it:

# Check what IP the domain resolves to
dig yourdomain.com A +short
# Returns: 203.0.113.42

# Connect directly to the IP with the Host header to see what's served
curl -H "Host: yourdomain.com" http://203.0.113.42 -I

# Check what the default virtual host serves (without Host header)
curl http://203.0.113.42 -I

If the direct IP request returns a generic page, your web server isn't configured for that domain.

Fix it: Add a virtual host configuration:

# Nginx
server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    root /var/www/yourdomain;
    # ...
}

# Apache
<VirtualHost *:80>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com
    DocumentRoot /var/www/yourdomain
</VirtualHost>

4. Multiple A Records with the Wrong One Dominant

DNS allows multiple A records for a domain. If you have both the old IP and the new IP in your A records, clients get both and alternate between them — sometimes hitting the old server, sometimes the new one.

Diagnose it:

dig yourdomain.com A
# Look for multiple ANSWER SECTION entries

Fix it: Remove the old A record, keeping only the new IP.

5. The Old Host is Still Serving Your Site

When you cancel a hosting plan, some providers continue serving your site for a period, or have a cached copy at the old IP. If your DNS was pointing to their IP and someone still has a cached DNS answer, they'll still reach the old host.

This resolves on its own as DNS caches expire, but if the old host is actively serving old content, it can confuse you into thinking your DNS change didn't work.

Diagnose it:

# Check what the old IP returns
curl -H "Host: yourdomain.com" http://OLD_IP_ADDRESS -I

If the old host is still responding, that's expected — users with cached DNS will still reach it until their cache expires. The key question is: what does the authoritative nameserver say?

6. www vs Apex Domain Misconfiguration

You updated the A record for yourdomain.com but not for www.yourdomain.com (or vice versa). Now one resolves correctly and the other doesn't.

Diagnose it:

dig yourdomain.com A +short      # Check apex
dig www.yourdomain.com A +short  # Check www

Fix it: Ensure both records point to the correct IP, or use a CNAME for www pointing to the apex.

7. Cloudflare Proxy Caching Old Content

If your domain uses Cloudflare's proxy (orange cloud), Cloudflare caches content. Pointing the origin server to a new IP while Cloudflare serves cached content can create an inconsistent experience.

Diagnose it:

# Check Cloudflare response headers for cache status
curl -I https://yourdomain.com | grep -i cf-cache-status

Fix it: Purge Cloudflare's cache from their dashboard (Caching → Configuration → Purge Everything) and ensure your origin IP is updated in Cloudflare's DNS settings.

Systematic Diagnosis Steps

When your domain points to the wrong place, run through this in order:

# 1. What IP does the authoritative nameserver say?
dig yourdomain.com @$(dig yourdomain.com NS +short | head -1) A +short

# 2. What IP are public resolvers returning?
dig yourdomain.com @8.8.8.8 A +short   # Google
dig yourdomain.com @1.1.1.1 A +short   # Cloudflare

# 3. What IP is your local machine using?
dig yourdomain.com A +short

# 4. What does that IP actually serve?
curl -H "Host: yourdomain.com" http://$(dig yourdomain.com A +short) -I --connect-timeout 5

If step 1 returns the wrong IP → fix the DNS record at your registrar/DNS provider. If step 1 is right but steps 2–3 are wrong → wait for propagation (or flush local cache). If all IPs are right but step 4 is wrong → fix the web server virtual host configuration.

Preventing This in Future

Lower TTLs before planned migrations. Before pointing a domain at a new server, lower the TTL on your DNS records to 300 seconds (5 minutes). Changes propagate in minutes instead of hours. Raise it back after migration is complete.

Monitor your DNS records. Domain Monitor monitors your DNS records and alerts you when an A record, CNAME, or nameserver changes unexpectedly. If someone changes your DNS records without your knowledge, or if a migration causes an unexpected state, you'll know immediately. Create a free account.

Test from multiple locations. Use tools like dig @8.8.8.8, dig @1.1.1.1, and online DNS propagation checkers to confirm what different parts of the internet see before declaring a migration successful.

See what is DNS propagation and A record vs CNAME vs Alias for more on DNS record types and propagation behaviour.

Also in This Series

• How to Monitor Stripe Webhooks and Checkout Flows
• How to Monitor MySQL Availability, Slow Queries, and Replication Lag
• How to Monitor PostgreSQL Performance and Connection Issues
• How to Monitor Queue Workers on Laravel, Node.js, and Python Apps
• How to Prove Website Downtime to Your Hosting Provider
• DNS Propagation Taking Too Long? What to Check First
• How to Rotate SSL Certificates Without Breaking Your Site
• Let's Encrypt Renewal Failed: Common Causes and Fixes
• Internal vs Public Status Pages: When You Need Both
• How to Reduce Alert Fatigue Without Missing Real Incidents
• Best Status Page Tools for SaaS Startups