RoamGauge › Guides

Wi-Fi says connected. Nothing loads.

Full bars, a checkmark next to the network name, and a browser that spins forever. This is four separate faults wearing one symptom, and the fix for each is different. Here is how to tell them apart in the order that costs you the least time.

The 30-second triage

Open a browser and go to http://neverssl.com. Type the http:// yourself — this only works over plain HTTP, because an HTTPS request cannot be intercepted and redirected without a certificate error.

Cause 1: the captive portal has not been completed

The most common cause anywhere with guest Wi-Fi, and the easiest to miss, because modern phones are good at hiding it. iOS quietly probes a known URL when it joins a network; if the answer is not what it expects, it pops the sign-in sheet. Sometimes that sheet gets dismissed, fails to appear, or appears and silently fails to submit.

Fix: open http://neverssl.com, complete the sign-in, and do it before starting a VPN. A VPN connecting on join will often prevent the portal from ever showing.

Cause 2: DNS is broken, filtered or intercepted

The route out is fine, but names are not turning into addresses. Three flavours:

• The resolver is dead. The network handed you a DNS server that is not answering. Everything fails, immediately, with a name error rather than a timeout.
• DNS is being intercepted. The network transparently redirects every port 53 query to its own resolver, whatever you configured. Usually harmless, occasionally the reason a specific hostname will not resolve.
• DNS is being filtered. A category filter — common in hotels, schools and on corporate guest Wi-Fi — returns a block page or nothing at all for whole classes of domain.

Fix: try an address directly. http://1.1.1.1 in a browser skips DNS entirely; if that loads and names do not, you have found your fault. Setting a public resolver like 1.1.1.1 or 8.8.8.8 in Wi-Fi settings fixes a dead resolver, but note that it does not defeat transparent interception — those queries are redirected before they leave the building. Encrypted DNS (DoH/DoT) does get past interception, when the network allows it out.

Cause 3: an IPv6 address with no IPv6 route

The subtle one, and the one that produces the most maddening symptom: some things work and others hang for thirty seconds before falling back.

Your phone has been given a global IPv6 address, so it believes IPv6 works and tries it first for any site that publishes an AAAA record. But the network never actually routes IPv6 anywhere. Every connection to a dual-stack site — which is most large sites — stalls until the happy-eyeballs timer gives up and retries over IPv4.

Fix: there is no clean client-side fix on iOS, which does not expose a per-network IPv6 toggle. The practical answers are to use a VPN (the tunnel carries its own routing and sidesteps the broken path entirely) or to tether. It is worth recognising, though, because it is otherwise indistinguishable from "the Wi-Fi is just slow" and no amount of reconnecting will improve it.

Cause 4: no usable address at all

DHCP did not answer, so your device gave itself a link-local address — 169.254.x.x on IPv4. You are associated with the access point and have no path beyond it. Related: a network so heavily NATted that the address you were given is inside the carrier-grade range 100.64.0.0/10, which works for browsing but breaks anything expecting an inbound connection.

Fix: forget the network and rejoin, which forces a fresh DHCP request. If it recurs, the venue's DHCP pool is likely exhausted — a genuinely common failure in a full hotel — and there is nothing you can do from the phone. Tether.

Why this is hard to diagnose by hand

Every cause above produces some version of "it says connected and nothing works", and a phone deliberately hides the layer where they differ. You cannot see your DNS servers without digging, you cannot see whether IPv6 has a route, and you cannot tell a filtered port from a slow one by waiting.

RoamGauge runs all four checks at once and names the fault. It reads your address, gateway and DNS servers, detects a captive portal and offers you the sign-in link, tests the system resolver against a known-good one to catch filtering and interception, and checks whether an IPv6 address actually has an IPv6 route behind it. Then it tells you what to do — in a sentence, not a packet dump.