Wi-Fi-Only Website Failures: A Two-Network Test Plan Before You Reset Anything

Direct answer: if the same website works over mobile data but fails on Wi-Fi, the service is reachable through at least one network path. The useful question is not “which side is broken?” yet. It is what changes between the working mobile path and the failing Wi-Fi path?

Those paths can differ in public IP address, DNS resolver, proxy or VPN use, IPv4 and IPv6 availability, traffic steering, and the route taken to the site. A careful comparison can narrow the problem without prematurely blaming your router, ISP, mobile carrier, or the website.

Keep these conclusions separate:

• Mobile works: the site was reachable from one network at the time of testing.
• Wi-Fi fails: something about the Wi-Fi-side device configuration, local network, network exit, or destination treatment differs.
• DNS succeeds: the name was answered; it does not prove that the encrypted website connection will succeed.
• A VPN helps: it creates a different path; it does not identify the original fault by itself.
• A trace has asterisks: some routers may not answer diagnostic probes; it is not conclusive proof that those routers stopped your web traffic.

This article is designed as a small field test. Capture the comparison first. Change settings only after you know which comparison is meaningful.

Start with four plain-English terms

Wi-Fi is the short-range connection between your device and an access point or router. It is only the first part of the journey. Beyond it may be a home broadband provider, an office firewall, a building-wide connection, a filtering service, or a VPN.

Mobile data sends traffic through a carrier network. It normally uses a different internet-facing address and may use different DNS, routing, and policy than your Wi-Fi connection.

DNS is the naming system that helps a device find an address for a hostname such as portal.example. An A record supplies an IPv4 address; an AAAA record supplies an IPv6 address. A site may have either record type or both.

Public IP address is the internet-facing address a website can observe. It is different from the address shown inside many router apps. Addresses such as those in the private-use ranges described by the IANA private-address guidance are intended for internal networks and are not public internet identifiers. For a clearer distinction, see how private IP addresses work.

One more term is helpful: an ASN, or Autonomous System Number, identifies a network participating in internet routing. ISP, carrier, cloud, and content-delivery networks can each have ASN context. It is useful context for a support team; it is not proof that a particular network caused the failure.

The rule that makes this test trustworthy: hold everything else still

Do not compare a phone on 5G with a laptop on Wi-Fi and call that a network test. You may actually be comparing two browsers, two VPN profiles, two DNS settings, two caches, and two devices.

Instead, use this controlled baseline:

1. Write down the exact hostname that fails. app.example.com and www.example.com can use different infrastructure.
2. Use the same device, browser, and page URL on both connections.
3. Use a private browsing window where practical. This reduces the influence of older cookies, redirects, and signed-in browser state.
4. For the baseline, turn off optional consumer VPNs and proxies. If a work policy requires a VPN or managed proxy, do not bypass it; record that it is present.
5. Test Wi-Fi and then mobile data within a short time window. Record the time, time zone, and exact browser message.
6. Classify the visible result: timeout, connection reset, certificate warning, access-denied page, blank or partial page, or a page that loads normally.

That is enough to turn a vague complaint into an observation: “On the same laptop and URL, the page timed out on Wi-Fi at this time and loaded on mobile data at this time.”

Build a two-network evidence card

Before restarting a router, make a compact record for each connection. The goal is comparison, not surveillance.

On Wi-Fi, open the IP lookup tool and note the displayed public IP version, provider or network label, approximate location result, and time. Repeat on mobile data. Treat location as network context or an estimate, not proof of where you physically are. As the EFF’s IP-address overview explains, an IP address can reveal network or rough-location information without reliably revealing a person’s identity or precise address.

Do not publish the complete card in a forum. A support team may need a public IP and timestamp privately, but strangers do not need your account details, authentication links, internal hostnames, or full unredacted route output.

Run the test in the order that preserves the most evidence

1. Find out whether this is one-site or many-site behavior

On the failing Wi-Fi connection, try a few unrelated well-known sites. This is not a formal diagnosis, but it changes the next step.

• Many unrelated sites fail: investigate a broad Wi-Fi, router, DNS, or internet-access issue first.
• One hostname or one service fails: keep the focus on that exact hostname, its DNS answers, address families, path, and possible destination policy.
• Only a signed-in page fails: also consider browser state, an account-specific condition, or an application security decision. A general connectivity test alone cannot settle that question.

2. Check whether a VPN, proxy, or managed network is part of the Wi-Fi path

A VPN changes more than apparent location. It can change the public exit address, DNS behavior, route, and sometimes which IP version is used. Similarly, an office security product may proxy web connections only on a managed network.

Use the proxy check as one comparison clue, then inspect your device’s VPN and proxy settings. The result cannot detect every managed intermediary and cannot prove that no VPN exists. Its value is to prevent a mistaken assumption that the Wi-Fi path is direct.

