強制入口重新導向疑難排解：解決訪客 WiFi 連線失敗問題

當訪客 WiFi 顯示已連線但無法存取網際網路時，表示裝置已加入網路，但強制入口重新定向功能發生故障。常見原因包括作業系統探測遭阻擋、缺少 walled garden 條目或 DNS 失敗。其他原因還包括 DHCP 位址池耗盡，或 RADIUS Access-Accept 未到達閘道。這些問題都能透過設定來解決。

「訪客 WiFi 已連線但無法存取網際網路」代表什麼狀況？

裝置已加入網路名稱（SSID）且顯示滿格訊號，但無法載入任何內容。各平台對此狀況的報告方式有所不同：

• iOS 會在網路名稱下方顯示「無網際網路連線」。
• Android 會顯示「已連線，但無法存取網際網路」或指向空白頁面的「登入網路」提示。
• Windows 將網路標記為「無網際網路」。

訪客看到運作正常的 WiFi 圖示，但瀏覽器卻無法存取網路，因此會歸咎於場地管理者。

一種症狀背後可能隱藏著數個不同的故障原因。您通常會看到以下幾種模式之一：

• 登入頁面完全沒有在任何裝置上出現。
• 登入頁面有出現在 iPhone 上，但沒有出現在 Android 手機上，反之亦然。
• 瀏覽器顯示憑證或隱私權警告，而非登入頁面。
• 訪客填妥表單並看到成功訊息後，依然無法存取網際網路。
• 離峰時間一切正常，尖峰時間則出現故障。

每種模式都指向網路的不同層級。請先觀察這些模式，不要急著重啟基地台。

強制入口偵測的運作原理

強制入口是閘道在授予網際網路存取權限之前所顯示的網頁。依據您的架構設計，閘道可以是控制器、防火牆或基地台。

各大主要作業系統一加入網路時，就會立即檢查是否存在強制入口。系統會向已知位址發送純 HTTP 要求，並將回應與預期結果進行比對。每種比對結果都代表不同的含意：

• 回應相符。 裝置假設其具備開放的網際網路連線。
• 閘道傳回 HTTP 302 重新定向。 裝置得知自己位於入口之後。它會開啟一個輕量級瀏覽器視窗（通常稱為 Captive Network Assistant），並載入您的登入頁面。
• 要求未收到回應。 裝置回報無網際網路且不會開啟任何視窗。

Microsoft 文件指出，其網路連線狀態指示器 (NCSI) 也會解析 dns.msftncsi.com 作為 DNS 檢查。因此，當驗證前的 DNS 發生故障時，即使 HTTP 運作正常，Windows 筆記型電腦仍可能回報無網際網路。

通常是什麼原因導致強制入口重新定向失敗？

大部分的情況是由七個原因所致。這些原因涵蓋了從位址指派到驗證的不同層級。

作業系統探針遭阻擋

閘道器的驗證前存取控制清單 (ACL) 會丟棄探針而非進行重新導向。裝置未收到任何回應，因而判定無法連線至網際網路，導致永遠不會開啟入口網站。

阻擋探針主機名稱的 DNS 過濾服務也會產生相同效果。這是入口網站完全未出現的最常見原因。

HTTPS 與 HSTS 中斷攔截

如 RFC 6797 所定義，HTTP 強制安全傳輸技術 (HSTS) 會指示瀏覽器僅能透過 HTTPS 存取網域。瀏覽器出廠時隨附 HSTS 網域預載清單，其中包括 Google 和大多數銀行網域。當訪客輸入 google.com 時，瀏覽器會在請求離開裝置前升級為 HTTPS。

若未出示 google.com 的憑證（閘道器並未擁有該憑證），閘道器便無法重新導向該請求。瀏覽器將顯示無法跳過的高風險安全警告。

解決方法是僅重新導向上方表格中的純 HTTP 探針，這些探針正是為了此目的而存在。切勿為了入口網站重新導向而攔截 HTTPS。

圍牆花園範疇過窄

