Website Not Loading on Some Networks? Diagnose It

A website that loads on your office Wi-Fi but fails on mobile data—or works for visitors on one internet provider but not another—can be difficult to diagnose. The cause may be DNS, IPv4 or IPv6 connectivity, TLS, caching, or a problem somewhere along the network path. The key is to compare results systematically instead of changing several settings at once.

This guide explains how developers and website owners in India can narrow down the cause, collect useful evidence, and decide what to investigate next. The checks are diagnostic; no single test can reproduce every visitor's network conditions.

Key takeaways

Compare the same URL from at least two networks and record the time, error, and device.
Check DNS answers, IPv4 and IPv6 separately, and the TLS connection before assuming the web server is down.
A successful HTTP status check confirms only that a particular request reached a responding server; it does not test every ISP, device, or route.
Change one variable at a time and preserve the original results so you can identify what helped.

Start by narrowing down the failure

First, establish what “does not work” means. A blank page, a browser timeout, a certificate warning, a DNS error, and an HTTP error point to different parts of the connection.

Make a small test record for each attempt:

Full URL, including https://, path, and any subdomain such as www.
Date and time, including time zone.
Network and provider, such as home broadband, office Wi-Fi, or mobile data.
Device, operating system, browser, and whether a VPN or proxy is enabled.
Exact browser message or command-line output.

Try the exact same URL on another device connected to the same network, then on the original device using a different network. This helps separate a device or browser problem from a network-specific one. If possible, ask a person on a separate connection to test without changing the URL.

A useful first distinction is whether the failure happens before an HTTP response. “Name not resolved” suggests DNS; a connection timeout suggests reachability or filtering; a TLS warning points to the encrypted connection; and a page displaying an HTTP status means a server or intermediary responded. These are clues, not definitive diagnoses.

Check DNS answers and resolver differences

DNS translates a hostname such as www.example.com into IP addresses. Different networks can use different recursive DNS resolvers, and those resolvers may have different cached answers or receive different answers because of DNS configuration. A stale or incorrect record can therefore affect some visitors while others reach the site normally.

For a domain you own or are authorized to troubleshoot, compare the answers returned on the affected network with those from another network. On a system with dig installed, you can check IPv4 (A) and IPv6 (AAAA) records:

 dig example.com A
 dig example.com AAAA

You can also use nslookup example.com where dig is unavailable. Compare the results with the records configured at your DNS provider, taking account of the relevant hostname. The apex domain and www may have separate records or use different routing.

If results differ, check the DNS provider's configuration, recent changes, record targets, and TTLs. A TTL influences how long resolvers may cache an answer; it does not guarantee that every cache updates at the same moment. Flushing a device's DNS cache can help test that device, but it will not clear a resolver cache operated by an ISP or fix an incorrect authoritative record.

If you compare against a public resolver, treat it as one comparison point, not as proof that the ISP resolver is wrong. Resolver choice can be affected by network policy, and changing DNS is not a universal fix. Record the resolver and answers used for each test.

Test IPv4 and IPv6 independently

A hostname can have both A and AAAA records. These allow clients to try IPv4 and IPv6, but the presence of an address record does not prove that the corresponding route and server configuration work for every visitor. A broken or incomplete IPv6 path can affect IPv6-capable clients, while clients using only IPv4 may appear unaffected.

Use curl to compare connections to the same HTTPS URL over each IP family:

curl -4 -sS -D - -o /dev/null https://example.com/
curl -6 -sS -D - -o /dev/null https://example.com/

These commands make a GET request and print response headers while discarding the body. An error with -6 but success with -4 is a reason to investigate IPv6 DNS, routing, firewall rules, and server or CDN support. It is not, by itself, proof of which component is at fault. Some networks or devices may not provide usable IPv6 connectivity, so a failed IPv6 test from one location is not enough to establish a site-wide issue.

If you use a CDN or load balancer, check that IPv4 and IPv6 traffic are both enabled and directed to the intended service. Avoid deleting an AAAA record simply to hide an IPv6 problem without first confirming the effect on your hosting and visitors.

Inspect the TLS connection

HTTPS uses TLS to establish an encrypted connection and authenticate the server. Failures can occur if the certificate is expired, does not cover the hostname, or is not presented with a complete certificate chain. Incorrect server configuration, an intermediary, or a device with an incorrect clock can also affect the result.

On a system with OpenSSL installed, this command can show information about the certificate presented for a hostname:

openssl s_client -connect example.com:443 -servername example.com -showcerts

