跳至主要內容

什麼是 WiFi 登入頁面 (Splash Page)?

本技術參考指南為 IT 經理和網路架構師提供 WiFi 登入頁面的權威說明、其與 Captive Portal 的架構關係,以及具體可行的部署策略。內容涵蓋實作最佳實踐、合規性要求,以及如何衡量訪客 WiFi 基礎設施的商業影響力。

📖 4 分鐘閱讀📝 985 字數🔧 2 範例3 練習題📚 8 關鍵定義

收聽此指南

查看播客逐字稿
什麼是 WiFi Splash Page? — Purple 智慧簡報 [前言 — 約 1 分鐘] 歡迎來到 Purple 智慧簡報。我是您的主持人,今天我們要探討一個恰好位於網路基礎架構與客戶體驗交會點的主題:WiFi splash page。 現在,如果您是 IT 經理、網路架構師或場域營運總監,您幾乎肯定已經部署過這類頁面,或者正準備部署。但市場上對於 splash page 究竟是什麼、它與 captive portal 有何不同,以及最關鍵的——一個設計良好的頁面與一個會悄悄破壞顧客體驗並留下合規風險的頁面之間有何區別,存在著令人驚訝的混淆。 因此,讓我們深入探討。在接下來的十分鐘內,我將帶您了解其技術架構、關鍵的設計決策、來自餐旅業和零售業的實際部署案例,以及即使是經驗豐富的團隊也會踩到的特定陷阱。最後,您將獲得一個清晰的架構,用以評估或重新設計您自己的部署。 [技術深挖 — 約 5 分鐘] 讓我們從基本原理開始。WiFi splash page(有時稱為顧客 WiFi 登入頁面或 WiFi 登入頁面)是使用者在首次連接到顧客無線網路並開啟瀏覽器時所看到的網頁介面。它是您顧客 WiFi 體驗的前門。 但這正是術語容易混淆的地方。Splash page 與 captive portal 並不是同一回事,儘管這兩個術語在日常對話中經常混用。讓我對此進行精確的說明,因為這在架構上非常重要。 Captive portal 是網路層的機制——這項基礎架構組件會攔截未經身分驗證的 HTTP 流量、執行 DNS 重新導向,並將裝置保持在受限的網路狀態,直到完成身分驗證。它運作於 OSI 模型的第二層和第三層。這涉及您的存取控制器、如果您執行 802.1X 的 RADIUS 伺服器、您的 VLAN 設定以及您的 DNS 解析器。Captive portal 就是守門人。 相較之下,splash page 是呈現層——也就是 captive portal 呈現給使用者的網頁。它是顧客實際看到並與之互動的 HTML、CSS 和 JavaScript。它包含您的品牌形象、身分驗證選項、資料收集表單、您的 GDPR 同意機制以及您的服務條款。 簡單來說:captive portal 是鎖,而 splash page 是門。您兩者都需要,但它們提供截然不同的功能,且由不同的團隊管理——網路工程師負責 portal 基礎架構,而行銷與 IT 團隊則共同負責 splash page 的體驗。那麼,這在技術上是如何運作的?當裝置連線到您的訪客 SSID 時,它會被放入一個受限制的 VLAN(我們稱之為預先驗證 VLAN)。DNS 查詢會被攔截並解析為您的 Captive Portal 控制器的 IP 位址。任何 HTTP 請求(請注意,這就是為什麼僅限 HTTPS 的瀏覽對 Captive Portal 偵測帶來了一些有趣的挑戰)都會透過 302 回應重新導向至 Splash Page URL。該裝置的作業系統,無論是 iOS、Android 還是 Windows,都內建了 Captive Portal 偵測機制。Apple 裝置會 ping captivenetwork.apple.com;Android 裝置則會存取 connectivitycheck.gstatic.com。當這些請求傳回非預期的回應時,作業系統就會知道它處於 Captive Portal 後方,並會自動顯示登入提示。 一旦使用者完成了 Splash Page 流程(無論是輸入電子郵件地址、透過社群媒體登入進行驗證、接受條款,還是輸入優惠券代碼),Captive Portal 控制器就會在其驗證表中更新該裝置的 MAC 位址或 IP 位址,將其移至驗證後 VLAN,並授予完整的網際網路存取權限。系統會追蹤該工作階段,通常會套用可設定的逾時和頻寬原則。 現在我們來談談驗證方法,因為這正是企業價值開始產生差異化的地方。您有幾種選擇。最簡單的是一鍵點擊(click-through)——使用者只需接受條款即可獲得存取權限。不收集任何資料,摩擦極小,但對企業的價值也微乎其微。再進一步是電子郵件註冊,您可以藉此收集經過驗證的電子郵件地址。接著是社群媒體登入(Facebook、Google、Apple ID),這能為您提供更豐富的個人檔案和經過驗證的身分,不過您必須依賴第三方 OAuth 流程以及這些平台的資料分享政策。而在更進階的層面,您可以使用包含自訂欄位的表單註冊、會員計劃整合以及 CRM 同步。 驗證方法的選擇會直接影響您的資料品質、轉換率以及合規性表現。一鍵點擊能為您帶來接近 100% 的連線率,但第一方資料為零。詳細的註冊表單可能會將您的連線率降低到 60% 或 70%,但能為您提供具備行銷價值的實用資料。對於大多數企業部署而言,最佳平衡點是社群媒體登入或搭配單一行銷訂閱核取方塊的電子郵件註冊——摩擦力足夠低以維持高轉換率,資料品質也足夠高以具備商業實用價值。 在合規性方面,這是不可妥協的。如果您在英國或歐盟營運,GDPR 適用。您的 splash page 必須針對任何行銷傳播提供清晰、主動的同意機制。根據 GDPR 第 7 條,預先勾選的方框並非有效同意。您的隱私權聲明必須易於存取(而不是埋在 40 頁的 PDF 中),且您必須能夠證明同意是自由給予、具體、知情且明確的。如果您處於醫療保健環境中,您還需要考慮所收集的任何數據是否可能構成第 9 條規定的特殊類別數據。如果您的賓客 WiFi 網路傳輸任何付款卡數據(即使是間接的),PCI DSS 範圍蔓延是一個真正的風險,需要透過適當的網路分割來解決。 [實施建議與陷阱 — 約 2 分鐘] 好的,我們來談談部署。無論您是在擁有 200 間客房的飯店、50 家分店的零售連鎖店,還是擁有 40,000 個座位的體育場進行部署,您在開始時做出的架構決策將決定您在規模擴大時會經歷多少痛苦。 第一:雲端管理與地端部署。對於多站點部署,雲端管理的 Captive Portal 解決方案幾乎總是正確的答案。它們為您提供集中式的 splash page 管理、所有位置一致的品牌形象、即時分析,以及無需接觸個別存取控制器即可推送更新的能力。地端解決方案有其適用之處(高安全性環境、WAN 連線能力差的場地,或對數據落地有嚴格要求的組織),但營運開銷明顯更高。例如,Purple 的平台作為雲端管理的解決方案運作,無論供應商為何,都能與您現有的存取點基礎設施整合,這在多供應商環境中是一個顯著的優勢。 第二:不要低估重新導向延遲的問題。關於 Captive Portal 最常見的抱怨之一是 splash page 需要太長時間才能顯示。這通常是由以下三種原因之一引起的:DNS 重新導向回應時間慢、splash page 本身託管在效能不足的伺服器上,或者(這越來越常見)僅限 HTTPS 的瀏覽阻止了初始 HTTP 重新導向的觸發。現代作業系統對 Captive Portal 偵測的處理相當好,但在上線之前,您應該在 iOS、Android、Windows 和 macOS 上測試您的部署,因為其行為會有所不同。 第三:工作階段管理。預先決定工作階段的持續時間、過期時的處理方式,以及返回的用戶是否需要重新驗證。對於旅宿業,與客房預訂綁定的 24 小時工作階段非常合理。對於零售環境,您可能需要較短的工作階段,並搭配重新驗證提示以傳送新的促銷訊息。對於體育場或活動場地,單日工作階段通常較為合適。這些不僅僅是 UX 決策,它們還會影響您的 RADIUS 伺服器負載和分析數據品質。 現在來談談陷阱。我在企業部署中看到的最大問題,就是將 Splash Page 視為設定後即可置之不理的資產。您的 Splash Page 是一個即時的行銷管道。它應該根據季節進行更新、測試轉換率,並針對合規性變化進行審查——特別是隨著 GDPR 指引的演變。第二個陷阱是行動裝置最佳化做得不夠。超過 80% 的訪客 WiFi 連線來自智慧型手機。如果您的 Splash Page 沒有完全採用響應式設計,且無法在 4G 連線下於三秒內載入,您就會流失連線。第三個陷阱是忽略了驗證後的體驗。用戶連線後會發生什麼事?他們是進入帶有促銷優惠的品牌歡迎頁面?還是直接被丟到他們原本試圖瀏覽的任何網站?連線後的那個瞬間是高度受矚目的接觸點,但大多數營運商都完全浪費掉了。 [快速問答 — 大約 1 分鐘] 讓我快速解答一些我經常從 IT 和營運團隊那裡聽到的問題。 「我們可以使用現有的存取點(AP)嗎?」— 在大多數情況下,是的。像 Purple 這樣雲端管理的 Captive Portal 平台,可以透過標準 RADIUS 或 API 整合,與 Cisco Meraki、Aruba、Ruckus、Ubiquiti 以及大多數其他企業級 AP 廠商進行整合。 「我們該如何處理不支援 Captive Portal 偵測的裝置?」— 您可以設定一個 Walled Garden(圍牆花園):在驗證前可存取的 IP 地址和網域白名單。這能確保您的 Splash Page 本身始終可以存取。 「我們需要為訪客提供獨立的 SSID 嗎?」— 是的,絕對需要。訪客流量必須與您的企業網路隔離。最低要求是 VLAN 切割;最佳實踐是採用完全獨立的實體或邏輯網路,並擁有自己的網際網路出口。 「那 WPA3 呢?」— WPA3 是目前的無線安全標準,應該作為您任何新部署的預設設定。請注意,WPA3 使用等同同時驗證(SAE),這會改變交握行為——請確保您的 Captive Portal 控制器支援此功能。 [總結與後續步驟 — 大約 1 分鐘] 總結來說。WiFi Splash Page 是一個具備品牌形象且可互動的網頁介面,位於您的訪客 WiFi 網路前端。它是 Captive Portal 系統中面向用戶的組件,同時也是網路存取控制機制、數據收集工具、合規性檢查點和行銷管道。 關鍵的決策包括:驗證方法、資料欄位、同意機制、工作階段持續時間以及連線後的體驗。做好這些設定,您的顧客 WiFi 就會轉化為第一方數據資產,進而帶來可衡量的行銷投資報酬率(ROI)。如果設定錯誤,您將面臨合規性風險,並帶來令人沮喪的顧客體驗。 如果您正在評估或重新設計您的部署,我建議從 Purple 的顧客 WiFi 平台開始 — 它在單一雲端管理解決方案中處理了 Captive Portal 基礎架構、Splash Page 產生器、分析功能以及 CRM 整合。節目資訊中附有指向 Purple 顧客 WiFi 產品頁面,以及其關於雲端與地端 Captive Portal 部署指南的連結。 感謝您的收聽。我們下次見。

