IPv6 settings to compare when pages fail on one network
Checking Whether the Router Shows IPv6 as Active
The router’s internet status page provides the initial clue when pages load on one network but not another. Opening the admin panel through a browser, typically via addresses like 192.168.0.1 or 192.168.1.1, reveals sections labeled WAN, Internet Status, or IPv6. From there, the display indicates whether IPv6 is connected, disconnected, or left unconfigured. A disconnected or address-failing IPv6 status suggests the failing network likely relies on IPv6 for certain sites, while the working one falls back to IPv4. Modern routers often come with IPv6 enabled, yet whether the connection actually works depends on the internet service provider. A valid IPv6 address and gateway appearing in the router status mean the network fully supports IPv6, so the trouble could lie somewhere else.
When the interface shows no IPv6 address or just a blank field, the network may not support the protocol at all, which can make pages hang if a site tries contacting the device through IPv6 first. That admin screen becomes the first clear piece of evidence about which protocol version is genuinely live.
Comparing DNS Settings Between the Two Networks
DNS setup often varies between a working network and a failing one, especially with one side using automatic ISP-provided DNS while the other relies on a public resolver. On the problematic network, a look inside the device’s Wi-Fi settings for DNS configuration reveals whether any address has been entered manually. Contrasting those listed DNS addresses with the ones on the working side helps identify a discrepancy. When no custom DNS entry exists, the failing network falls back to the router’s default, which may struggle to resolve some domains over IPv6.
A common fix is to switch both networks to the same public DNS resolver, such as 8.8.8.8 and 8.8.4.4 for IPv4 or 2001:4860:4860::8888 for IPv6. After changing the DNS on the failing network, clearing the browser cache or restarting the browser before reloading the page shows whether the original DNS server was the bottleneck. Keeping the same DNS on both networks removes one variable and makes future comparison easier.
Inspecting IPv6 Address Assignment and Prefix Length
After confirming the router shows an active IPv6 connection, the next step is to check how the device receives its IPv6 address. On a Windows computer, opening the command prompt and typing ipconfig reveals the IPv6 Address line under the active network adapter. On a phone, the Wi-Fi details screen shows a field labeled IP Address or IPv6 Address. Comparing the address prefix with the one on the router’s IPv6 status page indicates whether the device has a global unicast address starting with 2001 or 2xxx rather than a link-local address starting with fe80. A global IPv6 address on the device combined with persistent page failures points to a prefix-length mismatch as a likely cause. A prefix length of /64 is standard, while a /128 prefix may indicate a point-to-point link that some home routers handle incorrectly.
On the router admin page, a field called IPv6 Prefix Length, Subnet Prefix, or Delegated Prefix shows the current value. A prefix length that differs from what the ISP assigns suggests the router may be splitting the address space incorrectly, causing some connections to time out. Resetting the router’s IPv6 settings to obtain the prefix automatically from the ISP often resolves this mismatch.
| What to Check | Visible Sign or Label | Next Action |
|---|---|---|
| Router IPv6 status | Connected or Disconnected label | If disconnected, contact ISP or check modem compatibility |
| DNS server addresses | IPv4 and IPv6 DNS fields in Wi-Fi settings | If blank or ISP default, switch to a public resolver on both networks |
| Device IPv6 address | Starts with 2001, 2xxx, or fe80 | If fe80 only, restart the router or check prefix length in DHCPv6 settings |
Testing IPv6 Reachability and Fallback Behavior
Instead of guessing which protocol the failing page uses, a quick reachability test from the device reveals the situation. Opening a browser and visiting a site like test-ipv6.com or ipv6-test.com shows whether IPv6 is working end to end and whether the device can reach IPv4-only sites as a fallback. A test result showing IPv6 as broken but IPv4 as working indicates the failing page may be trying to load resources over IPv6 while the network cannot route them. In that case, disabling IPv6 temporarily on the router or device confirms whether IPv6 is the cause. For a long-term fix, checking whether the router supports a feature called DNS64 or NAT64, which translates IPv6 requests to IPv4 destinations, provides a path forward. A router that does not support that feature, combined with an ISP that does not offer a dual-stack connection, makes keeping IPv4 as the primary protocol on devices that visit a wide range of sites the safest habit.
After making any protocol or DNS change, testing the same page on both networks confirms consistency. Keeping a saved screenshot of the router status and DNS settings from both networks gives a repeatable reference for future troubleshooting.