Signal full. Right network name. The device says connected. Yet not a single page will load, and the login screen that normally appears on its own hasn't appeared at all.
This complaint almost always ends the same way: the Wi-Fi isn't broken. One setting on your device is preventing the portal from being noticed.
How your device knows there's a login page
This part is rarely explained, though knowing it makes every fix below make sense.
The moment you connect, your device quietly visits one address belonging to its manufacturer and waits for a reply it already knows by heart. Android asks a Google server, iPhones ask an Apple server, Windows asks a Microsoft one.
It reads the result like this:
| What the device gets back | What it concludes | What you see |
|---|---|---|
| Exactly the reply it expected | Normal internet | Nothing at all; it just works |
| A different reply, redirected elsewhere | There's a portal | The login page opens by itself |
| No reply whatsoever | The network is faulty | A warning icon, and no login page |
The third row is what you're experiencing. The portal is there, but your device never reaches the conclusion that it is. How portals themselves work is covered in the guide to captive portals.
The three things that most often block it
That check depends on DNS. A portal works by diverting every DNS request to its own page, and the following three stop your requests going through it.
- Private DNS (DNS-over-HTTPS). The number one cause, and the least suspected. Your DNS requests are encrypted and sent straight to the provider you chose, so the portal can't divert them. The device never learns a portal exists.
- A VPN still running. All traffic is wrapped before the network can touch it. The portal can't interrupt, and the VPN itself can't connect because you haven't logged in. Each waits on the other.
- A fixed DNS you set yourself. If you ever entered 8.8.8.8 or 1.1.1.1 manually, the effect is the same, see the guide to changing DNS.
The order to check in
Work through these in sequence. Most cases end at step two.
Turn the VPN fully off
Not merely disconnecting, but switching off "always-on" or "block connections without VPN" if present. While that's active, no traffic can reach the portal.
Turn off private DNS temporarily
On Android: Settings › Network & internet › Private DNS › Off. On iPhone, check for an installed DNS profile under Settings › General › VPN & Device Management. Turn it back on once you've logged in.
Open a plain http:// address
The key here is http, not https. An unencrypted address gives the portal room to redirect
you. Test pages such as http://neverssl.com exist for precisely this.
Forget the network, then reconnect
This forces the check to run from scratch. Reconnecting without forgetting often isn't enough, because the device reuses its earlier conclusion.
Try a private browsing window
If the portal opened here before, your browser may be holding an old copy. A private window bypasses it.
Turn off randomised MAC address
Modern phones use a device address that changes, for privacy. If you've logged in here before, the network no longer recognises you, or conversely, thinks an old session is still running. The setting sits in that network's details, usually called "Randomised MAC" or "Private address".
Don't click through certificate warnings. A security warning appearing as the portal tries to open is a sign that a redirect is happening on an encrypted connection, not permission to push past it. Dismiss it and open a plain http:// address instead. Getting used to clicking through warnings like this is exactly the habit fake networks rely on, as covered in the guide to fake Wi-Fi and evil twins.
If it still won't appear
One shortcut often works: opening the network's gateway address directly in your browser. That
address is visible in your Wi-Fi connection details, commonly 192.168.0.1 or
192.168.1.1, and on many networks the portal itself answers there.
If even that fails, the problem is most likely on the network's side rather than yours:
- The network's quota is spent or the bill unpaid. The portal still greets you, but there's nothing to pass you through to.
- The user limit is full. Portals cap simultaneous devices, and latecomers get no page, see the guide to venue Wi-Fi capacity.
- The portal service is down. Common, since portals often run on a cloud service separate from the router.
Telling these apart is simple: ask whether other visitors can currently use it. If nobody can, there's no point digging further through your phone's settings. The broader checks for when a device refuses to connect at all are in the guide to Wi-Fi connection failures.
If you own the network
This complaint consumes more staff time than it appears to, and most of it is avoidable:
- Don't force HTTPS on the portal page. The portal needs to be able to greet people over a plain connection, because that's where redirection is still possible.
- Extend the session length. A one-hour session means café guests logging in repeatedly during a single visit.
- Ask for as little as possible. Long forms raise the failure rate, and data you don't collect is data you don't have to protect, see the guide to collecting customer data.
- Provide a way out. Post a network name and backup password, or a QR code, so guests whose portal misbehaves are still served, see the guide to Wi-Fi QR codes.
The login page appears because your device runs one small check. If a VPN, private DNS, or manual DNS blocks that check, the page will never arrive on its own.
Switch all three off, open one plain http:// address, and the portal almost always appears. Once you're logged in, turn your VPN and private DNS back on, on public Wi-Fi they're exactly where they're most useful, as covered in the guide to using public Wi-Fi safely.
Frequently asked questions
Why doesn't the Wi-Fi login page appear automatically?
Your device decides to show it based on one small check it makes after connecting. If that check is blocked, usually by private DNS, a VPN still running, or a custom DNS you set yourself, the device never realises a portal exists, so the page is never displayed.
Why does opening a site give me a security warning instead?
Because modern sites use HTTPS, and the portal is trying to redirect you to its own page. That redirect can't happen on an encrypted connection without triggering a warning. The fix is to open a plain http:// address, not to click through the warning.
Is turning off private DNS risky?
Temporarily, on one network, the risk is small. What matters is turning it back on once you've logged in, since without it your DNS requests are again readable by the network you're borrowing.