header_image.png

執行摘要

對於管理大規模網路的 IT 經理和網路架構師而言,網路存取控制與使用者呈現層之間的區別至關重要。WiFi 登入頁面(Splash Page)是呈現層——也就是呈現給連線至訪客無線網路之使用者的品牌化、互動式網頁介面。雖然它經常與 Captive Portal(攔截流量的底層網路機制)混為一談,但登入頁面是使用者體驗的前門,負責處理驗證、資料收集和合規性同意。

部署高效的登入頁面需要在減少使用者阻力與最大化企業資料精確度及安全性之間取得平衡。本指南將深入剖析登入頁面的技術架構,詳細介紹在旅宿業和零售業等複雜環境中的實作策略,並提供一個框架,說明如何利用 Guest WiFi 等解決方案將營運上的必要需求轉化為可衡量的資產。

技術深度剖析:架構與標準

要了解登入頁面,必須先了解為其提供服務的 Captive Portal 架構。Captive Portal 運作於 OSI 第 2 層和第 3 層。當裝置與訪客 SSID 建立關聯時,通常會被放入驗證前的 VLAN 中。在此狀態下,存取控制器會攔截 DNS 查詢和 HTTP 請求,並執行 302 重新導向至登入頁面 URL。

登入頁面本身則運作於第 7 層。它是用於收集使用者憑證或同意書的 HTML、CSS 和 JavaScript 介面。現代作業系統(iOS、Android、Windows)利用內建的 Captive Portal 網路助理(CNA)機制——例如 Apple 對 captivenetwork.apple.com 的查詢——來偵測此重新導向,並在虛擬瀏覽器中自動顯示登入頁面。

