AI AI Tools Guidebook
Troubleshooting

Site Loads Intermittently After Connecting a Domain

One refresh the site loads, the next shows a hosting error or parking page. The real causes after binding a domain to a new host, and how to force every resolver onto the new record.

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

You connected a domain to a new host yesterday. Refresh and the site loads. Refresh again and you get the host’s Domain not configured / Invalid Configuration page, or a registrar parking page. Refresh once more and it works. A friend on a different ISP can’t reach it at all; another says it’s fine. This is the classic signature of a half-transitioned DNS state: some resolvers serve the new record, some still serve a cached old one, and each visitor’s result is effectively a coin flip until every cache expires.

Fastest fix (most cases): delete every stale A/AAAA/CNAME record so only the new target remains, confirm your registrar’s nameservers actually point at the DNS zone you’re editing, then force a refresh on the big public resolvers with Google’s flush tool and Cloudflare’s purge tool. After that it’s just waiting out the original TTL.

This article walks through what’s happening in the DNS layer, how to tell which bucket you’re in, and how to accelerate the transition.

Which bucket are you in?

Run one diagnostic first so you fix the right thing:

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
What you seeMost likely causeJump to
Two IPs come back from a single resolverDuplicate/stale A records in the zoneCause 1
Resolvers return different single IPs, one of them oldUneven propagation / high old TTLCause 3, 4
One IP is a registrar/host default page IPOld host still claims the domain, or a hidden parking recordCause 2, 7
dig ns yourdomain.com shows two different NS setsNameserver delegation mismatchCause 5
IPv4 fine, but dig AAAA returns an old IPStray AAAA recordCause 6

Common causes

Ordered by hit rate, highest first.

1. Multiple A records present

You added the new A record but never deleted the old one. Resolvers receive two A records for the same name and pick one, usually round-robin, so roughly half of requests land on the dead host. A common variant: some registrars auto-create a second A record (often for the apex or www) when you add the first, so you end up with a conflict you didn’t type.

How to spot it:

dig yourdomain.com

If ;; ANSWER SECTION: lists two or more A records with different IPs, that’s it.

2. Old host still has the domain bound

Your previous host still considers the domain “attached” and serves its default 404/holding page whenever its IP is hit. Even after you change DNS, that host keeps answering for any resolver still pointed at the old IP.

How to spot it: open the old host’s dashboard and check whether the domain is still listed under its domains/sites. It should be removed or released.

3. CDN / public-resolver cache uneven across data centers

Large resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1) run many points of presence and don’t all expire a cached record at the same instant. Cloudflare’s 1.1.1.1, for example, caches a record for up to 3 hours (or the record’s TTL if it’s shorter, as of June 2026). One data center may still hold the old answer while another already serves the new one.

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 means uneven propagation. Note: if your new host uses Anycast (Vercel, Cloudflare Pages, Netlify all do), the same hostname can legitimately resolve to the same advertised IP everywhere — so with those hosts a single, stable IP across all resolvers is the “done” state, not multiple IPs.

4. Old record TTL was high

A record with a TTL of 86400 (24 hours) tells every resolver to keep serving the cached answer for up to a full day after you change it. That cache is already running when you make the change, so you can’t shorten it retroactively.

How to spot it: check the TTL the resolver is currently handing out. The number in the dig answer counts down — if you query twice 10 seconds apart and it drops by ~10, you’re being served from a stale cache that won’t refresh until it hits 0:

dig +noall +answer +ttlunits @8.8.8.8 yourdomain.com

5. Nameserver delegation mismatch

This is the most-missed cause. Your registrar says the domain is delegated to one set of nameservers, but you’re editing a DNS zone on a different provider (or the domain still lists the registrar’s default nameservers alongside the new ones). Resolvers may follow either delegation, so some get your new records and some get an empty or old zone. Symptom looks identical to propagation but never resolves on its own.

How to spot it:

dig ns yourdomain.com +short

The nameservers returned must match exactly what your registrar shows under “Nameservers.” If you see two different sets, or the registrar lists nameservers that don’t match the zone you’re editing, fix the delegation at the registrar.

6. AAAA (IPv6) record points elsewhere

Your A record is correct but an old AAAA (IPv6) record still points at the old host. Visitors on IPv6-preferred networks (most modern mobile carriers) reach the dead host while everyone else is fine.

How to spot it:

dig AAAA yourdomain.com +short

It should be empty or point to the new host. Important: Vercel does not support IPv6 for third-party custom domains as of June 2026 — if you’re on Vercel, any AAAA record will break for IPv6 users, so delete it entirely.

7. Hidden registrar parking / pre-set A record (newer domains)

Brand-new domains frequently ship with a registrar parking-page A record (and sometimes a wildcard) that doesn’t show in the basic zone editor. The symptom is textbook intermittence: sometimes you hit your host, sometimes a “this domain is parked” page.

