AI AI Tools Guidebook
Troubleshooting

Site Opens Intermittently After Domain Connect

Sometimes the site loads, sometimes it shows a hosting platform error or DNS error. Common causes after binding a domain to a new platform.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

You connected a domain to a new platform yesterday. You refresh — site loads. Refresh again — Vercel’s “Domain not configured” page. Refresh — works again. A friend on a different ISP says they can’t reach the site at all; another says it’s fine. The site is in a half-transitioned DNS state where some resolvers see the new record and some still see the old. Until full propagation completes and any stale records are cleared, what each visitor sees is essentially random.

This article walks through what’s happening in the DNS layer and how to accelerate the transition.

Common causes

Ordered by hit rate, highest first.

1. Multiple A records present

You added the new A record but forgot to delete the old one. Resolvers receive multiple A records and pick one (often round-robin).

How to spot it:

dig yourdomain.com

If ;; ANSWER SECTION: shows 2+ A records with different IPs, that’s it.

2. Old hosting still has domain bound

Your old hosting platform still considers the domain “bound” and serves its default page when its IP is hit. Even after you removed DNS, that hosting might be holding the domain.

How to spot it: Visit your old hosting dashboard → check if domain is still listed. Should be removed.

3. CDN / DNS cache uneven across data centers

Cloudflare and similar global DNS may propagate within their own network at different rates. Some users hit a DC with the old record cached, others hit a DC with the new.

How to spot it:

dig @8.8.8.8 yourdomain.com
dig @1.1.1.1 yourdomain.com
dig @208.67.222.222 yourdomain.com

Different IPs across resolvers = uneven propagation.

4. Old record TTL was high

DNS records with TTL of 24 hours mean some resolvers will keep serving the old record for up to 24 hours after you changed it.

How to spot it: Check what TTL was on the record before you changed it. If 86400 (24h), expect intermittence for up to 24h.

5. DNS provider has split-brain (rare)

Some advanced DNS setups (geo-DNS, custom responses) intentionally return different records to different clients. If misconfigured, this looks like intermittence.

How to spot it: Test dig from multiple geographic locations via dnschecker.org. If results vary geographically in unexpected ways, your DNS provider might have geo rules.

6. AAAA (IPv6) record points elsewhere

You have A pointing correctly but AAAA pointing to old host. Users with IPv6 preference hit old host.

How to spot it:

dig AAAA yourdomain.com

Should be empty or point to new host.

Shortest path to fix

Step 1: Check DNS from multiple resolvers

for dns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
  echo -n "$dns: "
  dig @$dns +short yourdomain.com
done

Different IPs = propagation in progress. All same = propagation complete.

Step 2: Remove ALL stale records

In your DNS provider:

  • Delete old A records (only new should remain)
  • Delete old CNAME records pointing to old host
  • Delete AAAA records that point to old host (or remove entirely if you don’t need IPv6 yet)

Step 3: Remove domain from old hosting

In your old hosting provider’s dashboard, remove or “release” the domain. Otherwise old hosting may continue claiming the domain when its IP is hit.

Step 4: Wait for original TTL to expire

If old TTL was 24h, wait 24h after change for all resolvers to drop the old cache. There’s no shortcut.

Step 5: Verify with global checker

dnschecker.org → enter your domain → see resolution from 30+ countries. All should show new IP.

Step 6: Test from real different networks

Phone on cellular, friend’s home, VPN to another country. If all show new site, propagation is complete.

When this is not on you

DNS propagation truly is asynchronous and incomplete for hours to a day after a change. Some intermittence is unavoidable in that window — there’s no technical workaround for “ISP A’s cache hasn’t expired yet.”

Easy to misdiagnose as

Hard-refreshing the browser doesn’t help — the issue is upstream DNS, not local cache. Flush local DNS once you’ve confirmed propagation is complete.

Prevention

  • Lower TTL to 300 seconds at least 24 hours before any DNS change.
  • Remove old hosting bindings BEFORE switching DNS (not after).
  • Delete all stale records (A, AAAA, CNAME) before adding new ones.
  • After change, wait the original TTL duration before declaring it “broken.”
  • Test from dig @8.8.8.8 to bypass local DNS cache.

FAQ

  • How long for full propagation? Usually 1-24 hours, occasionally 48. Depends on original TTL and how aggressive ISP resolvers are.
  • Can I force resolvers to refresh? No — they refresh on TTL expiry. You can’t dictate when other resolvers refresh their cache.

Tags: #Domain #DNS #SSL #Troubleshooting #Intermittent #DNS propagation

Related Articles