A website that opens on office Wi-Fi but fails through mobile data presents a useful clue. Investigating network-specific website failures means comparing the paths visitors actually use, not just checking whether DNS records look correct. Different networks can reach different addresses, IP versions, or content delivery servers.
The goal is to identify which group of requests fails and what those requests share. This guide focuses on destination selection and source-network policy. It goes beyond basic connectivity checks to distinguish resolver differences from IPv6 faults, regional delivery problems, and access restrictions.
Define the Failure Before Comparing Networks
“The domain does not work” can describe several unrelated problems. Record the exact hostname, requested page, time, and visible error. A failed name lookup requires different evidence than an access-denied page.
- Name lookup failure: The browser cannot obtain a usable destination address.
- Connection timeout: The connection attempt receives no timely response.
- Certificate warning: The server responds, but its identity or trust checks fail.
- HTTP error: The web service returns an error such as 403 or 502.
- Partial page: The main page loads, but another hostname fails to deliver required files.
Compare the same full address on both networks. The bare domain and its www hostname may follow different paths. Redirects can also send visitors to another hostname.
Use one device across two approved connections when practical. Keep its browser settings unchanged. Record VPN, proxy, and browser secure-DNS settings because they can alter the comparison.
Build a Destination and Network Comparison
For network-specific website failures, a small comparison table is more useful than repeated browser refreshes. Capture a successful request and a failed request close together.
| Evidence | What to Record |
|---|---|
| Source network | Office, mobile carrier, home ISP, or approved remote test location |
| DNS path | Configured resolver and any browser DNS override |
| Answer | IPv4 addresses, IPv6 addresses, aliases, and remaining cache lifetime |
| Actual connection | Destination address and IP version used by the request |
| Outcome | Lookup error, timeout, certificate issue, or HTTP status |
| Delivery evidence | Request identifier or edge location, when the provider exposes one |
Browser developer tools can often show the remote address and response headers. However, available details vary by browser and connection method.
Do not assume that different addresses prove a fault. Large websites intentionally direct visitors to different servers. Conversely, the same public address can route different networks to different physical locations.
Separate DNS Cache Divergence From Intended Answers
A recursive resolver looks up DNS answers for clients and caches them. An authoritative server publishes the domain’s records. Compare both layers before editing the zone.
Check the affected network’s resolver, an approved comparison resolver, and the authoritative servers. Record A records for IPv4 and AAAA records for IPv6. Follow CNAME records, which point one hostname to another.
A time to live, or TTL, controls how long a resolver may cache an answer. Negative answers can also remain cached. Changing a record does not immediately erase those stored results.
Different answers can also reflect intentional geographic routing or internal DNS policy. An office resolver might return a private address while public resolvers return a public address.
Cloudflare’s overview of DNS resolution explains these roles. For response-code interpretation, see our guide to NXDOMAIN and SERVFAIL differences.
Avoid treating “propagation” as a universal waiting period. Ask which record changed, which cache retains the previous answer, and whether authoritative servers agree.
Check DNSSEC and ISP Resolver Behavior
DNSSEC adds signatures that let validating resolvers verify DNS data. A broken trust chain can make one resolver reject an answer while another returns it.
This difference can resemble an ISP outage. Yet switching resolvers may only hide the underlying fault. Compare validation results before changing any production settings.
- Check whether failures occur only through validating resolvers.
- Review signature validity and the parent domain’s delegation signer, or DS, record.
- Confirm that the registrar’s DS record matches the active DNS signing configuration.
- Ask the DNS provider to examine inconsistent authoritative responses.
Do not disable validation as a routine fix. Repair the trust chain with the responsible provider. Cloudflare’s DNSSEC explanation describes how those checks work.
ISP resolvers may also apply security filtering or encounter upstream reachability faults. Compare the same query type and time across resolvers. A successful public-resolver query does not prove the ISP deliberately blocks the domain.
Browser secure DNS may bypass the operating system’s resolver. Confirm the browser’s actual lookup path before drawing conclusions from command-line tests.
Test IPv4 and IPv6 as Separate Website Paths
A working IPv4 service does not prove that IPv6 works. A mobile carrier may prefer IPv6, while an office connection reaches the same hostname over IPv4.
Where curl supports these options, compare these requests from each affected network. Replace the example hostname with one you administer.
curl -4 -I --connect-timeout 10 https://www.example.com/
curl -6 -I --connect-timeout 10 https://www.example.com/These commands request response headers. Some applications handle header-only requests differently, so compare a normal browser request too. A network without IPv6 connectivity cannot provide a meaningful end-to-end IPv6 test.
If only IPv6 fails, inspect the AAAA destination, routing, firewall policy, and web listener. Also check whether that destination presents the correct certificate.
Our guide to live certificate checks covers destination-specific certificate evidence.
Do not disable IPv6 across the business as a first response. Establish whether the service advertises an unusable IPv6 destination or the source network lacks a working path.
Correlate CDN Edges With Failed Requests
A content delivery network, or CDN, serves visitors through distributed edge locations. Network-specific website failures can follow one edge even when DNS and the origin server appear healthy.
Compare successful and failed requests using provider request identifiers, timestamps, and edge details. The origin is the backend server that supplies content to the CDN.
- One edge may fail to connect to the origin.
- Regional routing may lead some visitors through a faulty path.
- An edge may hold stale content or a cached error.
- Different edges may receive inconsistent security or certificate configuration.
The same destination IP does not exclude an edge problem. Anycast routing lets multiple locations advertise the same address.
Avoid testing HTTPS by simply replacing the hostname with an IP address. That changes identity checks and virtual-host selection. Controlled destination tests should preserve the hostname and certificate validation.
Do not expose a protected origin just to bypass the CDN. Use provider diagnostics or an approved, restricted test path instead.
Review Geographic and Source-Network Policies
A 403 response proves that an HTTP service answered. It does not identify which security rule rejected the request.
Review CDN, firewall, and application logs for the affected request. Look for geographic restrictions, address reputation checks, rate limits, and rules targeting hosting or VPN networks.
Shared public addresses complicate this review. Many mobile subscribers or office users may share one outward-facing address. Their combined activity can trigger a threshold.
Geographic databases can also classify an address differently from its user’s actual location. Compare the source address in service logs with the policy decision.
If a rule caused the failure, correct its scope rather than disabling the whole protection layer. Test any exception narrowly and define when to remove it.
Escalate With Evidence, Not a Propagation Guess
Before changing DNS, identify the failed layer. Different answers suggest resolver or routing-policy investigation. Matching answers with IPv6-only failures point elsewhere. Edge-specific errors require delivery-provider evidence.
Send the responsible provider a concise comparison: timestamps with time zones, source networks, destination addresses, IP versions, response codes, and request identifiers. Share public addresses and logs through an appropriate private channel.
Professional remote assistance can help when network-specific website failures span DNS, hosting, and security providers. Tech Rescue Ops LLC can help organize the evidence and coordinate targeted checks without broad security exceptions or unnecessary production changes.