Ubiquiti UniFi 訪客入口網站未重定向：原因與解決方法

UniFi Captive Portal 通常會停止重新導向，是因為 SSID 不再是啟用狀態的 Hotspot、訪客用戶不處於未授權狀態、所需的預先授權路徑無法連線到外部服務，或者門戶網站無法向 UniFi 傳達授權。請嚴格按照以下順序驗證這些步驟 1 2 3。

要進行 UniFi 訪客重新導向，必須滿足哪些條件？

這是一份針對先前可正常運作之設定的故障排除指南。您不需要重新建置整個訪客 WiFi 網路。相反地，本指南將從訪客裝置開始，一路排查到控制器，然後再返回外部服務。這種順序可以防止常見的錯誤：在得知具體是哪一個步驟失敗之前，就先修改 SSID、防火牆或 DNS 設定。

Ubiquiti 將 Hotspot 定義為可套用於 WiFi SSID 或整個網路或 VLAN 的功能。然後在該 Hotspot 設定中啟用 Captive Portal。因此，訪客 VLAN、訪客 SSID 或網路隔離原則本身，並不能證明重新導向流程已處於活動狀態。如果 UniFi Network 應用程式的使用者介面在更新後發生變更，請遵循 Ubiquiti 官方文件確認 Hotspot 和 Captive Portal 的目前狀態，而不是依賴舊有的選單位置。1

對於外部門戶網站，Ubiquiti 描述了精確的使用者歷程。裝置連線到設定了 Hotspot 和 Captive Portal 的 SSID。它一開始作為 GUEST，狀態為 authorised: false。當它嘗試發出網頁請求時，UniFi 會將其重新導向到外部門戶網站伺服器。伺服器接收用戶端和基地台的識別詳細資訊，獲取 UniFi 用戶端 ID，然後透過 Network API 請求授權。成功完成的流程會使狀態變更為 authorised: true。2

診斷規則： 切勿將「已連線至 WiFi」的情況視為成功條件。成功的條件是未授權的測試用戶端到達預期的登入服務，完成其程序，顯示 authorised: true，然後獲得預期的存取權限。 2

在開始隔離故障之前，您需要準備什麼？

請使用全新且未授權的測試裝置。已獲得授權的裝置是極差的診斷工具，因為它可能會跳過您需要檢查的步驟。請記錄 SSID 或網路名稱、測試時間、裝置類型、作業系統，以及裝置是顯示自動登入提示，還是僅顯示一般的瀏覽器結果。Apple 表示 iOS 和 macOS 在首次連線網路時會發送探測，以偵測 Captive Portal 攔截並顯示登入頁面。這意味著缺少自動視窗是一個有用的線索，但並非閘道器無法重新導向一般瀏覽器請求的決定性證據。 4

保持測試範圍受限。不要一開始就新增廣泛的訪客存取規則。不要刪除運作正常的整合。不要從另一個場域複製預先授權的允許清單。您必須確定訪客的實際路徑以及確切中斷的階段。如果問題涉及多個站點，請在每個站點中使用全新的裝置進行相同的測試。站點之間的差異比關於共享控制器更新的理論更有用。

對於 Purple 部署，請在測試期間保持開啟當前文章 UniFi Integration: Best Practices & Common Questions。Purple 使用直接的控制器 API 登入，而非背景 RADIUS 認證通道。因此，專用的 API 帳戶必須是控制器本地帳戶、具有管理員寫入權限、停用雙重認證 (2FA) 且不需要變更密碼。Purple 也針對硬體主控台與自行託管的 UniFi OS Server 記錄了不同的帳戶位置要求。3

如何隔離失敗的步驟？