If an approved VPN makes the site load, record that result exactly: “Direct Wi-Fi failed; Wi-Fi through the approved VPN loaded.” Do not jump to “the ISP is blocking it.” The VPN may have changed DNS, egress IP reputation, routing, or IP-family behavior.

3. Compare DNS answers for the exact hostname

Use the DNS lookup tool for the affected hostname. Look separately for A and AAAA records. If you have access to a command line, Microsoft documents nslookup as a DNS-query tool; a basic Windows comparison can be:

nslookup -type=A example.com
nslookup -type=AAAA example.com

The important point is modest: DNS answers a naming question. A valid answer does not guarantee the later connection, encryption, or page request will work.

Different DNS answers are not automatically bad. Large services can deliberately return different addresses for traffic distribution. More useful signals include a resolver timeout, a response that appears to block the hostname, no answer where another comparison produces one, or a pattern where the address family available on Wi-Fi consistently fails.

If you test an alternate DNS resolver and the page begins working, treat that as a useful comparison rather than a final diagnosis. The resolver change may have altered both name resolution and which service edge received your connection.

4. Split the question into IPv4 and IPv6

When a hostname has both A and AAAA records, a device may have two possible address families. Modern connection behavior can attempt IPv4 and IPv6 in a coordinated way to improve the chance of connecting. The IETF’s RFC 8305 guidance on Happy Eyeballs Version 2 describes this concurrent, dual-stack connection problem and why fallback behavior can mask an underlying path issue.

If your system has curl, compare the same HTTPS endpoint deliberately:

curl -4 -I https://example.com
curl -6 -I https://example.com

Interpret this narrowly:

• IPv4 succeeds and IPv6 fails on Wi-Fi: you have evidence of an IPv6-specific difference from that network to that endpoint at that time.
• IPv6 succeeds and IPv4 fails on Wi-Fi: you have evidence of an IPv4-specific difference.
• Both fail on Wi-Fi but mobile loads: return to the proxy, DNS, destination-policy, and route comparisons.
• Both tests succeed but the browser fails: browser extensions, cached state, HTTPS inspection, service workers, or application-specific behavior become more relevant.

Do not make permanent IPv6 disablement your first fix. A temporary test can be useful evidence. Permanently disabling a normal address family can hide a repairable problem and create a different one later.

5. Use route traces as hints, not as a blame map

A route trace sends probes with progressively larger hop limits and records routers that reply. On Windows, the documented command is:

tracert -4 example.com
tracert -6 example.com

Microsoft’s TRACERT troubleshooting guidance explains the TTL-based method. The limitation matters: a router can decline or rate-limit trace replies while still forwarding ordinary website traffic. Therefore, a row of asterisks is not proof that the listed hop is the failure point.

A trace is most useful when it supports an already clear pattern, such as an IPv6-only failure that repeats from the same Wi-Fi network. Redact private hostnames, customer labels, and other sensitive information before sharing output.

Use this result-to-action guide

Two realistic ways this workflow helps

Scenario: a home user cannot open a healthcare portal on home Wi-Fi

The portal loads on the same laptop when the user turns off Wi-Fi and uses mobile tethering. Other websites work at home. The user records both public network contexts, checks the hostname’s A and AAAA records, and finds that the Wi-Fi IPv4 request succeeds while the IPv6 request repeatedly times out. That does not prove the portal “blocks IPv6.” It gives the ISP or portal operator a focused observation: an IPv6-specific failure from one access path, with timestamps and the exact hostname.

Scenario: everyone in an office sees an access-denied page for one vendor dashboard

Staff can reach the dashboard from mobile data, but several employees see the same explicit denial from office Wi-Fi. The office path is managed, and the proxy comparison suggests an intermediary is present. This is not a reason for every employee to reboot Wi-Fi. The evidence points toward an organization egress IP, proxy policy, or vendor-side allow-list or security decision. IT and the vendor can compare the office network context and timestamps privately.

Common myths that waste time

• “If mobile works, my Wi-Fi router must be broken.” Not necessarily. The difference may be DNS, a proxy, IPv6, the public network exit, routing, or a destination rule.
• “A successful DNS lookup proves the website is up.” No. DNS is an earlier naming step, not a complete website transaction.
• “Changing DNS proves my old DNS was the root cause.” Not always. It can also change traffic steering and the service edge you reach.
• “A VPN proves my ISP intentionally blocked the site.” No. A VPN changes several variables at once.
• “The IP location displayed by a tool is my verified physical location.” No. It is network context or an estimate and should not be treated as a verified address.
• “Asterisks in a traceroute identify the bad router.” No. Diagnostic probes can be filtered or deprioritized independently of normal forwarding.
• “I should disable IPv6 forever if IPv4 works.” No. Use a temporary comparison to report a family-specific issue instead of hiding it permanently.

