Quick Answer
Open a new tab and go to a plain HTTP address like http://neverssl.com or http://example.com. Captive portals often fail to auto-launch on HTTPS sites, and forcing a plain HTTP request usually triggers the login page to appear immediately.
Why This Happens
Public networks in hotels, airports, and cafes use a captive portal, a login or terms-of-service page that’s supposed to intercept your first web request and redirect you to it. ChromeOS normally detects this automatically and pops up a portal notification, but that detection relies on catching an unencrypted HTTP request. If your browser only tries to load HTTPS sites (which is now the default almost everywhere), there’s nothing for the portal to intercept, so it never appears and the connection looks “connected” while nothing actually loads.
Fix Steps
Step 1: Try a plain HTTP site
Open a new tab and type http://neverssl.com directly (not https). This site is intentionally built without HTTPS specifically so captive portals can intercept it, and it usually forces the login page to appear right away.
Step 2: Check for a portal notification
Look at the status area in the bottom right for a notification saying “Sign in to network” or similar. ChromeOS sometimes detects the portal correctly but the notification gets dismissed or missed, so clicking the Wi-Fi network name again can bring it back.
Step 3: Forget and rejoin the network
Click the network, select “Forget,” then rejoin it fresh. This resets ChromeOS’s portal detection state and often triggers the login page on the new connection attempt.
Step 4: Disable “Always use secure connections” temporarily
Go to Settings > Privacy and security > Security, and check whether “Always use secure connections” is forcing all requests to HTTPS. If enabled, temporarily disabling it can allow the portal-detection request through, though remember to turn it back on afterward.
Step 5: Try a different browser tab type
Open an Incognito window and try loading a plain HTTP page there. Extensions and cached redirects sometimes interfere with portal detection in a regular window but not in Incognito.
Step 6: Restart the Chromebook on the network
If nothing loads the portal, restart the Chromebook while still in range of the network. A fresh connection attempt after boot sometimes triggers detection that a live reconnect doesn’t.
Still Not Fixed?
If neverssl.com and a network forget/rejoin both fail to bring up a login page, ask venue staff for the exact portal URL, since some public networks have a broken or misconfigured captive portal that no client-side workaround can fix. If the connection shows as joined but no page loads at all, even the portal test page, see our guide on a Chromebook connected but with no internet.
FAQ
Why does this happen more often now than a few years ago?
Browsers and websites have shifted almost entirely to HTTPS by default, which is good for security but breaks the traditional way captive portals detect a new client, since that detection depends on an unencrypted HTTP request going out first.
Is neverssl.com safe to use?
Yes, it’s built specifically for this purpose and intentionally serves no HTTPS version, so it’s a normal and expected way to trigger portal pages, not a workaround that carries any real risk.
Does this affect every public Wi-Fi network?
No, well-configured captive portals detect the connection correctly regardless of HTTPS usage. This issue only shows up on portals that specifically rely on catching an HTTP request.