從存取層開始。確認受影響的 WiFi SSID 或其整個網路的設定仍被設為已啟用 Captive Portal 的 Hotspot。Ubiquiti 記錄了目前的 WiFi - SSID 路徑，並針對整個網路或 VLAN 設定單獨記錄了 Hotspot Zone 路徑。此區別解答了常見的 UniFi guest network vs hotspot 混淆。如果 Hotspot 功能未啟用，即使隔離的訪客網路是正確的分段，仍可能無法啟動登入工作流程。1 接下來，檢查新連線的用戶端。您必須驗證記錄的未授權狀態，而非僅僅是無線關聯。如果不存在該狀態，請返回 Hotspot 設定以及所選的 SSID 或網路。在此階段正確之前，請勿繼續進行 DNS、外部提供商或 UDM Pro 整合。外部服務無法授權未曾進入外部 Hotspot 流程的訪客。2

然後，從同一部裝置觸發一般的網頁請求。如果該請求到達外部服務，請保留結果作為證據。若未到達，請專注於訪客分段的預先授權路徑。Purple 僅在訪客完成其外部流程後才連接訪客，其支援指南指出，提交表單後出現空白畫面與訪客規則封鎖了完成登入所需的隱藏網頁流量有關。請驗證 Pre - Auth ACL 與授權後設定。宣告取自提供商目前文件的必要目標路由路徑。3

在此階段，請精確使用 allow list 一詞。這不是已授權訪客的一般網頁目的地列表，而是核准前所需的路由集合，例如外部服務以及完成登入交易所需的必要元素。Purple 的支援文章是其目前需求的最具權威性來源。請將支援文章的連結插入您的事件工單中並記錄版本日期，而不是在運行手冊中嵌入已複製且未更新的列表。3

如何驗證外部入口網站授權與 UDM 路徑？

如果登入頁面成功載入，您的調查重點將從攔截轉移到授權。Ubiquiti 表示，重新導向會將基地台的 MAC 位址、用戶端的 MAC 位址、原始請求的 URL 以及 SSID 傳遞給外部入口網站。外部服務可以使用用戶端的 MAC 位址從網路 API 取得用戶端 ID，然後發出授權請求。控制器端的確認是該用戶端的狀態為 authorised: true。2

請依此順序審查證據：第一，提供商是否收到了受影響用戶端的重新導向？第二，它是否識別出與 UniFi 列出的同一個用戶端？第三，它是否發送了授權請求？第四，UniFi 是否將該用戶端回報為已授權？此順序可為本地 IT 團隊和 MSP 提供共享的事件記錄。此外，這也打破了單方聲稱「入口網站已載入」而另一方堅稱「防火牆沒問題」的無效率循環。

關於 UDM Pro guest portal 的問題需要進行相同的驗證，並對控制器的分類進行額外的檢查。Purple 的指南指出，目前在 UniFi 硬體主機和現代版本的 UniFi OS Server 上的部署必須使用目前的 UniFi Network 整合選項，只有較舊且未更新的獨立控制器應用程式才使用舊版（legacy）選項。在硬體主機上，Purple 建議在 UniFi OS 的主控制面板中建立專用帳戶。如果部署已升級、轉移或重新分類，請在修改訪客的防火牆原則之前，重新審查該帳戶的位置和整合的分類。3

Purple 的支援指南中也將控制器可達性定義為一個獨立的邊界。如果外部服務無法透過經核准的防火牆路徑，在其穩定的公開 IP 位址或 FQDN 處連通您的控制器，則無法完成授權。請驗證註冊用於整合的位址、其入站路徑以及供應商核准的允許規則。請遵循支援文章以獲取適用於該版本的最新部署步驟，而不是僅在本地清單中複製連線值。3

常見問題與如何解決？

訪客網路已隔離，但登入頁面從未啟動

請將此問題視為 DNS 事件之前的 Hotspot 狀態檢查。確認受影響的 WiFi SSID 或網路是否已啟用 Hotspot 與 Captive Portal 功能。Ubiquiti 明確將僅限 WiFi 的 Hotspot 設定與整個網路或 VLAN 的設定區分開來。請還原至所需的設定，重新連線一部新裝置，並在測試任何外部連結之前，確認 UniFi 現在是否已記錄未授權的訪客。1 2