When advanced routing evidence matters—and when it does not

Most home users do not need to investigate BGP or RPKI. Those topics become relevant when a network operator or hosting team is examining a persistent, route-specific reachability problem.

A Route Origin Authorization, or ROA, is a cryptographically signed authorization for an ASN to originate a prefix, as defined in ARIN’s RPKI terminology. RPKI validation can inform routing decisions, but an RPKI state alone does not explain every partial outage. Reachability can also vary with announcements, policies, propagation, peering, and the destination service. The BGP prefix-origin validation specification and RIPE NCC’s RPKI tools and resources are appropriate references for operators, not instructions for a household to alter routing records.

For a public service operator, independent observations may be useful. RIPE Atlas built-in measurements include IPv4, IPv6, DNS, SSL/TLS, HTTP, ping, and traceroute options. They can help show whether a symptom appears from more than one outside network. They still cannot exactly reproduce a particular customer’s browser, DNS resolver, VPN, and access-network setup.

What to send when you escalate

A short report is more useful than a long accusation. Send this privately to the responsible ISP, workplace IT team, website owner, host, or CDN support channel:

1. Exact affected hostname and URL path, if relevant.
2. Date, time, and time zone for at least one failed Wi-Fi attempt and one successful mobile attempt.
3. Exact error message or a redacted screenshot.
4. Device, operating system, browser or app, and whether a VPN, proxy, or managed security product was active.
5. Whether other unrelated sites work on Wi-Fi.
6. Wi-Fi and mobile public-network context from the IP lookup tool, shared only with the responsible party when needed.
7. A and AAAA DNS results and whether IPv4 versus IPv6 testing changed the outcome.
8. A redacted trace only if it adds a repeatable, relevant clue.

If you need provider-registration context for an observed public address, use the WHOIS lookup tool. Use it to identify an organization or registry context—not to identify a household, employee, or individual.

Privacy boundaries and what the future changes

Network diagnosis works best when it uses the minimum evidence needed. A public IP can be dynamic, shared, associated with an organization, or used through a proxy or VPN. It is not a person’s name, a reliable street address, or proof of who took an action. Keep account numbers, passwords, session links, internal device names, and full unredacted traces out of public posts.

Over time, this kind of comparison will become more important, not less. Devices can use IPv4 and IPv6, encrypted DNS, private relay features, VPNs, managed inspection, and multiple application protocols. Websites can select different delivery edges and security treatment for different network paths. The durable skill is to write down what happened before claiming why it happened.

For future checks, return to the IP tools collection and repeat the same small evidence card. A consistent method is more valuable than a large collection of unrelated screenshots.

Conclusion

A website that fails only on Wi-Fi is a comparison problem first. Keep the device and hostname constant, record each network exit, check for a proxy or VPN, compare DNS answers, test IPv4 and IPv6 separately when possible, and read route traces with caution. The result may not immediately name the responsible network, but it will replace guesswork with evidence that a support team can investigate.

Frequently asked questions

What does it mean if a website works on mobile data but not Wi-Fi?

It means the site was reachable through the mobile network path at the time you tested it. Wi-Fi may differ in public IP address, DNS resolver, proxy or VPN use, IPv4/IPv6 behavior, routing, or destination-side treatment. The symptom alone does not prove which difference is responsible.

How do I test Wi-Fi and mobile data fairly?

Use the same device, browser, exact hostname, and short time window. Record the error text on Wi-Fi, then test the same URL on mobile data. Note whether an optional VPN or proxy is active, and avoid changing several settings before recording the baseline.

Does a successful DNS lookup mean the website should open?

No. DNS can successfully return an address while a later connection, encryption step, or application request fails. DNS is important evidence, but it is only one stage of reaching a website.

How can I check whether IPv6 is the difference without disabling it permanently?

Check whether the hostname has both A and AAAA records, then compare the same endpoint over IPv4 and IPv6 where your device supports that test, such as curl -4 and curl -6. Report a repeatable family-specific result rather than permanently turning off IPv6.

Do asterisks in a traceroute prove that router is broken?

No. Routers can ignore or limit trace probes while continuing to forward normal web traffic. Treat trace output as one clue and correlate it with the actual website result, DNS behavior, and IPv4/IPv6 comparison.

What should I send to my ISP, IT team, or the website owner?

Send the exact hostname, timestamps and time zone, error text, device and browser details, VPN/proxy state, whether mobile succeeds, public-network context shared privately, DNS A/AAAA results, and any repeatable IPv4-versus-IPv6 result. Include a redacted trace only when it adds useful evidence.