圍牆花園是指裝置在通過驗證前可以存取的網域與 IP 位址清單。如果缺少某個項目，登入頁面將無法完整載入或登入步驟會失敗。常見的缺漏包括：

• 社群或單一登入 (SSO) 的身分提供者端點，例如 Microsoft Entra ID、Okta 或 Google Workspace。
• 為您的登入頁面提供字型、指令碼與樣式表單的內容交付網路 (CDN) 網域。
• 金流處理商網域（如果您對存取收取費用）。
• Purple 的強制入口與 RADIUS 端點，詳列於 Purple 針對您硬體設備所提供的整合指南中。

DNS 在驗證前失敗

裝置必須先解析入口網站的主機名稱，才能載入頁面。在以下兩種情況下，重新導向將無法指向任何位置：

• 閘道器在驗證前狀態阻擋了 DNS。
• DHCP 發放了裝置無法連線的 DNS 伺服器。

Android 還帶來了另一個變數。若訪客設定了特定的私人 DNS 主機名稱，Android 會預期使用連接埠 853 上的 DNS over TLS。在自動模式下，它會退回使用一般的 DNS。

DHCP 位址池耗盡

當位址池耗盡時，新裝置雖然會關聯至 AP，但無法取得 IP 位址。Windows 接著會為自己指派 169.254.x.x 連結本地位址，其他系統也會顯示類似的自我指派狀態。

由於沒有有效的位址，裝置無法傳送探針。它看起來已連線，但無法連線至網際網路。這是體育場、會議中心與交通樞紐在尖峰時間發生的典型故障。

RADIUS 從未傳送 Access-Accept

RADIUS (Remote Authentication Dial-In User Service) 負責將驗證伺服器的登入決定傳送至您的閘道器。伺服器會回覆 Access-Accept 或 Access-Reject（如 RFC 2865 所定義）。接著閘道器會開啟存取權限或保持封閉。

填寫完表單卻仍保持離線狀態的訪客，幾乎總是意味著閘道錯過了 Access-Accept。常見的三個原因為：

• 共享金鑰 (shared secret) 不符。
• 防火牆封鎖了 UDP 1812（驗證）或 UDP 1813（會計）。RFC 2865 和 RFC 2866 定義了這些連接埠。
• 控制器上的伺服器位址錯誤。

入口網站自身的憑證已過期

您的登入頁面是透過 HTTPS 提供服務。若其 TLS 憑證過期，所有現代瀏覽器都會以安全性警告封鎖該頁面。重導向功能運作完全正常，但訪客仍無法登入。

如何確定是哪種原因？

請依序向上檢查網路堆疊。每項檢查都能排除一層問題，因此請在第一個失敗點停止。

1. 裝置是否擁有有效的 IP 位址？ 請在 Windows 上執行 ipconfig /all，或檢查手機上的網路詳細資料。169.254.x.x 位址或完全沒有位址，皆指向 DHCP 問題。請檢查 DHCP 伺服器上的位址池使用率。若高於 90%，即代表即將耗盡。
2. DNS 能否解析？ 請從訪客虛擬區域網路 (VLAN)（邏輯上獨立的網路區段）中的裝置查詢入口網站主機名稱。若查詢失敗，表示預先驗證的 DNS 被封鎖，或是 DHCP 分配的 DNS 伺服器錯誤。
3. 探針是否取得 302 回應？ 請在訪客 VLAN 上擷取封包，或瀏覽其中一個 HTTP 探針 URL。您應該會看到探針，接著是指向入口網站的 HTTP 302。若探針沒有回應，表示 ACL 丟棄了封包。若完全沒有探針，表示裝置認為自己已經連線，這通常是因為快取狀態所致。請清除（忘記）該網路並重新連線。
4. 登入頁面是否完整載入？ 開啟瀏覽器開發者工具 (F12) 並觀察網路標籤頁。若對第三方域名的請求被封鎖，表示圍牆花園 (walled garden) 設定有缺口。
5. 閘道是否收到 Access-Accept？ 請檢查控制器的 RADIUS 記錄。成功登入後，會收到狀態為 Start 的 Accounting-Request。若登入後未出現會計紀錄，則表示 RADIUS 路徑已中斷。

