跳至主要內容
繁體中文

Captive Portal 登入：疑難排解與說明指南

本指南為理解、部署和排解企業級訪客 WiFi 環境中的 Captive Portal 登入系統提供全面的技術參考。本指南解釋了現代 Captive Portal 使用的確切 HTTP 重新導向和 DNS 綁架機制，詳細說明了 HSTS 和安全的 HTTPS 瀏覽器如何封鎖本機重新導向，並提供了一份清晰、可操作的疑難排解檢查清單，涵蓋用戶端修正（停用 VPN、關閉隨機 MAC 位址、使用 NeverSSL）和營運商端解決方案（Walled Garden 設定、DHCP 租用時間最佳化、DNS 攔截驗證）。場所營運商、IT 經理和網路架構師將發現本指南對於減少訪客支援工單並最大化其無線基礎架構的投資報酬率至關重要。

📖 3 分鐘閱讀📝 605 字數🔧 2 範例❓ 3 練習題📚 10 關鍵定義

收聽此指南

查看播客逐字稿
TITLE: Captive Portal 登入 — 疑難排解與說明 FORMAT: Purple 技術簡報播客 VOICE: 英式英文男性 — 資深方案架構師語氣 DURATION: 約 8 分鐘 --- [SECTION 1: 導言與背景 — 0:00 至 1:15] 您好，歡迎收聽本次來自 Purple 的技術簡報。我是您的主持人，今天我們將探討企業無線網路中最常見、但也最令人沮喪的挑戰之一：Captive Portal 登入失敗。 我們都遇過這種情況。您在飯店、零售店或機場連接到訪客 WiFi 網路，但卻什麼也沒發生。登入頁面沒有出現，您的網際網路連線中斷，只能盯著空白畫面或莫名其妙的安全警告。對於場域營運總監和 IT 經理來說，這不只是一個微不足道的技術小故障。它直接威脅到客戶滿意度、增加支援工單，並阻礙了收集有價值的訪客分析數據，而這些數據正是證明您無線基礎設施投資報酬率（ROI）合理性的關鍵。 在本次播客中，我們將深入剖析現代 Captive Portal 的底層機制。我們將詳細解釋 HTTP 重新導向機制是如何運作的、為什麼像 HSTS 這樣的安全網頁標準有時會阻擋它，並為您的訪客和 IT 團隊提供實用的疑難排解清單。讓我們開始吧。 --- [SECTION 2: 技術深度剖析 — 1:15 至 6:15] 要理解為什麼 Captive Portal 無法載入，我們首先必須了解裝置最初是如何偵測到它的。 當您的智慧型手機或筆記型電腦與開放的訪客 SSID 連結並透過 DHCP 接收 IP 位址時，作業系統不會等您開啟瀏覽器。在背景中，系統服務會立即向特定的、由廠商控制的金絲雀（canary）URL 發送一個未加密的 HTTP GET 請求。 對於 Apple 裝置，它會查詢 captive.apple.com/hotspot-detect.html 並尋找 "Success" 這個字。Google 裝置會查詢 gstatic generate-204 URL，並預期收到 204 No Content 狀態碼。Windows 裝置則會查詢 Microsoft 連線測試文字檔案。 如果網路具備開放的網際網路存取權，這些探測就會成功，作業系統也會保持安靜。但在訪客網路中，無線閘道器或控制器會攔截此 HTTP 探測。閘道器不會讓它到達公共網際網路，而是傳回指向 Captive Portal 認證頁面安全 FQDN 的 HTTP 302 或 303 重新導向。作業系統偵測到這個非預期的重新導向，意識到它位於 Captive Portal 之後，並立即彈出一個專用的沙盒化瀏覽器視窗 — 通常稱為 Captive Portal Assistant — 來顯示登入頁面。 這種重新導向機制多年來一直運作良好。但隨後迎來了 HTTPS 革命，以及一個名為 HSTS（HTTP Strict Transport Security）的重要標準。 HSTS 是一種安全政策，強制瀏覽器僅使用安全、加密的 HTTPS 連線與網站進行通訊。如果訪客連線到您的 WiFi，且其瀏覽器或應用程式嘗試與啟用 HSTS 的網域（例如 Google、Facebook 或其銀行入口網站）進行聯繫，瀏覽器將嚴格執行 SSL/TLS 憑證驗證。 如果您的無線閘道器嘗試攔截該 HTTPS 請求並將其重定向到 Captive Portal，它必須出示 SSL 憑證。由於閘道器的憑證與請求的網域名稱不符，瀏覽器會偵測到中間人攻擊。它會顯示一個巨大的、無法繞過的安全警告，並完全封鎖該重定向。使用者會看到一個損毀的頁面，且 Captive Portal 永遠無法載入。 為了解決這個問題，現代網路必須確保作業系統傳送的初始未加密 HTTP 探測免受 HTTPS 攔截，從而使它們能夠乾淨地重定向到 Portal 的安全網域。此外，我們看到 RFC 8910 正在被採用，它定義了一個標準化的 Captive Portal API。這允許 DHCP 伺服器直接向用戶端裝置告知 Captive Portal 的 URL，從而完全繞過對 DNS 劫持或 HTTP 重定向的需求。 --- [第 3 節：實施建議與陷阱 — 6:15 至 8:15] 那麼，我們該如何實施一個健全的 Captive Portal 來避免這些陷阱呢？ 首先，讓我們談談 Walled Garden（圍牆花園），或稱為驗證前存取控制清單（Access Control List）。這是未經驗證的訪客允許存取的外部網域清單。如果您的 Walled Garden 設定錯誤，Captive Portal 頁面就根本無法載入。您不僅必須包含您登入頁面的 FQDN（例如 Purple 的雲端伺服器），如果您提供社群登入，還必須包含任何社群身分驗證提供商（如 Google、Apple 或 Facebook）的網域。由於這些提供商會不斷更新其驗證網域和 CDN IP 範圍，因此使用支援萬用字元網域窺探（wildcard domain snooping）的無線控制器是絕對必要的。 第二，最佳化您的 DHCP 和 DNS。在購物中心或體育場等繁忙的場所，IP 位址耗盡是一個無形的殺手。如果您的訪客 DHCP 租約時間設定為預設的 24 小時，您的 IP 位址將迅速耗盡。請將訪客租約時間設定在 15 到 30 分鐘之間。此外，請確保您的 DNS 伺服器具有高度回應能力，且允許未經驗證的使用者進行 DNS 查詢。如果他們無法解析 Canary URL，則 Portal 偵測程序在啟動之前就宣告失敗。 最後，考慮轉移到像 OpenRoaming 這樣基於設定檔的身分驗證。在我們的 Purple Connect 授權下，Purple 可作為 OpenRoaming 的免費身分驗證提供商。這使再次光臨的訪客能夠在 Layer 2 自動且安全地連線到您的 WiFi，在首次造訪後完全繞過 Captive Portal。它提供了無縫、類似行動網路的體驗，同時保持頂級的安全防護。 --- [單元 4：快速問答 — 8:15 至 9:15] 讓我們根據場地營運團隊最常遇到的問題，進行一次快速問答。 問題一：為什麼我的訪客 WiFi 登入頁面沒有自動顯示？ 這幾乎總是因為訪客裝置上啟用了 VPN，或者因為他們使用了自訂的安全 DNS 設定（例如 DNS-over-HTTPS）。這兩種情況都會阻止本地閘道器攔截初始的 HTTP 探測。 問題二：訪客如何手動強制載入 Captive Portal 頁面？ 請指導他們開啟一般的瀏覽器視窗，並輸入 http://neverssl.com。因為該網站的設計旨在從不使用 SSL，閘道器可以輕鬆攔截請求並觸發重定向。 問題三：為什麼訪客每次離開幾分鐘後就必須重新登入？ 這是由於 MAC 位址隨機化所致，這是現代 iOS 與 Android 裝置上的預設隱私功能。它會向網路呈現一個新的 MAC 位址，從而中斷工作階段的持續性。請指導他們停用訪客 SSID 的「私有位址」（Private Address）。 --- [單元 5：總結與後續步驟 — 9:15 至 10:00] 總結來說，可靠的訪客 WiFi 體驗建立在對 Captive Portal 機制的深入理解之上。透過最佳化您的圍牆花園、管理 DHCP 範圍，並向您的一線工作人員宣導簡單的用戶端解決方案（如停用 VPN 和使用 NeverSSL），您可以大幅減少支援工單並保持您的訪客連線。 為了提供企業級的可靠性，Purple 的雲端管理 Captive Portal 平台開箱即可提供強大的跨裝置相容性，確保您的重定向機制每次都能完美運作。 感謝您收聽本次 Purple 技術簡報。如需更多指南和資源，請造訪我們的網站 purple.ai。下次見，祝您網路安全，訪客連線順暢。

