故障排除 Captive Portal 重定向：解决访客 WiFi 连接失败问题

Captive Portal

在授予完全互联网访问权限之前，向加入网络的设备展示的网页。网关会拦截设备的初始 HTTP 连接探测，并将其重定向到该门户 URL。

每个访客 WiFi 登录页面背后的技术机制，从酒店大堂到体育场大厅。在 RFC 8910 中定义。

Walled garden

设备在完成 Captive Portal 认证之前可以访问的域名和 IP 地址集。发往 walled garden 目标地址的流量可绕过认证要求。

必须包含系统探测 URL、身份提供商端点、CDN 域名和支付处理程序域名。配置错误的 walled garden 是导致 Captive Portal 失败的第二大常见原因。

NCSI (网络连接状态指示器)

一项 Windows 功能，通过探测 `msftconnecttest.com` 来确定设备是否拥有互联网访问权限，或者是否处于 Captive Portal 之后。在 Microsoft 的网络文档中定义。

如果网关阻止了此探测，Windows 将报告“无互联网访问”，并且绝不会触发 Captive Portal WebView。解决方法是将 NCSI URL 添加到认证前准许列表中。

HSTS (HTTP 严格传输安全)

在 RFC 6797 中定义的一种网络安全策略，用于指示浏览器拒绝普通 HTTP 连接，并拒绝任何与域名不完全匹配的证书。

防止网关拦截 HTTPS 请求以进行 Captive Portal 重定向。包括 google.com 在内的主要域名在所有主流浏览器中都位于 HSTS 预载入列表中。

HTTP 302 重定向

一种标准的 HTTP 响应代码，表示请求的资源临时位于不同的 URI，并在 Location 标头中提供。

网关用于将设备的连接探测转向 Captive Portal 登录页面的机制。某些网关会使用 HTTP 303 或带有重定向主体的 HTTP 200 代替。

RADIUS (远程用户拨号认证服务)

一种提供集中化认证、授权和计费 (AAA) 管理的网络协议，在 UDP 端口 1812（认证）和 1813（计费）上运行。

Purple 的云平台充当 RADIUS 服务器。本地网关（Meraki、Aruba 等）向 Purple 的 RADIUS 服务器发送认证请求，并根据 Access-Accept 或 Access-Reject 响应执行操作。

MAC 地址缓存

存储设备唯一硬件标识符的过程，以便识别返回的设备并维护会话状态，而无需重新进行认证。

支持在短暂断开连接和会话窗口内的重复访问之间保持会话持久性。对于宾客在不同区域之间移动的酒店环境至关重要。

基于身份的网络

Purple 的架构模型，其中访问策略、VLAN 分配和分析是基于已认证的用户身份应用，而不仅仅是基于设备的 IP 或 MAC 地址。

可在 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 硬件上实现精细的访问控制、个性化体验以及将网络行为准确归因到个人用户。

DHCP 耗尽

DHCP 地址池中所有可用的 IP 地址都已被分配的状态，导致新设备无法获取地址，从而无法访问 Captive Portal。

在高峰期的高密度场馆中很常见。其表现与 Captive Portal 故障完全相同 - 设备显示已连接到 SSID 但无法上网。可通过检查服务器上的 DHCP 租约使用率来进行诊断。

Why does the captive portal redirect fail to open automatically on mobile devices?

Mobile operating systems (iOS, Android, Windows) rely on unauthenticated HTTP probes to vendor endpoints (such as captive.apple.com or connectivitycheck.gstatic.com/generate_204). If the network gateway does not intercept port 80 traffic with a clean HTTP 302 redirect, or if DNS queries for those probe domains are dropped before authentication, the Captive Network Assistant (CNA) will not launch.

Why does the 'captive portal login keeps stopping' error occur on Android devices?

The 'captive portal login keeps stopping' error on Android occurs when the system WebView crashes during redirection or when the gateway drops the generate_204 HTTP probe midway through authentication. Clearing the cache of the Android System WebView or Chrome app, disabling randomized MAC addresses for the venue SSID, and navigating manually to an unencrypted HTTP probe address resolves the crash loop.

How do unencrypted HTTP sites like neverssl.com force a captive portal login screen to load?

Because modern browsers enforce HTTP Strict Transport Security (HSTS) on encrypted domains like google.com, wireless gateways cannot intercept HTTPS traffic without triggering browser certificate warnings. Navigating to an unencrypted HTTP destination such as http://neverssl.com or http://1.1.1.1 sends a plaintext request that the gateway can safely intercept with an HTTP 302 redirect to the login splash page.

Why do Android devices show 'Sign into network' errors or fail the generate_204 probe?

Android devices query clients3.google.com/generate_204 and connectivitycheck.gstatic.com. If the wireless controller or walled garden blocks access to Google IP addresses without intercepting the HTTP request with a 302 redirect, Android detects a connection error or assumes an isolated intranet, suppressing the portal prompt. Whitelisting the required probe domains or ensuring transparent HTTP redirection resolves this.

How do you prevent HTTPS certificate warnings when intercepting captive portal traffic?

When a guest browser navigates to an HTTPS domain prior to login, intercepting the TLS handshake triggers severe browser security warnings (such as NET::ERR_CERT_COMMON_NAME_INVALID) due to HSTS and certificate mismatch. Enterprise networks prevent this by leaving HTTPS traffic undisturbed and relying exclusively on plaintext HTTP probe interception to trigger the operating system's native captive portal browser.

What causes RADIUS authentication timeouts during captive portal guest login?

RADIUS timeouts occur when the wireless access point or controller fails to receive a RADIUS Access-Accept packet from the authentication server within the timeout window (typically 5 seconds). Common causes include outbound UDP ports 1812 and 1813 being filtered by perimeter firewalls, mismatched RADIUS shared secrets, or asymmetric routing between the access point and the cloud RADIUS service.

How does RFC 8910 (Captive Portal API) resolve modern captive portal connection issues?

RFC 8910 standardizes captive portal discovery via DHCP Option 114 and IPv6 Router Advertisements. Rather than intercepting DNS queries or HTTP packets, the network directly advertises the captive portal API endpoint URL to connecting client devices. Modern operating systems query this API directly, eliminating HSTS certificate collisions, DNS hijacking latency, and CNA browser rendering bugs.

How does MAC address randomisation affect captive portal reconnection?

iOS 14+ and Android 10+ rotate private MAC addresses periodically or when re-associating with SSIDs. If a guest network tracks sessions solely by physical MAC address, returning visitors are forced to authenticate repeatedly. Enterprise platforms like Purple solve this by tying session authorisation to user identity tokens and Passpoint (Hotspot 2.0) profiles rather than transient hardware MACs.

How does Purple resolve captive portal redirect failures across multi-vendor networks?

Purple operates as a hardware-agnostic cloud overlay across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Fortinet, and UniFi hardware. By automating walled garden configurations, managing trusted SSL redirect domains, and providing high-availability cloud RADIUS clusters with sub-second failover, Purple eliminates captive portal redirect drops and delivers reliable guest onboarding.