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

Example — map symptoms to the layer to examine. These are hypothetical observations, not monitored incidents.

The table helps choose the next observation, not an automatic remedy. A record being visible in DNS tells you nothing about whether TCP, TLS or the web application works.

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.