Short answer: a captive portal is a gate in front of the network, not the network itself. The phone associates with the access point and reports a Wi-Fi connection, but every request is held until a web login completes. If the login page never appears, the phone is not connected in any useful sense — and on networks that register devices by address, Private Wi-Fi Address is the other half of the problem.
Why "connected" and "online" are different states
A wireless association is a link-layer agreement: the phone and the access point agree on encryption and start exchanging frames. A captive portal sits above that. It intercepts traffic and answers everything with a redirect to a login page until you authenticate.
That produces the classic hotel symptom: the Wi-Fi icon is full, the network name is right, and nothing loads. It also produces the less obvious one: the phone may decide the network has no internet, mark it as such, and deprioritise it — so you get "connected" plus cellular data doing the work.
A portal normally opens by itself. On iOS it does so by showing a *Sign In* option or a sheet. When that does not happen, it is usually one of three things: the portal's detection page was never fetched, the phone's address was refused before the portal could run, or the portal needs a specific trigger.
Getting the login page to appear
Work through these in order; the first two resolve most cases.
- Open the network's ⓘ page in
Settings → Wi-Fi, tap the network you are on, and look for Sign In to Network or a similar action. This is the most direct route and the one people miss because it is a setting, not a browser. - Force a plain web request. Open a browser and go to
http://neverssl.comor anyhttp://address. Plain HTTP triggers the redirect; a page the phone has cached as HTTPS may load from cache and skip it entirely. - Turn off cellular data briefly, if the phone is quietly falling back to cellular and never showing you the portal at all.
- Tap the network again in the Wi-Fi list. Re-associating often re-triggers the portal detection.
- Toggle Wi-Fi off and on, then join again. This re-runs the detection sequence from scratch.
- Forget the network and join again. This clears any cached portal state and the stored profile, and is the step that fixes a portal that worked once and has refused since.
Where Private Wi-Fi Address fits in
Instead of the phone's hardware address, iOS presents a random address generated for each network. The point is that a café or an airport cannot recognise your phone across visits and build a profile of where you go.
The cost appears on two kinds of network:
- Networks that register devices by address. A hotel that issues access per device, a campus network, a corporate guest network, a home router with MAC filtering. These compare the address against an allow list, and a new random address is simply not on it. The login appears to fail for no reason, or the network associates and immediately rejects the phone.
- Portal implementations that bind a session to the address. If the address changes between the portal's first contact and the login, the session it created does not match the device completing it. The login page may loop, or accept and still not grant access.
The fix is narrow and per network: open the network's ⓘ in Settings → Wi-Fi, set Private Wi-Fi Address to *Off* for that network, then forget and rejoin. You can also set it to *Fixed*, which keeps a stable random address for that network rather than the hardware one — useful when the venue wants a stable identifier but you would rather not expose the hardware address. Leave it on for the networks you do not control.
What people get wrong about this
- "The password is wrong." If the password were wrong, the phone would not associate at all. A full Wi-Fi icon with nothing loading is a portal or a policy, not a password.
- "The hotel's Wi-Fi is broken." It works on a laptop because the laptop shows the login page the moment a browser opens, and its address may already be registered. The phone's behaviour is not the same.
- "I need a VPN to get online." A VPN cannot help before the portal lets you through; it adds a second thing that can fail. Complete the portal first.
- "Turning Private Wi-Fi Address off permanently is safer." It is a privacy trade, not a safety switch. Turn it off for the one network that requires it, and leave the default in place everywhere else.
- "Forget and rejoin works, so it is fixed." Sometimes the portal session expired. If you have to forget and rejoin every time you come back, the network is registering by address and you should set the address to Fixed for it.
Apple documents the Wi-Fi settings, including the private address option, in its own troubleshooting guidance for a connection that will not work. Apple does not publish a number for how long a portal session lasts, because that is set by the venue's system rather than by iOS — treat any quoted duration as the venue's own.