Captive portal not showing? Fixes for the WiFi login page

A guest tells the bar staff the WiFi does not work. Their phone has joined the network and shows full bars, and nothing loads. In most cases like this the captive portal never appeared, so the phone is sitting in the walled garden waiting for a sign-in nobody asked it for.

This guide is for venue owners and the people who set up their WiFi. It works through the causes in the order worth checking, with the setting to look at for each. What is a captive portal? explains the mechanism in full: the phone sends a plain HTTP test request as it joins, the network redirects that request, and the phone opens the sign-in page. Each fault below breaks one link in that chain.

If you are a guest trying to get online

If you are sitting in a cafe or hotel with a phone that has joined the WiFi and will not load anything, try these in order.

1. Open your browser and go to http://neverssl.com. It never uses HTTPS, so the network can swap it for the login page.
2. Forget the network in your WiFi settings and join it again, so the phone runs its automatic check from scratch.
3. Pause any VPN or ad blocker until you have signed in, then switch it back on.
4. On an iPhone, if it says the network is not compatible with Private Relay, go to Settings, Wi-Fi, tap the More Info button next to the network and turn off Limit IP Address Tracking for that network, as Apple's Private Relay guide describes. If you dismissed the login screen with Without Internet, forget the network and join it again to bring the Welcome screen back.
5. On an Android phone, if the network details say "Private DNS server cannot be accessed", the WiFi is blocking the encrypted DNS service your phone is set to use. Set Private DNS to Automatic in your network settings while you use this network.
6. If none of that works, tell the staff. The fault is probably in the venue's network settings, and the rest of this guide is for whoever looks after them.

Start with who it fails for

Before changing any settings, find out how widespread the problem is. The pattern of failures points at the cause faster than any single test.

If the fault started after a change, look at that change first. The walled garden and the portal address are the settings most often edited by mistake.

The guest opened an HTTPS site first

A network can only redirect a request it can read. A plain HTTP request is readable, so the gateway can answer it with the portal. An HTTPS request is encrypted and checked against the site's certificate, so a gateway that answers in the site's place produces a certificate warning, and sites that use HSTS refuse to load over plain HTTP at all. Nearly every home page, search engine and app now uses HTTPS.

Usually this does not matter, because the phone's own test request is plain HTTP and opens the portal before the guest has typed anything. It matters when that automatic check has been missed or blocked for one of the reasons below and the guest then opens a browser. They see a privacy warning, a page that cannot be reached, or a spinner, and decide the WiFi is broken.

The guest's fix is to open an address that starts with plain http://. http://neverssl.com is built for this: it never uses HTTPS, so the network can redirect it to the portal. Printing that address under the network name on the table card saves staff from explaining it. The network's fix is whichever cause below stopped the automatic check.

The walled garden lets the test address through

The walled garden is the list of hosts a guest can reach before signing in. It should hold the portal's own address and the hosts the sign-in page loads from, and nothing else. The mistake that hides the portal is adding an operating system's test address to it, often while chasing a different fault, or adding a whole domain such as *.apple.com, *.gstatic.com or *.google.com because one file on the page came from there.

When a phone's test request reaches the real server, it gets the reply it expects and decides the network is open. No sign-in window opens, and the guest is left in the walled garden with no internet and no portal. The failure is usually limited to one platform: iPhones stop seeing the portal after someone allows captive.apple.com or a broad Apple domain, and Android phones after connectivitycheck.gstatic.com or a broad Google domain goes in.

Do not add these test hosts to the walled garden to make the check pass: a check that passes before sign-in is what stops the login window from opening. Google Fonts files come from fonts.gstatic.com, which is why a broad *.gstatic.com entry turns up so often. CaptiFi's sign-in page loads its fonts from fonts.googleapis.com and fonts.gstatic.com, so add those two by name, remove the test hosts and any wildcard that covers them, and test again with a phone that has never joined the network.

The walled garden is missing a host the page needs

The opposite fault shows as a sign-in window that opens and then stays blank, spins, or reports that the page cannot be reached. The redirect worked, but the page itself, or a file it loads, is blocked because its host is not in the walled garden.

Every external portal publishes the hosts it needs, and they vary by hardware. On a FortiGate network, CaptiFi's list is app.captifi.io, captifi.io and *.captifi.io, plus fonts.googleapis.com and fonts.gstatic.com for the page's fonts; leave the font hosts out and the page can load half-broken, or not at all on some iPhones. UniFi calls the same list Pre-Authorization Access, Meraki calls it the walled garden and FortiGate calls it exempt destinations. The exact entries for each system are in its setup guide, linked from the hardware page. A portal that takes card payments also needs the payment provider's hosts, which the provider documents.

A VPN or content filter starts first

