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

Executive Summary

For CTOs and network architects overseeing high-density venues—such as those in Retail , Hospitality , Healthcare , and Transport —the "Connected, No Internet" error on Guest WiFi networks is a persistent operational headache. While often misdiagnosed as an AP hardware fault or insufficient upstream bandwidth, the root cause in enterprise environments is typically DNS timeout caused by network congestion.

When hundreds of devices concurrently probe for captive portal detection (e.g., captive.apple.com), the default UDP port 53 queries can overwhelm standard upstream resolvers. If the DNS response exceeds the OS-level timeout window (typically 1-5 seconds), the device assumes no internet connectivity exists, failing to trigger the captive portal. This guide details the technical architecture of this failure mode and demonstrates how deploying an enterprise DNS filter resolves the bottleneck, reducing query latency from thousands of milliseconds to sub-200ms, ensuring compliance with standards like IEEE 802.1X and GDPR, and dramatically improving the guest onboarding experience.

Technical Deep-Dive

The Captive Portal Detection Mechanism

When a client device associates with an access point and receives a DHCP lease, it must verify internet reachability before fully transitioning to a connected state. This is achieved via captive portal detection probes:

• iOS/macOS: HTTP GET to captive.apple.com
• Android: HTTP GET to connectivitycheck.gstatic.com
• Windows: HTTP GET to msftconnecttest.com

Before the HTTP GET can be issued, the device must resolve the hostname via DNS. This initial DNS query is the critical failure point in high-density environments.

Why Congestion Triggers DNS Timeouts

DNS queries typically use UDP, a connectionless protocol without transport-layer retransmission. In a congested network—such as a stadium during half-time or a hotel during morning peak hours—UDP packets are easily dropped or delayed.

If the venue relies on a standard ISP resolver or a public DNS service (like 8.8.8.8), the round-trip time (RTT) plus the processing time at the resolver can exceed the OS's hardcoded timeout limit. When the timeout expires, the device flags the connection as "Connected, No Internet" and halts the captive portal redirection process.

Furthermore, short Time-To-Live (TTL) values on these probe domains exacerbate the issue. As devices constantly associate and disassociate, cached entries expire rapidly, triggering a flood of simultaneous DNS queries precisely when the network is under maximum load.

The Role of the Enterprise DNS Filter

An enterprise DNS filter, such as the one integrated into Purple's WiFi Analytics platform, acts as a high-performance, local or edge-proximate resolver. By intercepting DNS queries before they traverse the congested WAN link, the filter:

1. Caches High-Frequency Domains: Serves probe domains locally, reducing RTT to sub-millisecond levels.
2. Policy Enforcement: Drops queries for malicious or blocked domains immediately, conserving WAN bandwidth.
3. Audit Logging: Provides an audit trail for IT Security , aiding in GDPR compliance and incident response.

Implementation Guide

Deploying an enterprise DNS filter requires careful architectural planning to avoid introducing new points of failure.

1. Resolver Placement and Latency Optimization

Deploy the DNS filter as close to the network edge as possible. For distributed retail chains, a cloud-delivered edge node is appropriate; for large single-site venues like stadiums, a localized appliance or virtual machine on the core switch is preferred. The goal is to minimize the number of routing hops between the guest VLAN and the resolver.

2. Captive Portal Whitelisting (Passthrough)

The most critical configuration step is ensuring your captive portal domain is explicitly whitelisted. If the DNS filter delays or blocks the resolution of the authentication portal itself, you will induce the exact error you are attempting to solve.

3. TTL Tuning and Cache Management

Configure the local resolver to aggressively cache captive portal probe domains. While respecting upstream TTLs is standard practice, overriding TTLs for captive.apple.com and similar domains to a minimum of 60 seconds locally can drastically reduce upstream query volume during peak association events.

4. Integration with Existing Infrastructure

Ensure the DNS filter deployment aligns with your existing network segmentation. Guest DNS traffic must remain isolated from corporate DNS infrastructure to maintain PCI DSS compliance. This isolation is crucial whether you are optimising hotel WiFi for business travelers or securing a public sector deployment.

Listen to our technical briefing podcast for more context on these implementation steps:

Best Practices

• Avoid Public Resolvers for Guest Networks: Relying on 8.8.8.8 or 1.1.1.1 as the primary DHCP-assigned DNS for high-density guest networks introduces unacceptable latency variability.
• Implement DNS over HTTPS (DoH) Carefully: While DoH improves privacy, it bypasses traditional port 53 filtering. Ensure your enterprise DNS solution can inspect or manage DoH traffic if required by venue policy.
• Monitor UDP Port 53 Drops: Configure your firewall or core switch to alert on excessive UDP port 53 packet drops, which is a leading indicator of impending DNS timeouts.
• Regularly Review Blocklists: Over-aggressive filtering can break legitimate applications. Review DNS query logs weekly to identify false positives.

For public sector deployments, ensuring robust connectivity is part of broader digital inclusion initiatives, as recently highlighted when Purple Appoints Iain Fox as VP Growth – Public Sector .

Troubleshooting & Risk Mitigation

When the "Connected, No Internet" error occurs, IT teams should follow a structured diagnostic path rather than immediately assuming bandwidth exhaustion.

1. Packet Capture (PCAP): Run a packet capture on the guest VLAN filtering for udp port 53. Look for queries without corresponding responses within a 2-second window.
2. Simulate the Probe: Use curl or wget from a test device on the guest VLAN to manually hit http://captive.apple.com/hotspot-detect.html. Measure the DNS resolution time versus the HTTP response time.
3. Check Firewall Rules: Verify that no rate-limiting or QoS policies are inadvertently throttling UDP port 53 traffic from the guest subnet.
4. Verify Offline Capabilities: In environments with intermittent WAN connectivity, consider features like Purple's Offline Maps Mode to maintain some level of user engagement even when upstream internet is degraded.

ROI & Business Impact

Resolving DNS timeouts directly impacts the bottom line for venue operators.

• Reduced Support Overhead: The "Connected, No Internet" error is a primary driver of Level 1 support tickets in hospitality and retail. Eliminating it reduces IT operational expenditure.
• Increased Data Capture: A failed captive portal load means a lost opportunity for data capture and user authentication. By ensuring rapid portal rendering, venues maximize the ROI of their WiFi Analytics platforms.
• Enhanced Guest Satisfaction: Seamless connectivity is a baseline expectation. Minimizing onboarding friction directly correlates with improved Net Promoter Scores (NPS) and positive venue reviews.

By shifting the perspective from "we need more bandwidth" to "we need optimized DNS resolution," network architects can deliver enterprise-grade guest WiFi that scales gracefully under pressure.