splash_vs_captive_portal.png

一旦使用者在登入頁面上完成驗證流程,Captive Portal 控制器就會收到 API 或 RADIUS(遠端使用者撥入驗證服務)授權訊息。接著,控制器會更新其狀態表,將裝置的 MAC 位址移至已授權狀態,通常會將用戶端轉移到具有完整網際網路路由的驗證後 VLAN,並套用頻寬或工作階段逾時原則。

驗證機制與 802.1X

雖然簡單的 Splash Page 依賴於註冊後使用基於 MAC 位址驗證的開放網路,但企業環境正日益轉向安全上網。Passpoint (Hotspot 2.0) 和基於設定檔的驗證利用 802.1X/EAP (可延伸驗證協定) 來提供加密連線。在這些情境中,Splash Page 可作為初始的上網入口網站,供使用者註冊並下載安全設定檔,從而擺脫傳統的開放式 SSID。Purple 作為 OpenRoaming 等服務的免費身分識別提供者,彌補了 Splash Page 註冊與無縫、安全後續連線之間的差距。

實作指南

在分散式企業中部署 Splash Page 需要標準化。無論您是為 零售 連鎖店還是 餐飲旅宿 場所進行配置,實作方法都決定了營運開銷。

  1. 架構選擇:在本地控制器和雲端管理解決方案之間進行選擇。雲端架構(詳見我們的指南 雲端型與本地端 Captive Portal:哪種適合您的企業? )提供了跨多個 AP 廠商的 Splash Page 集中管理,減少了設定偏差。
  2. 圍牆花園 (Walled Garden) 設定:確保載入 Splash Page 所需的 IP 位址和網域(包括 CDN、社群登入 API 和驗證伺服器)在預先驗證 ACL (存取控制清單) 中被明確允許。若未能正確設定圍牆花園,將導致 Splash Page 無法載入。
  3. 驗證策略:選擇符合企業目標的驗證方法。社群登入 (OAuth) 和表單式註冊可為 WiFi Analytics 收集高質量的數據,而簡單的點擊通過則提供高吞吐量,但無法擷取任何數據。
  4. 響應式設計:超過 80% 的訪客 WiFi 連線來自行動裝置。Splash Page 必須具備高度響應性,利用最小的承載量以確保即使在高密度、高干擾的射頻 (RF) 環境中也能快速轉譯。

