A website that loads on home broadband but fails on mobile data—or works in one office but not another—can be difficult to diagnose. The cause may be DNS, an IPv4 or IPv6 path, TLS, caching, or a connectivity rule on the affected network. The key is to compare the same site across networks and test each layer in a sensible order.
This guide walks developers and website owners through that process, explains what common tests can and cannot tell you, and shows how to collect useful evidence before changing server or network settings.
Key takeaways
- Compare the same URL, device, browser, and time period across at least two networks.
- Check DNS answers, IPv4 and IPv6 separately, then investigate TLS and HTTP responses.
- A successful HTTP status check only describes the checker’s own route to the site; it cannot rule out problems on a visitor’s network.
- Record exact errors and test results before changing DNS, CDN, firewall, or server settings.
Start by defining the failure
First, establish what “does not work” means. Ask the affected person to record the full URL, the time of the problem, the network type (for example, office Wi-Fi, home broadband, or mobile data), the device, and the exact browser error. Avoid sharing private information such as account details or session-bearing URLs.
Check whether the failure affects:
- One page or every page on the domain.
- One device or multiple devices on the same network.
- One browser or multiple browsers.
- The domain name, a subdomain, or a third-party resource used by the page.
If possible, test the same device on a second network. This reduces the number of variables: if the site works on mobile data but not Wi-Fi, the device and browser are less likely to be the only cause. It does not prove the Wi-Fi network is at fault, but it helps narrow the investigation.
Troubleshoot in layers
1. Check basic connectivity
Confirm that the affected device can reach other websites and that it is not behind a captive portal, such as a hotel or public Wi-Fi sign-in page. Check whether a VPN, proxy, security product, or managed-network policy is enabled. These can change DNS resolution or route traffic differently.
If only one site fails, note whether the failure is immediate or follows a delay. A timeout may indicate that a connection is not completing, while a browser message about a certificate points toward a different layer. Error wording varies by browser, so save the exact text rather than relying on a paraphrase.
2. Compare DNS answers
DNS translates a hostname such as example.com into IP addresses. Different networks or DNS resolvers may return different answers, especially when a site uses a CDN or geographically distributed infrastructure. Different answers are not automatically wrong; investigate whether the answer is expected and whether the returned address is reachable.
On macOS or Linux, try:
dig example.com A
dig example.com AAAA
On Windows PowerShell, try:
Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA
Repeat the checks on the working and failing networks, ideally close together in time. Compare the A records (IPv4), AAAA records (IPv6), response status, and resolver shown by the tool. If a lookup fails only on one network, investigate that network’s DNS resolver, filtering, or cache before changing the domain’s records.
A public DNS lookup website or command-line query can provide another comparison, but it may use a different resolver and location from the affected user. It does not show exactly what every device or ISP will receive.
3. Test IPv4 and IPv6 independently
A hostname may publish an A record for IPv4, an AAAA record for IPv6, or both. A device and network that support IPv6 may prefer an IPv6 route. If that route is misconfigured or unreachable while IPv4 works, some users may see delays or failures even though other networks load the site normally.
Use curl to compare connection attempts:
curl -4 -I --connect-timeout 10 https://example.com/
curl -6 -I --connect-timeout 10 https://example.com/
These commands ask curl to use IPv4 and IPv6 respectively and request response headers. A failed IPv6 test is meaningful only if the test machine and network have IPv6 connectivity; it does not by itself prove the website is broken. Compare results from a network known to support each protocol, and review the DNS records and hosting or CDN configuration before removing an address record.
4. Check TLS and the certificate path
HTTPS begins with a TLS handshake before the browser can receive an HTTP response. Certificate expiration, a hostname mismatch, an incomplete certificate chain, an unsupported protocol or cipher configuration, or an incorrect server configuration can prevent that handshake. Network appliances that inspect or filter encrypted traffic may also affect what a user sees.
If the connection reaches the server, inspect the certificate details in the browser. From a terminal, this command can show information about the TLS connection and certificate presented for the hostname:
openssl s_client -connect example.com:443 -servername example.com
The -servername option supplies the hostname for Server Name Indication, which matters when a server hosts multiple sites. This command is a diagnostic, not a complete certificate-validation test; interpret its output carefully and compare it with a browser’s certificate details. Do not tell users to bypass certificate warnings as a workaround.
5. Separate HTTP responses from connection failures
When TLS succeeds, the server or an intermediary may return an HTTP status such as 200, 301, 403, or 500. A status response is useful evidence, but it does not explain every failure: a browser can fail before an HTTP request reaches the site, and an HTTP checker tests from its own network and location.
You can use the HTTP status checker to see whether it receives an HTTP response from its vantage point. If it reports a response while a visitor still cannot load the site, continue investigating the visitor’s DNS, IP version, route, filtering, and TLS path. A successful check does not prove the site is reachable from every ISP or network.
6. Consider caches and CDN behavior
A browser, operating system, local DNS resolver, ISP resolver, or CDN may retain data for a period of time. As a result, two networks can temporarily resolve a hostname differently, or a device may continue using an old answer after a DNS change. Browser cache can also preserve stale page assets, although it is less likely to explain a connection timeout before the page begins loading.
Compare the DNS answers and timestamps first. If a change was recently made, check the record’s TTL and the authoritative DNS configuration, then allow for resolver caching rather than repeatedly changing records. A private browser window can help test some browser state, but it does not clear system DNS caches or change the network route.
For CDN-backed sites, check whether the failure is limited to particular paths, regions, or edge locations. Review CDN logs and origin health where available. Avoid assuming that a different IP address is an error: CDN responses can legitimately vary by resolver, location, or configuration.
A practical comparison workflow
Use this sequence to collect evidence without making premature changes:
- Write down the exact URL and error. Include time, device, browser, and network type.
- Test the same device on another network. Keep the browser and URL consistent.
- Check DNS on both networks. Compare A and AAAA answers and note the resolver.
- Test IPv4 and IPv6 separately. Only interpret an IPv6 failure if that network supports IPv6.
- Check TLS. Compare the browser certificate details and, where appropriate, terminal output.
- Check for an HTTP response. Use browser developer tools or
curl; treat remote checker results as one network’s observation. - Review server-side evidence. Check web server, CDN, firewall, and application logs for the affected time and source where available.
- Change one thing at a time. Re-test from both networks and record what changed.
For a quick header request, curl -I is convenient, but some servers handle HEAD requests differently from normal page loads. If results are surprising, try a regular request and inspect the browser’s Network panel as well.
Common mistakes
- Treating one successful check as proof of universal availability. A status checker or test from your own office only confirms that one route worked at that time.
- Changing DNS records before comparing answers. This can introduce additional propagation and caching variables without addressing the cause.
- Ignoring AAAA records. A working IPv4 route does not guarantee that the IPv6 route is healthy.
- Assuming every timeout is a server outage. The request may be blocked or lost on the device’s network path before it reaches the server.
- Confusing a browser cache with DNS cache. Clearing one does not necessarily clear the other.
- Disabling a firewall or certificate validation to “test.” This weakens protection and may hide the real issue. Use controlled, authorized diagnostics instead.
- Comparing different URLs or times. Redirects, changing CDN conditions, and deployments can make results hard to interpret if the tests are not comparable.
Recommended troubleshooting practices
Keep a simple incident record containing the URL, timestamp with time zone, network type, DNS answers, IPv4 and IPv6 results, TLS error details, HTTP response if any, and relevant server logs. Redact tokens, personal data, and other sensitive values before sharing the record.
For a site you manage, verify that DNS records point to the intended service, the TLS certificate covers the hostname and is correctly served, and both advertised IP versions are supported by the deployed infrastructure. Review access-control rules for unintended blocks, and use monitoring from more than one network or region when availability across networks matters.
Do not treat a URL parser or an HTTP status tool as a replacement for testing real connectivity. Each tool observes only the parts of the request it can reach, from its own environment.
Conclusion
When a website is not loading on some networks, compare the failing and working paths methodically. Start with the exact error and DNS, then test IPv4 and IPv6, examine TLS, and distinguish connection failures from HTTP responses. Careful, repeatable comparisons make it easier to identify whether the issue lies with the site, a network, or an intermediary—without making changes that obscure the evidence.