📚 核心系列的一部分：Captive Portal 終極指南 →

header_image.png

執行摘要

對於現代企業場所而言，訪客無線網路不再只是單純的便利設施；它代表了客戶互動、營運情報和品牌定位的關鍵接觸點。然而，這些網路的商業價值完全取決於初始連線體驗的可靠性。當訪客連線到網路，而 Captive Portal 登入頁面無法顯示時，場所會立即面臨現場摩擦增加、支援工單暴增以及失去數據擷取機會的困境。

這些故障的核心在於安全的網路標準與 Captive Portal 歷來使用的網路層攔截技術之間存在著根本性的衝突。現代網頁瀏覽器和作業系統的設計旨在偵測並阻止未經授權的流量重導向，以保護使用者免受中間人 (MitM) 攻擊。透過了解精確的 HTTP 和 DNS 重導向順序、HTTP 嚴格傳輸安全 (HSTS) 等安全協定的影響，以及破壞這些機制的用戶端設定，IT 部門可以實施強健的組態，確保無縫引導。

本指南詳細介紹了 Purple 的雲端託管 Guest WiFi 平台如何應對這些挑戰，以在所有消費型作業系統中提供高可用性的重導向，從而將場所支援開銷降至最低，並最大化無線基礎設施投資的回報。無論您是部署在 餐旅業 、 零售業 、 醫療保健 還是 交通運輸 環境中，本指南中的原則和檢核表皆普遍適用。

