Android 強制入口登入：登入並修正失敗問題
Published
您站在飯店大廳，手機顯示已連線，卻什麼也載入不出來。沒有登入頁面，沒有任何可供採取的錯誤提示，只有應用程式不斷旋轉載入，而 WiFi 圖示上帶有一個小小的警告。這代表 Android 強制入口登入沒有正常發揮作用，或是網路回應 Android 的檢查方式讓手機卡在已連線與已連線至網際網路之間。
解決問題很少靠隨機點按。Android 遵循明確的偵測狀態機，只要您知道自己處於哪個狀態，就會知道該點按什麼、該變更什麼設定，或者故障是否出在場地端。建議從系統提示開始，接著擴展至瀏覽器、隱私權設定，最後才是強制入口本身的設計。
目錄
- 在一分鐘內登入 Android 上的強制入口
- Android 如何判斷網路是否需要登入
- 自行排解手機上的登入失敗問題
- 強制入口偵測的已知問題
- Kiosk 與受管理 Android 裝置
- 選擇能在 Android 上良好運作的入口設計
在一分鐘內登入 Android 上的強制入口
在您打開 Chrome 之前，請先點選登入網路通知。Android 會在其專用的登入檢視中開啟該頁面、追蹤您的選擇，並在您完成時重新測試網路。您自己開啟的瀏覽器分頁完全無法進行這些處理，這就是為什麼略過提示的使用者經常遇到頁面顯示已登入，但手機卻仍堅持沒有網際網路的原因。
- 輕觸「登入網路」通知。 下拉通知欄或輕觸 WiFi 名稱下方的提示。它通常會在加入網路後的幾秒內出現，並帶您直接進入場所頁面，無需猜測 URL。
- 如果沒有通知，請開啟純 http 頁面。 在您的瀏覽器中造訪 http 地址，而非 https。入口網站可以攔截並重新導向純 http 請求，而加密頁面則會停滯或跳出憑證警告。請選擇近期未造訪過的地址，這樣瀏覽器就不會從快取中回應而完全繞過網路。
- 完成場所要求的步驟。 接受條款、輸入您的房號、輸入簡訊驗證碼，或使用提供的社群帳號登入。請勿過早關閉視窗，因為 Android 需要完成訊號來重新測試。
- 等待警告標籤消失。 WiFi 圖示的警告三角形應該會消失，且沒有網際網路的標示也應隨之不見。這個變化代表 Android 已重新驗證連線，而不只是載入頁面；這正是成功完成登入與白費工夫填寫表單之間的差別。
- 如果仍顯示「沒有網際網路」，請重新開關一次 WiFi。 在嘗試其他更複雜的步驟之前，請先關閉並重新開啟 WiFi。重新加入網路會強制進行新檢查並清除過期的結果。
成功看起來很平凡無奇，而這正是重點所在。通知清除後，您想要的頁面隨即載入，且在您離開瀏覽器後，您的應用程式仍能繼續正常運作。如果您正在為員工或賓客建立可重複使用的指南，操作指南 集合可以協助您將這些步驟維持在服務台人員容易遵循的格式。
Android 如何判斷網路是否需要登入
Android 並非透過查看您的瀏覽器來做出決定。它會在背景提出詢問，然後對答案做出判斷。
當您的手機連線至 WiFi 時，會傳送明文 HTTP 測試（probe）至已知的連線端點，並預期收到特定的空白成功回應。如果網路攔截了該請求並傳回重導向或登入頁面，Android 就會將該網路視為受限入口並提示您。Android 11 強制入口說明文件 指出，Android 在 2014 年發布的 Android 5.0（對應 API level 21）中引進了內建的強制入口偵測功能，且歷史上該測試使用的是 connectivitycheck.gstatic.com。
該日期對營運商至關重要。入口網站處理並非額外外掛的瀏覽器技巧，而是一個控制提示、驗證標籤以及應用程式是否認定自身已連線的作業系統功能。
Android 內部的分工職責
Android 分工處理工作。NetworkMonitor 測試可達性與入口狀態。預裝的強制入口登入應用程式會顯示身份驗證頁面，並向系統回報您的選擇。
在您登入後，Android 會重新測試。若探測現在通過，網路將轉為已驗證狀態，警告也會清除。若未通過，即使您填妥了登入表單，仍可能無法使用網路。
較新的路徑更為簡潔。網路可以在 DHCP 期間使用 DHCP Option 114 來宣傳其入口，指向 Android 的強制入口API端點。Android NetworkCapabilities 參考資料 支援此流程的相關應用程式端，其中 Android 11 及更高版本可以在 DHCP 處理期間擷取該端點，且帶有 captive: true 的 JSON 回應會使 Android 直接呈現系統登入介面。如果該 API 不可用，Android 將退回使用探針。
對於應用程式開發人員而言，訊號位於網路回呼中。NET_CAPABILITY_CAPTIVE_PORTAL 代表最新的探測偵測到了強制入口。NET_CAPABILITY_VALIDATED 則代表網路已通過驗證。
來自入口網站的 HTTP 200 頁面並非已連網的證明。只有在網路達到已驗證狀態時，才算登入成功。
解讀網路回應
| 網路回應 | Android 的判定結果 | 您看到的畫面 |
|---|---|---|
| 測試端點傳回 HTTP 204 | 網際網路已連通，無入口 | 無提示，可正常瀏覽網路 |
| 傳回 HTTP 200 並包含入口 HTML（而非 204） | 偵測到強制入口 | 顯示登入通知 |
| 測試遭封鎖、逾時或 DNS 失敗 | 驗證失敗，未識別出入口 | 無提示，顯示「無網際網路連線」標籤 |
| 透過 DHCP Option 114 傳送強制入口 JSON（Android 11 及更新版本） | 需要登入 | 直接開啟系統登入頁面 |
| 您登入後測試通過 | 網路已完成驗證 | 警告清除，應用程式可連線 |
請從左至右閱讀表格。Android 並非在審查您的品牌形象、表單欄位或頁面外觀是否完備。它審查的是探測回應在登入前是否以預期的形式改變，以及在登入後是否恢復正常。
假設飯店的平板電腦加入賓客網路卻從未彈出提示。員工經常歸咎於登入頁面並開始重新設計按鈕。請先檢查探測（probe），因為如果網路阻擋了探測、使其逾時或過於自由地放行，Android 可能永遠無法達到觸發提示的強制狀態。
這是需要維持的心智模型。提示取決於網路如何回應單一自動化檢查。 精美的入口網站無法修正錯誤的探測回應，而正確的探測回應即使搭配簡單的入口網站，也能讓人感到可靠。
解決您自己手機上的登入失敗問題
在一次變更數個設定之前，請先依序排查以下症狀。一次進行一項變更，重新測試一次，然後再繼續進行。
| 症狀 | 可能原因 | 修復方法 |
|---|---|---|
| 加入網路後沒有登入通知 | 探針被阻擋或快取結果過期 | 清除此網路設定並重新加入，然後在瀏覽器中開啟純 http 頁面 |
| 登入頁面僅在造訪 https 網站時出現 | 入口網站僅重新導向純 http 請求 | 開啟 http 頁面以觸發重新導向 |
| 已登入但仍顯示「沒有網際網路」 | 私人 DNS 或 VPN 阻擋了檢查 | 關閉私人 DNS 與 VPN，然後重新開關 WiFi |
| 入口網站重複出現 | 此連線階段變更了隨機 MAC 地址 | 將網路設定改為對此網路使用裝置 MAC 地址 |
| 登入頁面空白或無法傳送 | 瀏覽器快取過期或入口網站頁面舊化 | 清除瀏覽器快取並嘗試其他瀏覽器 |
| 在一部手機上正常，另一部則不行 | 不同的 Android 版本或隱私設定 | 比較 Android 版本並在關閉隨機 MAC 的情況下測試 |
| 已連線，但應用程式仍無法使用 | 連線能力尚未完成重新驗證 | 等待 30 秒，然後重新開關飛航模式 |
我建議使用此順序，因為它是從成本最低的修復方法開始，並避免在非必要情況下削弱隱私設定。
- 切換 WiFi，然後清除記憶並重新連線。 這會清除快取的驗證結果，並強制進行全新的偵測。
- 檢查私人 DNS、VPN 和隨機 MAC。 這些設定直接部位於 DNS、路由和裝置識別的路徑上，因此是下一個可能的阻礙因素。
- 清除瀏覽器快取或嘗試使用第二個瀏覽器。 當頁面空白、僅載入一半或無法送出時，請執行此操作。
隱私注意事項：關閉私人 DNS 或 VPN 會降低您在公共網路上的保護。登入成功後，請立即將兩者重新開啟；在此之前，請勿進行網路銀行交易或變更密碼。
隨機MAC 位址這項設定經常讓人困惑。如果強制入口授權了一個 MAC 身分，而您的手機在下次連線時提供另一個身分，場地端就會視為新裝置並再次顯示強制入口。將該單一網路設定為使用裝置 MAC 可以穩定會話，但您不應該針對所有網路進行全域變更。
如果這些方法都無效，請停止重設設定。記錄時間、網路名稱和裝置型號，然後將這些詳細資訊提供給場地人員，以便他們檢查入口網站端。如果問題超出 WiFi 登入範圍，您可以 尋求手機問題協助，這涵蓋了更廣泛的裝置故障；但對於從未完成驗證的場地入口網站，恢復原廠設定是無法解決問題的。
強制入口偵測的已知問題
營運人員直覺的解決方案是在登入前允許更多功能變數名稱。但這種直覺做法可能會完全破壞 Android 強制入口登入。
目前的 Captifi 針對強制入口未顯示的指引 解釋道，Android 會執行自動連線檢查，通常預期從 Google 連线檢查端點收到 HTTP 204 回應。如果圍牆花園過度開放該端點的存取權限，Android 可能會判定已存在不受限制的網際網路存取，從而抑制登入提示。簡單來說，您的存取白名單可能會讓手機誤以為根本沒有入口網站。
這就是營運商忽視的權衡。過窄的允許清單可能會阻擋入口網站所需的付款指令碼或身份提供者。過寬的允許清單雖可保持頁面美觀，卻會移除開啟該頁面的觸發機制。
狀態機發生故障的地方
失敗的情況並不完全都是缺少提示。DNS 失敗可能會導致驗證停滯。VPN 或私有 DNS 設定可能會繞過場地的解析程式。僅限 HTTPS 行為會讓強制入口無法安全地進行重新導向。MAC 隨機化可能會讓同一支手機在多次連線時看起來像多台不同的裝置。
您無法透過登入頁面的螢幕截圖來除錯這些情況。請記錄會話訊號，以顯示 Android 到達了哪個狀態以及在何處停止。
- 探針結果：檢查是否傳回 204、重新導向、入口 HTML 或無任何回應？
- DNS 結果：端點是否透過場地解析程式成功解析？
- 重新導向狀態：閘道是否將裝置傳送至入口 URL？
- WebView 錯誤：登入檢視表是否無法呈現或傳送？
- 隨機 MAC 身分：入口授權了哪一個 MAC？
- 驗證後驗證：表單完成後網路是否成功通過？
假設您的記錄顯示允許的探測且已成功登入，卻始終未進行驗證。請勿先歸咎於手持裝置。請檢查登入後的重新導向與授權解除，因為入口網站可能已接受表單，但未通知網路放行該裝置。
我建議依此順序進行四項變更。
- 將驗證前允許清單保持在入口及其登入提供者所需的最低限度。
- 為每個失敗和成功的工作階段記錄上述每個遙測欄位。
- 測試符合 HTTPS 安全規範的註冊，使訪客不會依賴單一純 HTTP 觸發條件。
- 為不應依賴入口的裝置規劃非入口路徑，使用諸如 OpenRoaming WiFi、Passpoint 或受控管憑證等選項。
Kiosk 與受管理的 Android 裝置
一部受管理的平板電腦可能會處於正確重定向的網絡中，但卻永遠不會顯示登入視窗。這並非訊號強度的問題。這通常是策略問題。
一般消費者的建議假設您可以點選通知、停用 VPN 和編輯 WiFi 隱私權設定。但 Kiosk 使用者通常無法執行上述任何操作。針對 Kiosk 強制入口的企業行動化指南 指出，強制入口是由預先載入的應用程式處理，且 Kiosk 政策必須明確允許該應用程式；因此被阻擋的強制入口系統封包意味著即使網路運作正常，登入頁面也永遠不會啟動。
這種情況常發生在無人將該裝置視為手機的場所。例如醫院和學校的平板電腦、零售手持裝置、飯店平板電腦，以及場所擁有的報到櫃檯螢幕。訪客的個人手機可正常登入，因此工作人員宣稱網路正常，而受管的裝置機隊卻保持離線狀態。
假設當主管在員工手機上測試相同的網路時，零售手持裝置可正常運作，但 Kiosk 版本卻保持斷線。在您改動入口網站前，請先檢查策略允許清單。手機證明了重新導向存在，而手持裝置則證明了託管映像檔無法開啟該頁面。
請依此順序執行營運人員檢查。
- 在您的 EMM 或 MDM 政策中允許強制入口系統封包，然後推播該政策並在一部測試裝置上重新連線至網路。
- 在該特定裝置映像檔上測試 Android System WebView，因為過期或已停用的 WebView 可能會導致入口頁面空白或無法傳送。
- 為無法顯示互動式入口頁面的裝置定義備用註冊路徑，例如預先裝設的設定檔或基於憑證的連線，其理念類似於結構化的 BYOD 註冊，而非共用密碼。
策略第一，WebView 第二，備援第三。如果您顛倒了這個順序，您就會為那些只需獲得顯示已偵測到頁面之權限的裝置，建置出不必要的替代方案Android。
選擇適用於 Android 的入口網站設計
請從三個標準開始，而非從強制頁面設計開始。訪客返回的頻率、裝置是個人裝置還是受管理裝置，以及必須支援哪些 Android 版本，應決定其設計。
對於一次性訪客而言，使用強制入口仍然十分實用。請將驗證前白名單（pre-auth allowlist）保持得越小越好，支援訪客預期的登入方式，並確保登入後的放行速度足夠快，讓 Android 能在使用者開始切換設定之前完成驗證。您只需使用 Splash URL 與 RADIUS，即可在 15 分鐘內將我們自己的入口新增至控制器，登入選項包含 SSO、Google、Apple、Facebook 和簡訊，但設定迅速並不代表您不需要測試測試端點（probe）的行為。
對於再次造訪的訪客，如果可以避免，我不建議每次造訪都強制使用入口網站。Passpoint 或 OpenRoaming 讓安裝過一次的設定檔能在再次造訪時自動連線，無須經過入口網站的阻礙，也無須重複填寫表單。在評估 訪客 WiFi 解決方案 時，可將該途徑與您目前的設定進行比較，並在承諾採用前確認您的控制器與 RADIUS 設定支援此選項。
然後像營運人員一樣進行測試，而不是像設計人員一樣。
- 支援的最舊 Android 版本：確認出現提示且驗證完成。
- 目前的 Android 裝置：確認預設的私有 DNS 和隨機 MAC 不會讓使用者受阻。
- 受管 Kiosk 版本：確認原則允許強制入口應用程式且 WebView 能夠轉譯頁面。
在每台裝置上，請等待已驗證狀態並開啟兩個應用程式，而不僅是瀏覽器。單一通過測試的手機無法證明太多事情，因為偵測結果會因 Android 版本、DHCP 支援以及裝置策略而異。唯有在三者皆通過後，才能推廣給訪客使用。
如果您的 Android 訪客一直遇到無法跳出提示、無法驗證或無法保持登入的入口網站，Purple Access 可以協助您在現有的無線基地台上，為一次性訪客提供客製化品牌的強制入口，並為再次造訪的裝置提供 Passpoint 或 OpenRoaming。在下一次部署之前，歡迎與我們洽談測試您最舊的 Android 裝置、目前的微型手持裝置以及任何受管理的導覽機版本，以確保第一次登入就能順利運作。
