Ubiquiti UniFi 的 Captive Portal
本權威技術指南詳細介紹了在 Ubiquiti UniFi 網路應用程式上配置外部 Captive Portal (Purple) 的步驟。內容涵蓋底層網路機制、逐步部署訪客網路、Walled Garden 白名單、RADIUS 認證，以及針對高階 IT 專業人員與網路管理員的疑難排解策略。
收聽此指南
查看播客逐字稿
📚 核心系列的一部分：多租戶 WiFi →
執行摘要
隨著企業實體場域（從大型連鎖零售商 [1]、多站點餐旅集團 [2]，到主要交通樞紐 [3] 與教育機構 [4]）尋求最大化其無線基礎設施的價值，內建熱點控制器的限制已成為顯著的營運瓶頸。Ubiquiti UniFi 生態系統提供了高度可靠、具成本效益且可擴充的硬體。然而，其原生的訪客分頁（guest portal）缺乏現代企業營運所需的進階數據擷取、多站點分析、CRM 整合、全球隱私合規（GDPR、CCPA、PCI DSS）以及獲利能力。
本技術參考指南提供了將 Purple 的企業級 WiFi 智慧平台 [5] 覆蓋於 Ubiquiti UniFi 網路架構之上的完整架構說明。透過利用 UniFi 的 外部 Portal 伺服器（External Portal Server）功能，網路架構師與系統整合商可以繞過本地控制器的限制。此整合將訪客身分驗證導向至 Purple 安全的雲端託管身分與分析引擎，將基本工具轉化為企業級的行銷與營運資產。
技術深度剖析
為了部署安全且穩定的外部 Captive Portal，網路工程師必須了解未驗證用戶端連線至無線網路時發生的底層通訊與狀態移轉。
訪客連線與重新導向生命週期
UniFi Captive Portal 工作流程運作於嚴格的狀態模型。當用戶端關聯至已啟用訪客功能的 SSID 時，將啟動以下循序程序：
| 階段 | 元件 | 行動 / 狀態移轉 | 技術機制 |
|---|---|---|---|
| 1. 關聯 | 用戶端與基地台 (AP) | 用戶端關聯至 SSID；DHCP 伺服器分配 IP 地址、子網路遮罩、閘道器與 DNS 伺服器。 | 標準 802.11 關聯與 DHCP 租約。 |
| 2. 隔離 | UniFi 基地台 (AP) | AP 將用戶端 MAC 地址置於已隔離 / 待處理狀態 (authorized: false)。 |
於 AP 的虛擬介面上本地套用 Layer 2/3 阻擋規則。 |
| 3. DNS 攔截 | AP 本地精靈程序 | AP 執行本地 DNSmasq 程序以攔截來自待處理用戶端的所有 DNS 查詢。 | 無論用戶端的 DNS 設定為何，AP 都會將所有 port 53 (UDP/TCP) 流量重新導向至其本地 DNS 解析器。 |
| 4. HTTP 攔截 | AP 重新導向器 | AP 在 port 80 上執行輕量級 HTTP 重新導向器精靈程序。 | 攔截用戶端發出的任何 HTTP 請求。AP 回應 HTTP 302 Found 重新導向。 |
| 5. 重導向 | 用戶端瀏覽器 | 用戶端的瀏覽器（或作業系統的 Captive Portal 助理）被重導向至設定的外部入口網站 URL。 | 302 重導向 URL 會附加包含用戶端和 AP 中介資料的重要查詢參數。 |
| 6. 驗證 | 外部入口網站 (Purple) | 用戶端與 Purple 歡迎頁面互動，完成驗證（例如：社群登入、電子郵件註冊、SMS 一次性密碼 OTP）。 | 託管於 Purple 雲端基礎架構的安全 HTTPS 工作階段。 |
| 7. API 握手 | Purple Cloud & UniFi Controller | Purple 驗證憑證，並向 UniFi Network 應用程式發出安全的 API 呼叫。 | 包含用戶端 MAC 位址、站點 ID 和工作階段參數的 REST API 呼叫 (POST 請求)。 |
| 8. 授權 | UniFi Controller & AP | UniFi Controller 將用戶端狀態更新為 authorized: true，並將更新後的 ACL 推送至 AP。 |
AP 針對該用戶端 MAC 位址移除 Layer 2/3 阻擋，授予通往網際網路閘道器的完整路由權限。 |
重導向查詢參數
當 UniFi AP 發出 HTTP 302 重導向時，它會在外部入口網站 URL 後附加一組標準化的查詢參數。外部入口網站必須擷取這些參數，以識別用戶端並執行後續的 API 授權：
https://portal.purplehotspot.com/guest/s/default/?ap=94:2a:6f:d0:30:57&id=1c:71:25:63:e4:24&t=1742398732&url=http://connectivitycheck.gstatic.com%2F&ssid=purple-guest
ap：用戶端關聯的特定 UniFi Access Point 的 MAC 位址。id：請求網路存取的用戶端裝置之 MAC 位址。t：代表重導向啟動時間的 Unix 時間戳記，用於安全驗證。url：用戶端嘗試存取的原始 URL（通常是作業系統的 captive portal 偵測端點）。ssid：用戶端連線的 SSID 名稱，讓入口網站能呈現特定站點的品牌形象。
圍牆花園（授權前存取控制）
在用戶端獲得授權之前，除了授權前存取清單（通常稱為圍牆花園，Walled Garden）中明確定義的目的地之外，所有流量都會被阻擋。由於現代用戶端裝置會執行自動化的 Captive Portal 助理 (CPA) 以透過 HTTPS 測試連線，且外部驗證通常依賴第三方身分識別提供者 (IdP)，因此設定完備且準確的圍牆花園至關重要。
如果圍牆花園中遺漏了所需的網域或 IP 範圍，歡迎頁面將無法載入、社群登入按鈕會卡死，或者用戶端裝置會判定網路中斷而完全斷開 WiFi 連線。
實作指南
本節概述了將 Purple 的外部 Captive Portal 與 Ubiquiti UniFi 網路應用程式（控制器）整合所需的逐步設定步驟。
步驟 1：網路分段與 VLAN 設定
為確保企業級安全與合規性（例如 PCI DSS 和 GDPR），訪客流量必須與公司資源、POS 系統和 IoT 網路完全隔離。
- 導覽至 UniFi 網路應用程式中的 Settings > Networks。
- 點擊 Create New Network。
- 按如下方式設定網路：
- Name：
Purple Guest Network - VLAN ID：
90（或任何專用的訪客 VLAN 標記） - Network Type：Guest（這會自動套用用戶端隔離，防止訪客之間的通訊）。
- Gateway IP/Subnet：設定適當的子網（例如
10.90.0.1/22以支援最多 1022 個同時發生的訪客租約）。 - DHCP Range：啟用 DHCP 並定義範圍（例如
10.90.0.10到10.90.3.254）。 - DNS Server：設定為可靠的公共解析器（例如 Cloudflare
1.1.1.1和 Google8.8.8.8）以確保快速的 DNS 解析。
- Name：
步驟 2：訪客 SSID 設定
- 導覽至 Settings > WiFi 並點擊 Create New WiFi Network。
- 設定 SSID 參數：
- Name (SSID)：
Purple Guest WiFi - Security Protocol：Open（Captive Portal 將處理驗證）。
- Network：選擇在步驟 1 中建立的
Purple Guest Network(VLAN 90)。 - Client Device Isolation：確保將此選項切換為 ON。
- Name (SSID)：
- 向下捲動至 Hotspot Portal 並勾選 Enable Captive Portal 框。
步驟 3：設定外部入口網站伺服器
啟用 Hotspot Portal 後，您必須將驗證重導向至 Purple 的安全雲端伺服器。
- 導覽至 Settings > Profiles > Guest Hotspot（在舊版控制器中為 Settings > Guest Control）。
- 在 Authentication 下，選擇 External Portal Server。
- 設定以下欄位：
- IP / FQDN：輸入 Purple 提供的 FQDN（例如
portal.purplehotspot.com）。 - Use Secure Portal (HTTPS)：切換為 ON（此為安全性與現代瀏覽器相容性所必需）。
- Redirect Using Hostname：切換為 ON 並輸入 FQDN
portal.purplehotspot.com。 - Port：
443（標準 HTTPS）。 - HTTPS Redirection：切換為 ON（這允許 AP 攔截初始 HTTPS 請求並進行重導向，但需要仔細進行 DNS 管理）。
- IP / FQDN：輸入 Purple 提供的 FQDN（例如
步驟 4：設定預先授權存取（Walled Garden）
為了允許未經驗證的訪客載入 Purple 登入頁面並透過第三方身分識別提供者 (IdP) 進行驗證，請將以下網域和 IP 範圍新增至 Settings > Profiles > Guest Hotspot > Pre-Authorization Access 下的 Pre-Authorization Access 清單中：
[
"portal.purplehotspot.com",
"*.purple.ai",
"*.purplehotspot.com",
"accounts.google.com",
"ssl.gstatic.com",
"*.googleapis.com",
"*.facebook.com",
"*.facebook.net",
"*.fbcdn.net",
"*.apple.com",
"captive.apple.com",
"connectivitycheck.gstatic.com",
"*.microsoft.com",
"*.live.com"
]
注意：針對使用 Stripe 金流處理的部署，請將 *.stripe.com 和 *.stripe.network 新增至預先授權清單。
步驟 5：建立 API 握手
為使 Purple 能授權訪客，其雲端伺服器必須與您的 UniFi Network Application 進行通訊。
適用於 UniFi Network Application 9.1 及更新版本（推薦使用 REST API）
- 在 UniFi 控制器中，導覽至 Settings > Control Plane > Integrations。
- 在 API Keys 區段下，點擊 Generate New API Key。
- 分配一個名稱（例如：
Purple Integration Key）並將權限設定為 Administrator。 - 複製產生的 API Key。
- 登入您的 Purple Portal，導覽至 Venue Settings > Integration > Ubiquiti UniFi，貼上該 API Key 以及您 UniFi 控制器的公開 FQDN（例如：
unifi.yourdomain.com:443）。
適用於舊版控制器（憑證制 API）
- 導覽至 Settings > System > Admins。
- 建立一個專用的本地管理員帳戶（例如：
purple_api）。 - 分配 Administrator 或 Hotspot Operator 權限。
- 設定一個強式且獨特的密碼。
- 在 Purple Portal 中，於 UniFi Integration 分頁下輸入這些憑證。
最佳實踐
1. SSL 憑證要求
切勿在生產環境的 UniFi 控制器或外部入口網站伺服器上使用自簽名 SSL 憑證。現代網頁瀏覽器與作業系統的 Captive Portal 助理 (CPA) 執行嚴格的 SSL/TLS 驗證。自簽名憑證會觸發非常顯眼的安全性警告（例如：「您的連線不是私密連線」），導致極高的放棄率並損害品牌形象。
- 在 UniFi 控制器的 FQDN 上部署有效且受公開信任的 SSL 憑證（例如 Let's Encrypt 或商業 CA 憑證）。
- 確保控制器的 FQDN 無論從內部訪客 VLAN 還是公開網際網路都能正確解析。
2. DNS 設定
慢速的 DNS 解析是導致 Captive Portal 重導向緩慢的主要原因。
- 請勿將訪客 DNS 指向 UniFi 閘道器的本地 IP，除非該閘道器已設定高效能的 DNS 轉發。
- 相反地，請設定訪客 DHCP 範圍，直接向用戶端派發快速、具彈性的公共 DNS 伺服器（例如，主要：
1.1.1.1，次要：8.8.8.8）。
3. RADIUS 訪客 WiFi 設定（企業級替代方案）
對於需要以憑證或憑證為基礎的 802.1X 安全性，而非使用具有網頁入口網站的開放式 SSID 之場所，UniFi 支援外部 Cloud RADIUS 整合 [6]。
- 在 Settings > Profiles > RADIUS 下設定 RADIUS Profile。
- 輸入 Purple 提供的主要與次要 RADIUS 伺服器 IP 及共用金鑰（Shared Secrets）。
- 啟用 RADIUS Accounting 並將 Interim Update Interval 設定為
300秒，以確保即時工作階段追蹤。 - 在 SSID 設定下，將安全通訊協定設定為 WPA2 Enterprise 或 WPA3 Enterprise [7]，並選擇 RADIUS Profile。
疑難排解與風險緩釋
部署外部 Captive Portal 時，網路管理員經常會遇到幾種常見的故障模式。下表詳細說明了這些問題、其根本原因以及確切的緩釋步驟：
| 症狀 | 根本原因分析 | 糾正措施與緩釋方案 |
|---|---|---|
| 白畫面 / Portal 無法載入 | 用戶端裝置無法解析或連線至外部 portal 伺服器的 FQDN。 | 1. 確認 portal.purplehotspot.com 已加入 Pre-Authorization Access 預先授權允許清單。2. 確保訪客用戶端已透過 DHCP 取得有效的 IP 與 DNS 伺服器。 3. 在用戶端裝置上執行 DNS 查詢，以驗證是否能成功解析 portal FQDN。 |
| 「連線並非私密連線」SSL 錯誤 | UniFi Controller 正在使用自我簽署憑證，或者重導向的 FQDN 與 SSL 憑證的通用名稱 (Common Name) 不符。 | 1. 在 UniFi Controller 上安裝受公開信任的 SSL 憑證。 2. 驗證 Redirect Using Hostname 已啟用，且與憑證上的 FQDN 完全一致。 3. 在 UniFi 訪客控制設定中停用「Redirect HTTPS」，以防止 AP 嘗試攔截連接埠 443 上的 HTTPS 流量，這會自然地觸發 SSL 警告。 |
| 驗證成功，但網路遭封鎖 | Purple 雲端已成功驗證使用者，但向 UniFi Controller 授權用戶端 MAC 位址的 API 呼叫失敗。 | 1. 檢查防火牆規則，確保從 Purple 的 IP 範圍輸入到 UniFi Controller 的連接埠 443（舊版為 8443）已開放。2. 驗證在 Purple Portal 中輸入的 API 金鑰或本機管理員憑證是否有效，且具備系統管理員 (Administrator) 權限。 3. 檢查 UniFi Controller 記錄檔 ( server.log) 以確認是否有 API 驗證失敗。 |
| 社群登入（例如 Google）按鈕無法運作 | 身分識別提供者 (IdP) 的驗證網域被 AP 的存取控制清單封鎖。 | 1. 將特定 IdP 的完整萬用字元網域新增至 Pre-Authorization Access 預先授權允許清單（例如 *.google.com、*.googleapis.com）。2. 如果使用 Facebook，請確保 Facebook SDK 網域已完全列入白名單。 |
| 頻繁斷線 / 重新驗證提示 | UniFi Controller 工作階段逾時時間短於 Purple 工作階段持續時間，或者 DHCP 租約時間太短。 | 1. 將 UniFi 訪客熱點的 Session Timeout 設定與 Purple 工作階段策略對齊（例如 24 小時）。 2. 將訪客 VLAN 上的 DHCP 租約時間增加至至少 12 或 24 小時，以防止 IP 位址耗盡與工作階段中途重新驗證。 |
投資報酬率與商業影響
雖然部署外部 Captive Portal 需要仔細的網路工程規劃，但其帶來的商業成效與投資報酬率（ROI）遠超過初始實作的複雜性。
企業數據收集與 CRM 強化
原生的 UniFi 訪客入口網站是一個「盲目」的公用程式，它僅授予網際網路存取權限，而無法收集使用者身分。藉由重疊 Purple，場域可以完全符合 GDPR 和 CCPA 合規性的方式收集寶貴的第一方數據（電子郵件、電話號碼、社群個人資料）。這些數據會自動與 CRM 系統、行銷平台（例如 Salesforce、HubSpot、Mailchimp）和會員計劃進行即時同步，從而實現高針對性的行銷活動，進而提高回訪率和客戶終身價值。
多站點管理與白牌化
對於託管服務供應商（MSP）和多站點企業營運商而言，透過獨立的 UniFi 控制器管理數百個場域的訪客 WiFi 是極其低效的。Purple 提供單一、集中的雲端儀表板，無論底層的 UniFi 控制器分佈如何，都能管理全球所有場域的歡迎頁面、合規條款和分析數據。
即時分析與空間智慧
Purple 將 UniFi 無線網路轉化為強大的感測器陣列。藉由分析探測請求（probe requests）和連線中繼資料，Purple 提供了深度的空間智慧，包括：
- 客流量分析：總訪客人數、路過流量及轉換率（從路過到進入）。
- 停留時間：平均造訪時間，依客戶類型（新客戶與回訪客戶）進行細分。
- 回訪頻率與間隔：客戶回訪的頻率以及兩次造訪之間間隔的時間。
- 場域熱點圖：訪客流量與密度的視覺化呈現，使零售商和場域營運商能夠最佳化動線佈局和人力配置。
透過零售媒體網路實現變現
對於體育場、購物中心和機場等大型場館，Captive Portal 歡迎頁面代表了極具價值的數位房地產。Purple 讓場館能夠透過與零售媒體網路整合來將此空間變現，在顧客連線的當下直接向其投放針對性的程式化廣告、贊助登入體驗和在地化促銷活動。
參考資料
- [1] Purple 零售方案： 零售場域的 WiFi 行銷與分析
- [2] Purple 餐旅方案： 飯店與餐廳的企業訪客 WiFi 解決方案
- [3] Purple for Transport: 交通樞紐的公共 WiFi 與分析
- [4] Purple for Healthcare: 醫療設施的患者與訪客 WiFi 解決方案
- [5] Purple Core Products: 企業級顧客 WiFi 平台
- [6] Cloud RADIUS 整合指南： 如何使用 Cloud RADIUS 實施 802.1X 驗證
- [7] 網路存取控制最佳實踐： 2026 年 10 大最佳網路存取控制 (NAC) 解決方案
- [8] Cisco 無線參考（比較架構）： Cisco 無線 AP：2026 年產品與部署指南
- [9] 教育界 WiFi 參考： 學校 WiFi：2026 年管理員與 IT 指南
- [10] Purple 分析平台： WiFi 分析與行銷平台
關鍵定義
Captive Portal
一個攔截訪客初始網路連線的網頁，在授予完整網際網路存取權限之前，要求進行身分驗證、註冊或接受條款。
在連接至開放式訪客 SSID 時立即遇到；由 AP 重定向器和外部入口網站伺服器管理。
External Portal Server
託管訪客歡迎頁面並處理使用者身分驗證的第三方網頁應用程式（例如 Purple），可繞過內建控制器入口網站的限制。
在 UniFi 訪客熱點設定中進行配置，以取代原生的 UniFi 登入頁面。
Walled Garden (Pre-Authorization Access)
未經驗證的用戶端在完成 Captive Portal 登入流程之前可以存取的網域、子網域或 IP 位址白名單。
對於載入入口網站頁面本身、CSS/JS 資產以及第三方 OAuth 登入端點至關重要。
DNSmasq
在 UniFi 存取點上本機執行的輕量級 DNS 轉發器和 DHCP 伺服器，用於在預先授權狀態下攔截並重定向訪客 DNS 查詢。
處理初始 DNS 重定向，強制用戶端裝置觸發其內建的 Captive Portal 助理。
API Authorization Handshake
外部入口網站伺服器 (Purple) 向 UniFi 控制器發起安全 API 呼叫，以將用戶端 MAC 位址從「隔離」狀態轉換為「已授權」狀態的過程。
在使用者於歡迎頁面成功完成登入流程後立即發生。
Client Device Isolation
一種安全功能，可防止同一 SSID 或 VLAN 上的無線用戶端彼此通訊，從而降低本機網路攻擊的風險。
在 UniFi WiFi 和網路設定中啟用，以保護訪客隱私並確保場所網路的安全。
RADSEC (RADIUS over TLS)
一種透過將 RADIUS 身分驗證和計費流量封裝在安全 TLS 通道中來確保其安全的協定，可防止在公用網路上被竊聽和竄改。
UniFi Network 8.4+ 支援此功能，適用於使用 WPA2/WPA3 企業版的安全多站點企業部署。
CPA (Captive Portal Assistant)
iOS、Android、Windows 和 macOS 上內建的作業系統公用程式，透過嘗試獲取已知的 HTTP/HTTPS 端點來自動偵測 Captive Portal。
連接後立即在使用者裝置上觸發「登入 WiFi」彈出式視窗。
範例
一家擁有 150 台 UniFi AP 且在 AWS 上自行代管 UniFi 網路應用程式的高人流量購物中心需要部署 Purple。IT 團隊希望使用 Google 和 Facebook 社群登入來進行訪客認證。然而，在初步測試期間，訪客點擊社群登入按鈕後會面臨空白畫面或 DNS 解析錯誤。
此問題是由於嚴格的 Walled Garden（授權前存取）限制所致，該限制阻止了訪客裝置在獲得授權前解析或連線到 Google 和 Facebook 的認證端點。若要解決此問題，網路管理員必須登入 UniFi 網路應用程式，導覽至 Settings > Profiles > Guest Hotspot，然後展開 Pre-Authorization Access 區段。他們必須新增 Google 和 Facebook 身分驗證提供商的完整萬用字元網域。對於 Google，這包括 accounts.google.com、ssl.gstatic.com 和 *.googleapis.com。對於 Facebook，則需要 *.facebook.com、*.facebook.net 和 *.fbcdn.net。此外，請確保訪客網路的 DHCP 範圍配置為直接向用戶端發布快速的公共 DNS 伺服器（例如 1.1.1.1 和 8.8.8.8），而不是指向本機 UniFi 閘道，因為本機閘道可能會成為授權前 DNS 查詢的瓶頸。
一家 MSP 正在為擁有 50 家精品飯店的連鎖集團部署 Purple。每家飯店在現場都有一個本機 UniFi Cloud Gateway Max。MSP 希望從單一 Purple 帳戶管理所有站點，但擔心安全性以及考慮到本機閘道位於具有 NAT 的動態公共 IP 後方，Purple 的雲端將如何與各個本機控制器進行回傳通訊以授權訪客 MAC 地址。
最佳架構是利用 UniFi 的官方 REST API 搭配輸入連接埠轉發（inbound port forwarding）或反向代理，並結合動態 DNS (DDNS)。對於每家飯店：1) 在 Cloud Gateway Max 上配置 DDNS 主機名稱（例如 hotel01.mspdomain.com），以便隨時追蹤閘道的公共 IP。2) 在閘道上設定連接埠轉發規則，將高位非標準連接埠（例如 10443）上的輸入 HTTPS 流量轉發到本機閘道的管理 IP（連接埠 443）。3) 在 UniFi 控制器中，導覽至 Settings > Control Plane > Integrations 並產生唯一的 API Key。4) 在 Purple Portal 中，為每家飯店配置一個唯一的「Venue」（場地），並選擇 Ubiquiti UniFi 整合。輸入帶有轉發連接埠的唯一 DDNS 位址（例如 hotel01.mspdomain.com:10443）以及為該站點產生的特定 API Key。最後，透過將來源 IP 限制在 Purple 的公共雲端 IP 範圍內，來確保每個閘道上的輸入連接埠轉發安全，防止來自網際網路其他地方的未授權存取。
練習題
Q1. 網路管理員在 UniFi 訪客網路上配置了外部 Captive Portal。在測試期間，他們發現 Captive Portal 歡迎頁面成功載入，但在訪客輸入其電子郵件地址並按一下「連接」後，瀏覽器掛起並最終顯示逾時錯誤。用戶端仍處於隔離狀態。此問題最可能的原因是什麼？應該如何進行調查？
提示：入口網站頁面已載入，這意味著 DNS 和 walled garden 運作正常。失敗發生在訪客提交其憑證*之後*。
查看標準答案
最可能的原因是 Purple 雲端與 UniFi Controller 之間的 API 授權交握失敗。由於 Captive Portal 頁面已載入且訪客能夠進行互動，因此 DNS 和預先授權存取（Walled Garden）設定是正確的。然而，當訪客完成驗證時，Purple 會嘗試向 UniFi Controller 發送安全的 REST API 呼叫（POST 請求），以授權該用戶端的 MAC 地址。如果 UniFi Controller 位於防火牆、NAT 後方，或位於未進行適當連接埠轉發的私有網路中，或者 API 憑證（或 API Key）不正確，授權請求將會失敗或逾時。調查步驟：1) 驗證 UniFi Controller 的 FQDN 和連接埠是否可從 Purple 的 IP 範圍公開存取。2) 檢查保護 UniFi Controller 的閘道器上的入站防火牆規則，確保連接埠 443（或 8443）已開啟。3) 在 Purple Portal 中，驗證 UniFi 整合設定是否包含正確的 API Key 或管理員憑證，以及 Controller URL 是否正確。4) 檢查 UniFi Controller 的 server.log 檔案，查看是否有任何來自 Purple IP 的入站連線嘗試或 API 驗證錯誤。
Q2. 企業部署需要使用外部 Captive Portal 設定訪客網路。網路架構師希望對所有 Captive Portal 流量使用 HTTPS，以防止憑證被竊聽。他們在 UniFi 中啟用了「使用安全入口網站 (HTTPS)」和「使用主機名稱重定向」，並指向外部 Portal FQDN。然而，當用戶端連線時，其瀏覽器立即顯示嚴重的「SSL 憑證一般名稱不符合」或「憑證不被信任」警告，從而阻斷存取。該如何解決這個問題？
提示：思考是哪台裝置提供初始重定向，以及它向用戶端呈現了什麼 SSL 憑證。
查看標準答案
此問題是由於 UniFi 存取點（AP）或 Controller 試圖攔截來自用戶端的 HTTPS 請求並將其重定向到 Captive Portal 所致。當用戶端連線並嘗試造訪 HTTPS 網站（例如 https://www.google.com）時，AP 的重定向器會攔截該流量。若要透過 HTTPS 進行重定向，AP 必須呈現 SSL 憑證。由於 AP 並未擁有 www.google.com 的有效 SSL 憑證，用戶端瀏覽器會檢測到中間人（MITM）狀況並拋出嚴重的 SSL 警告。解決方法：1) 確保 UniFi Controller 本身已安裝與其設定的 FQDN 相符且受公開信任的有效 SSL 憑證。2) 在 UniFi 訪客網路設定中，停用「重定向 HTTPS」（僅保持啟用 HTTP 重定向）。這可防止 AP 試圖攔截 HTTPS 流量。相反地，網路將依賴用戶端裝置作業系統的 Captive Portal 助理（CPA），該助理會使用純 HTTP 端點（例如 http://captive.apple.com 或 http://connectivitycheck.gstatic.com）測試連線。AP 可以安全地在連接埠 80 上攔截這些 HTTP 請求，並將其重定向到 Purple Portal 的安全 HTTPS URL（https://portal.purplehotspot.com），而不會觸發任何瀏覽器 SSL 警告。
Q3. 某連鎖飯店希望為其 VIP 訪客網路部署 WPA3-Enterprise 安全性，同時保持與 Purple 分析平台的整合。本地 IT 團隊不確定是否可以將標準的外部 Portal 伺服器 Captive Portal 重定向與 WPA3-Enterprise 結合使用。此情境下正確的架構方法是什麼？
提示：WPA3-Enterprise 使用 802.1X 驗證，這發生在關聯階段，也就是在指派 IP 位址之前。這與帶有 Captive Portal 的開放式 SSID 有本質上的不同。
查看標準答案
WPA3-Enterprise (與 WPA2-Enterprise) 使用 802.1X 認證，這在根本上與標準的 Captive Portal 網頁重定向不相容。在 802.1X 網路中，認證發生在關聯階段 (Layer 2)，使用 EAP 方法 (例如 EAP-TLS 或 PEAP)，然後才會為用戶端分配 IP 地址或允許其進入網路。因此，您無法將用戶端重定向到網頁版 Splash Page。要將 WPA3-Enterprise 與 Purple 整合：1) 從「外部入口網站伺服器」模型轉變為 外部 RADIUS 模型。2) 在 UniFi Network Application 中設定 RADIUS 設定檔，輸入 Purple 的 Cloud RADIUS 伺服器 IP 地址、認證連接埠 (通常為 1812)、計費連接埠 (通常為 1813) 以及共享金鑰。3) 啟用 RADIUS 計費 並將 過渡更新間隔 (Interim Update Interval) 設定為 300 秒。4) 將 VIP SSID 設定為使用 WPA3 Enterprise 並選擇該 RADIUS 設定檔。當 VIP 訪客連線時，其裝置會使用其唯一的企業憑證或證書，直接向 Purple 的 Cloud RADIUS 伺服器進行認證。Purple 的 RADIUS 伺服器會授權該連線並接收計費更新，從而使場所能夠擷取連線分析、工作階段持續時間和數據使用量，而無需網頁版 Splash Page。
繼續閱讀本系列
CommScope Ruckus 與 Purple WiFi 整合：安裝與設定指南
本技術參考指南為 CommScope Ruckus 架構與 Purple WiFi 的整合提供了權威的設定指南。其中詳細介紹了使用 Guest WiFi Captive Portal、透過 802.1X 的安全員工 WiFi，以及使用 Ruckus Dynamic PSK 的多租戶網路隔離的逐步部署步驟。
Allied Telesis 基地台與 Purple WiFi 整合
本指南提供將 Allied Telesis TQ 系列基地台與 Purple WiFi 整合的完整設定指南。內容涵蓋外部 Captive Portal 重新導向、802.1X RADIUS 驗證，以及使用私有預共用金鑰 (PPSK) 進行動態 VLAN 導向，以實現安全的多租戶部署。
Grandstream GWN Access Points 與 Purple WiFi 整合
本權威技術參考指南詳細說明如何將 Grandstream GWN Access Points 與 Purple 的 Guest WiFi 和分析平台進行整合。內容涵蓋 Grandstream Captive Portal 設定、RADIUS AAA 設定、Walled Garden 設定、具備動態 VLAN 導向的安全員工 802.1X 驗證，以及多租戶 PPSK 分段，為部署大規模訪客與員工 WiFi 的 MSP 和 IT 團隊提供具體且逐步的指引。