What is a captive portal and how does it work?

When you walk into a café and join its Wi-Fi, a sign-in page opens on your screen without you doing anything. That page is a captive portal.

It looks like a simple form. Behind it sit several mechanisms that manage your guest traffic. This article walks through them.

The short answer

A captive portal is a gate that keeps internet access closed until the guest is verified, and opens it afterwards. What holds the gate is not the Wi-Fi itself, but the device at the edge of your network.

Step by step

1. The device joins the network

The guest picks the guest network, with or without a shared password. At this point the device has joined the network but cannot reach the internet. It gets a local IP address, and that is all.

The distinction matters: "joining the Wi-Fi" and "getting online" are not the same thing. A captive portal sits exactly between those two steps.

2. The device probes the internet

Modern operating systems test whether the internet is really open as soon as they join a network, by sending a small request to a known address:

• Android asks Google's generate_204 address and expects an empty response.
• iOS and macOS probe Apple's captive.apple.com.
• Windows uses Microsoft's connectivity test address.

If the expected reply arrives, it decides the internet is open. If not, it concludes there is a gate.

3. The gate steps in

The device at the network edge does not answer an unverified guest's probe as expected. It redirects to the sign-in page instead.

Seeing this, the operating system opens the page by itself. That is the small browser window that slides up on an iPhone, and the "sign in to network" notification on Android.

4. The guest verifies

On the sign-in page the guest picks a method: phone number, voucher code, e-mail, or a registered username. If they enter a phone number, a one-time code arrives shortly after; they type it in.

At this step they also read and accept the privacy notice.

5. The gate opens

If verification succeeds, the device is added to the authorised list and its traffic starts reaching the internet. At the same moment a session record opens in the background: which device, which IP address, at what time, by which method.

From the guest's point of view the whole flow takes about 20 seconds.

What a captive portal does and does not solve

It does:

• Record who joined the network.
• Remove the need to pass a password around; a one-time code replaces it.
• Let you set speed, time and data limits per guest.
• Let you brand the welcome screen.

It does not:

• Strengthen your Wi-Fi signal. Coverage problems are solved at the access points.
• Act as a firewall on its own. Limiting what guests do online is a separate job.
• See inside a guest's encrypted traffic, and it should not.

Who serves the portal?

You can run a captive portal in three different places, and the choice is hard to change later:

Where it runs	Upside	Downside
Inside the access point	No extra hardware	Tied to the brand and model, limited logging
On a separate device at the network edge	Vendor independent, logs in one place	Cost of the device
In a cloud service	Easy to set up	Logs live elsewhere; if the line drops, so does the portal

If your access points come from different brands, or will be replaced later, running the portal on a device at the network edge is usually the calmer path. Replace the access points and your sign-in flow stays the same.

Two common problems

The sign-in page does not open by itself. Almost always a DNS setting. If the DNS server handed to the guest network points outside instead of at the gate device, the operating system's probe cannot resolve and the page never appears. Pointing the guest network's DNS at the gate device fixes it.

The page opens but stalls after sign-in. Usually the post-verification redirect. The address the guest was trying to reach before connecting is no longer valid; the portal needs to send them to a working address instead.

Summary

A captive portal is the layer that turns your guest Wi-Fi from "a password everyone knows" into "a service where you know who connected". The real decision at setup is where in your network the portal runs; the rest is configuration detail.