疑難排解 Captive Portal 重新導向：解決訪客 WiFi 連線失敗問題

Captive portal

在獲得完整的網路存取權限之前，向加入網路的設備顯示的網頁。閘道器會攔截設備的初始 HTTP 連線探測，並將其重新導向至該入口網站的 URL。

從飯店大廳到體育場通道，每個訪客 WiFi 登入頁面背後的機制。於 RFC 8910 中定義。

Walled garden

設備在完成 Captive Portal 驗證之前可以存取的網域和 IP 位址集合。流向 walled garden 目的地的流量會繞過驗證要求。

必須包含作業系統探測 URL、身分識別提供者端點、CDN 網域和付款處理商網域。設定錯誤的 walled garden 是導致 Captive Portal 失敗的第二常見原因。

NCSI (Network Connectivity Status Indicator)

一項 Windows 功能，透過探測 `msftconnecttest.com` 來判斷設備是否具有網際網路存取權限，或者是否處於 Captive Portal 之後。這定義在 Microsoft 的網路文件中。

如果閘道器阻擋了此探測，Windows 會報告「沒有網際網路存取權限」，且永遠不會觸發 Captive Portal 的 WebView。修正方法是將 NCSI URL 新增至驗證前的允許清單中。

HSTS (HTTP Strict Transport Security)

一項在 RFC 6797 中定義的網頁安全政策，指示瀏覽器拒絕一般 HTTP 連線，並拒絕任何與該網域不完全匹配的憑證。

防止閘道器攔截 HTTPS 請求以進行 Captive Portal 重新導向。包括 google.com 在內的主要網域在所有主流瀏覽器中都處於 HSTS 預載清單中。

HTTP 302 redirect

一種標準 HTTP 回應碼，表示所請求的資源暫時位於不同的 URI（於 Location 標頭中提供）。

閘道器用來將設備的連線探測轉向至 Captive Portal 登入頁面的機制。某些閘道器會改用 HTTP 303 或帶有重新導向內文的 HTTP 200。

RADIUS (Remote Authentication Dial-In User Service)

一種提供集中式驗證、授權和計帳 (AAA) 管理的網路協定，在 UDP 連接埠 1812（驗證）和 1813（計帳）上運作。

Purple 的雲端平台充當 RADIUS 伺服器。本地閘道器（Meraki、Aruba 等）會向 Purple 的 RADIUS 伺服器發送驗證請求，並根據 Access-Accept 或 Access-Reject 回應採取行動。

MAC address caching

儲存設備唯一硬體識別碼的程序，以便識別返回的設備並維持階段作業狀態，而無需重新驗證。

在階段作業視窗內實現短暫斷線和重複訪問時的階段作業持續性。對於房客在不同區域之間移動的餐旅環境至關重要。

Identity-Based Networks

Purple 的架構模型，在此模型中，存取政策、VLAN 分配和分析是根據已驗證的用戶身分識別（而非僅根據設備的 IP 或 MAC 地址）來套用的。

在 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 硬體上實現細粒度存取控制、個人化體驗，以及將網路行為準確歸因於個別用戶。

DHCP exhaustion

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.