Hotel Wi-Fi login page not showing? How to force the captive portal

You join the hotel Wi-Fi. The login page is supposed to appear. It does not. Every site you try fails, the phone says it is connected, and you have a meeting in ten minutes.

Captive portals fail more often now than they did five years ago, and the reasons are interesting: the web got more secure, and portals work by doing exactly the kind of interception that modern security is designed to prevent. Almost every failure traces back to that tension.

How a captive portal works

A portal is a network that lets you connect but not leave. Three mechanisms do the work.

DNS interception. Until you authenticate, the network answers every DNS query with the portal's own address. Ask for any hostname, get the portal.

HTTP redirection. When your browser then connects to that address expecting a website, the portal responds with a redirect to the login page instead of the content you asked for.

A walled garden. A small allowlist of destinations works before you log in: the portal itself, sometimes a payment provider, sometimes the hotel's own site. Everything else is blocked at the firewall.

Your device is not helpless in this. Phones and laptops run a connectivity check the moment they join a network, fetching a small known file from a server run by Apple, Google or Microsoft. If the response is not what it expects, the device concludes there is a portal and pops up the login sheet automatically. When that sheet does not appear, this check is usually what failed.

Why HTTPS breaks it

The redirect step only works on plain HTTP. With HTTPS, the connection is encrypted and authenticated before any content is exchanged, so the portal cannot inject a redirect without presenting a certificate for a domain it does not own. Attempting it produces a certificate warning rather than a login page, which is the browser correctly refusing to be intercepted.

Now consider that browsers default to HTTPS, most sites use HSTS to forbid plain HTTP entirely, and bookmarked and autocompleted URLs are almost always https://. The practical result is that a modern browser gives the portal almost no opportunity to redirect anything.

Which leads directly to the single most reliable fix: visit a plain http:// address on purpose. Type one with the protocol spelled out so the browser does not upgrade it. A bare IP address works well, since IP addresses rarely carry HSTS state. The portal finally gets an unencrypted request it can redirect, and the login page appears.

Fixes, in the order that works fastest

1. Open a plain HTTP address

   Type http:// explicitly. Something like http://1.1.1.1 or http://neverssl.com works because neither redirects you to HTTPS. This alone resolves most cases.

2. Use a private or incognito window

   Cached HSTS state and old redirects live in your normal browsing session. A private window starts clean, and for a host your browser previously learned to force HTTPS on, this is often the difference.

3. Turn off encrypted DNS temporarily

   If your device or browser uses DNS over HTTPS or DNS over TLS, the portal cannot intercept your lookups, so the redirect never starts. On iOS this may be a VPN style profile or a browser setting; on a laptop it is usually in the browser's security settings. Turn it off, connect, then turn it back on.

4. Disable the private Wi-Fi address for this network

   Covered in detail below. It is a per network toggle, so you are not giving up address randomisation anywhere else.

5. Forget the network and rejoin

   This re-runs the connectivity check from scratch, which is frequently all that is needed. Devices cache "this network is fine" state that survives the session expiring.

6. Check your clock

   A device whose time is badly wrong fails TLS validation on everything, including the connectivity probe and the portal's own page. An NTP time check shows the offset immediately, and it explains the otherwise baffling case where nothing secure will load anywhere.

7. Try the gateway address directly

   Many portals are served by the router itself. Find your gateway address and open http:// followed by it. This bypasses DNS entirely, which matters if DNS is the part that is broken.

Three modern features that block portals

Private and randomised MAC addresses

iOS, Android and recent Windows builds generate a different MAC address for each network you join. Portals track authenticated sessions by MAC, so a changed address looks like a brand new device that has never logged in.

Usually that just means logging in again. Sometimes it is worse: a portal that already has a session recorded for a MAC you no longer use can leave you in a state where the network thinks you are authenticated and your device does not, or vice versa, and the login page never appears because the portal believes it has nothing to ask you.

Turning off the private address for that one network resolves it. Every other network keeps randomisation, so the privacy cost is limited to a network that can already see everything you do anyway.

Encrypted DNS

DNS over HTTPS and DNS over TLS send your lookups to a resolver of your choosing over an encrypted channel. That is exactly what they are for, and it is exactly what a captive portal needs to prevent. With encrypted DNS active, the hijack step silently fails and you get connection errors rather than a login page.

Operating systems have improved at detecting a portal and temporarily suspending encrypted DNS, but the behaviour is inconsistent across versions and networks. If a portal will not appear and you use encrypted DNS, disable it, connect, then re-enable.

A VPN that connects automatically

An always on VPN tries to establish its tunnel the moment you join a network, before you have authenticated. The portal blocks it, the VPN keeps retrying, and depending on the client you either see nothing or the whole connection stalls. Disconnect the VPN, log in, then reconnect it, which is the right order anyway on a public network.

Diagnosing it properly

If the quick fixes do not work, three checks tell you which part of the chain is broken.

Is DNS being hijacked? Run a DNS lookup for a well known hostname. If it returns an address on your local subnet, such as something in 192.168.x.x, the portal is intercepting. That is the expected behaviour before authentication, and it confirms you are dealing with a portal rather than a broken network.

Where does the redirect point? Run an HTTP(S) Check against a plain http:// URL and read the redirect chain. The portal's real address appears in it. You can then open that address directly, which is useful when the automatic sheet refuses to appear.

Has the network let you out yet? Check your public IP. Before authentication it usually cannot be retrieved at all. Once it returns a normal looking address on the venue's provider, you are authenticated and any remaining problem is elsewhere.

One more thing worth knowing about conference and hotel networks: even after you authenticate, the walled garden often stays partially in place. Common ports are open and everything else is blocked. If the web works but a VPN, a game or a mail client does not, that is policy rather than fault, and a quick TCP connect test on the port you need will confirm it.

Staying safe once you are on

Captive portals are a good moment to be a little careful, because you are being asked to enter information on a page that appeared through deliberate interception.

• Never reuse a real password. If a portal asks for an email address and a password, that password should be unique and disposable. It is being sent to a venue's Wi-Fi vendor, not to a service you have a relationship with.
• Be wary of anything asking for payment details on an unencrypted page. Legitimate paid Wi-Fi uses HTTPS for the payment step. If the address bar shows plain HTTP at that point, stop.
• Do not install a certificate or a profile. A portal that asks you to install a root certificate is asking for the ability to read your encrypted traffic. Decline and use cellular data instead.
• Connect your VPN after you authenticate. That is the point where it becomes useful, and it is the right habit on any network you do not control.
• Check the network name with staff. "Free Airport WiFi" run from someone's laptop looks identical to the real one on a phone screen.

The short version

Portals work by hijacking DNS and redirecting plain HTTP, and modern devices are built to prevent both. So force a plain http:// request, use a private window, and temporarily disable encrypted DNS and any private MAC address for that network. If the sheet still refuses to appear, read the redirect chain to find the portal's real address and open it yourself. And treat whatever it asks you for with the suspicion that a page reached by interception deserves.