When one guest fails and everyone else is fine, look at that guest's phone. An always-on VPN tries to connect the moment the phone joins the WiFi, before the portal has let it through, so the VPN cannot reach its server and the phone's traffic goes nowhere. Ad blockers and content filters that run as a local VPN on the phone behave the same way.

The fix is on the guest's side: pause the VPN or filter, sign in, then switch it back on. On the network side, check that guests can make DNS lookups before signing in, using the DNS server your network hands out, so the portal's address can be found.

The guest dismissed the sign-in window

The sign-in window is easy to close by accident. On an iPhone or iPad, one of the choices for leaving it is Without Internet, which closes the window, keeps the phone joined to the WiFi with no internet access, and turns off Auto-Login for that network. Apple's support article on captive Wi-Fi networks says that with Auto-Login off, the Welcome screen appears the next time the phone connects, so leave the network and join it again, or forget it and rejoin, to bring the window back.

On Android, the sign-in notification can be swiped away; tapping the network name in the WiFi settings usually reopens the sign-in page. On a Windows laptop, the browser window the system opened may have been closed, and opening http://neverssl.com in any browser triggers the redirect again.

The device was let through before

Sometimes nothing is wrong. A portal that recognises a returning device lets it straight onto the internet without showing the page again, which CaptiFi does by design, and a device still inside its session will not see the page either. When you are testing, that means your own phone may never show the portal after the first sign-in. Forgetting the network does not reset it on an iPhone: Apple says the phone keeps the same private address if it was last made to forget that network less than 24 hours earlier (two weeks before iOS 18). Test with a phone that has never joined the network, or wait for the session to end.

Phone privacy settings can cause the reverse. Phones give each WiFi network a private MAC address in place of the hardware one. Android keeps that address for the network, but Apple's security guide lists open networks, Enhanced Open and captive portals among the connections where an iPhone uses a rotating address by default, and its guide to private Wi-Fi addresses says that address changes every two weeks. On a guest network with a portal, a regular's iPhone can therefore look like a new device every fortnight and be asked to sign in again. The MAC address randomisation entry explains how each system behaves.

The page loads, but the guest never gets online

When guests can see and submit the page but stay offline afterwards, the portal is working and the hand-off back to the network is not. The portal has to tell the controller or gateway to let the device through, and the method depends on the hardware.

Check for a shared secret pasted with a stray space, a firewall rule blocking outbound UDP 1812, and an API key regenerated on the controller after setup. If guests get online and then drop after a few minutes, the controller's own timeout is shorter than the session you set: FortiGate's default idle timeout, for example, is five minutes, and the FortiGate guide shows how to raise it.

Devices that cannot show a sign-in page

Smart TVs, streaming sticks, printers and card terminals often have no browser that can display a portal. On a portal network they join, fail the connectivity check, and either stay offline or show a vague network error. Put these devices on the staff network, or add their MAC addresses to a list of devices allowed through without the portal. On CaptiFi, venues on CaptiFi access points or a UniFi controller add the device under My Locations, Connection status, Pre-authorized devices, and it skips the sign-in page from then on. Most other business controllers have a similar list, under a different name on each. The guide to Chromecast and smart TVs on guest WiFi covers finding the address and the casting problem that follows.

A test routine after every change

Run this after every change to the network or the portal. It takes a few minutes.

1. Use a phone that has never joined the guest network, so it behaves like a first-time guest; forgetting the network is not enough on an iPhone, as the section on devices let through before explains.
2. Switch off mobile data, so nothing loads over 4G or 5G and hides the fault.
3. Join the guest network and wait ten seconds without opening anything.
4. Check that the window opens by itself, the page loads fully and the form submits.
5. Open an ordinary HTTPS site to confirm the internet works.
6. Repeat on the other platform: at least one iPhone and one Android phone, plus a Windows laptop if guests work at your venue.
7. Check the test guest appears in your portal's guest list, which on CaptiFi is Guest Visits on my.captifi.io.

If the page still will not appear, email hello@captifi.io with the hardware model, the controller version and which devices fail. CaptiFi's average support response time is under 2 hours, and the setup guide for your system, linked from the hardware page, lists its walled garden entries and portal settings.

Sources: Apple Support, Use captive Wi-Fi networks on your iPhone or iPad, Use private Wi-Fi addresses on Apple devices and Manage iCloud Private Relay for specific websites, networks, or system settings; Android Developers, Captive portal API support; Microsoft Learn, Network Connectivity Status Indicator FAQ; Mozilla Support, Captive portal detection, and the Firefox 155 release notes; the Android NetworkStack default probe addresses; IETF RFC 8952; and CaptiFi's hardware setup guides, October 2026. Product names are trade marks of their owners; CaptiFi is not affiliated with or endorsed by them.