然後將您看到的狀況與下表對照。

實作情境：包含 1,500 個座位的會議中心在尖峰時段的狀況

狀況。 一家會議中心在單一 /24 子網路上運行與會者網路，DHCP 租約時間為八小時。早上的專題演講運作順暢。午餐過後，抵達參加下午場次的與會者看到了「已連線，無網際網路」。服務台將其視為入口網站故障，並重啟控制頁面兩次。

處置方式。 診斷步驟 1 發現新裝置保留了 169.254.x.x 位址。/24 可提供 254 個可用位址，而八小時的租約保留了早上的每個位址。團隊將與會者 VLAN 移至 /21，並將租約縮短至 30 分鐘。

結果。 可用位址從 254 個增加到 2,046 個，大約是先前容量的八倍。離開與會者留下的位址現在會在 30 分鐘內返回位址池，而不是八小時。此修復僅花費一個變更維護時段，且不需要任何新硬體。

實作情境：擁有 200 間客房的飯店中 Android 房客無法登入

狀況。 在重新設計登入頁面後，一家擁有 200 間客房的飯店收到櫃檯轉達的 Android 房客抱怨。他們大多數人選擇了 Google 登入選項。入口網站有出現，但按鈕沒有反應。

處置方式。 IT 經理在一台 iPhone、一台 Android 手機和一台 Windows 筆記型電腦上測試了流程。筆記型電腦上的開發人員工具顯示對字型傳輸網路和 Google 登入網域的請求被封鎖。重新設計時新增了這兩者。團隊將它們新增至圍牆花園 (Walled Garden)。

結果。 Google 登入在第一次重新測試時於所有三台測試裝置上完成。此修復需要兩個圍牆花園條目，且不需要變更硬體。

實作情境：防火牆更新後的 40 家門市零售企業

狀況。 一家零售商利用週末更換了 40 家門市的防火牆。週一，每家更新門市的顧客都可以填寫登入表單，但仍保持離線狀態。尚未更新的門市則運作正常。

處置方式。 步驟 5 發現沒有來自已更新門市的記帳紀錄。新的防火牆範本預設拒絕外連 UDP，封鎖了 1812 和 1813。團隊向範本新增了明確的外連規則，並推播至所有 40 家門市。

結果。 推播後，來自每家門市的記帳紀錄重新出現。因為只有更新後的門市失敗，該模式直接指向範本，排除是 WiFi 的問題。

如何在每個作業系統和控制頁面上修復它？

控制頁面的修復在每個平台上都遵循相同的模式。作業系統的修復主要是了解各自的行為模式。

在您的控制頁面上

Purple 作為雲端重疊層運行於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。這八種平台上的修復模式完全相同：

1. 將訪客 SSID 指向 Purple 整合指南中的外部分頁強制入口 URL，並停用任何本機 Splash 頁面。
2. 將未經驗證的 HTTP 流量（包含探測）重新導向至該 URL。請勿變更 HTTPS。
3. 在驗證前允許 DNS 和 DHCP。
4. 新增圍牆花園（Walled Garden）項目：Purple 端點、身分驗證提供者端點以及登入頁面資產網域。
5. 輸入來自 Purple 儀表板的 RADIUS 伺服器位址與共用密鑰。然後確認防火牆允許出站 UDP 1812 與 1813。

功能表名稱會因廠商和韌體版本而異，因此請遵循適用於您平台的 Purple 整合指南。Fortinet 社群文件中關於 FortiGate 強制入口流程的說明，是參考重新導向順序時非常有用的廠商側指南。

在 iOS 和 macOS 上

如果強制網路助理未開啟，請在「設定」中忘記該網路並重新連線。這會強制發送全新的探測。

近期的 iOS 與 macOS 版本也支援 Captive Portal API。它允許網路透過 RFC 8910 中定義的 DHCP option 114 來通告其入口，進而減少對攔截的依賴。如果助理有開啟但保持空白，請檢查圍牆花園中的資產網域。

