A phone can show a solid Wi-Fi connection at a hotel or airport while web pages still refuse to load. The radio link is working, and the device may already have a local network address. Internet access is being held behind a captive portal.
A captive portal adds an access-control stage after a device joins the local network. The network can require a sign-in, payment, room number, voucher, or acceptance of terms before it permits ordinary traffic to reach the wider internet. This creates a useful distinction between being connected to Wi-Fi and having usable internet connectivity.
Joining Wi-Fi only establishes local network access
Connecting to a Wi-Fi network starts with the wireless link. The device associates with an access point and, on a typical IP network, obtains configuration such as an IP address, default route, and DNS information.
Those pieces can all succeed before the captive portal has granted internet access. The device may be able to communicate with local network infrastructure while traffic to external destinations is restricted, redirected, or otherwise intercepted according to the hotspot’s access policy.
This is different from entering a Wi-Fi password. A WPA2 or WPA3 passphrase controls access to the wireless network itself. A captive portal operates at a later stage and can impose another condition after the wireless connection exists. Some public hotspots are open at the Wi-Fi layer but still require portal interaction before general internet traffic is allowed.
As a result, the Wi-Fi icon mainly confirms a wireless network connection. It does not, by itself, prove that arbitrary internet destinations are reachable.
Devices actively test for internet access
Modern operating systems do not rely only on the presence of a Wi-Fi link. They typically perform connectivity checks after joining a network. These checks contact a known endpoint and inspect the result to determine whether normal internet access appears to be available.
A captive network can interfere with that expected result. The operating system then treats the connection as requiring portal interaction and can present a small sign-in window or a network notification.
The exact detection method varies by platform and version. It is therefore possible for two devices on the same hotspot to react differently. One may open a portal window immediately, while another remains connected but reports limited or unavailable internet access until the portal is opened another way.
Captive-portal detection is also distinct from a full connectivity test. A successful probe shows that a particular test reached its expected endpoint. It cannot guarantee that every website, service, protocol, or destination is reachable.
The portal page is part of an access-control system
The visible web page is only the user-facing part of the captive system. Behind it, the network needs a way to distinguish devices or sessions that have been admitted from those that have not.
Before authorization, the network can permit enough traffic for portal operation while restricting broader access. After the required action is completed, its policy can change for that device or session so ordinary internet traffic can pass.
Implementation details differ across hotspot systems. Access can be associated with network session state or device identifiers, and operators can apply time limits or other policies. This variation is one reason a portal session may not behave identically after reconnecting, moving between access points, or changing a device privacy setting.
The portal also does not make an open wireless network equivalent to an encrypted one. Access control and radio-link encryption solve different problems. A hotspot can require a portal while the underlying Wi-Fi network remains open.
HTTPS limits transparent redirection
Captive portals are often described as redirecting a browser to a login page, but modern HTTPS traffic places limits on that idea.
With plain HTTP, a network in the path can return a redirect or substitute a response without first establishing an encrypted connection to the requested site. HTTPS is designed to prevent that kind of transparent substitution. The browser expects the server to prove its identity with a valid certificate for the requested hostname before encrypted application data is exchanged.
A captive network cannot simply present its own login page as though it were an unrelated HTTPS site without creating a certificate mismatch. Operating-system connectivity checks and dedicated captive-portal windows help avoid depending on arbitrary HTTPS navigation to expose the portal.
This also explains a familiar failure mode: manually opening a secure site may produce an error or no useful portal page, even though the hotspot is waiting for authorization. The network’s portal mechanism and the browser’s certificate validation are operating under different constraints.
DNS behavior can complicate the symptom
Name resolution is another part of the connection that can make captive access appear inconsistent. A portal needs to direct a device toward its access page, but devices may use different DNS configurations and encrypted DNS modes.
Some platforms account for captive networks in their connectivity stack so portal access can still function under supported private or encrypted DNS configurations. Exact behavior depends on the operating system and network.
A DNS failure is not the same condition as captive access. If names cannot be resolved after a portal session has been accepted, the problem may lie with the hotspot’s DNS service, the device’s resolver configuration, or upstream connectivity. Similarly, a working DNS lookup does not prove that the network permits the resulting connection.
Separating these layers is useful: Wi-Fi association, IP configuration, DNS resolution, portal authorization, and external reachability are related, but success at one layer does not guarantee success at the next.
A remembered network can still require a new portal session
Devices commonly remember Wi-Fi networks so they can associate again when the same network is nearby. That remembered wireless configuration does not necessarily preserve captive-portal authorization indefinitely.
Hotspot policy can expire a session, require fresh acceptance, or treat a later connection as new. A device can therefore reconnect automatically to a familiar network and still need another portal interaction.
Changes to a device’s network identity can matter as well. Many current operating systems support private or randomized MAC addresses on Wi-Fi networks. Since hotspot implementations vary, a network that ties access state to a particular identifier can treat a changed identity as a different client.
That does not mean MAC address randomization is inherently incompatible with captive portals. It means portal state depends on how the specific network tracks admission, and that mechanism is separate from the saved Wi-Fi credentials on the device.
Connected and online are separate states
Captive portals expose a distinction that is easy to miss on ordinary home networks. A device can have a healthy radio connection, valid local IP configuration, and access to nearby network services without having unrestricted internet access.
When a public hotspot shows as connected but the internet remains unavailable, the Wi-Fi signal alone is not enough to diagnose the state. The missing piece may be portal authorization rather than weak reception or a failed wireless link.
That separation is useful beyond public hotspots. Network indicators summarize several layers into a small icon or status label. Treating local connection and external reachability as separate conditions gives a more accurate picture of what the device is actually able to do.