技術深入探討

為了有效排除 Captive Portal 故障，網路管理員必須了解用戶端裝置連線到開放式或預共用金鑰 (PSK) 訪客無線網路時發生的確切事件順序。現代作業系統（包括 Apple iOS/macOS、Google Android、Microsoft Windows 和 Linux 發行版）不會等待使用者開啟瀏覽器來測試網際網路連線能力。相反地，它們會在完成關聯和 DHCP 階段後，立即執行自動化的主動探測機制。

Captive Portal 偵測順序

連線和驗證過程遵循高度結構化的順序：

步驟 動作 技術說明 預期成功指標
1 關聯 用戶端在第 2 層與訪客 SSID 進行關聯。 成功的 802.11 關聯框架交換。
2 IP 預配 DHCP 伺服器指派 IP 地址、子網路遮罩、閘道器和本機 DNS 伺服器。 用戶端收到 DHCP ACK 封包。
3 主動探測 作業系統背景服務傳送未加密的 HTTP GET 請求至特定廠商的 canary URL。 HTTP 200 OK (Apple/Windows) 或 HTTP 204 No Content (Google)。
4 攔截與重新導向 無線閘道器/控制器攔截 HTTP 探測，並傳回指向入口網站的 HTTP 302/303 重新導向。 HTTP 302 重新導向至 Captive Portal FQDN。
5 入口網站轉譯 Captive Portal 助理 (CPA) 瀏覽器引擎開啟並轉譯歡迎頁面。 成功轉譯登入介面。 
+--------+             +------------+             +------------+             +-------------------+
| 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 <-------------------------------------------------------------||

captive_portal_redirect_flow.png

每個作業系統都使用一組特定的 Canary URL 和預期回應來判定網路狀態。Apple (iOS/macOS) 會探測 http://captive.apple.com/hotspot-detect.html，預期會收到一個在標題和內文中都只包含 Success 字樣的 HTML 文件。Google (Android/ChromeOS) 會探測 http://connectivitycheck.gstatic.com/generate_204，預期會收到一個狀態碼為 204 No Content 且主體為空的 HTTP 回應。Microsoft (Windows 10/11) 會探測 http://www.msftconnecttest.com/connecttest.txt，預期會收到 Microsoft Connect Test 的純文字回應。

如果裝置收到預期的回應，就會判定該網路具有直接且暢通無阻的網際網路存取權限。如果回應被修改（例如收到 HTTP 302 重新導向），作業系統的 Captive Portal 助理 (CPA) 會立即啟動一個專用的沙盒瀏覽器視窗，以顯示重新導向的目的地：Captive Portal 登入頁面。