在 Android 上

Android 在偵測到入口時會顯示「登入網路」通知。如果通知從未出現，請確認閘道重新導向了 connectivitycheck.gstatic.com，而非將其丟棄。

如果訪客看到「無法存取私人 DNS 伺服器」，代表其手機設定了嚴格的私人 DNS 主機名稱。您有兩個選擇：

• 在驗證前允許連接埠 853 上的 DNS over TLS。
• 請訪客將私人 DNS 切換為自動。

在 Windows 上

Windows 依賴 NCSI HTTP 探測及其 DNS 檢查。如果入口未自動開啟，請瀏覽至任何純 HTTP 網站以手動觸發重新導向。如果在登入後持續顯示「無網際網路」，通常表示閘道仍在重新導向探測。在這種情況下，閘道尚未套用 Access-Accept。

在瀏覽器中

請指導第一線人員引導訪客造訪 HTTP 位址，切勿造訪如 google.com 等 HSTS 網域。Firefox 會針對 detectportal.firefox.com 執行自己的探測，因此請在您的重新導向測試中包含該主機。

您該如何防止訪客 WiFi 重新導向失敗再次發生？

大多數重複發生的事件源於變更，而非原始建置。韌體更新、新的防火牆範本、登入頁面重新設計或過期的憑證都可能未經測試即上線。請將這些控制措施建置到您的變更流程中：

• 每次變更後在三個平台上進行測試。 使用一支 iPhone、一支 Android 手機和一台 Windows 筆記型電腦。如果一個平台失敗而其他平台通過，請先檢查圍牆花園是否有遺漏。
• 按高峰期而非平均值計算容量。 計算最大併發裝置數量並增加預留空間。瞬時訪客網路通常使用 15 到 30 分鐘的租約。
• 將連線階段設定為符合造訪情況。 旅宿業和零售場所通常會設定 24 小時的連線階段，因此訪客在每次入住或造訪期間只需登入一次。
• 每日監視登入量。 Purple 的 WiFi 分析 會依據場所報告登入情況。單一據點的登入量突然下降，能在訪客抱怨之前，提醒您發生了 RADIUS 或圍牆花園故障。
• 將憑證與共用金鑰納入變更管理。 記錄強制入口憑證的到期日。將 RADIUS 共用金鑰儲存在防火牆與控制器團隊皆可存取的地方。
• 區隔訪客流量。 將訪客放入專屬的 VLAN。PCI DSS 將網路區隔視為防止訪客網路納入持卡人資料環境範圍的方法。
• 針對 MAC 隨機化做好規劃。 近期的 iOS 與 Android 版本會針對每個網路使用隨機 MAC 位址，且某些模式會隨時間旋轉位址。以 MAC 位址為主的連線階段快取，屆時將會要求再次造訪的訪客重新登入。
• 妥善收集同意聲明。 GDPR 要求針對行銷資料取得知情且明確的同意。Purple 的自主選擇同意選項會針對每種用途提供單獨的選擇。

讓再次造訪的訪客免於透過強制入口進行驗證

最持久的修復方式是完全移除重複造訪時的重新導向。

• Passpoint 是基於 Hotspot 2.0 規格打造的業界認證。它可讓裝置使用儲存的設定檔自動加入網路。
• OpenRoaming 由 Wireless Broadband Alliance 營運，負責聯合身分提供者。如此一來，訪客現有的憑證即可在所有參與的場所中使用。

兩者皆使用 IEEE 802.1X（此為基於連接埠之網路存取控制的標準），因此不存在會發生故障的強制入口。

Purple 的適用情境

Purple Guest WiFi 以獨立於硬體的雲端覆蓋層方式運作，因此您只需透過設定即可修復重新導向故障，無須更換新硬體。Purple 為 90 多個國家/地區的 80,000 多個實體場所提供服務，每年支援 5 億名使用者與登入次數。該平台具備 99.999% 的正常執行時間，並獲得 ISO 27001、Cyber Essentials 及 B Corp 認證。此外亦符合 GDPR 與 CCPA 規範。