splash_page_elements.png

最佳實踐與合規性

Splash Page 是主要的合規性檢查點。在受 GDPR 或 CCPA 管轄的司法管轄區內營運,需要嚴格遵守數據隱私標準。

  • 明確同意:行銷訂閱必須使用未勾選的核取方塊。預先勾選的方塊違反了 GDPR 第 7 條。
  • 數據最小化:僅要求提供服務或經同意的行銷所必需的數據。
  • PCI DSS 範圍:確保賓客 WiFi 網路與企業網路和銷售點(POS)系統在邏輯上完全隔離(透過 VLAN 和防火牆規則),以防止範圍擴大至 PCI 合規性稽核。
  • 無障礙設計:確保 Splash Page 符合 WCAG(網頁內容無障礙指南)標準,採用適當的對比度與便於螢幕閱讀器讀取的 HTML 語意。

收聽我們關於 Splash Page 架構與部署策略的高階技術簡報:

疑難排解與風險緩釋

即使是架構完善的部署也會遇到問題。常見的故障模式包括:

  • HTTPS 攔截失敗:隨著網路全面轉向 HTTPS,舊版 Captive Portal 若在沒有受信任憑證的情況下企圖攔截 HTTPS 流量,將會觸發嚴重的瀏覽器安全性警告(HSTS 錯誤)。緩釋措施是依賴作業系統層級、利用 HTTP 進行偵測的 CNA 機制,或是透過 Passpoint 實作安全上網。
  • DNS 解析延遲:如果在預先驗證狀態下分配的 DNS 伺服器反應緩慢或無回應,初始重新導向將會失敗。請確保賓客網路使用的是本機且高可用性的 DNS 解析器。
  • MAC 隨機化:現代行動作業系統為了隱私而採用隨機 MAC 位址。雖然這增加了對未驗證使用者進行長期追蹤的難度,但將工作階段與已驗證使用者設定檔(例如電子郵件或 CRM ID)綁定的 Splash Page,能有效減輕對分析和工作階段管理的影響。