HSTS 與 HTTPS 重新導向衝突

傳統的 Captive Portal 重新導向方法依賴 DNS 劫持或 HTTP 攔截。當未經驗證的使用者嘗試瀏覽任何網站時，閘道器會攔截 TCP 連接埠 80 (HTTP) 或連接埠 443 (HTTPS) 的流量，並代表目的地伺服器做出回應，注入 HTTP 302 重新導向。雖然這在未加密的 HTTP 網頁瀏覽時代運作順暢，但在現代以 HTTPS 為主導的環境中，這會帶來嚴重的安全與營運挑戰。

主要的障礙是 HTTP 嚴格傳輸安全 (HSTS)，這是 RFC 6797 中規範的一種網頁安全策略機制。HSTS 強制瀏覽器僅使用安全的 HTTPS 連線與網站進行互動。當瀏覽器嘗試連線至已啟用 HSTS 的網域（例如 Google、Facebook 或銀行入口網站）時，它會嚴格禁止任何未加密的通訊，並執行嚴格的 SSL/TLS 憑證驗證。

如果 Captive Portal 閘道器嘗試攔截發往 HSTS 網域的 HTTPS 請求，它必須向用戶端出示自己的 SSL 憑證或偽造的憑證。由於閘道器的憑證與所請求的網域名稱不相符，用戶端的瀏覽器會偵測到中間人攻擊，並顯示無法繞過的安全警告（例如 NET::ERR_CERT_COMMON_NAME_INVALID 或 您的連線不是私密連線）。瀏覽器會完全封鎖重新導向，導致 Captive Portal 頁面無法載入，進而讓使用者面臨連線中斷的狀況。

為了減輕此問題，現代企業無線網路採用了兩種先進機制。第一，豁免作業系統探測 (OS probes) 可確保作業系統發送的未加密 HTTP 探測永遠不會受到 HTTPS 攔截；閘道器必須允許使用標準 HTTP 302 回應將未加密的 HTTP 探測重導向到 Captive Portal 的安全完全符合網域名稱 (FQDN)。第二，RFC 8910 (Captive Portal API) 定義了一種機制，其中 DHCP 選項 (Option 114) 或 IPv6 路由器公告會通知用戶端裝置 Captive Portal API 端點的確切 URL。相容的用戶端裝置會直接查詢此 API 以獲取入口網站 URL 和網路狀態，而不是依賴暴力 DNS 劫持或 HTTP 重導向，從而完全繞過 HSTS 衝突。

實作指南

部署可靠的 Captive Portal 需要在實體無線基礎架構（Access Points、控制器、閘道器）與雲端入口網站平台之間進行仔細的協調。本節提供了一個與供應商無關、逐步說明的實作指南，以確保跨企業網路的強健重導向相容性，並參考了 Cisco、Aruba 和 Ruckus 控制器中的標準設定。對於相關的存取控制架構，請參閱關於 如何使用 Cloud RADIUS 實作 802.1X 驗證 的指南。

步驟 1：圍牆花園 (ACL) 設定

圍牆花園或存取控制清單 (ACL) 定義了未經驗證的訪客裝置在登入之前被允許存取的特定外部網域、IP 地址或子網路。如果圍牆花園設定不正確，用戶端裝置將無法解析或載入 Captive Portal 資源，從而導致空白畫面或逾時錯誤。

為確保與 Purple 平台的無縫運作，圍牆花園必須包含以下元件。入口網站 FQDN 是裝載歡迎頁面 (splash page) 伺服器的完全符合網域名稱（例如 *.purple.ai 或區域變體）。如果入口網站支援社群登入，則必須包含身分驗證提供者 (IdP) — 圍牆花園必須包含這些提供者用於 OAuth 驗證的廣泛網域清單。裝載歡迎頁面上使用的 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 網域
Google accounts.google.com, ssl.gstatic.com, fonts.gstatic.com, lh3.googleusercontent.com
Facebook 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 允許訪客在首次造訪時，於其裝置上安裝安全設定檔。隨後造訪全球任何參與的場域時，該裝置會自動且安全地在 Layer 2 使用 WPA3-Enterprise 與 802.1X 驗證與網路建立關聯，完全繞過 Captive Portal。這提供了無縫、類似行動網路的漫遊體驗，同時維持安全、加密的資料傳輸。如需詳細的實作指南，請參閱 如何使用 Cloud RADIUS 實作 802.1X 驗證 。

