“Connected, no internet” — and no login page anywhere. This is the single most common captive portal complaint, and it is almost never the portal being broken. It is the phone never getting the chance to discover the portal exists.
✍️ Technical Anshu📵 The Missing Popup⏱️ 8 minute read
🎥 Portal behaviour tested live in the full setup video
A captive portal cannot grab a phone by the shoulder. The phone has to notice the portal, and it notices in one specific way: the moment it joins a network, it quietly asks the internet for a tiny known test page. If the answer comes back wrong — a login page instead of the expected reply — the phone concludes “there is a portal here” and pops it up. Everything in this guide follows from that one mechanism, including the part nobody believes at first: an HTTPS site can never trigger your portal page, and it is not supposed to.
What the phone does in the first seconds after joining (illustrative)
Phone joins Guest WiFi
→ asks for its tiny test page (plain HTTP probe)
→ firewall answers with the portal instead
→ phone decides: "portal found" → popup opens
Guest opens an HTTPS app first instead
→ no probe answer, no popup, app just spins
→ guest concludes: "your WiFi is broken"
The popup is triggered by the phone's own detection probe — not by any website the guest opens afterwards.
1
First, Reproduce It Properly
On the test phone, forget the guest network completely. A phone that was already signed in will not show you the new-guest experience.
Turn mobile data off for the test — phones quietly fail over to 4G/5G and hide portal problems completely.
Rejoin and wait ten full seconds without opening any app. Watch for the popup or the "sign in to network" notification.
Half of all "portal is broken" reports die at this step: the phone was using mobile data, or it was already authenticated from an earlier session.
2
Why Opening a Website Often Shows Nothing
Guests open their banking app, Instagram or a bookmarked HTTPS site and wait for a login page that cannot legally appear. A firewall may redirect a plain-HTTP request to the portal, but redirecting an HTTPS request would mean impersonating that secure site — browsers are built to refuse exactly that, and they show a certificate error instead of your page.
The working advice for guests is one sentence for your reception desk and your help card: join the WiFi and wait for the popup; if it does not come, turn WiFi off and on once — that re-runs the phone's detection probe. Opening random apps will never do it.
3
The Checks That Find the Real Cause
Is the guest really captured? Confirm the device is on the guest SSID and its traffic hits the guest interface the capture rule watches. A rule matched to the wrong interface captures nobody — or everybody.
Is the device pass-listed? A phone once added to Pass Listed Client Addresses skips the portal forever. Test with a phone that has never been exempted.
Does DNS answer before login? The phone's probe needs name resolution to work (or fail in the portal's favour). A guest VLAN whose DNS is fully blocked pre-login can starve the detection mechanism.
Is it one phone or all phones? One phone suggests its own settings — a private DNS (DNS-over-TLS) setting on Android is a classic, because encrypted DNS bypasses the local answers the detection relies on. All phones failing points back at the firewall.
Did the session already exist? A long session timeout means yesterday's guest is still signed in today. That is the portal working as configured — check Active Sessions before debugging ghosts.
4
Fix the System, Not the Guest
Once the cause is found, fix it at the layer that owns it: correct the capture rule, remove the accidental pass-list entry, repair guest DNS, or shorten a silly session length. Then re-test from a forgotten network with mobile data off, on both an Android and an iPhone.
And print the one-sentence instruction where guests can see it. The best portal support is a card on the counter that makes the phone call unnecessary.
⚠️ Do not "fix" this by disabling HTTPS checks, installing certificates on guest phones, or telling guests to ignore browser warnings. The popup mechanism exists precisely so portals never need to touch secure traffic. If a setup seems to require breaking that, the setup — not the phone — is wrong.
🎥 Watch the Portal Test in the Video
Joining as a fresh guest and watching the portal appear — the live test is in the full setup video.
The popup appears on Android but not on iPhone. Why?
Each system runs its own detection probe and its own mini browser, and they fail differently. If Android works, the portal itself is alive — look at the iPhone side: stale network profile (forget and rejoin), a VPN app holding the connection, or an old saved session. Test with a second iPhone before changing firewall settings.
Guests say the WiFi shows Connected but apps do not work. Same problem?
Usually yes — the device joined and got an address but never completed the portal, so the firewall is holding its traffic, exactly as designed. The missing piece is the popup. Walk the checks in this guide, starting with forgetting the network and turning mobile data off.
Can I force the portal page to open inside the guest's normal browser?
Not reliably, and not for HTTPS — by design. The supported path is the operating system's own portal popup. Everything else (typing a short address you print on a card, for example opening the firewall's portal address directly) is a fallback for the desk to offer, not the main mechanism.
This guide is based on the Technical Anshu captive portal video • Stuck on a step? Ask in the video comments — you will get a reply 🙏