解決訪客 WiFi 出現「已連線但無網路」的錯誤
您將能夠診斷訪客在訪客 WiFi 上看到「已連線，無網路」的原因，並透過變更設定來解決問題，無需購買新硬體。本指南將說明如何區分 DNS 超時與 DHCP、受控園區 (walled garden) 及速率限制等故障，接著在您已運行的無線基地台 (AP) 上部署鄰近的企業級 DNS 過濾器。
Video overview
收聽此指南
查看播客逐字稿
核心系列的一部分：訪客 WiFi 指南 →
Guest WiFi “Connected, No Internet” Root-Cause Diagnostic Tool
Select your venue deployment profile, active connection failure symptom, and wireless infrastructure vendor to calculate probe timeout risks, diagnose DNS/DHCP bottlenecks, and generate multi-vendor remediation steps.
Root-Cause Diagnostic Analysis: Captive portal login popup never appears on mobile devices
Severity: CriticalOS captive portal detection probe DNS queries exceed the 2-5 second timeout window due to upstream resolver latency or dropped UDP packets.
Devices display "Connected, No Internet" and automatically drop the connection or fail back to mobile cellular data.
Deploy a local enterprise DNS caching filter, allowlist probe domains, and ensure UDP port 53 is allowed pre-authentication.
Vendor Implementation Guide: Cisco Meraki (Meraki Dashboard)
- DNS Configuration & Resolver Tuning:Under Wireless > Configure > Access control > Addressing and traffic, set Client IP assignment to "External DHCP server" or "Bridge mode" with reliable public Anycast DNS (1.1.1.1, 8.8.8.8).
- DHCP Scope & Lease Duration:In Security & SD-WAN > Configure > Addressing & VLANs, decrease DHCP lease time on the Guest VLAN to 30 minutes to prevent scope starvation.
- Walled Garden Pre-Authentication Rules:Under Wireless > Access control > Walled garden, enable Walled garden and add: *.purple.ai and the portal hosts only. Leave the OS probe hosts (captive.apple.com, connectivitycheck.gstatic.com, msftconnecttest.com) out, or devices will think they are online.
# Meraki Dashboard Configuration:
# 1. Wireless > Configure > Access Control > Splash Page: "Sign-on splash page"
# 2. Walled Garden ranges: *.purple.ai, fonts.googleapis.com (not the OS probe hosts)
# 3. Client IP assignment: Bridge Mode (NAT mode restricts Layer 2 client isolation)Experiencing guest WiFi onboarding failures across your venue?
Purple works with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet, and manages the pre-auth walled garden and DNS allowances that most of these failures trace back to.
訪客 WiFi 上的「已連線但無網際網路」錯誤，發生在強制入口載入前連線檢查失敗的情況。在繁忙的場所中，UDP 連接埠 53 DNS 查詢 (RFC 1035) 會在擁塞期間逾時。要解決此問題，需要將訪客 DHCP 範圍指向快取 DNS 過濾器、完成跨控制器（如 Cisco Meraki）的圍牆花園網域設定，並審視流量整形規則。
訪客 WiFi 上的「已連線，無網際網路」代表什麼？
訪客看到滿格訊號且已加入網路，但任何內容都無法載入。登入頁面從未出現，因此他們無法接受條款或登入。接著他們便會走向前台、服務點或服務櫃檯。
每個作業系統對此警告的措辭不同。您的場所支援團隊應能識別所有警告：
- Windows 在網路名稱下方顯示「無網際網路」。
- Android 顯示「已連線，但無法存取網際網路」或「可能無法連線至網際網路」。
- iPhone 和 iPad 在網路名稱下方顯示「無網際網路連線」。
這三種情況都來自相同的機制。加入網路後，裝置會請求一個知名的網址來測試連線。如果該測試傳回預期的頁面，裝置就會將連線視為正常運作。如果傳回登入頁面，裝置會開啟強制入口。如果完全沒有收到回應，裝置就會回報「無網際網路」。
| 作業系統 | 連線檢查主機名稱 | 失敗時訪客看到的內容 |
|---|---|---|
| iOS、iPadOS、macOS | captive.apple.com | 「無網際網路連線」 |
| Android | connectivitycheck.gstatic.com | 「已連線，但無法存取網際網路」 |
| Windows 10 與 11 | www.msftconnecttest.com | 「無網際網路」 |
在裝置可以請求這些頁面中的任何一個之前，它必須透過 DNS 尋找主機名稱。該尋找過程就是大多數高密度連線失敗的起因。
通常是什麼原因導致訪客 WiFi 出現已連線但無網際網路的錯誤？
擁塞網路上的 DNS 逾時
DNS (網域名稱系統) 將主機名稱轉換為 IP 位址。如 RFC 1035 所定義，大多數 DNS 查詢都透過 UDP 連接埠 53 進行。UDP 沒有內建的重傳機制，因此封包遺失的查詢只能等待裝置本身的重試計時器。
擁塞通常是突發性的。想像一下體育場的中場休息、飯店的早餐退房時間，或是列車進站時。數百台裝置在幾秒鐘之內加入，並且每台裝置都會同時發送尋找請求。如果解析器位於繁忙的 WAN 連線對端，距離多個跳躍 (hop)，查詢就會延遲或被丟棄。裝置隨之放棄，入口網站永遠不會開啟，訪客就會看到「無網際網路」。
其他常見原因
在繁忙的場所中，DNS 是最常見的原因，但並不是唯一的原因。也請排除以下情況：
- 缺少圍牆花園清單項目。 圍牆花園是裝置在登入前可以存取的網域清單。如果缺少您的入口網站或其資源，頁面就無法載入。
- DHCP 位址池耗盡。 如果位址池用盡，裝置會自行分配 169.254.x.x 位址，且無法連線至任何目標。
- UDP 連接埠 53 的速率限制或 QoS 流量調節。 單一用戶端或單一 SSID 限制設定過嚴，可能會在突發流量期間導致 DNS 資源枯竭。
- 加密 DNS。 DNS over HTTPS (DoH, RFC 8484) 與 DNS over TLS (DoT, RFC 7858) 會將查詢傳送到外部解析程式。若圍牆花園封鎖了這些解析程式，將會在登入前中斷查詢。
- 上游網路中斷。 若 WAN 連線本身中斷，所有裝置都會失敗，所有有線連接埠也會一併失效。
如何判斷是由哪種原因所致？
請從現象模式著手，而非硬體。在變更任何設定前，先使用此矩陣縮小可能的原因範圍。
| 觀察到的現象 | 最可能的原因 | 首要行動 |
|---|---|---|
| 錯誤在可預測的高峰期暴增，離峰時段正常 | 壅塞導致 DNS 超時 | 將訪客 DHCP 指向附近的快取 DNS 過濾器 |
| 整天下來所有裝置皆失敗 | 上游 WAN 中斷或 DHCP 中的 DNS 伺服器設定錯誤 | 測試 WAN 連線與 DHCP DNS 設定 |
| 裝置顯示 169.254.x.x 位址 | DHCP 位址池已耗盡 | 擴大位址池或縮短租約時間 |
| 入口網站開始載入但卡住或顯示空白頁面 | 圍牆花園遺漏入口網站網域 | 從您的 Purple 設定文章中新增網域 |
| 僅部分 Android 裝置或筆記型電腦失敗 | 裝置上設定了私用 DNS、DoT 或 DoH | 請訪客將「私用 DNS」切換為「自動」 |
| 僅在超越每台 AP 容許的裝置數量上限時失敗 | UDP 連接埠 53 設有速率限制或 QoS | 檢視訪客 SSID 流量修整規則 |
您的支援團隊可執行的三項檢查
- 檢查裝置的 IP 位址。 169.254.x.x 位址指向 DHCP 問題，而非 DNS。正常的訪客範圍位址代表裝置已正常加入網路。
- 在測試裝置上計算查詢時間。 在訪客網路上的筆記型電腦執行
nslookup captive.apple.com。繁忙時段若回應緩慢或失敗，即證實存在 DNS 瓶頸。 - 在訪客 VLAN 上擷取封包。 VLAN (虛擬區域網路) 可將訪客流量與您的其他網路相隔離。針對
udp port 53過濾擷取結果，並尋找沒有對應回應的查詢。
接著檢查錯誤發生的時間。在 WiFi Analytics 中，將連線與登入量與訪客回報問題的時間進行比對。若失敗情況與最繁忙的時段吻合，即明確指向網路壅塞。
對於您的特定設置有任何疑問嗎？
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話，我們將向您展示其他與您相似的用戶是如何解決此問題的。
企業級 DNS 過濾器如何解決瓶頸？
企業級 DNS 過濾器是位於您控制之下、部署在靠近訪客網路位置的解析程式。它能取代目前由 DHCP 發放的遠端 ISP 或公開解析程式。它透過執行三項工作來消除超時問題。
從快取提供回應。 在繁忙的場館中，連線檢查主機名稱每小時會被要求數千次。附近的過濾器能直接從快取回應重複的查詢，因此這些查詢完全不需要跨越壅塞的 WAN 連線。
提早丟棄非必要的流量。 對於惡意或已封鎖類別的查詢，過濾器會直接拒絕。這能為重要的查詢釋放出 WAN 容量。
它會記錄每次查詢。 您會收到哪些網域失敗、失敗時間和頻率的紀錄。下次主管回報問題時，就能將猜測轉化為確切證據。
部署位置
對於分散式資產（例如擁有數百個小型據點的 零售 連鎖店），具有附近邊緣位置的雲端傳送篩選器通常是務實的選擇。對於大型單一據點（例如體育場或會議中心），由現場託管的解析程式可完全避免 WAN 上的查詢。在兩種情況下，都請在 DHCP 中提供兩個解析程式位址，以免單點故障導致網路中斷。
決定成功的兩項設定
首先，在篩選器中允許您的強制入口網域。如果篩選器封鎖或延遲了入口，將會重現您想要修復的相同錯誤。其次，將訪客 DNS 與企業 DNS 分開。PCI DSS 將網路分割視為防範訪客網路存取持卡人資料環境範圍的方法。
如何在各廠商與作業系統上進行修復？
在您的存取點和控制器上
Purple 獨立於硬體之外，並作為雲端重疊架構執行於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 上。修復方式在所有系統上皆遵循相同的公式步驟：
- 將訪客 DHCP 範圍中的 DNS 伺服器更新為您的企業 DNS 篩選器。
- 完成圍牆花園 (walled garden)。 Cisco Meraki、HPE Aruba 和 Ruckus 皆使用「圍牆花園」一詞。請遵循適用於您廠商的 Purple 設定文章，其中列出了要允許的確切網域。
- 檢查訪客流量塑造 (traffic shaping)，避免在流量突增期間因個別用戶端限制而節流 UDP 連接埠 53。
請勿在不同廠商之間複製設定。選單名稱和預設值各不相同，因此請結合使用廠商自身的說明文件與 Purple 設定文章。
在訪客的裝置上
當只有單一訪客受影響而其他人正常時，您的服務台團隊可以嘗試以下步驟：
- 清除網路設定並重新連線，以觸發新的連線檢查。
- 在瀏覽器中開啟純 http:// 位址，強制顯示入口。
- 在 Android 上，將「私人 DNS」設定為「自動」。 固定私人 DNS 提供者可能會在登入前封鎖查詢。
- 暫停任何 VPN 應用程式，直到訪客完成登入。
實作情境
以下數據僅供說明參考，並非取自特定部署項目。請將其作為您場地量測指標的參考模型。
擁有 200 間客房的飯店早餐時段
狀況。 櫃檯收到關於「無法連線至網際網路」的投訴集中在上午 7 點至 9 點之間，即訪客退房前查看電子郵件的時間。存取點顯示訊號良好且有空閒的傳輸時間。訪客 DHCP 分配了 ISP 的解析程式，該程式經由繁忙的線路跨越了多個躍點。
採取的行動。 IT 經理在尖峰時段執行了 nslookup，發現查詢完全失敗。團隊將訪客 DHCP 指向雲端 DNS 篩選器，將入口網域新增至圍牆花園，並將訪客 DNS 與物業管理網路分開。
**結果。**根據 WiFi Analytics 與服務台記錄顯示，尖峰時段的入口網站完成率從 81% 提升至 97%。服務台接獲的 WiFi 抱怨案件從每早約 15 件降至兩件。如需更多關於 飯店 訪客網路的資訊，請參閱我們的旅宿業頁面。
中場休息時容納 3 萬人的體育場
**狀況。**球迷反映每次中場休息時都會出現「已連線但無網際網路」，但每半場的前 10 分鐘運作順暢。訪客 VLAN 上的封包擷取顯示，在流量突增期間有 DNS 查詢未獲回應的情形。
**處置措施。**網路架構師部署了具備雲端備援機制的本機解析器。團隊移除了對 UDP 連接埠 53 進行速率限制的單一用戶端限制，並將 DHCP 範圍轉移至新的解析器。
**結果。**在中場休息時，未回應的 DNS 查詢在後續擷取中從 12% 降至 1% 以下。與上一場比賽相比，中場休息期間的球迷登入量增加了 40%。
如何防止「已連線但無網際網路」的錯誤再次發生？
- **切勿僅依賴遠端的公共解析器。**公共 DNS 總體效能良好，但距離數個跳躍（hop）遠的解析器會在流量突增期間增加您無法控制的延遲。
- **針對未回應的 DNS 查詢設定警示。**設定您的防火牆或核心交換器，以便在訪客網路上 UDP 連接埠 53 的丟包率上升時發出標記，這能在訪客察覺之前提示逾時狀況。
- **每月審查 DNS 過濾封鎖清單。**過度激進的分類會破壞合規的應用程式，並產生新的支援工單。
- **設定日誌保留期。**DNS 日誌會將 IP 位址連結至造訪的網域，因此請將其視為 GDPR 規範下的個人資料處理。
- **在硬體支援的情況下採用 RFC 8910。**這能讓 DHCP 告知裝置強制入口的位置，減少裝置對連線檢查查詢的依賴。
- **考量回訪者的 Passpoint。**Passpoint（亦稱 Hotspot 2.0）與 OpenRoaming 允許裝置安全地加入而無需強制入口，從而為這些裝置完全消除此故障模式。
Purple 在 90 多個國家/地區的 80,000 多個現場場地營運 Guest WiFi，每年有 5 億名使用者與登入次數。從 醫療照護 等候室到 列車，規律始終如一：在購買頻寬之前，請先修復 DNS。
常見問題
我們需要新的基地台來修復「已連線但無網際網路」的錯誤嗎？
不需要，在大多數情況下您並不需要。當錯誤發生在尖峰時間時，原因通常是 DNS 解析，而非基地台硬體。修復方法是變更設定：將訪客 DHCP 指向附近的企業 DNS 過濾器、完成圍牆花園（walled garden）並審查流量整形規則。僅在封包擷取顯示基地台本身在正常負載下丟棄流量，且已排除 DHCP 與 DNS 問題後，才更換硬體。
Purple 能否搭配我們現有的硬體運作？
是的，Purple 可以運行在您現有的基地台 (Access Point) 上。Purple 獨立於硬體架構，並可以雲端重疊網路的形式部署於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 上。您無需全部拔除更換。Purple 為每個供應商都發布了設定文章，列出了您的控制器所需的 walled garden 網域，以便強制入口在訪客登入前順利載入。
企業級 DNS 過濾器會拖慢我們的訪客 WiFi 速度嗎？
不會，配置得當的 DNS 過濾器通常會使查詢速度更快。它比 ISP 或公開解析器更接近訪客網路，並能直接從快取中回應重複的查詢。風險在於位置與設定，而非過濾本身。請提供兩個解析器位址以達到備援效果，並允許您的強制入口網域，使過濾器絕不會延遲登入頁面。
為什麼不直接給訪客提供像 8.8.8.8 這樣的公開解析器？
您可以這麼做，但這無法解決網路壅塞導致的逾時問題。公開解析器仍然位於您的廣域網路 (WAN) 連結對面，因此每次查詢都會與引發故障的高峰流量相互競爭。此外，它無法提供任何過濾功能，也沒有用於疑難排解的查詢紀錄。鄰近的企業過濾器能從快取回應、拒絕不合適的類別並記錄每次失敗的查詢，這些都是公開 DNS 無法為您做到的。
我們該如何在 GDPR 規範下處理 DNS 查詢紀錄？
請將 DNS 紀錄視為個人資料，因為它們會將 IP 位址連結至裝置造訪過的網域。請設定明確的保留期限、限制僅供您的網路與安全團隊存取，並在您的隱私權通知中記錄其目的。Purple 通過 ISO 27001 認證並符合 GDPR 規範，且您的 DNS 過濾器供應商在您引導訪客流量通過它之前，也應展示同等的認證。
部署需要投入多少精力？
變更本身很小；測試佔據了大部分的精力。您只需更新訪客 DHCP 範圍中的 DNS 伺服器、將入口網域新增至過濾器的允許清單，並檢查 walled garden。請計劃在真實的高峰期（例如早餐尖峰時間或半場休息時間）進行測試，因為離峰的下午無法重現導致錯誤的網路壅塞。
Passpoint 或 OpenRoaming 會消除這個錯誤嗎？
是的，對於使用它們的裝置來說確實如此。Passpoint 與 OpenRoaming 能讓裝置在沒有強制入口的情況下安全加入，因此不會發生入口故障的情況。首次造訪者以及沒有 Passpoint 設定檔的裝置仍會使用強制入口，因此您仍然需要快速的 DNS 與完整的 walled garden。建議兩者同時實施：針對再次造訪的訪客採用 Passpoint，針對其他所有人則採用經最佳化的入口。
關鍵定義
強制入口
訪客網路在提供網路存取前所提供的登入頁面。RFC 8910 定義了 DHCP 和 IPv6 路由器通告 (Router Advertisement) 選項，可告知裝置入口網站的 API 位址，因此不必從失敗的網頁請求中推斷入口網站。
您的訪客在此接受條款或進行登入。如果入口網站始終無法開啟，他們就無法上網，問題就會反映到服務櫃檯或協助點。
連線檢查
每個作業系統在加入網路後傳送到已知主機名稱的 HTTP 請求：iOS、iPadOS 和 macOS 上為 captive.apple.com；Android 上為 connectivitycheck.gstatic.com；Windows 10 和 11 上則為 www.msftconnecttest.com。預期的頁面代表已連線，登入頁面會觸發強制入口，而無回應則代表「無網路」。
此檢查會產生您的支援團隊所看到的各種警告變體。它首先取決於 DNS 查詢，而高密度連線的故障正是從這裡開始發生的。
DNS（功能變數名稱系統）
RFC 1035 中規範將主機名稱解析為 IP 位址的協定。大多數查詢透過 UDP 連接埠 53 傳輸，該連接埠沒有內建的重傳機制，因此遺失的查詢會等待裝置自身的重試計時器。
當數百台裝置同時加入，且解析器位於繁忙的廣域網路 (WAN) 連線另一端時，查詢就會超時，強制入口也永遠無法開啟。
企業級 DNS 過濾器
由您控制且部署於靠近訪客網路位置的解析器，它能從快取回應重複的查詢、拒絕惡意或受阻擋類別的查詢，並依網域、時間和頻率記錄每一次查詢。
它能在您的訪客 DHCP 範圍中取代遠端 ISP 或公共解析器。針對分散式據點可部署雲端型服務，針對單一大型場館則可部署於本機。
受控園區 (Walled garden)
裝置在強制入口網路進行驗證前，可以連線的網域清單。Cisco Meraki、HPE Aruba 與 Ruckus 皆在其控制器設定中使用此術語。
如果缺少您的入口網站網域或資源，頁面將會停擺或顯示空白。Purple 的各廠商設定文章列出了確切允許的網域。
DHCP 位址池耗盡
動態主機設定協定 (RFC 2131) 伺服器在其作用域內沒有可用位址的狀態，導致新裝置自動指派 169.254.x.x 連結本地位址，無法連線至任何目標。
訪客裝置上的 169.254.x.x 位址指向的是 DHCP ปัญหา而非 DNS。請擴大位址池或縮短租約時間。
DNS over HTTPS (DoH) 與 DNS over TLS (DoT)
加密的 DNS 傳輸方式：如 RFC 8484 所規範，DoH 會在 HTTPS 內部傳送查詢；如 RFC 7858 所規範，DoT 則透過 TLS 工作階段傳送查詢。兩者皆會將尋找傳送至網路外部的解析程式。
若圍牆花園封鎖了這些外部解析程式，會在登入前中斷尋找。在 Android 上，請要求訪客將「私人 DNS」設定為「自動」。
VLAN（虛擬區域網路）
由 IEEE 802.1Q 標記所定義的邏輯網路區段，能在共享的交換架構上將訪客流量與其他網路區隔開來。
在訪客 VLAN 上擷取封包並對 udp 連接埠 53 進行篩選，以找出未回應的查詢。網路分段亦可防止訪客流量進入 PCI DSS 持卡人資料環境範疇。
Passpoint (Hotspot 2.0) 與 OpenRoaming
Passpoint（亦稱為 Hotspot 2.0）基於 IEEE 802.11u 網路發現與 IEEE 802.1X 基於連接埠的驗證，讓具有設定檔的裝置無需透過強制入口即可安全連線。OpenRoaming 則將此機制延伸至參與計畫的各個網路。
具有設定檔的再次造訪者不會觸發入口網站，因此這種失敗模式對他們而言將不復存在。首次造訪者仍需要快速的 DNS 與完整的圍牆花園。
GDPR 個人資料（DNS 記錄）
根據 UK GDPR 與歐盟 GDPR，將識別碼（例如 IP 位址）與活動相連結的資訊視為個人資料，必須明確指定用途、限制保留期限並限制存取權限。
DNS 篩選記錄會將 IP 位址與造訪的網域連結。請設定保留期限、限制僅供網路與資安團隊存取，並在隱私權聲明中記載使用目的。
範例
一家擁有 200 間客房的飯店，在上午 7 點到 9 點之間接獲櫃檯反映「無網路」的客訴。無線基地台顯示訊號正常且空口時間 (airtime) 充足，但訪客 DHCP 發放的 ISP 解析器卻隔著繁忙的連線需要跨越數個跳躍點 (hop)。IT 經理該怎麼做？（數據僅供參考。）
IT 經理在尖峰時段使用訪客網路的筆記型電腦執行 nslookup，發現查詢直接失敗，確認瓶頸在於 DNS 而非無線電訊號故障。團隊將訪客 DHCP 指向雲端 DNS 過濾器，讓重複的連線檢查查詢能直接由快取回應。他們將入口網站網域新增至受控園區 (walled garden)，使登入頁面能在登入前順利載入。他們保持訪客 DNS 與物業管理網路互相隔離，以維持網路片段化。經由 WiFi Analytics 與櫃檯紀錄衡量，尖峰時段的入口網站完成率從 81% 提升至 97%，櫃檯客訴也從每早約 15 件降至 2 件。
一座可容納 30,000 人的體育場中，球迷在每次中場休息時都回報「已連線但無網路」，而每半場的前十分鐘連線卻很順暢。在訪客 VLAN 上擷取的封包顯示，突發流量期間的 DNS 查詢均無回應。網路架構師該如何處理？（數據僅供參考。）
此模式指向網路擁塞，因此架構師部署了具備雲端備援的本機解析器。將查詢保留在本機，可在突發流量期間完全免除廣域網路 (WAN) 的負擔。團隊還發現並移除了限制 UDP 連接埠 53 的每用戶端速率限制，該限制會在數千台裝置同時連線時導致 DNS 匱乏。他們將訪客 DHCP 範圍移至新的解析器。後續的封包擷取顯示，中場休息時未回應的 DNS 查詢從 12% 降至 1% 以下。與上一場比賽相比，中場休息期間的球迷登入人數增加了 40%。
練習題
Q1. 體育場的 IT 總監注意到在中場休息期間，有數千名使用者連線至 WiFi，卻無法開啟強制入口。核心交換器顯示大量的 UDP 封包遺失。他們是否應該將 WAN 頻寬從 2Gbps 增加到 5Gbps？
提示：請思考被捨棄的是何種協定，以及其是否與有效負載頻寬或連線狀態限制有關。
查看標準答案
否。增加 WAN 頻寬無法解決此問題。UDP 封包遺失表示防火牆或解析程式無法處理龐大的同時段 DNS 查詢量（狀態表耗盡或 CPU 限制）。正確的做法是在邊緣部署高效能的本機 DNS 篩選器，於本機快取並回應這些查詢，完全繞過 WAN 瓶頸。
Q2. 您剛剛在飯店的訪客網路上部署了企業級 DNS 篩選器。訪客現在可以快速解析公開網站，但首次連線時，卻未被重導向至飯店的登入頁面。最可能的設定錯誤是什麼？
提示：請思考登入頁面本身的網域名稱。
查看標準答案
最可能的錯誤是強制入口自身的網域未在 DNS 篩選器中明確加入白名單（直通）。篩選器封鎖或延遲了入口網站 URL 的解析，導致重導向無法完成。
Q3. 某公務機關要求所有訪客 WiFi 流量必須記錄 90 天，以符合安全性政策。部署企業級 DNS 篩選器如何協助滿足這項要求？
提示：請比較 DNS 篩選器與標準防火牆所處理的資料有何不同。
查看標準答案
企業級 DNS 篩選器原生即可記錄用戶端裝置發出的所有 DNS 查詢。這能提供清晰且可搜尋的稽核軌跡，記載何時請求了哪些網域，無需對所有加密的 HTTPS 有效負載流量進行深層封包檢測，即可滿足 90 天的記錄保留要求。
常見問題
Why does guest WiFi say connected but no internet?
The 'Connected, No Internet' status occurs when a client device associates with an access point and receives an IP address, but its operating system detection probe fails to reach the internet. On guest WiFi networks, this is most commonly caused by DNS query timeouts on captive portal detection domains (such as captive.apple.com or connectivitycheck.gstatic.com), DHCP lease scope exhaustion, or firewalls blocking pre-authentication DNS traffic.
How do captive portal detection probes work on guest WiFi across iOS, Android, and Windows?
When connecting to an open or guest WiFi SSID, modern operating systems immediately transmit plaintext HTTP probe requests to vendor test URLs (iOS uses captive.apple.com/hotspot-detect.html, Android queries connectivitycheck.gstatic.com/generate_204, and Windows tests msftconnecttest.com/connecttest.txt). If the network returns an HTTP 200/204, the OS marks the connection as having internet. If it receives an HTTP 302 redirect, it launches the captive portal browser. If the initial DNS query for the probe domain times out, the OS reports 'Connected, No Internet' and drops the link.
How do DNS timeouts trigger guest WiFi connection drops?
In high-density environments, hundreds of devices query upstream DNS resolvers simultaneously over UDP port 53. If the local guest WiFi network forwards raw queries directly to rate-limited ISP resolvers without caching, response latency spikes above 2,000ms. Mobile devices enforce strict 2- to 5-second probe timeouts. Once that threshold is exceeded, the device assumes the network is broken and abandons the connection before the splash page can load.
What walled garden domains must be allowed before guest WiFi captive portal login?
Pre-authentication access control lists (walled gardens) on guest WiFi networks must permit outbound UDP and TCP port 53 to your designated DNS resolvers, DHCP transactions (UDP 67/68), and OS detection probes (captive.apple.com, connectivitycheck.gstatic.com, msftconnecttest.com). If using external captive portal hosting, CDN styling, or social login, you must also allow your portal domain (*.purple.ai), Google Fonts (fonts.googleapis.com), and OAuth endpoints.
How does DHCP pool exhaustion cause connected without internet errors on guest WiFi?
When venues configure long DHCP lease durations (such as 24 hours) on guest WiFi in environments with rapid visitor turnover, the pool of available IP addresses quickly runs out. New arrivals may associate with the access point via 802.11 beacons, but fail to receive a valid DHCPOFFER or default gateway, receiving a self-assigned 169.254.x.x APIPA address instead. Shortening lease times to 30 to 60 minutes and configuring dynamic VLAN pooling prevents scope starvation.
How does Purple prevent captive portal and DNS timeout failures on guest WiFi?
Purple acts as a resilient, hardware-agnostic guest WiFi management platform across Cisco Meraki, HPE Aruba, Ruckus, Ubiquiti UniFi, and Fortinet architectures. By optimizing captive portal redirection flows, automating walled garden rules, and integrating with high-speed Anycast DNS, Purple ensures detection probes succeed instantly, onboarding visitors in under 3 seconds without connection drops.
參考來源
- RFC 1035: Domain names, implementation and specification
- RFC 8484: DNS queries over HTTPS (DoH)
- RFC 7858: DNS over Transport Layer Security (DoT)
- RFC 8910: Captive-portal identification in DHCP and Router Advertisements
- RFC 2131: Dynamic Host Configuration Protocol
- PCI Security Standards Council: PCI DSS
- Information Commissioner's Office: UK GDPR guidance
繼續閱讀本系列
使用封包擷取 (PCAP) 診斷慢速 WiFi 效能
本技術參考指南為 IT 經理、網路架構師和場域營運總監提供了一套結構化的封包級方法論，利用封包擷取 (PCAP) 分析來診斷和解決慢速企業級 WiFi 效能。透過剖析原始的 802.11 訊框 - 包括重傳率、空口時間利用率和實體層元數據 - 團隊可以精準地將 RF 層瓶頸與有線網路或應用程式問題隔離開來。本指南適用於高密度場域，包括飯店、零售連鎖、體育場和會議中心，提供具體可行的診斷工作流程、真實案例研究以及設定補救步驟，以收回網路容量並保護顧客體驗。
為什麼您的體育場 WiFi 會陷入停頓（以及如何解決）
本權威技術指南探討了體育場 WiFi 壅塞的根本原因 - 50,000 台設備同時載入程序化廣告和遙測數據的背景雜訊 - 並為部署邊緣 DNS 過濾作為主要緩解策略提供了詳細的架構藍圖。本指南專為 IT 總監、CTO 和網絡架構師設計，提供可行的實施指南、真實案例研究和可衡量的 ROI 框架，幫助場館營運商回收頻寬並大規模提供高效能的連線。
為什麼我們的顧客 WiFi 這麼慢？診斷網路擁塞問題
本指南診斷了顧客 WiFi 擁塞的隱形原因 - 背景遙測、程式化廣告網路以及 OS 自動更新 - 這些在顧客開啟瀏覽器前就合共消耗了高達 40% 的公共 WiFi 頻寬。指南為 DNS 過濾與 QoS 策略提供了一個分階段且不限廠商的實作框架，可收回這些頻寬、提升顧客體驗並帶來可衡量的 ROI。本指南專為飯店、零售、活動和公共部門環境的 IT 總監與營運經理而設計。
對於您的特定設置有任何疑問嗎？
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話，我們將向您展示其他與您相似的用戶是如何解決此問題的。