3. 確保符合法規架構

訪客 WiFi 的部署在設計上必須嚴格遵守全球資料隱私與安全標準。為了符合 GDPR / CCPA 合規性，Captive Portal 必須呈現清晰、明確的服務條款與隱私權政策。行銷傳播的同意必須由使用者主動勾選（而非預先勾選），且使用者必須擁有簡單直覺的機制來要求刪除資料。為了符合 PCI DSS 合規性，如果訪客網路與場域的銷售點 (POS) 系統共存於相同的實體基礎設施上，則必須強制執行嚴格的邏輯區隔。必須使用防火牆規則與 ACL 將訪客 VLAN 與生產和付款卡 VLAN 完全隔離。在無線安全方面，請實作 WPA3-Transition 模式，以允許較舊的裝置使用 WPA2-Personal 進行連線，同時讓較新的裝置受益於 WPA3 增強的安全性，包括受保護的管理框架 (PMF)。

疑難排解與風險緩釋

當收到訪客無線網路問題的報告時，場域營運與前台工作人員需要一個清晰、有結構的診斷順序來識別並解決根本原因。Captive Portal 失敗通常分為兩類：用戶端設定錯誤與營運商端基礎設施問題。

troubleshooting_checklist.png

用戶端診斷與排除檢查清單

對於協助訪客的前台工作人員，請依序執行以下步驟。

1. 停用啟用中的 VPN。 虛擬專用網路（VPN）會在用戶端裝置與遠端伺服器之間建立加密通道。由於 VPN 用戶端在連線到網路時會立即嘗試加密並路由所有流量，因此會繞過本地閘道的 DNS 綁架和 HTTP 重新導向規則。顧客必須暫時停用其 VPN 才能完成 Captive Portal 登入，之後即可安全地重新啟用 VPN。

2. 關閉專用/隨機 MAC 位址。 現代作業系統（iOS 14+ 和 Android 10+）預設會啟用「專用 Wi-Fi 位址」或「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 位址池使用率：藉由檢查本地閘道器或路由器上的 DHCP 範圍；如果位址池使用率達 100%，請將租約時間縮短至 5-10 分鐘，以快速回收已離開訪客的 IP 位址。驗證 DNS 重導向規則：藉由在閘道器介面上進行封包擷取 (PCAP)，以確認未經驗證的用戶端是否成功向 port 53 發送 DNS 查詢並收到回應。稽核 Walled Garden 延遲：以確保 Walled Garden 已最佳化，且 Walled Garden 網域的 DNS 解析在控制器上正確快取。最後，檢查憑證過期情況：以確保安裝在無線控制器或閘道器上的 SSL/TLS 憑證有效、未過期，且由受信任的憑證授權單位 (CA) 簽署。

投資報酬率 (ROI) 與商業影響

投資像 Purple 這樣強大、雲端託管的 Captive Portal 平台，能為企業場域帶來可衡量的財務與營運回報。藉由系統化地解決 Captive Portal 登入問題，企業組織能直接提升營收與盈餘。

減少支援開銷與訪客阻力

對於旅宿和零售場域，第一線服務人員經常需要花費寶貴的時間來排查訪客 WiFi 連線問題。高 Captive Portal 失敗率會導致訪客挫折感增加和負面的線上評論、大量低複雜度的支援工單呈報給 IT 團隊，以及第一線服務人員因分心而偏離其主要職責所導致的營運效率低下。藉由導入 Purple 強大且跨平台相容的重導向機制，場域通常能減少 50% 至 70% 與 WiFi 相關的支援客訴。

最大化資料擷取與行銷投資報酬率 (ROI)

Captive Portal 是擷取寶貴第一方客戶資料（包括電子郵件地址、電話號碼和社群設定檔）的主要閘道。當 Captive Portal 無法載入時，場域就會失去註冊該訪客的機會。透過正常運作的 Portal，場域可以讓行銷傳播的訂閱率達到 60% 以上，從而快速擴大其客戶 CRM 資料庫。藉由將訪客驗證與 WiFi Analytics 整合，場域營運商可以深入洞察訪客行為，包括停留時間、回訪率以及不同區域的人流量模式。

開啟零售媒體與變現商機

