疑難排解公共 WiFi：「已連線，無網際網路」與 Splash Page 重新導向失敗的修復指南
本權威技術參考指南說明了 Captive Portal 偵測的底層運作機制，並詳細剖析阻止訪客 WiFi 連線的六大主要失敗模式。它為 IT 主管和網路架構師提供了實用的疑難排解框架，用以解決 HTTP 重新導向問題、DNS 衝突以及 MAC 隨機化所帶來的挑戰。
Video overview
收聽此指南
查看播客逐字稿
核心系列的一部分：Captive Portal 指南 →
Public WiFi & Captive Portal Redirection Diagnostic Tool
Diagnose the root cause of splash page redirection failures, probe timeouts, and 'Connected, No Internet' errors across client operating systems and enterprise wireless controllers.
Root Cause Mechanism
The wireless controller or gateway is failing to intercept cleartext HTTP port 80 requests, or DNS queries for probe domains are being dropped by upstream firewalls before authentication.
http://captive.apple.com/hotspot-detect.htmlRecommended Remediation Actions
- Verify that UDP port 53 (DNS) is completely open in pre-authentication firewall policies to allow probe domain resolution.
- Ensure the AP or gateway intercepts cleartext HTTP requests (TCP 80) and issues an immediate HTTP 302 Found redirect to the portal URL.
- Do not intercept HTTPS port 443 before authentication, as HSTS and TLS SNI mismatches will trigger security warnings.
- Instruct users to test manual fallback URLs such as http://neverssl.com or http://captive.apple.com to trigger redirection.
Configuration Location: Wireless > Configure > Access control > Splash page
# Meraki Dashboard Configuration
1. Set Association Requirements to "Open (no encryption)"
2. Set Splash page to "Sign-on splash page / External captive portal"
3. In "Walled garden", add: *.purple.ai, *.purpleserver.net
4. Enable "RADIUS CoA (RFC 5176)" on port 3799*.purple.ai*.purpleserver.netEliminate Public WiFi Redirection Failures Across Your Estate
Purple's hardware-agnostic cloud guest WiFi platform eliminates captive portal drops, delivers sub-second splash page loading, and manages pre-auth walled gardens across Cisco Meraki, Aruba, Ruckus, and UniFi.
執行摘要
當顧客連線到您的 WiFi，登入頁面卻無法載入。他們看到「已連線，無網際網路」的警告後便放棄連線。對於場域營運總監與 IT 經理而言，這種失敗直接導致顧客體驗變差、支援工單增加，並錯失了收集第一方數據的機會，而這些數據正是投資無線基礎設施的合理依據。
本指南將詳細說明 Captive Portal 偵測在作業系統層級的運作原理，並指出導致大多數連線失敗的六大根本原因。它提供了一個實用且與特定廠商無關的排錯框架，用以解決 DHCP 耗盡、DNS 攔截失敗、不完整的 Walled Garden (圍牆花園)、被阻擋的 HSTS 重新導向、作用中的 VPN 衝突以及 MAC 位址隨機化等問題。
技術深度剖析：Captive Portal 偵測的實際運作原理
要排除 captive portal 的故障，您必須先了解 captive portal 在網路層級的實際作用。它不單單只是一個登入頁面，而是一種網路層級的流量攔截機制。
當訪客裝置加入訪客 SSID 時，它會透過 DHCP 取得 IP 位址。作業系統不會等待使用者開啟瀏覽器。相反地，背景系統服務會立即向廠商控制的探測 URL 發送未經加密的 HTTP GET 請求。Apple 裝置會查詢 captive.apple.com。Android 裝置會查詢 connectivitycheck.gstatic.com。Windows 裝置會查詢 msftconnecttest.com。Firefox 則會查詢 detectportal.firefox.com。
如果網路可以自由存取網際網路，這些探測會回傳預期的 HTTP 200 OK 回應，作業系統據此判定連線已啟用。然而，在訪客網路上，無線閘道器或控制器會在該 HTTP 探測到達網際網路之前對其進行攔截。閘道器不會回傳預期的回應，而是回傳一個指向 captive portal 歡迎頁面的 HTTP 307 Temporary Redirect。作業系統偵測到此非預期的重新導向，判斷其位於 captive portal 之後，並開啟一個沙箱瀏覽器視窗 (Captive Network Assistant) 來顯示登入頁面。
疑難排解與風險緩釋：六大失敗根本原因
當 captive portal 無法載入時，問題幾乎總是由以下六種特定失敗模式之一所引起。
\n
1. DHCP 位址池耗盡
這是高密度活動中的隱形殺手。如果您正在舉辦一場有 2,000 名與會者的會議，並使用標準的 /24 子網路，您將只有 254 個可用的 IP 位址。如果您的 DHCP 租期設定為預設的 24 小時，您的位址池將在活動開始後幾分鐘內耗盡。在此之後的每次連線嘗試都將在 Captive Portal 流程開始前宣告失敗。
解決方案： 對於高流動率的環境，請將訪客 DHCP 租期設定在 15 到 30 分鐘之間。根據尖峰時段的同時在線使用者人數來規劃您的子網路大小，而非僅依據平均出席人數。/22 子網路可提供 1,022 個可用位址，這是企業級場地建議的最小規模。
2. DNS 攔截失敗
Captive Portal 重導向依賴閘道器攔截 HTTP 探測。然而，該探測首先需要進行 DNS 查詢。如果您的 DNS 設定不允許未經驗證的用戶端解析外部網域名稱，則探測將永遠不會觸發。
解決方案： 確保您的防火牆原則明確允許來自未經驗證用戶端的 DNS 查詢（連接埠 53）。在測試裝置上進行封包擷取，以驗證您的 DNS 攔截是否正常運作。
3. 未設定完全的 Walled Garden
Walled Garden（驗證前存取控制清單）定義了未經驗證的訪客可以存取哪些外部網域。如果您的 portal 歡迎頁面從未包含在 Walled Garden 中的 CDN 載入資源，該頁面將會呈現為空白畫面。如果您透過 Google、Apple 或 Microsoft Entra ID 提供社群登入，則這些提供商所使用的每一個 OAuth 網域都必須加入白名單。社群身分驗證提供商會定期更新其 CDN IP 範圍和驗證網域；六個月前運作完美的 Walled Garden 可能會在一夜之間失效。
解決方案： 定期進行每季 Walled Garden 稽核。在硬體支援的情況下，使用萬用字元網域探測（wildcard domain snooping），此功能在 Cisco Meraki、HPE Aruba、Ruckus 和 Juniper Mist 上皆有原生支援。Purple 會自動維護並更新這些 Walled Garden 項目，這也是我們雲端管理服務的一部分。
4. HSTS 重導向阻擋
HTTP Strict Transport Security (HSTS) 是一種瀏覽器安全性原則，強制僅透過 HTTPS 連線到特定網域。如果訪客裝置嘗試與預載 HSTS 的網域進行通訊，而您的閘道器試圖攔截該 HTTPS 請求以重導向至 portal，瀏覽器將會偵測到憑證不符。這會顯示無法跳過的安全性警告，並完全阻擋重導向。
解決方案： 絕對不要對初始重新導向進行 HTTPS 攔截。請確保您的閘道器僅重新導向未加密的 HTTP Canary 探測。長期的標準化解決方案是 RFC 8910，它定義了 DHCP Option 114。此選項允許您的 DHCP 伺服器直接向用戶端裝置宣告 Captive Portal URL，完全不需要進行 HTTP 重新導向。iOS 14 和 Android 11（含）以上版本均原生支援此功能。
5. 用戶端裝置上啟用了作用中的 VPN
VPN 會加密來自裝置的所有流量，並在流量到達您的閘道器之前，透過外部通道進行路由。您的閘道器永遠不會收到 HTTP 探測，因此永遠不會觸發 Captive Portal 偵測程序。訪客既看不到登入頁面，也無法連線上網。
解決方案： 訪客必須停用 VPN、連線到入口網站，然後重新啟用 VPN。對於第一線服務人員來說，詢問訪客是否正在使用 VPN 應該是疑難排解的第一步。
6. MAC 位址隨機化中斷了工作階段持續性
現代 iOS 和 Android 裝置預設會使用隨機 MAC 位址作為隱私功能。每次裝置連線到網路時，可能會呈現不同的 MAC 位址。由於 Captive Portal 工作階段狀態是透過 MAC 位址進行追蹤的，因此一小時前已通過驗證的訪客在裝置的 MAC 變更後，可能會再次看到登入頁面。
解決方案： 對於訪客而言，解決方案是在其網路設定中針對您特定的 SSID 停用「專用位址」。營運商端的解決方案則是實作基於設定檔的驗證，例如透過 802.1X 進行 Passpoint 和 OpenRoaming，這會在第 2 層使用憑證而非 MAC 位址進行驗證，從而使隨機化變得無關緊要。
實作指南：建立具備彈性的架構
部署配置完善的 Captive Portal 需要主動進行架構決策。
- 在每次重大活動前驗證您的圍牆花園（Walled Garden）。 最低要求的項目包括：您入口網站的 FQDN 及其所有關聯的 CDN 網域、適用於 Apple、Google、Windows 和 Firefox 的 Captive Portal 偵測 URL，以及您支援的每個社群登入提供者的 OAuth 網域。
- 使用公開信任的 TLS 憑證。 自簽署憑證會在每部裝置上觸發瀏覽器警告。請在憑證過期前進行更新；憑證過期是導致整個場域的入口網站突然失效最常見的原因之一。
- 從全新的、未經驗證的狀態進行測試。 從先前已驗證的裝置測試入口網站將會完全繞過入口網站，因為工作階段仍然有效。請務必從新裝置，或從您已清除該網路並刪除 WiFi 設定檔的裝置進行測試。
- 調整閒置逾時。 許多控制器預設為 5 分鐘的閒置逾時，這對於在互動空檔會進入睡眠模式的行動裝置而言過於頻繁。在餐旅和零售環境中，請將閒置逾時設定為至少 30 分鐘。
投資報酬率與商業影響
Captive Portals 是一項成熟的技術，但它們具有一些固有的複雜性。策略性目標是朝向無縫且安全的驗證發展。
OpenRoaming 建立在 Passpoint 和 802.1X 之上，可協助再次到訪的訪客自動且安全地連線，而無需看到任何登入頁面。在我們的 Connect 方案下，Purple 可作為 OpenRoaming 的免費身分識別提供者。Premier Inn 和 Manchester Airports Group 等場所已經在使用它來消除重複訪客重新驗證的麻煩，同時保持完全符合 GDPR 並進行第一方數據收集。透過減少連線失敗，您可以直接增加收集的第一方數據量，從而提升客戶忠誠度和個人化互動。
技術簡報 Podcast
在我們 10 分鐘的技術簡報中，聽取我們的資深解決方案架構師對這些疑難排解步驟的詳細剖析。
關鍵定義
Captive Portal
一種網路層級的流量攔截機制，在使用者完成必要操作（例如在 Splash Page 上接受條款或提供憑證）之前，限制其網際網路存取。
企業場域保障訪客存取安全及收集第一方數據的首要方法。
Walled Garden
一種預先驗證存取控制清單，用於定義未驗證的訪客裝置允許存取哪些外部 IP 位址或網域。
對於在使用者完全通過驗證之前，允許其存取入口網站資產、CDN 以及 OAuth 身分識別提供商至關重要。
Captive Network Assistant (CNA)
當作業系統偵測到 Captive Portal 重新導向時，自動開啟的沙盒化、功能受限的瀏覽器視窗。
這是訪客實際看到您的登入頁面並進行互動的介面。
HSTS (HTTP Strict Transport Security)
一種網路安全策略機制，透過強制瀏覽器僅能透過安全的 HTTPS 連線與網站互動，保護網站免受中間人攻擊。
HSTS 會阻止閘道器使用 HTTPS 攔截將使用者重新導向至 Captive Portal，若設定不當，將會導致連線失敗。
DHCP Pool Exhaustion
DHCP 伺服器已分派其設定子網路中所有可用 IP 位址的狀態，導致新裝置無法加入網路。
在體育館或會議等高密度環境中，導致「已連線，無網際網路」錯誤的常見原因。
MAC Address Randomisation
現代行動作業系統中的一項隱私功能，可為每個 WiFi 網路產生隨機的 MAC 位址，以防止跨不同地點的追蹤。
此功能會中斷 Captive Portal 上的工作階段持續性，若訪客的 MAC 位址輪替，則會強制其重新驗證。
OpenRoaming
一個 WiFi 網路聯盟，允許使用者自動且安全地連接至參與的網路，無需輸入憑證或與 Captive Portal 進行互動。
針對重複訪客，這是取代 Captive Portal 的策略性後續方案，由 Purple 提供作為免費的身分驗證提供者。
RFC 8910 (DHCP Option 114)
一種標準，允許 DHCP 伺服器在分配 IP 位址期間，直接向用戶端裝置提供 Captive Portal 的 URL。
這完全繞過了 HTTP 重新導向的需求，解決了由 HSTS 引起的問題，並提高了 Portal 偵測的速度。
範例
一家位於倫敦市中心、擁有 350 間客房的酒店為訪客 WiFi 運作單一的 /24 子網路。在一次大型會議期間，400 名代表同時抵達。在 20 分鐘內，訪客紛紛反映已連線卻無法載入入口網站或存取網際網路。
立即的修復方案是將子網路擴展至 /22，提供 1,022 個可用位址，並將 DHCP 租期時間從 24 小時縮短至 8 小時。長期解決方案則是實施 Purple 的雲端管理 Captive Portal，該系統能即時監控 DHCP 核心池的利用率，並在資源耗盡前向網路團隊發出警報。
一家擁有 200 家門市的大型零售連鎖店，在其訪客入口網站上使用 Google 和 Facebook 的社群登入功能。在 Google 更新其 OAuth 架構後，訪客可以到達入口網站頁面，但點擊社群登入按鈕後卻出現空白畫面。
IT 團隊必須識別 Google 使用的新驗證網域，並將其加入 Walled Garden（預先驗證存取控制清單）中。為了防範未來再次發生此問題，他們應使用萬用字元網域項目（例如 *.google.com）而非寫死特定 IP 位址，並每季審查一次 Walled Garden。
練習題
Q1. 體育場的 IT 主管報告，在半場休息期間，成千上萬的球迷試圖連接至訪客 WiFi。部分人可以載入 Portal 頁面，但許多人報告他們的裝置卡在「正在取得 IP 位址」，或者在 Portal 出現之前顯示「已連線，無網際網路」。最可能的架構缺陷是什麼？
提示：請考慮同時連線量與網路區段上可用資源的對比。
查看標準答案
網路正經歷 DHCP 位址池耗盡。子網路規劃的規模可能過小 (例如 /24)，無法因應尖峰時段的同時使用負載，且 DHCP 租約時間可能設定得過長。建議的方法是擴大子網路規模 (例如擴大至 /22 或 /21)，並縮短 DHCP 租約時間以符合預期的停留時間 (例如針對體育場設定為 3 小時)。
Q2. 訪客連接至您的零售 WiFi 網路。當他們試圖載入熱門網站時，其裝置顯示安全警告「您的連線不是私密連線」，且 Captive Portal 從未出現。是什麼機制導致此阻擋？
提示：請思考現代瀏覽器如何處理安全連線上的強制重新導向。
查看標準答案
HSTS (HTTP Strict Transport Security) 正在阻擋重新導向。訪客試圖瀏覽預載 HSTS 的網域 (透過 HTTPS)，而無線閘道器試圖攔截該安全連線以重新導向至 Portal。瀏覽器偵測到憑證不符並阻擋了連線。閘道器必須設定為僅攔截未加密的 HTTP 探測。
Q3. 您最近在 Captive Portal 上啟用了 Google 和 Microsoft Entra ID 社群登入選項。訪客報告 Portal 頁面可以載入，但點擊登入按鈕會導致逾時。在 IT 部門無限制的員工網路上測試時，Portal 運作完全正常。缺少了什麼設定？
提示：請考慮在驗證完成之前，訪客裝置的網路狀態。
查看標準答案
Walled garden (驗證前存取控制清單) 不完整。Google 和 Microsoft Entra ID 所使用的 OAuth 驗證網域和 CDN 尚未加入白名單。由於訪客尚未通過驗證，閘道器會阻擋對這些外部網域的存取，導致社群登入程序逾時。IT 團隊必須將這些身分驗證提供者的萬用字元項目新增至 walled garden 中。
常見問題
Why does public WiFi fail to redirect to the splash login page?
Public WiFi fails to redirect when the wireless controller or gateway cannot intercept cleartext HTTP requests (TCP port 80), when upstream firewalls drop DNS queries for captive portal probe URLs (such as captive.apple.com or connectivitycheck.gstatic.com), or when modern client browsers enforce HSTS on HTTPS requests before authentication. Allowing pre-authentication DNS and redirecting HTTP traffic resolves the issue.
How do client operating systems detect public WiFi captive portals?
Upon connecting to an open or public WiFi network, iOS fires HTTP requests via Captive Network Assistant (CNA) to captive.apple.com/hotspot-detect.html, Android queries connectivitycheck.gstatic.com/generate_204 via CaptivePortalLogin, and Windows probes msftconnecttest.com/connecttest.txt via NCSI. If the network returns an HTTP 302 redirect, the operating system launches the captive portal webview. If the probe domain fails to resolve or times out, the device marks the connection as having no internet.
Why do users see SSL certificate or HSTS warnings on public WiFi?
When an access point or gateway intercepts encrypted HTTPS requests (port 443) and presents its own self-signed or vendor certificate to force a splash page on public WiFi, modern web browsers detect a domain mismatch and block the connection with an HSTS or untrusted certificate error. Public WiFi networks should only intercept cleartext HTTP port 80 requests or implement RFC 8910 DHCP Option 114 to cleanly announce the portal URL.
What causes public WiFi captive portals to loop back to the login page?
Infinite login loops occur when the wireless access point or controller fails to receive or process the RADIUS Access-Accept packet or RFC 5176 Change of Authorization (CoA) disconnect/re-authenticate message on UDP port 3799. As a result, the controller maintains the client device in the pre-authentication walled garden role despite successful submission of guest credentials on the public WiFi network.
How does Purple eliminate public WiFi splash page redirection failures?
Purple operates as a cloud-delivered, hardware-agnostic guest WiFi management platform across Cisco Meraki, HPE Aruba, Ruckus, Ubiquiti UniFi, and Fortinet architectures. By optimizing captive portal redirection flows, automating walled garden rules, and integrating with high-speed Anycast DNS, Purple ensures detection probes succeed instantly, onboarding visitors in under 3 seconds without connection drops.
繼續閱讀本系列
Ruckus captive portal 疑難排解：WISPr 重新導向、熱點與 walled garden 檢查清單
您將能夠根據訪客回報的症狀診斷發生故障的 Ruckus captive portal，並依序進行修復。此順序涵蓋熱點 (WISPr) 登入 URL、walled garden、北向入口網站介面密碼、RADIUS 驗證與計費，以及 HTTPS 重新導向憑證。這些檢查適用於 SmartZone、Ruckus One 與 Unleashed。
Ubiquiti UniFi captive portal 疑難排解：外部入口網站、熱點與 walled garden 檢查表
使用此檢查表找出您的 Ubiquiti UniFi captive portal 無法運作的原因並予以解決。您將對照症狀與六大原因、執行兩項快速測試，並修正外部入口網站伺服器、預先授權存取、訪客子網路限制、HTTPS 重新導向、控制器可達性或用戶端設定。
HPE Aruba captive portal疑難排解：重新導向、憑證與 walled garden 檢查清單
使用此檢查清單，從您看到的症狀診斷發生故障的 HPE Aruba captive portal：無重新導向、憑證警告或訪客永遠無法登入上網。接著您可以將故障追溯至 DNS、DHCP、walled garden、重新導向 URL、憑證或 RADIUS。最後，在 Instant AP、Aruba Central 或行動控制器上套用修正程式。
對於您的特定設置有任何疑問嗎？
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話，我們將向您展示其他與您相似的用戶是如何解決此問題的。