Captive Portal 登入：故障排除與詳解
本指南為理解、部署和排除企業級訪客 WiFi 環境中的 Captive Portal 登入系統提供全面的技術參考。它解釋了現代 Captive Portal 所使用的確切 HTTP 重新導向和 DNS 綁架機制，詳細說明了 HSTS 和安全 HTTPS 瀏覽器如何封鎖本機重新導向，並提供了一個清晰、可操作的故障排除清單，涵蓋用戶端修復（停用 VPN、關閉隨機 MAC 位址、使用 NeverSSL）和營運商端解決方案（Walled Garden 設定、DHCP 租期優化、DNS 攔截驗證）。場所營運商、IT 經理和網路架構師將會發現本指南對於減少訪客支援工單並最大化其無線基礎設施的投資報酬率至關重要。
收聽此指南
查看播客逐字稿
📚 核心系列的一部分：Captive Portal 終極指南 →
執行摘要
對於現代企業場所而言，訪客無線網路已不再只是簡單的便利設施；它代表了客戶互動、營運情報和品牌定位的關鍵接觸點。然而，這些網路的商業價值完全取決於初始連線體驗的可靠性。當訪客連線到網路，而 Captive Portal 登入頁面無法顯示時，場所會立即面臨前台摩擦增加、支援工單湧現以及失去數據收集機會的困境。
這些失敗的核心在於安全網路標準與 Captive Portal 歷史上所使用的網路層攔截技術之間的根本衝突。現代網頁瀏覽器和作業系統旨在偵測並阻止未經授權的流量重導向，以保護使用者免受中間人 (MitM) 攻擊。透過深入了解精確的 HTTP 和 DNS 重導向順序、安全協定（如 HTTP Strict Transport Security (HSTS)）的影響，以及干擾這些機制的用戶端設定，IT 組織可以實施強大的設定，以確保無縫的引導流程。
本指南詳細介紹了 Purple 的雲端管理 Guest WiFi 平台如何應對這些挑戰，以在所有消費級作業系統中提供高可用性的重導向，從而最大限度地減少場所的支援開銷，並最大化無線基礎設施投資的回報。無論您是在 Hospitality 、 Retail 、 Healthcare 還是 Transport 環境中進行部署，本指南中的原則和檢查清單均普遍適用。
技術深度解析
為了有效解決 Captive Portal 故障，網路管理員必須了解用戶端裝置連線到開放式或預先共用金鑰 (PSK) 訪客無線網路時發生的確切事件順序。包括 Apple iOS / macOS、Google Android、Microsoft Windows 和 Linux 發行版在內的現代作業系統，不會等待使用者開啟瀏覽器來測試網際網路連線。相反地，它們會在完成關聯和 DHCP 階段後，立即執行自動化的主動探測機制。
Captive Portal 偵測順序
連線和驗證過程遵循高度結構化的順序：
| 步驟 | 動作 | 技術描述 | 預期成功指標 |
|---|---|---|---|
| 1 | 關聯 | 用戶端在 Layer 2 與訪客 SSID 進行關聯。 | 成功的 802.11 關聯框架交換。 |
| 2 | IP 撥配 | DHCP 伺服器指派 IP 地址、子網路遮罩、閘道器和本機 DNS 伺服器。 | 用戶端收到 DHCP ACK 封包。 |
| 3 | 主動探測 (Active Probing) | 作業系統背景服務向特定廠商的 Canary URL 發送未加密的 HTTP GET 請求。 | HTTP 200 OK (Apple/Windows) 或 HTTP 204 No Content (Google)。 |
| 4 | 攔截與重新導向 (Interception & Redirect) | 無線閘道器/控制器攔截 HTTP 探測，並返回指向該入口網站的 HTTP 302/303 重新導向。 | HTTP 302 重新導向至 Captive Portal 的 FQDN。 |
| 5 | 轉譯入口網站 (Portal Rendering) | Captive Portal Assistant (CPA) 瀏覽器引擎開啟並轉譯 Splash 頁面。 | 成功轉譯登入介面。 |
+--------+ +------------+ +------------+ +-------------------+
| Client | | AP/Gateway | | DNS Server | | Captive Portal IP |
+--------+ +------------+ +------------+ +-------------------+
| | | |
|--- 1. DHCP Request --->| | |
|<-- 2. DHCP Ack --------| | |
| (IP & DNS Assigned) | | |
|--- 3. DNS Query ------>|------------------------->| |
| (canary URL) | | |
|<-- 4. DNS Response ----|<-------------------------| |
| (Resolved IP) | | |
|--- 5. HTTP GET ------->| | |
| (canary URL) | | |
|<-- 6. HTTP 302 --------| | |
| (Redirect to Portal)| | |
|--- 7. DNS Query ------>|------------------------->| |
| (Portal FQDN) | | |
|<-- 8. DNS Response ----|<-------------------------| |
| (Portal IP) | | |
|--- 9. HTTP/S GET ------>-------------------------------------------------------->|
| (Render Splash Page)| | |
|<-- 10. Render Page <-------------------------------------------------------------||
每個作業系統都使用一組不同的 Canary URL 和預期回應來判定網路狀態。Apple (iOS/macOS) 會探測 http://captive.apple.com/hotspot-detect.html，並預期收到在標題和內文中都僅包含 Success 字樣的 HTML 文件。Google (Android/ChromeOS) 會探測 http://connectivitycheck.gstatic.com/generate_204，並預期收到 HTTP 狀態碼 204 No Content 且內文為空。Microsoft (Windows 10/11) 則探測 http://www.msftconnecttest.com/connecttest.txt，並預期收到 Microsoft Connect Test 的純文字回應。
如果裝置收到預期的回應，就會判定該網路具有直接且不受阻礙的網際網路存取權限。如果回應被修改 - 例如收到 HTTP 302 重新導向 - 作業系統的 Captive Portal Assistant (CPA) 會立即啟動一個專用的沙盒瀏覽器視窗來顯示重新導向目標：即 Captive Portal 登入頁面。
HSTS 與 HTTPS 重新導向衝突
傳統的 Captive Portal 重新導向方法依賴 DNS 綁架或 HTTP 攔截。當未經身分驗證的使用者嘗試瀏覽任何網站時，閘道器會攔截 TCP 連接埠 80 (HTTP) 或連接埠 443 (HTTPS) 流量，並代表目的地伺服器進行回應，植入 HTTP 302 重新導向。雖然這在未加密的 HTTP 網頁瀏覽時代運作順暢，但在現代以 HTTPS 為主導的環境中，這會帶來嚴重的安全與營運挑戰。
主要障礙是 HTTP Strict Transport Security (HSTS)，這是一種在 RFC 6797 中規範的網頁安全策略機制。HSTS 強制網頁瀏覽器僅使用安全的 HTTPS 連線與網站進行互動。當瀏覽器嘗試連線到已啟用 HSTS 的網域時 - 例如 Google、Facebook 或銀行入口網站 - 它會嚴格禁止任何未加密的通訊，並執行嚴格的 SSL/TLS 憑證驗證。
如果 Captive Portal 閘道器嘗試攔截對 HSTS 網域的 HTTPS 請求，它必須向用戶端出示自己的 SSL 憑證或偽造的憑證。由於閘道器的憑證與所請求的網域名稱不符，用戶端的瀏覽器會偵測到中間人攻擊，並顯示無法繞過的安全警告（例如 NET::ERR_CERT_COMMON_NAME_INVALID 或 您的連線不是安全連線）。瀏覽器會完全封鎖該重新導向，導致 Captive Portal 頁面無法載入，使用者的連線也會中斷。
為了緩解此問題，現代企業無線網路利用了兩種先進的機制。首先，排除 OS 探測可確保作業系統傳送的未加密 HTTP 探測絕不會受到 HTTPS 攔截；閘道器必須允許未加密的 HTTP 探測，並使用標準的 HTTP 302 回應重導向至 Captive Portal 的安全完全限定網域名稱 (FQDN)。其次，RFC 8910 (Captive Portal API) 定義了一種機制，其中 DHCP 選項 (Option 114) 或 IPv6 路由器公告會通知用戶端裝置 Captive Portal API 端點的確切 URL。相容的用戶端裝置會直接查詢此 API 以獲取入口網站 URL 和網路狀態，而不是依賴暴力 DNS 綁架或 HTTP 重導向，從而完全繞過 HSTS 衝突。
實作指南
部署可靠的 Captive Portal 需要實體無線基礎架構（存取點、控制器、閘道器）與雲端入口網站平台之間的仔細協調。本節提供了一個與廠商無關的逐步實作指南，以確保跨企業網路的強健重導向相容性，並參考了 Cisco、Aruba 和 Ruckus 控制器中的標準設定。如需相關的存取控制架構，請參閱關於 如何使用雲端 RADIUS 實作 802.1X 驗證 的指南。
步驟 1：圍牆花園 (ACL) 設定
圍牆花園（Walled Garden）或存取控制清單 (ACL) 定義了未經驗證的訪客裝置在登入之前允許存取的特定外部網域、IP 地址或子網路。如果圍牆花園設定不正確，用戶端裝置將無法解析或載入 Captive Portal 的資源，從而導致空白畫面或逾時錯誤。
為了確保與 Purple 平台的無縫運作，圍牆花園必須包含以下元件。入口網站 FQDN 是託管 Splash Page 伺服器的完全限定網域名稱（例如 *.purple.ai 或地區變體）。如果入口網站支援社群登入，則必須包含身分識別提供者 (IdP) - 圍牆花園必須包含這些提供者用於 OAuth 驗證的龐大網域名稱清單。還必須包含託管 Splash Page 上使用的 CSS、JavaScript、字型或圖片的內容傳遞網路 (CDN)。
許多現代控制器在其圍牆花園設定中支援萬用字元網域名稱（例如 *.purple.ai）。控制器會動態窺探來自未驗證用戶端的 DNS 查詢；當用戶端查詢與萬用字元相符的網域時，控制器會暫時將傳回的 IP 地址新增至用戶端預先驗證的允許清單中。對於僅支援靜態 IP 地址的舊型控制器，管理員必須設定本機 DNS 代理，或定期更新與雲端入口網站關聯的靜態 IP 區段。
步驟 2：DHCP 和 DNS 最佳化
由於 Captive Portal 偵測高度依賴初始網路握手，因此必須針對高密度、瞬時環境優化 DHCP 和 DNS 設定。在零售商場、交通樞紐或體育場等高人流量的場所中，IP 位址耗盡是導致 Captive Portal 故障的常見原因。如果 DHCP 租期設定得太長（例如 24 小時），IP 池將迅速耗盡，導致新訪客無法取得 IP 位址。對於訪客網路，DHCP 租期應設定在 15 至 30 分鐘（900 至 1800 秒）之間。
訪客用戶端必須分配一個可靠、快速的 DNS 伺服器，以便能夠解析公共網域和本地 Captive Portal 的 FQDN。強烈建議使用企業級公共 DNS 解析器，例如 Cloudflare 1.1.1.1 或 Google 8.8.8.8，或本地高效能 DNS 轉發器。至關重要的是，無線閘道器必須允許未經驗證的用戶端進行 DNS 解析。如果防火牆規則封鎖了未驗證使用者的 port 53 (UDP/TCP) 流量，用戶端作業系統將無法解析 Canary URL，進而導致 Captive Portal 助理永遠無法啟動。
步驟 3：SSL/TLS 憑證管理
當訪客裝置被重新導向到 Captive Portal 時，瀏覽器會與該 Portal 的 FQDN 建立安全 HTTPS 連線。為了防止出現憑證警告畫面，Captive Portal 必須使用有效的、受大眾信任的 SSL/TLS 憑證來確保安全。自我簽署憑證會立即被現代行動作業系統封鎖，導致 Captive Portal 助理無法轉譯網頁。如果重新導向機制需要用戶端與本地閘道器 IP 進行通訊（例如，用於本地 MAC 與 IP 的繫結），則閘道器必須具有與其本地 FQDN 相符的有效憑證，且此 FQDN 必須可由訪客 DNS 解析。
最佳實踐
為了維持高效能的訪客無線網路、減少支援工單並最大化使用者滿意度，網路營運商應遵循以下產業標準和最佳實踐。
1. 針對社群登入優化 Walled Garden 規則
當使用社群登入選項來收集使用者個人資料時，必須精心維護 Walled Garden。社群媒體平台會頻繁更新其驗證子網域和 CDN IP 範圍。如果 Walled Garden 中遺漏了任何一個必要的網域，社群登入彈出視窗將無法載入或無限期當掉。
| 提供商 | 必要的 Walled Garden 網域 |
|---|---|
accounts.google.com, ssl.gstatic.com, fonts.gstatic.com, lh3.googleusercontent.com |
|
facebook.com, *.facebook.com, *.fbcdn.net, m.facebook.com |
|
| Apple | appleid.apple.com, appleid.cdn-apple.com, gsa.apple.com |
2. 轉型至基於設定檔的驗證與 OpenRoaming
雖然 Captive Portal 非常適合用於初始資料收集和接受服務條款，但每次造訪時重複登入流程會增加使用者摩擦。現代企業網路正越來越多地轉向基於設定檔的驗證和 Passpoint (Hotspot 2.0) 技術，例如 OpenRoaming。
在 Purple Connect 授權下，Purple 可作為 OpenRoaming 服務的免費身分識別提供商。Passpoint 允許訪客在首次造訪期間在其裝置上安裝安全設定檔。隨後造訪全球任何參與的場域時，裝置都會使用 WPA3-Enterprise 和 802.1X 驗證，在 Layer 2 自動且安全地與網路關聯，完全繞過 Captive Portal。這提供了無縫、類似行動網路的漫遊體驗，同時保持安全、加密的資料傳輸。如需詳細的實作指南，請參閱 如何使用 Cloud RADIUS 實作 802.1X 驗證 。
3. 確保符合法規架構
訪客 WiFi 的部署在設計上必須嚴格遵守全球資料隱私和安全標準。為了符合 GDPR / CCPA Compliance，Captive Portal 必須呈現清晰、明確的服務條款和隱私權政策。行銷通訊的同意必須由使用者主動勾選加入（不得預先勾選），且使用者必須擁有簡單直覺的機制來請求刪除資料。為了符合 PCI-DSS Compliance，如果訪客網路與場域的銷售時點情報系統 (POS) 共用相同的實體基礎設施，則必須執行嚴格的邏輯區隔。必須使用防火牆規則和 ACL 將訪客 VLAN 與生產和付款卡 VLAN 完全隔離。在無線安全方面，請實作 WPA3-Transition Mode，以允許較舊的裝置使用 WPA2-Personal 進行連線，同時讓較新的裝置受益於 WPA3 增強的安全功能，包括保護管理畫面 (PMF)。
疑難排解與風險緩釋
當收到訪客無線網路問題報告時，場域營運和前線工作人員需要清晰、有條理的診斷順序，以識別並解決根本原因。Captive Portal 故障通常分為兩類：用戶端設定錯誤和營運商端基礎設施問題。
用戶端診斷與解決方案檢查清單
對於協助訪客的前線工作人員，請依序執行以下步驟。
1. 停用作用中的 VPN。虛擬私人網路會建立一條從用戶端裝置直接到遠端伺服器的加密通道。由於 VPN 用戶端會在連線網路時立即嘗試加密並路由所有流量，因此會繞過本機閘道器的 DNS 劫持和 HTTP 重新導向規則。訪客必須暫時停用其 VPN 才能完成 Captive Portal 登入，之後即可安全地重新啟用 VPN。
2. 關閉專用/隨機 MAC 位址。現代作業系統（iOS 14+ 和 Android 10+）預設會啟用專用 WiFi 位址或 MAC 隨機化以防止追蹤。雖然這有利於隱私，但此功能會導致裝置在後續連線或短暫閒置後，向網路呈現不同的 MAC 位址。這會破壞基於 MAC 的工作階段持續性，迫使訪客重複進行驗證。請引導訪客在其裝置的無線設定中，針對該場域的 SSID 停用專用位址。
3. 繞過安全 DNS (DoH/DoT)。如果訪客設定了自訂 DNS 伺服器，或在瀏覽器設定中使用了 DNS-over-HTTPS (DoH) 或 DNS-over-TLS (DoT)，瀏覽器將拒絕接受本機閘道器劫持的 DNS 回應。使用者必須暫時在其瀏覽器設定中停用安全 DNS，或清除其裝置的 DNS 快取，以允許本機重新導向正常運作。
4. 強制執行未加密的 HTTP 連線 (NeverSSL)。如果 Captive Portal 協助程式無法自動啟動，訪客的瀏覽器可能會卡在嘗試載入 HTTPS 網頁。請引導訪客開啟一般的瀏覽器視窗，並瀏覽至 http://neverssl.com。由於此網站是專門設計為永不使用 SSL/TLS，因此閘道器可以攔截 HTTP 要求，並成功將 HTTP 302 重新導向植入至訪客網際網路登入畫面。
5. 忘記並重新加入網路。如果先前的驗證工作階段異常終止，用戶端裝置可能會保留過期的 DHCP 或 ARP 快取資料。在無線設定中忘記該網路並重新連線，可強制執行乾淨的 DHCP 握手，並重新啟動 Captive Portal 偵測程序。
營運商端基礎架構疑難排解
針對網路管理員在調查多個訪客回報 portal 失敗的系統性問題時，應進行以下檢查。監控 DHCP Pool 使用率，透過檢查本地閘道器或路由器上的 DHCP 範圍；如果 pool 的使用率達到 100%，請將租約時間縮短至 5 - 10 分鐘，以便快速回收已離開訪客的 IP 位址。驗證 DNS 重新導向規則，透過在閘道器介面上進行封包擷取 (PCAP)，以確認未經驗證的用戶端是否成功將 DNS 查詢發送到 port 53 並收到回應。稽核 Walled Garden 延遲，以確保 walled garden 已最佳化，且 walled garden 網域的 DNS 解析在控制器上正確快取。最後，檢查憑證過期情況，以確保安裝在無線控制器或閘道器上的 SSL/TLS 憑證有效、未過期，且由受信任的憑證授權單位 (CA) 簽署。
投資報酬率與商業影響
投資像 Purple 這樣強大、雲端管理的 Captive Portal 平台，能為企業場域帶來可衡量的財務與營運回報。藉由系統性地解決 Captive Portal 登入問題，企業組織能直接影響營收與利潤。
減少支援開銷與訪客阻力
對於旅宿和零售場域而言，前線工作人員經常花費寶貴的時間排除訪客 WiFi 連線故障。高 Captive Portal 失敗率會導致訪客挫折感增加和負面的線上評價、大量低複雜度的支援工單呈報給 IT 團隊，以及前線工作人員因分心而偏離主要職責所造成的營運效率低下。藉由導入 Purple 強大且跨平台相容的重新導向機制，場域通常能減少 50% 至 70% 的 WiFi 相關支援客訴。
最大化數據擷取與行銷投資報酬率
Captive Portal 是擷取寶貴第一方客戶數據（包括電子郵件地址、電話號碼和社群設定檔）的主要閘道。當 Captive Portal 無法載入時，場域就會失去註冊該訪客的機會。透過正常運作的 portal，場域在行銷溝通方面的選擇同意率 (opt-in rate) 可達到 60% 以上，從而快速成長其客戶 CRM 資料庫。藉由將訪客驗證與 WiFi Analytics 整合，場域營運商能深入洞察訪客行為，包括停留時間、回訪率以及不同區域的客流量模式。
開啟零售媒體與變現商機
對於購物中心、體育場館和展覽中心等大型場所而言，captive portal 代表了極具價值的數位房地產。透過利用 splash page 和登入後重定向畫面，營運商可以切入快速增長的零售媒體（Retail Media）市場。在顧客連線的確切時刻，向其展示高度精準、具備位置感知能力的廣告，或向品牌銷售贊助方案，將傳統的 IT 成本中心轉化為直接產生收益的資產。
參考文獻
[1] Wikipedia 貢獻者。"Captive Portal"。維基百科，自由的百科全書。 https://en.wikipedia.org/wiki/Captive_portal
[2] IETF RFC 6797。"HTTP Strict Transport Security (HSTS)"。網際網路工程任務組。 https://datatracker.ietf.org/doc/html/rfc6797
[3] IETF RFC 8910。"Captive-Portal Identification in DHCP and Router Advertisements"。網際網路工程任務組。 https://datatracker.ietf.org/doc/html/rfc8910
[4] Wireless Broadband Alliance。"OpenRoaming"。WBA。 https://wballiance.com/openroaming/
[5] NeverSSL。"NeverSSL: Helping you get online"。NeverSSL。 http://neverssl.com/
關鍵定義
Captive Portal
在向新連線的顧客網路使用者授與更廣泛的網際網路存取權限之前，向其呈現的網頁。該入口網站通常需要驗證（電子郵件、社群登入或優惠券代碼）、接受服務條款或兩者兼具。它是企業 WiFi 部署中收集顧客資料的主要機制。
IT 團隊在處理顧客 WiFi 投訴時，常將 Captive Portal 視為第一個故障點。瞭解入口網站的技術架構對於診斷登入頁面為何無法顯示至關重要。
DNS 綁架
一種 Captive Portal 閘道器所使用的技術，不論實際查詢的網域為何，本機 DNS 伺服器都會回傳 Captive Portal 伺服器的 IP 位址，以回應來自未認證用戶端的所有 DNS 查詢。這會強制用戶端的瀏覽器連線到入口網站，而非原先預期的目的地。
DNS 綁架是大多數 Captive Portal 重新導向實作背後的核心機制。它對 HTTP 流量有效，但會被用戶端裝置上的 DNS-over-HTTPS (DoH) 和 DNS-over-TLS (DoT) 設定阻擋。
HTTP Strict Transport Security (HSTS)
一種網路安全策略機制 (RFC 6797)，指示瀏覽器僅使用 HTTPS 與網站進行通訊，並拒絕任何 HTTP 連線或包含無效 SSL 憑證的連線。一旦瀏覽器從網域收到 HSTS 標頭，即會在指定的持續時間 (max-age) 內強制執行此策略，即使使用者手動輸入 HTTP URL 也是如此。
HSTS 是現代裝置上 Captive Portal 重新導向失敗的首要原因。當閘道器試圖攔截對已啟用 HSTS 網域的 HTTPS 請求時，瀏覽器會偵測到憑證不符並封鎖重新導向，進而導致入口網站無法載入。
Captive Portal Assistant (CPA)
內建於現代作業系統 (Apple 的 CNA、Android 的 CPA、Windows 的 NCSI) 中的沙盒化、輕量級瀏覽器程序，當作業系統偵測到其位於 Captive Portal 後方時會自動啟動。CPA 在限制性環境中轉譯起始頁面，以防止入口網站存取裝置憑證或永續性儲存空間。
CPA 是促使大多數裝置上自動彈出登入頁面的原因。如果 CPA 無法啟動 (例如因 VPN 或 DoH)，訪客必須手動瀏覽至入口網站 URL。
Walled Garden
一種驗證前的存取控制清單 (ACL)，定義了未認證的訪客裝置在完成 Captive Portal 登入前，允許存取的特定外部網域、IP 位址或子網路。在完成驗證之前，walled garden 之外的資源都將被封鎖。
設定錯誤的 walled garden 是 Captive Portal 失敗最常見的原因之一，特別是對於需要存取多個第三方 OAuth 網域的社群登入流程。
MAC Address Randomization
現代行動作業系統 (iOS 14+、Android 10+) 中的一項隱私功能，可讓裝置在連線至每個 WiFi 網路時，呈現隨機產生的 MAC 位址，而非其硬體指派的 MAC 位址。在連線期間，該隨機位址也可能會定期變更。
MAC 隨機化會破壞 Captive Portal 工作階段的持續性，因為閘道器使用 MAC 位址來追蹤已驗證的用戶端。當 MAC 變更時，閘道器會將該裝置視為新的、未認證的用戶端，進而強制進行重新驗證。
RFC 8910 (Captive Portal API)
一項 IETF 標準，定義了一種網路機制，可使用 DHCP Option 114 (適用於 IPv4) 或 IPv6 路由器公告選項，向用戶端裝置告知 Captive Portal 的存在及其 URL。相容的裝置會直接查詢公告的 API 端點以判斷其網路狀態並取得入口網站 URL，從而消除了對 DNS 綁架的需求。
RFC 8910 是用於 Captive Portal 偵測、符合標準的現代 DNS 綁架替代方案。它透過在網路層傳達入口網站 URL，而非試圖攔截 HTTP/HTTPS 流量，來解決 HSTS 衝突。
DNS-over-HTTPS (DoH)
一種透過 HTTPS 連線將 DNS 查詢傳送至信任的解析器 (例如 Cloudflare 1.1.1.1 或 Google 8.8.8.8) 來進行加密的協定，而非將其作為純文字 UDP 封包傳送至網路指派的 DNS 伺服器。這可防止本機閘道器攔截或劫持 DNS 回應。
現代瀏覽器 (Chrome、Firefox、Edge) 與作業系統已越來越多預設啟用 DoH。當 DoH 處於作用中狀態時，Captive Portal 的 DNS 綁架機制將被繞過，且訪客網際網路登入畫面將不會自動出現。
NeverSSL
一個公共公用事業網站 (http://neverssl.com)，專為不使用 SSL/TLS 加密而設計。它可以作為 Captive Portal 重新導向的可靠手動觸發器，因為閘道器隨時可以攔截其未加密的 HTTP 請求，並向其注入一個指向 Portal 登入頁面的 302 重新導向。
當訪客裝置無法自動顯示 Captive Portal 登入頁面時，NeverSSL 是建議的手動解決方案。第一線服務人員應接受培訓，引導訪客前往此 URL，以此作為第一線的排除步驟。
OpenRoaming (Passpoint/Hotspot 2.0)
由無線寬頻聯盟 (WBA) 開發的全球 WiFi 漫遊標準，允許裝置使用預先安裝的憑證設定檔，自動且安全地驗證加入參與的 WiFi 網路，而無需手動進行 Captive Portal 互動。驗證過程使用 WPA3-Enterprise 和 802.1X 協定。
對於企業級訪客 WiFi，OpenRoaming 是超越 Captive Portal 的長期演進方案。在 Purple 的 Connect 授權下，Purple 充當 OpenRoaming 的免費身份提供者，使再次光臨的訪客在後續造訪時能夠完全繞過 Captive Portal。
範例
一家擁有 350 間客房的市中心飯店在所有樓層和公共區域部署了由 Purple 支援的訪客 WiFi 網路。櫃台每天收到 15 - 20 起因訪客無法載入 Captive Portal 登入頁面而產生的投訴。該飯店使用 Cisco Catalyst 9800 無線控制器和 Cisco ISR 4331 路由器。初步調查顯示，該問題在執行 iOS 17 的 iPhone 和 Android 13 裝置上最為常見。網路架構師應如何診斷並解決此問題？
從結構化的四層診斷開始。第 1 層 (DHCP)：登入 Cisco ISR 4331 並執行 show ip dhcp pool 和 show ip dhcp binding。檢查作用中綁定的總數與位址池大小的對比。如果利用率超過 85%，則表示位址池即將耗盡。使用 ip dhcp pool GUEST_WIFI 和 lease 0 0 30 將租期從預設的 1 天縮短為 1800 秒（30 分鐘）。第 2 層 (DNS)：在 Catalyst 9800 上，驗證驗證前 ACL（用於 Captive Portal SSID）是否允許 UDP 和 TCP 連接埠 53 流量傳輸到指派的 DNS 伺服器。在訪客 VLAN 介面上進行封包擷取，以確認 DNS 查詢已獲得回應。第 3 層 (Walled Garden)：導覽至 Catalyst 9800 GUI 的 Configuration > Tags & Profiles > Policy。檢查與訪客 SSID 相關聯的 URL 篩選器清單。確認已包含 *.purple.ai、accounts.google.com、*.facebook.com、appleid.apple.com 以及所有相關聯的 CDN 網域。在 URL 篩選器上啟用 DNS 探查，以允許通配符網域解析。第 4 層 (iOS 專用)：iOS 17 裝置使用 captive.apple.com/hotspot-detect.html 作為其探測 URL。確認 Catalyst 9800 正在攔截此 HTTP 請求，並傳回指向 Purple Portal FQDN（例如 https://portal.purple.ai）的 HTTP 302 重新導向。驗證 Purple Portal 憑證是否有效且非自我簽署。如果重新導向轉至控制器的本機 IP 而非雲端 Portal FQDN，請更新 SSID 設定中的外部重新導向 URL。
一家擁有 120 家分店的全國性零售連鎖店，已使用透過 Aruba Central 管理的 Aruba Instant AP 部署了顧客 WiFi。行銷團隊報告，Captive Portal 上的「使用 Google 登入」社群登入選項在約 30% 的顧客中失敗。普通的電子郵件登入選項運作正常。該問題斷續出現，且在最近更新了 Aruba 韌體的分店中更為常見。網路與 IT 團隊應該如何調查此問題？
社群登入斷續失敗而電子郵件登入成功，是經典的 Walled Garden 網域涵蓋範圍問題，可能是由於韌體更新重設或變更了驗證前 ACL 所致。請按以下步驟進行。步驟 1 - 重現與擷取：在受影響的分店中，將測試裝置連線到顧客 SSID 並嘗試 Google 登入。在點擊「使用 Google 登入」之前，開啟瀏覽器開發者工具（F12 > 網路索引標籤）。記錄任何失敗的要求 - 這些將顯示為紅色的項目，並帶有 ERR_CONNECTION_REFUSED 或 ERR_NAME_NOT_RESOLVED 等狀態碼。這些失敗的網域就是遺漏的 Walled Garden 項目。步驟 2 - 稽核 Aruba Central Walled Garden：登入 Aruba Central 並導覽至顧客網路的 SSID 設定。審查 Walled Garden / 白名單項目。Google 的 OAuth 流程至少需要：accounts.google.com、ssl.gstatic.com、fonts.gstatic.com、www.gstatic.com、lh3.googleusercontent.com 和 oauth2.googleapis.com。在韌體更新後，Aruba Central 可能已還原為範本導向的設定，從而遺漏了其中一些項目。步驟 3 - 啟用 DNS 探聽 (DNS Snooping)：在 Aruba Central 中，為顧客 SSID 啟用基於 DNS 的白名單。這允許 AP 動態解析並將符合已設定通配符模式（例如 *.google.com、*.gstatic.com）的網域所傳回的 IP 位址加入白名單。這比靜態 IP 白名單更具彈性，因為 Google 的 CDN IP 經常變更。步驟 4 - 驗證與部署：在試點分店測試修正程式，確認 Google 登入成功率達到 95% 以上，然後透過 Aruba Central 的群組原則部署將更新後的設定推送至所有 120 家分店。
練習題
Q1. 一間舉辦 2,000 人會議的會議中心報告指出，有 40% 的與會者無法在其裝置上顯示訪客 WiFi 登入頁面。活動在 30 分鐘前開始。無線基礎架構使用的是 Ruckus SmartZone 控制器。最可能的根本原因是什麼？最快的解決方法又是什麼？
提示：請考慮活動的規模 (同時有 2,000 個連線) 以及活動開始後經過的時間。想想在一個高密度活動的前 30 分鐘內，哪種網路資源最容易耗盡。
查看標準答案
最可能的根本原因為 DHCP 位址池耗盡。由於 2,000 名與會者在 30 分鐘內同時嘗試連線，訪客 VLAN 的 DHCP 位址池幾乎可以肯定已經枯竭，特別是在租期設定為預設的 8 或 24 小時的情況下。無法取得 IP 位址的與會者將看不到登入頁面，因為如果沒有分配到有效的 IP，Captive Portal 的偵測程序就無法開始。最快的解決方法是登入 Ruckus SmartZone 控制器，導覽至訪客 VLAN 的 DHCP 伺服器設定，並將租期縮短至 5 - 10 分鐘，以強制快速回收已離開或斷開連線之與會者的位址。此外，請檢查 DHCP 位址池大小是否足以應付預期的同時使用人數 - /24 子網路 (254 個位址) 的位址池對於 2,000 名與會者來說是不夠的。如果可以，請將位址池擴充至 /22 或 /21 子網路 (1,022 或 2,046 個位址)。作為第二項檢查，請驗證 SmartZone 上的預先驗證 ACL 是否允許來自未驗證用戶端的 DNS 查詢 (連接埠 53)，因為高流量的 DNS 流量有時會觸發速率限制規則。
Q2. 一間飯店的 IT 經理收到來自入住 412 號房客的投訴。該房客表示，WiFi 登入頁面短暫出現，他們輸入了電子郵件地址並接受了條款，但現在每隔 10 - 15 分鐘就被要求重新登入一次。同一樓層的其他房客並未報告此問題。該房客使用的是執行 iOS 17 的 iPhone 15。最可能的原因和解決方法是什麼？
提示：此問題僅限於單一裝置，且涉及在極短的時間間隔內重複進行重新驗證。請考慮 iOS 17 在預設情況下會對 WiFi 網路的 MAC 位址採取什麼動作，以及飯店的無線閘道器如何追蹤已驗證的作期。
查看標準答案
最可能的原因是 MAC 位址隨機化。iOS 14 及更新版本預設會啟用私設 Wi-Fi 位址（Private Wi-Fi Address），這會導致 iPhone 向每個網路提供隨機產生的 MAC 位址。在 iOS 17 中，隨機化的 MAC 可能會定期輪替（大約每 24 小時一次）或在每次與新網路建立關聯時輪替。飯店的無線閘道器是透過 MAC 位址來追蹤已驗證的訪客工作階段；當 MAC 位址變更時，閘道器會將該裝置視為新的、未驗證的用戶端並阻擋網際網路存取，進而再次觸發 Captive Portal。訪客的解決方案是針對該飯店的 SSID 停用私設位址：前往「設定」>「Wi-Fi」，點擊飯店 SSID 旁邊的 (i) 圖示，然後關閉「私設 Wi-Fi 位址」。該裝置將使用其硬體 MAC 位址重新連線，且工作階段將會持續，無需重複重新驗證。作為營運商端更長期的緩解措施，飯店應考慮實施基於 IP 位址（除 MAC 之外）的工作階段持續性，或為回訪訪客過渡到 OpenRoaming/Passpoint，這能完全消除 Captive Portal 重新驗證的問題。
Q3. 某家連鎖零售商的 IT 團隊使用 Purple 設定了新的 Captive Portal。Walled garden 已設定了 Portal 網域和主要的社群登入提供商網域。在測試期間，Portal 頁面載入正常，且電子郵件登入選項可以使用，但當測試人員點擊「使用 Google 登入」時，會短暫出現 Google 登入彈出視窗，然後在未完成驗證的情況下關閉。測試人員使用的是執行 Android 13 並搭載 Chrome 瀏覽器的 Samsung Galaxy S23。IT 團隊應該調查什麼？
提示：Google 彈出視窗出現但未完成便關閉 - 這代表最初重新導向至 Google OAuth 的步驟是運作的，但在驗證回呼或權杖交換期間發生了失敗。請思考除了 accounts.google.com 之外，完整的 Google OAuth 2.0 流程中還涉及哪些網域。
查看標準答案
此症狀 - Google 彈出視窗出現但未完成便關閉 - 指出最初重新導向至 Google 的 OAuth 步驟成功了（accounts.google.com 已在 walled garden 中），但後續一或多個 OAuth 回呼或權杖交換網域被阻擋了。Web 應用程式的 Google OAuth 2.0 流程涉及 accounts.google.com 之外的多個網域。IT 團隊應在測試裝置上開啟 Chrome DevTools（或使用桌上型電腦瀏覽器模擬該流程），點擊「使用 Google 登入」，並觀察「網路」索引標籤是否有任何失敗的請求。常見缺失的網域包括：oauth2.googleapis.com（權杖端點）、www.googleapis.com（API 呼叫）、ssl.gstatic.com 和 fonts.gstatic.com（用於登入頁面資源的 Google CDN），以及 lh3.googleusercontent.com（設定檔圖片載入，這可能導致彈出視窗懸停）。在 Aruba/Cisco/Ruckus 控制器設定中，將所有識別出缺失的網域新增至 walled garden，並在控制器支援 DNS snooping 的情況下使用萬用字元模式（*.googleapis.com、*.gstatic.com）。每次新增後重新測試，以隔離出特定的阻擋網域。一旦完整的 Google OAuth 流程成功完成，請在推出至生產環境之前，在 Android 和 iOS 裝置上驗證此修正。
繼續閱讀本系列
Ruijie 的 Captive Portal：搭配 Purple 訪客 WiFi 進行設定
說明 Purple 的雲端訪客 WiFi 如何透過網頁驗證和 RADIUS（自命令列設定）部署於 Ruijie RG 系列基地台之上，以及在哪裡可以找到確切的設定步驟。
設計 B2B Captive Portals：收集註冊姓名與公司資料
本指南為 IT 經理與場域營運商提供了一個與廠商無關的技術框架，用於設計 B2B captive portals。指南詳細說明了如何規劃註冊欄位以擷取註冊姓名和公司資料，在確保高填答率的同時，維持 GDPR 合規性並建立企業帳戶級別的情報。
Captive Portal 架構：安全性、重新導向與最佳實踐
一份關於企業級 Captive Portal 架構的權威技術參考指南。本指南為部署安全且富含數據的訪客 WiFi 網路的 IT 主管，深入剖析網路隔離、DNS 重新導向、RADIUS 認證以及安全合規性。