對於購物中心、體育館和展覽中心等大型場所而言，captive portal 代表了優質的數位版位。透過利用登入頁面和登入後重新導向網頁，營運商可以開拓快速成長的零售媒體市場。在顧客連線的確切時刻向其展示高度精準、具備位置感知能力的廣告，或向品牌銷售贊助方案，將傳統的 IT 成本中心轉化為直接帶來營收的資產。

參考資料

[1] 維基百科貢獻者。"Captive Portal"。《維基百科，自由的百科全書》。 https://en.wikipedia.org/wiki/Captive_portal

[2] IETF RFC 6797。"HTTP Strict Transport Security (HSTS)"。網際網路工程任務組 (Internet Engineering Task Force)。 https://datatracker.ietf.org/doc/html/rfc6797

[3] IETF RFC 8910。"Captive-Portal Identification in DHCP and Router Advertisements"。網際網路工程任務組 (Internet Engineering Task Force)。 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 部署中收集顧客資料的主要機制。

在顧客 WiFi 投訴中，IT 團隊常將 Captive Portal 視為第一個故障點。瞭解該入口網站的技術架構對於診斷登入頁面為何無法顯示至關重要。

DNS Hijacking

一種 Captive Portal 閘道器所使用的技術，其中本機 DNS 伺服器會針對未經驗證之用戶端的所有 DNS 查詢返回 Captive Portal 伺服器的 IP 位址，而不管實際查詢的網域為何。這會強制用戶端的瀏覽器連接到 Portal，而不是原本預期的目的地。

DNS hijacking 是大多數 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 請求時，瀏覽器會偵測到憑證不符並封鎖重新導向，進而導致 Portal 無法載入。

Captive Portal Assistant (CPA)

內建於現代作業系統（Apple 的 CNA、Android 的 CPA、Windows 的 NCSI）中的沙盒化、輕量級瀏覽器處理程序，當 OS 偵測到其位於 Captive Portal 後方時會自動啟動。CPA 在限制型環境中呈現 Splash 頁面，以防止 Portal 存取裝置憑證或永續性儲存空間。

CPA 是導致登入頁面在大多數裝置上自動彈出的原因。如果 CPA 未能啟動（例如由於 VPN 或 DoH），訪客必須手動瀏覽至 Portal 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 端點，以判定其網路狀態並取得 Portal URL，從而消除對 DNS 劫持的需求。

RFC 8910 是用於 Captive Portal 偵測的現代且符合標準的 DNS 劫持替代方案。它透過在網路層傳輸 Portal URL，而不是嘗試攔截 HTTP/HTTPS 流量，解決了 HSTS 衝突。

DNS-over-HTTPS (DoH)

一種藉由將 DNS 查詢透過 HTTPS 連線傳送到受信任的解析器（例如 Cloudflare 1.1.1.1 或 Google 8.8.8.8），而不是將其作為純文字 UDP 封包傳送到網路分配的 DNS 伺服器來加密 DNS 查詢的協定。這可以防止本機閘道器攔截或劫持 DNS 回應。

在現代瀏覽器（Chrome、Firefox、Edge）和作業系統中，DoH 已預設啟用。當 DoH 處於作用中狀態時，Captive Portal 的 DNS 劫持機制會被繞過，且訪客網際網路登入畫面將不會自動出現。

NeverSSL