在外部網頁載入之前重新導向失敗

請將此問題視為預先授權路徑的測試。擷取訪客裝置的 DNS 解析程式、目標解析結果以及瀏覽器的執行結果。接著，將訪客規則與入口網站供應商的最新需求進行比較。Purple 的指南非常明確：當訪客在提交表單後看到空白畫面時，Pre-Auth ACL 或後續授權設定可能會封鎖完成此程序所需的流量。請勿使用寬鬆的訪客網際網路存取來取代針對性的預先授權策略。3

外部網頁已載入，但訪客仍處於離線狀態

這是授權邊界的問題。請驗證供應商事件中的用戶端身分、供應商向 UniFi 發送的請求，以及控制器的最終用戶端狀態。Ubiquiti 的外部流程將重新導向與後續透過 API 執行的授權動作區分開來。網頁成功載入代表第一階段已完成，但這並不表示用戶端隨後已被標記為已授權。2

UniFi Network 或 UDM 的更新變更了預期路徑

不要假設舊版控制器的設定仍然符合目前的整合方式。Purple 將現代的 UniFi Network 部署與先前的獨立控制器區分開來，並針對硬體主控台與自我託管的 UniFi OS Server 帳戶建立，記錄了個別的說明指南。請再次檢查專用的本機帳戶、其寫入權限、2FA 狀態、密碼變更設定以及整合分類。然後使用新裝置重新測試。3

Pi-hole 或上游 DNS 過濾會阻擋 UniFi 熱點嗎？

這可以是分析的一部分，但在沒有證據的情況下不應直接下結論。經核准的主要來源並未指出 Pi-hole 是導致 UniFi 重新導向失敗的原因。請將 DNS 視為一條可測量的路徑。確認提供給訪客區段的解析程式，檢查外部服務的目的地是否成功解析，在變更管理控制下測試經核准的 DNS 路徑，並比較結果。Apple 裝置的探測是另一個同時記錄自動登入體驗與一般瀏覽器請求的理由。4

如何在下一個高峰期到來前證明解決方案正常運作？

請使用可重複的發布驗證流程。它應該遵循與真實訪客相同的路徑，而非僅僅對控制器進行簡單的連線檢查。第一，中斷網路關聯或使用新的測試裝置。第二，連線到受影響的 SSID。第三，確認用戶端未經授權。第四，發起一般網頁請求。第五，確認外部服務收到重新導向。第六，完成核准的登入流程。第七，確認 authorised: true 狀態並測試正常存取。2

在 旅宿餐飲業 場所迎來客流高峰前、在 零售業 活動檔期前、在 交通運輸業 活動前，或在 醫療保健業 的訪客需求增加前，執行此驗證。將結果保留為營運記錄：每個步驟的成功或失敗、裝置類型、控制器分類以及所套用的任何變更。這比「訪客 WiFi 無法使用」這種籠統的警告更有實用價值。

真實範例情境：飯店螢幕空白事件

一家擁有 200 間客房的飯店報告指出，房客連線到該品牌的 SSID 但卻顯示空白的登入頁面。值班工程師使用新裝置並確認狀態為 authorised: false，這表示存在 Hotspot 階段。頁面開始載入，但交易未完成。工程師將房客預先授權路徑與服務供應商目前的支援指南進行比較，驗證實際分配給房客區段的解析程式，然後重新測試。可衡量的完成條件是裝置完成登入，切換為 authorised: true 並取得預期的存取權限。2 3

真實範例場景：控制器變更後的零售門市

零售團隊報告指出，在變更控制器後，顧客連線到隔離的 SSID 但從未看到登入頁面。工程師並未從 DNS 開始著手。他確認 SSID 已隔離，然後檢查目前的 UniFi 設定中是否已啟用 Hotspot 和 Captive Portal 選項。在恢復所需的 Hotspot 狀態後，他重新連線新裝置，並在測試外部服務之前驗證記錄的未授權狀態。可觀察到的結果是重定向事件，隨後是完成的授權狀態。1 2