當傳送門發生故障時，原因幾乎總是出在區域環境：偵測規則、圍牆花園條目、DHCP 池或防火牆規則。

這些模式會在各個產業重複出現：

• 飯店 在辦理入住的高峰期會遇到重新導向錯誤。
• 零售 園區會在進行全區防火牆變更後遇到這些問題。
• 火車 與車站隨著乘客一波波上車，會面臨 DHCP 的壓力。
• 醫療保健 場所需要運作順暢的病患與訪客 WiFi，以免臨床人員被捲入技術支援求助電話。

常見問題

Purple 能否搭配我們現有的無線基地台使用？

可以。Purple 與硬體無關，可在 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 及 Fortinet 上作為雲端覆蓋層運作。您可以保留現有的無線基地台和控制器。您只需要將訪客 SSID 指向 Purple 的強制入口，並根據 Purple 的整合指南新增圍牆花園條目與 RADIUS 詳細資訊，然後進行測試即可。完全不需要拆除並更換設備。

我們需要新硬體來修復訪客 WiFi 已連線但無法連線至網際網路的問題嗎？

不需要。在幾乎所有情況下，問題都出在設定：遭封鎖的偵測、圍牆花園缺口、預先驗證 DNS、耗盡的 DHCP 池或 RADIUS 防火牆規則。您可以在現有的控制器、防火牆或 DHCP 伺服器上修復這些問題。只有當無線基地台密度無法滿足您的尖峰裝置數量時，硬體才會成為問題，而這可透過現場勘測來確認。

將我們的訪客 WiFi 轉移至 Purple 需要做什麼？

轉移至 Purple 是一項設定專案，而非安裝專案。在每個控制器上，您需將訪客 SSID 設定為 Purple 的外部入口，並新增圍牆花園與 RADIUS 設定。接著確認 UDP 1812 和 1813 的防火牆規則。下一步，在 Purple 中建立您的登入頁面與同意選項，並在 iOS、Android 及 Windows 上進行測試。多據點園區可以將控制器設定套用範本。

強制入口是否符合 GDPR 規範？

是的，前提是同意是在知情、明確且自由的情況下給予的。GDPR 要求針對每個目的（例如行銷電子郵件）提供獨立的肯定選擇，並排除預先勾選的方塊。Purple 的自主選擇訂閱功能會單獨顯示每個選項。Purple 通過 ISO 27001 認證，擁有 Cyber Essentials，且符合 GDPR 及 CCPA 規範。這能為您的資料保護官提供他們會詢問的合規標準。

再次光臨的訪客可以跳過登入頁面嗎？

可以。Passpoint 和 OpenRoaming 允許裝置使用儲存的設定檔或聯合身分自動加入。兩者皆使用具備 WPA2 或 WPA3-Enterprise 加密的 IEEE 802.1X 驗證，因此再次存取時不會發生強制入口重新導向失敗的情況。許多場所同時執行這兩者：針對首次光臨的訪客與資料收集使用強制入口，並針對再次光臨的訪客、乘客及學生使用 OpenRoaming。

我們要如何知道登入何時開始失敗？

按場地監控登入量。Purple 的 WiFi 分析功能會報告每個站點的登入情況，因此某個位置的突然下降會與其正常模式及您的其他場地形成鮮明對比。這種下降通常意味著最近的變更引發了 RADIUS、受限園區（walled garden）或 DHCP 故障。在儀表板中發現問題，比等待前台的抱怨傳達到 IT 部門更為迅速。

我們應該使用強制入口還是共享的 WiFi 密碼？

如果您想要取得第一方數據和同意，請使用強制入口；只有在兩者皆不需要時，才使用共享密碼。共享預先共享金鑰會使用 WPA2 或 WPA3-Personal 加密流量。但是，它無法提供任何關於連接者的資訊，且密碼容易流傳。強制入口可收集獲得同意的第一方數據，而 Passpoint 或 OpenRoaming 則可為再次存取提供自動化的加密存取。