The -servername option sends the hostname using Server Name Indication (SNI), which matters when a server hosts multiple sites on one address. This command is a diagnostic aid, not a complete TLS audit. Review the browser's exact certificate warning and verify the certificate, hostname, chain, and expiration in your server or hosting configuration.

If the site works on one connection but shows a certificate warning on another, compare the hostname and certificate details carefully. Do not ask visitors to ignore certificate warnings; they indicate that the browser could not verify the connection as expected.

Separate HTTP responses from network failures

Once a request reaches an HTTP server or intermediary, it can return a status such as 200, 301, 403, or 503. The status and response headers may help identify a redirect, access rule, or server-side error. An HTTP checker can provide a quick view of a response from its own testing environment. For example, you can check an HTTP status to see what response the tool receives.

That result is only one observation. It does not show that every ISP can resolve the hostname, reach the same IP address, complete TLS, or receive the same CDN response. A checker may use a different region, resolver, IP family, and network path from the affected visitor. Conversely, if a checker cannot retrieve the page, that alone does not identify the cause.

For a closer comparison from an affected device, run:

curl -v https://example.com/

The verbose output can help distinguish name resolution, connection, TLS negotiation, and HTTP response stages. Review output before sharing it publicly: URLs and headers can contain private information, especially if the request includes authentication or personal data. Do not include secrets in diagnostic commands or reports.

Investigate caching and intermediary behavior

Caching can make different visitors see different content, but it usually does not explain every connection failure. Consider several layers:

Browser cache: An older page or asset may remain stored in the browser.
Service worker: A site-installed service worker can intercept requests and serve cached responses or an offline page.
DNS cache: A device or recursive resolver may retain an earlier DNS answer until its cache expires or is refreshed.
CDN or proxy cache: A cached response may vary by location, cache key, or request headers.

Test in a private browsing window or another browser as a comparison, but remember that private browsing does not necessarily bypass service workers or network-level caches. If you operate the site, inspect CDN cache status, response headers, purge history, and cache rules for the affected URL. Purging a cache may help when stale content is confirmed, but it is not a general solution for DNS, TLS, or connectivity errors.

A practical troubleshooting workflow

Work through these steps in order and record the result of each test:

Confirm the scope. Test the same URL on the same device over the affected network and a second network. Then test another device on the affected network.
Capture the exact error. Note whether the browser reports a name-resolution error, timeout, TLS warning, or HTTP status.
Compare DNS. Check A and AAAA answers on both networks and verify the records against your DNS configuration.
Compare IP families. Use curl -4 and curl -6 to see whether the failure is limited to one family, where IPv6 is available.
Inspect TLS and HTTP. Use the browser's certificate details or curl -v, then note whether the request receives an HTTP response.
Check hosting and edge logs. If you operate the site, compare timestamps with web server, firewall, load balancer, and CDN logs. Look for requests from the affected source network and relevant edge errors.
Change one thing at a time. After a DNS, server, or cache change, repeat the same tests and note when the change was made. DNS caches and CDN behavior may not update everywhere immediately.

A simple report makes escalation more effective: include the URL, timestamps with time zone, network provider, device and browser, exact error, DNS answers, IPv4/IPv6 test results, and any request or CDN identifiers shown in the response. Redact personal information and sensitive headers.

Common mistakes

Assuming a working test proves the site works everywhere. It proves only that the tested client and path succeeded at that time.
Treating an HTTP checker as a network-wide test. It cannot reproduce every ISP, resolver, route, or device.
Changing DNS before collecting the current answers. That can remove useful evidence and may only move the problem to another resolver.
Ignoring IPv6 because IPv4 works. Compare both families when the domain publishes both address types.
Blaming the browser for a network error. Test another device and connection before drawing that conclusion.
Using a VPN as a permanent fix. A VPN can change routing and DNS, which may help isolate a path-related difference, but it can also introduce new variables. Use it only as a comparison and follow your organization's policies.
Sharing unredacted diagnostic output. Remove tokens, cookies, personal data, and private URLs before sending logs to a provider.

Conclusion

When a website is not loading on some networks, compare the failing and working paths in a consistent order: scope the issue, inspect DNS, test IPv4 and IPv6, check TLS, and determine whether an HTTP response is being returned. Keep timestamps and evidence, and use each result to choose the next test rather than treating one successful check as a complete diagnosis. If the issue appears limited to a provider or region, share the collected details with your hosting, CDN, DNS, or network provider so they can investigate the relevant path.

Website Not Loading on Some Networks? How to Diagnose It