真實範例場景：會議場地的外部授權失敗

會議場地的登入頁面已載入並接受了房客表單，但與會者仍處於離線狀態。團隊記錄了用戶端的 MAC 位址，並檢查外部服務供應商的重定向事件。接著，他們驗證該服務供應商是否已識別相同的用戶端、傳送了授權請求，且 UniFi 記錄為 authorised: true。針對 Purple 整合，他們還會驗證本機 API 帳戶、寫入權限、2FA 設定以及目前的控制器分級。預期的結果是可追溯的證據鏈，而不是對原因的猜測。2 3

事件關閉後，請在您的 Guest WiFi 營運流程中使用相同的版本控制。 Guest WiFi 區段提供了服務背景資訊，而 WiFi Analytics 則可協助營運團隊監控復原後的體驗。如需鄰近的營運控制，請參閱 Guest WiFi Management: Smart Authentication & Segmentation、Cloud Wifi Management: Secure Enterprise Connectivity 2026、Cisco Meraki splash page not working: a troubleshooting flowchart 指南以及 WiFi 7 Venue Deployment: Infrastructure Readiness for Stadiums and Hospitality Sites。

常見問題

我需要客用 VLAN 和 UniFi Hotspot 才能顯示登入頁面嗎？

不需要。 Ubiquiti 說明的 Hotspot 同時適用於 WiFi SSID 以及整個網路或 VLAN。關鍵條件在於相關的 SSID 或網路已啟用 Hotspot 和 Captive Portal 功能。隔離的客用 VLAN 只是區段劃分的選擇。它本身並不會建立未授權的用戶端狀態，也不會啟動外部重新導向。1 2

UniFi 的預先授權清單中應該加入哪些內容？

只需加入在核准前完成所選客用登入程序所需的必要路徑。 如果 Purple 在表單提交後出現空白畫面，通常與客用規則封鎖了完成登入所需的流量有關。請對照您目前的供應商文件，檢查預先授權 ACL 與授權後設定。請勿複製其他網站的網域名稱清單，也不要僅為了載入頁面而加入未受保護的網際網路存取。3

為什麼 UniFi 客用入口網站在應用程式更新後停止運作？

在修改網路之前，請先驗證 Hotspot 狀態、控制器分類和整合帳戶。 Ubiquiti 目前的文件將 Hotspot 設定與一般的客用網路區分開來。Purple 也將目前的 UniFi 網路整合與舊版的獨立控制器部署區分開來，針對硬體主控台與自行代管的 UniFi OS Server 提供了不同的帳戶指南。每次修復後，請使用乾淨的裝置重新測試。1 3

為什麼外部入口網站在我的 UDM Pro 上可以載入，但卻無法授權訪客？

頁面成功載入僅代表重新導向階段正常，並不代表最終授權階段成功。 請確認外部供應商已收到用戶端識別資訊、比對了 UniFi 用户端、發送了授權請求，且控制器顯示 authorised: true。對於 Purple，還需要確認專用的本機帳戶擁有寫入權限、未啟用 2FA，且沒有強制變更密碼的要求。2 3

Pi - hole 會中斷 UniFi Hotspot 的重新導向嗎？

請勿預設會如此。 經核准的主要來源並未將 Pi - hole 列為 UniFi 的已證實主因。請在變更控制下測試客用區段的實際解析程式、目標解析以及核准的 DNS 路徑。請同時記錄裝置的自動請求與一般瀏覽器的結果，因為 Apple 裝置在連線時會使用 Captive 網路探測。4

我需要更換我的 UniFi 存取點來解決重新導向錯誤嗎？

不，這不應作為首要措施。 記載的外部流程指出了一系列配置與授權步驟：Hotspot 狀態、未授權用戶端狀態、重新導向、外部處理以及控制器核准。在考慮更換硬體之前，請先使用新的測試裝置找出失敗的步驟。1 2

參考資料