解决访客 WiFi 上的“已连接但无法访问互联网”错误
您将能够诊断为何访客会在访客 WiFi 上看到“已连接，无互联网连接”，并通过配置更改而非更换新硬件来解决该问题。本指南将展示如何区分 DNS 超时与 DHCP、围墙花园（walled garden）及速率限制故障，然后在您已运行的接入点上部署就近的企业级 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 上出现“已连接但无互联网”错误的原因，通常是设备在 Captive Portal 加载前未通过连通性检查。在拥挤的场所中，UDP 端口 53 DNS 查询（RFC 1035）很容易因网络拥堵而超时。要解决此问题，需要将访客 DHCP 作用域指向缓存 DNS 过滤器，在 Cisco Meraki 等控制器上完整配置 walled garden 域名，并审查流量整形规则。
访客 WiFi 上的“已连接，无互联网”具体表现为何？
访客看到信号满格且已加入网络，但任何内容都无法加载。登录页面始终未出现，因此他们无法接受条款或登录。接着，他们就会走向前台、服务台或服务柜台。
每个操作系统对此警告的表述各不相同。您的现场支持团队应当能识别所有这些提示：
- Windows 在网络名称下方显示“无 Internet”。
- Android 显示“已连接但无法访问互联网”或“互联网可能不可用”。
- iPhone 和 iPad 在网络名称下方显示“无互联网连接”。
这三种情况均源于相同的机制。加入网络后，设备会请求一个已知的 Web 地址来测试连接。如果测试返回了预期页面，设备则认为连接正常。如果返回的是登录页面，设备就会打开 Captive Portal。如果根本没有收到任何响应，设备就会报告“无互联网”。
| 操作系统 | 连通性检查主机名 | 失败时访客看到的内容 |
|---|---|---|
| iOS、iPadOS、macOS | captive.apple.com | “无互联网连接” |
| Android | connectivitycheck.gstatic.com | “已连接但无法访问互联网” |
| Windows 10 和 11 | www.msftconnecttest.com | “无 Internet” |
在设备请求任何这些页面之前，它必须先通过 DNS 解析主机名。而这一查询步骤正是大多数高密度场景下发生故障的起点。
导致访客 WiFi 上出现“已连接无互联网”错误的原因通常是什么？
繁忙网络中的 DNS 超时
DNS（域名系统）用于将主机名转换为 IP 地址。根据 RFC 1035 的定义，大多数 DNS 查询都通过 UDP 端口 53 传输。UDP 没有内置的重传机制，因此丢弃的查询只能等待设备自身的重试定时器。
网络拥堵往往是突发的。例如体育场的半场休息、酒店的早餐退房高峰，或是列车进站时刻。数百台设备会在几秒钟内同时加入，每台设备都会立即发送域名解析请求。如果解析器位于多个跳数之外的繁忙 WAN 链路上，查询就会被延迟或丢弃。设备放弃请求后，Portal 页面便无法打开，访客就会看到“无互联网”。
其他常见原因
虽然 DNS 是高流向场所中最常见的原因，但并非唯一原因。还需要排除以下因素：
- 缺少 walled garden 条目。 Walled garden 是设备在登录前允许访问的域名列表。如果缺少 Portal 页面或其相关资源的域名，页面就无法加载。
- DHCP 地址池耗尽。 如果地址池用尽，设备会自动为自己分配 169.254.x.x 地址，从而无法连接任何网络。
- 速率限制或 QoS 抑制 UDP 端口 53。 按客户端或按 SSID 设置的限制过于严格，可能会在流量激增期间导致 DNS 饿死。
- 加密 DNS。 基于 HTTPS 的 DNS (DoH, RFC 8484) 和基于 TLS 的 DNS (DoT, RFC 7858) 会将查询发送到外部解析程序。如果未将这些解析程序加入 walled garden 白名单，查询就会在登录前被拦截。
- 上游网络故障。 如果 WAN 链路本身断开，所有设备都会失败，每个有线端口也会随之失效。
如何排查具体原因？
请从排查规律入手，而不是先动硬件。在更改任何设置之前，使用此矩阵缩小故障原因的范围。
| 您观察到的现象 | 最可能的原因 | 首要排查动作 |
|---|---|---|
| 错误在可预测的高峰期激增，空闲时正常 | 拥堵导致 DNS 超时 | 将访客 DHCP 指向附近的缓存 DNS 过滤器 |
| 全天所有设备均失败 | 上游 WAN 故障或 DHCP 中的 DNS 服务器错误 | 测试 WAN 链路和 DHCP 的 DNS 设置 |
| 设备显示 169.254.x.x 地址 | DHCP 地址池耗尽 | 扩大地址池或缩短租期时间 |
| Portal 页面开始加载但卡住或显示空白页 | walled garden 中缺少 Portal 域名 | 从 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 中，将连接和登录量与访客报告问题的时间进行对比。与最繁忙时段吻合的失败极有可能是由网络拥堵引起的。
企业级 DNS 过滤器如何解决瓶颈问题？
企业级 DNS 过滤器是一个由您控制、部署在靠近访客网络位置的解析程序。它会替代当前 DHCP 分发的远程 ISP 或公共解析程序。它通过三项工作来消除超时。
从缓存进行响应。 在繁忙的场馆中，连通性检查的主机名每小时会被请求数千次。附近的过滤器可以直接从其缓存响应重复的查询，从而无需跨越拥堵的 WAN 链路。
提前丢弃不需要的流量。 针对恶意或被阻止类别的查询会在过滤器端被拒绝。这就为关键的查询释放了 WAN 带宽容量。
它会记录每次查询。 您可以获得失败的域名、发生时间和频率的记录。下一次经理报告问题时，这些记录能将凭空猜测转化为有效证据。
部署位置选择
对于拥有数百个小型门店的 零售 连锁等分布式资产，采用具备就近边缘位置的云端过滤器通常是切实可行的选择。对于体育场或会议中心等单一大型场所，本地托管的解析器则能完全避免 WAN 上的查找流量。在这两种情况下，都要在 DHCP 中分配两个解析器地址，以防止单点故障导致网络瘫痪。
决定成功的两项设置
首先，在过滤器中允许您的强制门户域名。如果过滤器拦截或延迟门户，将会重新引发您试图修复的错误。其次，保持访客 DNS 与企业 DNS 分离。PCI DSS 将网络隔离视为防止访客网络进入持卡人数据环境范围的有效手段。
对您的具体配置有疑问吗？
我们的团队与 80,000 多个场所的运营方、IT 经理和网络工程师保持合作。预约 20 分钟的通话，我们将为您展示同行是如何解决类似问题的。
如何针对各个厂商和操作系统进行修复？
在您的接入点和控制器上
Purple 独立于硬件，可以作为云重叠网络运行在 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 上。修复步骤在所有这些设备上均遵循相同的三个步骤：
- 更新访客 DHCP 范围内的 DNS 服务器 为您的企业 DNS 过滤器。
- 完善围墙花园（Walled Garden）。 Cisco Meraki、HPE Aruba 和 Ruckus 都使用“围墙花园”这一术语。请参考针对您厂商的 Purple 设置指南，其中列出了要允许的准确域名。
- 检查访客流量整形设置，确保单客户端限制不会在突发高峰期对 UDP 端口 53 进行限速。
请勿在不同厂商之间复制设置。菜单名称和默认值有所不同，因此请结合 Purple 设置指南使用厂商自身的文档。
在访客设备上
当仅有单个访客受影响而其他人均正常时，您的服务台团队可以尝试以下步骤：
- 忽略网络并重新连接 以触发全新的连通性检查。
- 在浏览器中打开一个普通的 http:// 地址 以强制显示门户。
- 在 Android 上，将“私有 DNS”设置为“自动”。 固定的私有 DNS 提供商可能会在登录前拦截查找请求。
- 暂停任何 VPN 应用，直到访客完成登录。
实操场景分析
以下数据仅作说明使用，并非来自具体命名的实际部署。请将其作为您在自己场所进行测量的参考模型。
拥有 200 间客房的酒店早餐时段
状况。 前台关于“无法上网”的投诉集中在上午 7 点至 9 点之间，此时访客会在退房前查看电子邮件。接入点显示信号良好且空口时间充足。访客 DHCP 分配的是 ISP 的解析器，该解析器跨越繁忙线路且存在多个跳数。
应对措施。 IT 经理在高峰期运行了 nslookup，发现查找请求直接失败。团队将访客 DHCP 指向了云 DNS 过滤器，将门户域名添加到围墙花园中，并保持访客 DNS 与物业管理网络相互隔离。
结果。 根据 WiFi Analytics 和前台记录测算，高峰期 Portal 页面完成率从 81% 提升至 97%。前台收到的 WiFi 投诉量从每天早晨约 15 起降至 2 起。如需了解更多关于 酒店 客用网络的信息，请访问我们的酒店业页面。
中场休息时拥有 3 万名观众的体育场
现状。 每次中场休息时，球迷都会反馈出现“已连接但无法接入互联网”的问题，而半场比赛的前十分钟网络运行顺畅。客用 VLAN 上的数据包捕获显示，在流量突增期间出现 DNS 查询未响应的情况。
应对措施。 网络架构师部署了具有云端备用机制的本地解析器。团队取消了限制 UDP 端口 53 的单客户端速率限制，并将 DHCP 作用域迁移至新的解析器。
结果。 在后续的数据包捕获中，中场休息时未响应的 DNS 查询比例从 12% 降至 1% 以下。中场休息期间的球迷登录量比上一场比赛增长了 40%。
如何防止“已连接但无法接入互联网”的错误再次发生？
- 切勿仅依赖远程公共解析器。 公共 DNS 总体性能良好，但距离较远的解析器在流量突增期间会增加您无法控制的延迟。
- 对未响应的 DNS 查询设置警报。 配置您的防火墙或核心交换机，对客用网络上增加的 UDP 端口 53 丢包发出警报，这能在访客察觉到超时之前发出信号。
- 每月审查一次 DNS 过滤器黑名单。 过于激进的拦截分类会破坏合法应用并引发新的支持工单。
- 设置日志保留期限。 DNS 日志会将 IP 地址与访问的域名关联起来，因此在 GDPR 合规要求下应将其视为个人数据。
- 在硬件支持的前提下采用 RFC 8910。 它允许 DHCP 直接告知设备 Captive Portal 的位置，从而降低设备对连通性检查查找的依赖。
- 为老访客引入 Passpoint。 Passpoint（也称为 Hotspot 2.0）和 OpenRoaming 允许设备在无需 Captive Portal 的情况下安全接入，从而彻底消除了这一故障隐患。
Purple 在 90 多个国家的 80,000 多个实时场所运行 Guest WiFi，每年拥有 5 亿用户和登录量。从 医疗保健 候诊室到 列车，这一规律始终适用：在购买额外带宽之前，先修复 DNS 问题。
常见问题解答
我们需要更换新的无线接入点来解决“已连接但无法接入互联网”的错误吗？
不需要，在大多数情况下您无需更换。当错误集中在高峰时段发生时，原因通常是 DNS 解析，而非无线接入点硬件本身。解决方案是通过配置变更：将客用 DHCP 指向附近的企业级 DNS 过滤器，完成围墙花园设置并审查流量整形规则。只有在数据包捕获显示无线接入点本身在正常负载下发生丢包，且您已排除 DHCP 和 DNS 问题之后，才需要更换硬件。
Purple 能否与我们现有的硬件配合使用？
是的，Purple 可以运行在您现有的接入点上。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 服务器，将门户域名添加到过滤器的允许列表中，并检查围墙花园即可。请计划在真正的业务高峰期（例如早餐高峰或中场休息）进行测试，因为安静的下午无法复现导致错误的网络拥塞。
Passpoint 或 OpenRoaming 能消除此错误吗？
是的，对于使用它们的设备确实如此。Passpoint 和 OpenRoaming 允许设备安全加入而无需强制门户，因此不会发生门户加载失败的情况。首次访问的访客以及没有 Passpoint 配置文件（Profile）的设备仍会使用强制门户，因此您仍然需要快速的 DNS 和完整的围墙花园。建议两者结合运行：为再次到访的访客提供 Passpoint，为其他所有人提供调优后的门户。
关键定义
强制门户
访客网络在授予互联网访问权限之前提供的登录页面。RFC 8910 定义了一个 DHCP 和 IPv6 路由器通告选项，该选项向设备告知门户的 API 地址，因此设备无需从失败的 Web 请求中推断门户。
您的访客在此接受条款或进行登录。如果门户无法打开，他们将无法上网，问题就会落到前台或服务台。
连接检查
每个操作系统在加入网络后发送到已知主机名的 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 或公共解析器。对于分布式资产可部署云端交付版本，对于单个大型场所可部署在本地。
围墙花园
设备在强制门户网络上进行身份验证之前可以访问的域名列表。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 传输：DoH 如 RFC 8484 所规定在 HTTPS 内部传输查询，而 DoT 如 RFC 7858 所规定通过 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 点之间收到前台关于“无法访问互联网”的投诉。接入点显示信号良好且空闲信道空闲率充足，而访客 DHCP 将 DNS 解析器分发给跨越繁忙线路的多个跳数外的 ISP。IT 经理应该怎么做？（数字仅作示意。）
IT 经理在高峰时段从访客网络笔记本电脑运行了 nslookup，发现查询彻底失败，这证实了是 DNS 瓶颈而非无线电故障。团队将访客 DHCP 指向云端 DNS 过滤器，从而从缓存中响应重复的连接检查查询。他们将门户域名添加到围墙花园中，以便登录页面在登录前正常加载。他们将访客 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 拥堵的根本原因：5万台设备同时加载程序化广告和遥测数据而产生的背景杂音，并为部署边缘 DNS 过滤作为主要缓解策略提供了详细的架构蓝图。本指南专为 IT 总监、CTO 和网络架构师设计，提供可操作的实施指导、真实案例研究和可衡量的 ROI 框架，帮助场馆运营商夺回带宽并在大规模场景下提供高性能连接。
为什么我们的宾客 WiFi 如此缓慢？诊断网络拥塞
本指南诊断了宾客 WiFi 拥塞的隐性诱因 - 后台遥测、程序化广告网络和自动操作系统更新 - 在宾客打开浏览器之前，这些因素共同消耗了多达 40% 的公共 WiFi 带宽。它提供了一个分阶段、不依赖特定厂商的 DNS 过滤和 QoS 策略实施框架，以回收这部分带宽，改善宾客体验并实现可衡量的投资回报。本指南面向酒店、零售、活动和公共部门环境中的 IT 总监和运营经理。
对您的具体配置有疑问吗？
我们的团队与 80,000 多个场所的运营方、IT 经理和网络工程师保持合作。预约 20 分钟的通话，我们将为您展示同行是如何解决类似问题的。