ROI 與商業影響

部署 Splash Page 的商業影響,能將 IT 從成本中心轉變為營收推手。透過收集第一方數據,Splash Page 能直接為行銷與營運系統提供養分。

例如,在 交通運輸 樞紐中,Splash Page 分析能提供即時的人流量與停留時間指標。投資報酬率的衡量,不僅在於流暢的連線體驗減少了支援工單,更在於所產生的具體可行數據。網路效應策略(提供免費連線以推動用戶獲取)完全仰賴 Splash Page 作為轉換機制。最佳化的 Splash Page 能降低流失率、實現零售媒體變現,並支援會員系統整合,在初始連線完成後,持續提供可衡量的商業價值。

關鍵定義

登入頁面 (Splash Page)

呈現給嘗試連線至訪客網路之使用者的網頁式呈現層,用於驗證、同意聲明與品牌宣傳。

訪客 WiFi 的主要使用者介面,由 IT 與行銷部門共同管理。

Captive Portal

攔截流量並將未驗證使用者重新導向至登入頁面的網路層基礎架構。

在存取控制器或雲端平台上設定的閘門機制。

圍牆花園 (Walled Garden)

使用者在登入頁面上完成驗證之前可以存取的 IP 位址或網域白名單。

對於在登入過程中允許社群登入和 CDN 運作至關重要。

強制網路助理 (CNA)

自動偵測 Captive Portal 並彈出登入頁面的作業系統級虛擬瀏覽器。

透過消除手動開啟瀏覽器以觸發重新導向的需求,減少使用者阻力。

RADIUS

遠端用戶撥號驗證服務;一種提供集中式驗證、授權和計費 (AAA) 的網路協定。

由 Captive Portal 用於驗證憑證並在登入後套用網路原則。

MAC 隨機化

現代作業系統中的一項隱私功能,可為每個無線網路產生暫時性的 MAC 位址。

影響追蹤回訪裝置的能力,而無需要求其透過登入頁面重新進行驗證。