一個公共公用事業網站 (http://neverssl.com)，專門設計為永不使用 SSL/TLS 加密。它可作為 Captive Portal 重定向的可靠手動觸發器，因為閘道器可以始終攔截其未加密的 HTTP 請求，並向其注入 302 重定向至 Portal 登入頁面。

當訪客的裝置無法自動顯示 Captive Portal 登入頁面時，NeverSSL 是建議的手動因應措施。前台工作人員應接受培訓，引導訪客前往此 URL 作為第一線的解決步驟。

OpenRoaming (Passpoint/Hotspot 2.0)

由無線寬頻聯盟 (WBA) 開發的全球 WiFi 漫遊標準，允許裝置使用預先安裝的憑證設定檔，自動且安全地向參與的 WiFi 網路進行驗證，而無需手動進行 Captive Portal 互動。驗證使用 WPA3-Enterprise 和 802.1X 協定。

OpenRoaming 是企業級訪客 WiFi 超越 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 裝置上。網路架構師應如何診斷和解決此問題？

從結構化的四層診斷開始。第一層（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 分鐘）。第二層（DNS）：在 Catalyst 9800 上，驗證驗證前 ACL（用於 Captive Portal SSID）是否允許 UDP 和 TCP 53 連接埠的流量傳輸至分配的 DNS 伺服器。在訪客 VLAN 介面上進行封包擷取，以確認 DNS 查詢已獲得回應。第三層（Walled Garden）：導覽至 Catalyst 9800 GUI 的 Configuration > Tags & Profiles > Policy。檢查與訪客 SSID 關聯的 URL 篩選清單。確認已包含 *.purple.ai、accounts.google.com、*.facebook.com、appleid.apple.com 以及所有關聯的 CDN 網域。在 URL 篩選器上啟用 DNS 監聽（DNS snooping）以允許通配符網域解析。第四層（iOS 特定）：iOS 17 裝置使用 captive.apple.com/hotspot-detect.html 作為其探測 URL。確認 Catalyst 9800 正在攔截此 HTTP 請求，並向 Purple 入口網站 FQDN（例如 https://portal.purple.ai）傳回 HTTP 302 重新導向。驗證 Purple 入口網站憑證是否有效且非自我簽署。如果重新導向轉至控制器的本機 IP 而非雲端入口網站 FQDN，請更新 SSID 設定中的外部重新導向 URL。

考官評語： 此場景代表了最常見的企業級 Captive Portal 故障模式：高密度環境中的 DHCP 枯竭與不完整的 Walled Garden 結合。四層診斷方法至關重要，因為不同故障模式下的症狀通常相同——登入頁面就是無法顯示。在未先檢查 DHCP 的情況下直接跳到 Walled Garden 修正是一個常見的錯誤，會浪費大量時間。iOS 特定的檢查很重要，因為 Apple 的 Captive Portal 助理比 Android 的更嚴格；如果重新導向目標使用自我簽署憑證，或者無法透過分配的 DNS 伺服器解析入口網站 FQDN，它將拒絕轉譯入口網站頁面。此部署的另一種方法是在 ISR 4331 上啟用 RFC 8910 DHCP Option 114，這將允許 iOS 16+ 和 Android 12+ 裝置透過 DHCP 宣告的 API URL 偵測入口網站，從而完全繞過 DNS 綁架機制並從根本上解決 HSTS 衝突。

一家擁有 120 家分店的全國零售連鎖店，部署了使用 Aruba Instant AP 的顧客 WiFi，並透過 Aruba Central 進行管理。行銷團隊報告指出，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 位址加入白名單。由於 Google CDN 的 IP 經常變更，這比靜態 IP 白名單更具彈性。步驟 4 — 驗證與推廣：在試點分店測試此修正，確認 Google 登入成功率達到 95% 以上，然後透過 Aruba Central 的群組原則部署，將更新後的設定推送至所有 120 家分店。

考官評語： 此情境突顯了大規模企業部署中的關鍵營運風險：韌體更新會無形中重設安全或存取控制設定。關鍵的診斷洞察是電子郵件登入正常，但社群登入失敗 — 這立即將根本原因縮小到 walled garden，而非 DHCP、DNS 或憑證問題。使用瀏覽器開發人員工具來識別缺失的網域是一種實用且低成本的技術，一線 IT 人員無需封包擷取設備即可使用。建議使用萬用字元模式的 DNS 探聽而非靜態 IP 白名單，是雲端社群身分驗證提供商的正確長期解決方案，因為其 IP 範圍並非靜態，且僅記載為寬泛的 CIDR 區塊。如需深入探討零售環境中的網路存取控制，請參閱 [10 Best Network Access Control (NAC) Solutions for 2026](/blog/best-network-access-control) 指南。

練習題

Q1. 一家舉辦 2,000 人代表活動的會議中心報告稱，40% 的與會者無法在其裝置上顯示訪客 WiFi 登入頁面。活動於 30 分鐘前開始。無線基礎設施使用 Ruckus SmartZone 控制器。最有可能的根本原因是什麼，最快的解決方案是什麼？

提示：請考慮活動的規模（2,000 個同時連線）以及自活動開始以來已過的時間。思考在高密度活動的前 30 分鐘內，哪種網路資源最有可能被耗盡。

查看標準答案

最 thinkable 的根本原因是 DHCP 位址池耗盡。在 30 分鐘內有 2,000 名代表嘗試同時連線，訪客 VLAN 的 DHCP 位址池幾乎肯定已經耗盡，特別是如果租期時間被設定為預設的 8 或 24 小時。無法取得 IP 位址的代表將看不到登入頁面，因為在沒有分配有效 IP 的情況下，無法開始 Captive Portal 偵測順序。最快的解決方案是登入 Ruckus SmartZone 控制器，導覽至訪客 VLAN 的 DHCP 伺服器設定，並將租期時間縮短至 5-10 分鐘，以強制快速回收已離開或中斷連線之代表的位址。此外，請檢查 DHCP 位址池大小是否足夠滿足預期的同時在線使用者數量 —— 對於 2,000 名代表，254 個位址（/24 子網路）的位址池是不夠的。如果可能，請將位址池擴展到 /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 位址」，這會使 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 的 Samsung Galaxy S23 與 Chrome 瀏覽器。IT 團隊應該調查什麼？

提示：Google 彈出視窗出現但未完成便關閉，這代表最初重新導向至 Google 的 OAuth 程序已正常運作，但在驗證回呼（callback）或權杖交換期間發生了某些錯誤。請思考在整個 Google OAuth 2.0 流程中，除了 accounts.google.com 之外，還涉及哪些網域。

查看標準答案

此症狀（Google 彈出視窗出現但未完成便關閉）指出最初重新導向至 Google 的 OAuth 成功（accounts.google.com 已在圍牆花園中），但後續一或多個 OAuth 回呼或權杖交換網域被阻擋。Web 應用程式的 Google OAuth 2.0 流程涉及多個 accounts.google.com 以外的網域。IT 團隊應在測試裝置上開啟 Chrome 開發者工具（或使用桌上型電腦瀏覽器模擬此流程），點擊「使用 Google 登入」，並在「Network（網路）」索引標籤中觀察是否有任何失敗的請求。常見遺漏的網域包括：oauth2.googleapis.com（權杖端點）、www.googleapis.com（API 呼叫）、ssl.gstatic.com 和 fonts.gstatic.com（Google 登入頁面資源的 CDN），以及 lh3.googleusercontent.com（載入個人資料圖片，這可能會導致彈出視窗懸停無回應）。在 Aruba/Cisco/Ruckus 控制器配置中，將所有識別出遺漏的網域新增到圍牆花園中，若控制器支援 DNS Snooping，可使用通配符模式（例如 *.googleapis.com、*.gstatic.com）。每次新增後重新測試，以隔離具體被阻擋的網域。一旦完整的 Google OAuth 流程成功完成，請在 Android 和 iOS 裝置上驗證修正，然後再發布到實際運作環境中。

繼續閱讀本系列

如何在 Starlink 上設定 Captive Portal：偏遠地區與海事場所指南

本指南詳細介紹如何繞過 Starlink 原生硬體，並使用企業級路由設備整合雲端管理的 Captive Portal。您將學習如何克服 CGNAT 限制、強制執行 VLAN 隔離、管理衛星頻寬限制，並確保符合法規規範。

閱讀指南 →

Captive Portal 最佳做法：針對高轉換率與合規性的設計

本技術指南為 IT 經理、網路架構師和場域營運總監提供了部署 Captive Portal 的完整藍圖，在網路安全與高用戶轉換率之間取得平衡。內容涵蓋從 VLAN 區隔和 RADIUS 驗證，到符合 GDPR 規範的同意書設計與驗證方法選擇的完整架構。結合 Purple 於 2024 年在 80,000 多個場域和 4.4 億次登入的營運經驗，每項建議均基於真實的部署數據。

閱讀指南 →

如何優化 Captive Portals 以實現最大化網路安全與使用者轉換率

本指南為企業級場域優化 Captive Portals 提供完整的技術藍圖，涵蓋網路分段架構、身分驗證方法選擇、符合 GDPR 規範的同意書設計以及轉換率優化。本書專為飯店、連鎖零售、體育場館和公共部門機構的 IT 經理、網路架構師及 CTO 撰寫，協助其在網路安全與第一方數據收集之間取得平衡。Purple 在全球超過 80,000 個場域營運 Captive Portal 基礎設施，並在 2024 年處理了 4.4 億次登入，本指南所提供的框架皆源自於這些實務營運經驗。

閱讀指南 →