A website works for some visitors only

What it means

When a website works for some visitors but not others, the difference may come from DNS resolver answers, IPv4-versus-IPv6 connectivity, geographic or split-horizon routing, TLS configuration, a browser or CDN cache, a load balancer, or the web origin itself. An apparent partial outage is not automatically DNS propagation. Compare the same URL, hostname and time window before selecting a fix. DNS resolver behavior IPv6 records

This guide is read-only until a responsible operator confirms the failing layer. Do not ask visitors for credentials, change production DNS to a documentation address, or instruct them to disable certificate validation.

Try it

Simulation — compare two visitors at the same layers. Observe DNS, connection, TLS and HTTP for visitors A and B, choose the narrow correction supported by those observations, and retest the original URL. An unobserved layer stays unknown; changing a control is not evidence of a successful request.

Start with the IPv6-path incident. Both visitors receive the same A/AAAA data, yet B's declared IPv6 attempt fails. TLS and HTTP are not reached on that failed attempt. In the TLS incident, DNS and connection succeed but B receives the wrong certificate identity; the scene stops at TLS instead of presenting a normal HTTP response. Neither case is explained merely by the phrase “DNS propagation.”

For the DNS incident, the correction advances both visitors from t=0 to the saved entry's expiry at t=60 and obtains fresh data. It is not a global flush. The HTTP-cache correction revalidates the particular stored response. Other corrections represent narrowly described synthetic changes, not production commands. After a supported correction, Retest compares both visitors again; Reset restores the initial incident and removes observations, corrections and history.

The deliberately different-URL setting blocks a conclusion. Real comparisons must align scheme, hostname, path, question type and relevant time. This scene fixes connection-family choices rather than implementing browser connection racing, and no visitor data leaves the page. DNS behavior TLS identity HTTP cache rules

Environment and safe stopping point

The procedure assumes an authorized operator can collect harmless observations from the affected and unaffected contexts. Use the same approved URL and record time, address family and error stage; do not collect passwords, cookies, authorization headers or private response bodies. The read-only DNS syntax below is documented against BIND 9.20.23, not executed by this page. dig syntax

Stop when requests are not comparable or the failing layer is still unknown. A TLS trust or identity error is not a reason to bypass verification. Keep the previous configuration and a narrowly scoped rollback before an approved repair. If a change worsens either path, restore that known configuration through the normal process, retain the observations, and retest both contexts rather than switching to a different URL to manufacture a success.

Capture a comparable symptom

1. Ask affected and unaffected visitors for the URL and time, broad network type (for example office network versus mobile data), observed error stage, and whether other HTTPS sites work. Avoid collecting personally identifying details or sensitive page contents. Check whether the same hostname and scheme are being compared.
2. Classify the failure: DNS name error; connection timeout; TLS hostname/certificate failure; HTTP status error; or stale/incorrect content. These are different layers with different owners.
3. If a safe public status page exists for the hosting/CDN provider, compare its incident scope and timestamp; no provider status alone proves your site was affected.

Narrow the network and DNS differences

1. Compare the exact hostname's A and AAAA answers from representative configured resolvers. Query the authoritative zone separately to determine current published data. If answers differ, account for positive and negative caching and optional serve-stale. Don't replace NS, MX or TXT records as a diagnostic shortcut. Cached answers Serve-stale
2. Test IPv4 and IPv6 connectivity independently where available. A record with an address and an AAAA record with another address can lead clients to different reachable endpoints. DNS alone cannot prove an IPv6 socket, route, firewall rule, or service works; ask the network/hosting operator to verify them. AAAA meaning
3. For TLS failures, compare the original hostname used in SNI, the certificate names and expiry, and each endpoint's configured certificate. Never suppress certificate checking to mark the website healthy. A third-party CDN or reverse proxy may terminate TLS before the origin, so test the intended public route.
4. For HTTP 4xx/5xx or inconsistent content, compare CDN edge/origin health, deployments, host routing, access policies, cache keys and stale browser state. HTTP caching and application routing can differ even while DNS data matches exactly.

Safe checks and response

A basic read-only DNS query can help classify address-family differences when BIND dig is available. These are examples only, not live readings; they use the reserved example domain. dig manual

dig www.example.com. A +noall +answer
dig www.example.com. AAAA +noall +answer

Also compare full DNS response status when an answer section is empty; empty output from +answer by itself does not tell you whether a name is nonexistent or a server failed. Separate a DNS mismatch from a TLS or HTTP mismatch before changing anything.

Low-risk fix: If authoritative data is correct but a cache is old, keep both old and new endpoints available while observing TTL rather than repeatedly editing the record. If the IPv6 endpoint is broken, work with the authorized operator to repair connectivity/service before considering a controlled DNS rollback. For TLS or origin-specific faults, correct the corresponding endpoint or deploy configuration through its documented rollback path.

Verify the recovery

Re-test a representative affected and unaffected route for DNS type and status, address-family connectivity, TLS for the original hostname, and the expected HTTP response/content. Record the time and which layer was fixed; a single successful browser refresh does not prove that all networks recovered. Avoid broad DNS changes if the evidence points instead to an origin, edge or cache issue.

In practice

Use the DNS → network → TLS → HTTP → browser cache ordering to eliminate explanations cheaply and reversibly. This article covers multi-layer partial outages; if the primary symptom is solely an unpublished DNS change, use A DNS change is not visible for the more specific decision tree.

A failure is not an authoritative statement that a name is absent. Real resolvers also cache resolution failures under RFC 9520; that cache and its retry/backoff policy are outside this fixed diagnostic scene. Do not interpret repeated clicks as advice to hammer a failing nameserver. Failure caching

Key takeaways

Find the earliest comparable difference, not the most convenient explanation. Identical DNS data does not establish identical connectivity, TLS or cached content. Apply only the correction justified by observations, and verify the original URL from both affected and unaffected paths.