VLAN 分割

將實體網路邏輯分割為多個廣播網域的實務做法。

對於將訪客 WiFi 流量與企業基礎架構隔離以確保安全性和 PCI 合規性至關重要。

Passpoint (Hotspot 2.0)

一種使用 802.1X 無縫、安全驗證至公用 WiFi 網路的標準,可繞過傳統的開放式 SSID 登入頁面。

訪客 WiFi 的演進,其中登入頁面作為初始佈署入口網站,而非每日登入畫面。

範例

一家擁有 200 間客房的飯店需要部署訪客 WiFi 解決方案,該方案須與其物業管理系統 (PMS) 整合,以限制非房客的頻寬,同時為會員計劃成員提供高級別的頻寬。

  1. 部署雲端託管的 Captive Portal,並透過 RADIUS 與現有的 AP 基礎設施整合。
  2. 設定登入頁面以要求輸入房號和房客姓氏。
  3. Captive Portal 透過 Webhook 查詢 PMS API 以驗證憑證。
  4. 驗證成功後,RADIUS 伺服器會傳回廠商專屬屬性 (VSA),將高級頻寬原則設定檔套用至該使用者的工作階段。
考官評語: 此方法有效地將登入頁面用作通往 PMS 的 API 閘道。透過利用 RADIUS VSA,網路能根據使用者身分動態佈署 QoS,同時滿足安全與商業需求。

某大型連鎖零售商的訪客 WiFi 登入頁面流失率高達 40%。他們目前要求填寫包含郵寄地址在內的 6 欄位註冊表單。

  1. 重新設計登入頁面,以利用社群登入(Google、Apple)和簡化的 2 欄位電子郵件註冊表單。
  2. 實作漸進式分析 (Progressive Profiling):在首次造訪時擷取最少量的資料,並在隨後重新連線時提示輸入其他詳細資訊(例如用於會員獎勵的生日月份)。
  3. 確保 Walled Garden 包含社群提供商所需的 OAuth 網域。
考官評語: 減少連線點的阻力至關重要。漸進式分析在行銷團隊對豐富資料的需求,與 IT 團隊對高連線吞吐量和使用者滿意度的授權之間取得了平衡。

練習題

Q1. 某場域回報,透過 Android 裝置連線的使用者可以看到 Splash Page,但 iOS 裝置的使用者卻只看到空白畫面。最可能的架構設定錯誤是什麼?

提示:考慮不同作業系統用來偵測 Captive Portal 的特定網域。

查看標準答案

Walled Garden(認證前 ACL)可能設定錯誤。它允許了 Android 連線檢查網域,但封鎖了 Apple 的 CNA 網域(例如 captivenetwork.apple.com)。必須更新存取控制器,以允許流量傳送到 Apple 用於 Captive Portal 偵測的特定網域。

Q2. 行銷團隊希望在現有的 Splash Page 中加入 Facebook 登入選項。從網路工程的角度來看,在功能正常運作之前需要進行什麼設定變更?

提示:在使用者完全通過認證之前,裝置如何連線到 Facebook 的伺服器?

查看標準答案

網路工程師必須更新 Walled Garden,以包含 Facebook 的 OAuth 網域和 CDN。若不進行此設定,裝置在仍處於受限的認證前狀態時,將無法連線到 Facebook 以完成認證交握。

Q3. 在合規性稽核期間,發現 Splash Page 包含一個預先勾選的方格,寫著「我同意接收行銷電子郵件」。立即的風險是什麼?補救措施又是什麼?

提示:考慮關於同意的 GDPR 第 7 條規定。

查看標準答案

立即的風險是違反 GDPR,因為該法規規定同意必須是自由給予且明確的。預先勾選的方格在法律上是無效的。補救措施是立即更新 Splash Page 的 HTML,確保行銷訂閱核取方塊預設為未勾選,需要使用者採取主動確認動作。