How to spot it: look for a “default”/“parking”/“forwarding” toggle in the registrar UI, and run a global check (below). If any region returns an IP you never set, a hidden record is in play.

Shortest path to fix

Step 1: Confirm nameserver delegation first

dig ns yourdomain.com +short

If these don’t match your registrar’s nameserver list exactly, fix that at the registrar before touching anything else — no record edit will stick otherwise.

Step 2: Remove ALL stale records

In the DNS zone you control:

  • Delete old A records so only the new target IP remains.
  • Delete any CNAME pointing to the old host.
  • Delete AAAA records pointing to the old host (on Vercel, delete AAAA entirely).
  • Disable any registrar “parking,” “forwarding,” or “domain default” toggle.

Step 3: Release the domain from the old host

In the old host’s dashboard, remove or “release” the domain so it stops answering for it. Otherwise it keeps serving its default page to anyone still cached on the old IP.

Step 4: Force a refresh on the major public resolvers

You can push the big resolvers off a stale record without waiting:

  • Google Public DNS (8.8.8.8 / 8.8.4.4): dns.google/cache — enter the domain, pick the RR type (A, AAAA, CNAME), solve the CAPTCHA, flush.
  • Cloudflare 1.1.1.1: one.one.one.one/purge-cache — enter the domain and record type, purge.

This won’t touch your ISP’s resolver or individual devices, but it clears the two resolvers most checkers (and most users) hit.

Step 5: Wait out the original TTL

For caches you can’t flush, there’s no shortcut — they refresh only when the old TTL expires. If the old TTL was 86400, budget up to 24 hours from the moment you changed the record.

Step 6: Verify globally, then locally

Confirm with a global checker showing 30+ locations, then flush your own machine:

  • dnschecker.org or whatsmydns.net → enter the domain → every region should show the new IP.
  • Flush local cache only after global shows green:
    • macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
    • Windows (Admin prompt): ipconfig /flushdns

How to confirm it’s fixed

You’re done when all of these hold:

  1. dig ns yourdomain.com +short matches the registrar exactly.
  2. The loop in “Which bucket are you in?” returns the same new IP from every resolver.
  3. whatsmydns.net shows the new IP in every region with no stragglers.
  4. The new host’s dashboard reports the domain as Valid Configuration (no Invalid Configuration / Domain not configured banner).
  5. A real device on a different network (phone on cellular, or a VPN to another country) loads the new site on repeated hard refreshes.

When this is genuinely not your fault

DNS propagation is asynchronous by design. For the hours between your change and the original TTL expiring, some intermittence is unavoidable — there is no technical override for “this ISP’s resolver hasn’t expired its cache yet.” If steps 1-3 are clean and global checkers are mostly green, you’re just waiting.

Easy to misdiagnose as

Hard-refreshing the browser doesn’t help, because the problem is upstream DNS, not your browser or local cache. Flush local DNS only once you’ve confirmed propagation is complete — flushing too early just re-pulls whatever stale answer your nearest resolver still holds.

Prevention (next time)

  • Lower the record’s TTL to 300 seconds at least 24 hours before the cutover, so the world’s caches are already short-lived when you switch.
  • Release old host bindings before you change DNS, not after.
  • Delete all stale A/AAAA/CNAME records before adding the new ones.
  • Confirm registrar nameservers match the zone you’re editing before you start.
  • After the change, wait the original TTL before declaring it broken.
  • Test with dig @8.8.8.8 to bypass your own local cache.

FAQ

  • How long until full propagation? Standard record changes (A, CNAME, TXT) usually settle on the major resolvers within ~30 minutes to a few hours when TTLs are sane; with a high old TTL it can run the full 24 hours, occasionally 48. Nameserver changes can take 24-48 hours (per Vercel’s docs, June 2026).
  • Can I force resolvers to refresh early? Partly. You can flush the two biggest public resolvers yourself — Google at dns.google/cache and Cloudflare at one.one.one.one/purge-cache — but you cannot flush an arbitrary ISP’s resolver or a stranger’s device; those expire on their own TTL.
  • Why does dig look correct but the site still flaps? You’re likely querying a resolver that already refreshed, while the requests that fail go to one that hasn’t. Query several resolvers (the loop above) and check the TTL countdown to find the stale one.
  • My host shows a Vercel/Netlify Anycast IP from every resolver — why is it still intermittent? A stable Anycast IP is correct. If it still flaps, the cause is usually a leftover AAAA record (cause 6) or an Invalid Configuration banner from a missing/duplicate record, not propagation.
  • Should I just lower the TTL now to fix it? Lowering TTL now only speeds up future changes — the cache that’s hurting you today was set with the old TTL and ignores the new value until it expires.

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

Related Articles