解決訪客 WiFi 上出現的「Connected, No Internet」錯誤

解決訪客 WiFi 上 Connected but No Internet 錯誤 — Purple 技術簡報 [引言與背景 — 約 1 分鐘] 歡迎收聽 Purple 技術簡報系列。我是主持人，今天我們要解決企業場館網路中一個最棘手且令人沮喪的問題：訪客 WiFi 上的「connected, no internet」錯誤。 如果您管理飯店、零售連鎖店、體育場或會議中心的 WiFi 基礎設施，您一定遇過這種狀況。客人的裝置顯示滿格訊號、已關聯到您的存取點、也已分配到 IP 位址——但瀏覽器卻毫無回應。Captive Portal 從未載入。客人打電話給櫃檯。您的支援團隊執行 ping 測試，紙面上一切正常，但問題卻一再發生。 關鍵在於：在我於企業部署中遇到的絕大多數案例中，這並非硬體故障、不是防火牆設定錯誤，也不是傳統意義上的頻寬問題。這是一個 DNS 計時問題——而且幾乎總是由網路壅塞所觸發。今天，我想帶您深入探討為什麼會發生這種情況、如何可靠地診斷它，以及部署企業 DNS 篩選器如何永久解決這個瓶頸。 [技術深入探討 — 約 5 分鐘] 我們從基本原理開始。當一個訪客裝置連接到您的 WiFi 網路時，它在載入任何網頁之前、在您的 Captive Portal 可以進行重導之前、在任何認證發生之前——所要做的第一件事，就是透過 DNS 將網域名稱解析為 IP 位址。網域名稱系統是網際網路的電話簿。沒有它，您的裝置就無從得知要將流量傳送到何處。 現在，問題的起源在此。大多數消費型裝置——iPhone、Android 手機、Windows 筆電——都內建了一種稱為 Captive Portal 偵測探測的機制。舉例來說，在 iOS 上，裝置會向已知的 Apple 端點發送 HTTP 請求，例如 captive.apple.com。在 Android 上，它會嘗試 connectivitycheck.gstatic.com。在 Windows 上，它會探測 msftconnecttest.com。這些探測旨在偵測網路在授予網際網路存取權之前，是否需要登入頁面。 關鍵點在於：這些探測都依賴 DNS。在發送 HTTP 請求之前，裝置必須先解析探測端點的網域名稱。而這個 DNS 查詢是有逾時限制的——通常取決於作業系統，約在 1 到 5 秒之間。如果您網路上的 DNS 解析器沒有在該時間窗內回應，裝置便會判定網路沒有網際網路連線，即使它已完全關聯並擁有有效的 IP 位址。這便是「connected, no internet」錯誤。這不是連線失敗——而是 DNS 回應失敗。 那麼，為什麼在壅塞的網路上 DNS 會失敗？這就是許多團隊栽跟頭的地方。DNS 查詢預設是透過 UDP 在埠號 53 上傳送。UDP 是一種無連線協定——沒有交握、沒有確認、傳輸層沒有重傳機制。如果 DNS 封包因網路壅塞而被丟棄，用戶端就只能等待逾時到期，然後重試或放棄。在一個有數百或數千台並行裝置的訪客 WiFi 網路上——想像比賽中的體育場、客滿的飯店、主題演講中的會議中心——上行鏈路和 DNS 解析器很快就會達到飽和。 問題因訪客網路通常共用單一的上行 DNS 解析器而更加惡化，這通常是 ISP 的預設解析器，或者是像 8.8.8.8 這樣的公共解析器。當網路上每台裝置同時進行 Captive Portal 偵測探測、執行背景應用程式更新，以及為社群媒體和串流服務進行 DNS 查詢時，這單一解析器就成了瓶頸。查詢回應時間從正常的低於 50 毫秒範圍，攀升至數百甚至數千毫秒。逾時開始發生。「connected, no internet」錯誤便蜂擁而至。 還有一個值得了解的次要機制：TTL 耗盡。DNS 回應包含一個存活時間 (TTL) 值，告訴接收端裝置應將解析到的 IP 位址快取多久。在壅塞的網路上，裝置不斷關聯和解除關聯——這在高密度場館很常見——快取項目過期，必須頻繁地重新解析。這在網路承受最大壓力時，正好增加了解析器上的 DNS 查詢負載。 現在，傳統的應對方式是投入頻寬——升級上行鏈路、增加更多存取點、實施 QoS 策略。這些都是有效的措施，但並未解決根本原因。根本原因是您的 DNS 解析路徑並未針對高密度訪客環境進行最佳化。而這正是企業 DNS 篩選器所解決的問題。 企業 DNS 篩選器——例如 Purple 訪客 WiFi 平台中的 DNS 篩選功能——作為一個位於您的訪客裝置和上游網際網路之間的本地、高效能 DNS 解析器。它不是將每個查詢都轉發到遠端公共解析器，而是維護一個本地快取，快取頻繁解析的網域、原生處理 Captive Portal 偵測探測，並套用基於策略的篩選，在惡意或不符合政策的網域到達上游解析器之前將其封鎖。其結果是大幅降低了 DNS 查詢延遲——通常從兩到三秒的逾時降到低於 200 毫秒的回應——這意味著 Captive Portal 偵測探測首次嘗試即成功，「connected, no internet」錯誤消失，訪客引導時間顯著下降。 從標準的角度來看，此架構符合針對高密度部署的 IEEE 802.11 建議，並透過允許您記錄和稽核 DNS 查詢來支援 GDPR 資料處理要求——如果您是在公共部門或飯店許可下運作，這一點尤其相關。它也支援 PCI DSS 網路分段要求，確保訪客 DNS 流量與您的企業解析器基礎設施隔離。 [實作建議與陷阱 — 約 2 分鐘] 讓我為您提供實務的部署指導。當您在訪客 WiFi 網路上推出企業 DNS 篩選器時，有三個設定決策將決定您的成敗。 首先，解析器的放置位置。您的 DNS 篩選器必須部署得愈靠近訪客網路愈好——理想情況下，應與您的訪客存取點位於同一個 VLAN 或子網路。訪客裝置與解析器之間的每一跳都會增加延遲。如果您的 DNS 篩選器位於遠端資料中心，而您的訪客網路在曼徹斯特的一家飯店，增加往返時間將使目的無法達成。請使用本地設備或具有區域存在點 (PoP) 的雲端提供 DNS 篩選器。 其次，Captive Portal DNS 直通。這是我最常見的錯誤設定。部署 DNS 篩選器時，您必須確保 Captive Portal 的自有網域——即用來認證的訪客重導目標 URL——已加入篩選器的白名單。如果篩選器封鎖或延遲了您 Captive Portal 網域的解析，您將重新製造出您試圖解決的確切問題。部署任何 DNS 篩選策略後，務必明確測試 Captive Portal 的解析。 第三，TTL 調整。將您的本地 DNS 解析器設定為對 Captive Portal 偵測探測網域（Apple、Google、Microsoft）提供較短的 TTL，讓裝置頻繁重新查詢，並始終獲得快速的本地回應，而不是等待快取項目過期後才去查詢壅塞的上游解析器。對這些特定網域設定 30 到 60 秒的 TTL 是一個合理的起點。 要避免的陷阱是過度篩選。一些團隊部署了積極的 DNS 封鎖清單，不慎封鎖了合法訪客應用程式所使用的網域——串流服務、企業 VPN 端點、雲端儲存。這會產生不同類別的支援工單，但同樣損害訪客體驗。從保守的策略開始，監控 DNS 查詢記錄中的被封鎖網域，並在鎖定設定之前的兩週內進行調整。 [快問快答 — 約 1 分鐘] 我來快速回顧一下關於此主題我最常被問到的問題。 「我可以只使用 8.8.8.8 作為訪客 DNS 解析器嗎？」可以，但在負載下會逾時。在壅塞的網路上，本地或區域性解析器的效能永遠優於公共解析器。 「這會影響 WPA3 部署嗎？」不會——WPA3 改善了驗證安全性，但不會改變 DNS 解析路徑。無論使用何種加密標準，相同的 DNS 逾時問題都會發生。 「我如何知道 DNS 是造成『connected, no internet』錯誤的實際原因？」在尖峰負載期間，在訪客 VLAN 上執行封包擷取。篩選 UDP 埠 53 流量。如果您看到 DNS 查詢在兩秒內沒有對應的回應，那麼 DNS 逾時就是元兇。 「企業 DNS 篩選器有助於合規嗎？」是的——DNS 查詢記錄提供了稽核追蹤，支援 GDPR 的問責義務，並能協助事件回應。Purple 的平台原生包含了此記錄功能。 [總結與下一步 — 約 1 分鐘] 總結來說：訪客 WiFi 上的「connected, no internet」錯誤絕大多數是因網路壅塞導致未最佳化解析器路徑不堪重負所引起的 DNS 計時問題。解決方法不是更多的頻寬——而是一個本地、高效能的企業 DNS 篩選器，它能快速解析 Captive Portal 偵測探測、維護本機快取，並套用基於策略的篩選來減少上游查詢負載。 本週必做的三件事：在尖峰負載期間執行 DNS 封包擷取以確認診斷；檢視您目前的 DNS 解析器放置位置，並確定它是本地還是遠端；以及評估在您的訪客 VLAN 上部署企業 DNS 篩選器。 如果您想深入了解這些內容，Purple 平台文件詳細說明了 DNS 篩選器設定，purple.ai 上的訪客 WiFi 最佳化指南也值得配合本簡報一起檢閱。感謝收聽——我們下次見。 [節目結束]