公共 WiFi 故障排除：解决“已连接但无互联网”及展示页面重定向失败问题
本权威技术参考指南详细阐述了 Captive Portal 检测的底层机制，并剖析了导致访客 WiFi 无法连接的六种主要失效模式。它为 IT 经理和网络架构师提供了一个实用的故障排除框架，用于解决 HTTP 重定向问题、DNS 冲突以及 MAC 地址随机化带来的挑战。
Video overview
收听本指南
查看播客转录
核心系列的一部分：Captive Portal 指南 →
Public WiFi & Captive Portal Redirection Diagnostic Tool
Diagnose the root cause of splash page redirection failures, probe timeouts, and 'Connected, No Internet' errors across client operating systems and enterprise wireless controllers.
Root Cause Mechanism
The wireless controller or gateway is failing to intercept cleartext HTTP port 80 requests, or DNS queries for probe domains are being dropped by upstream firewalls before authentication.
http://captive.apple.com/hotspot-detect.htmlRecommended Remediation Actions
- Verify that UDP port 53 (DNS) is completely open in pre-authentication firewall policies to allow probe domain resolution.
- Ensure the AP or gateway intercepts cleartext HTTP requests (TCP 80) and issues an immediate HTTP 302 Found redirect to the portal URL.
- Do not intercept HTTPS port 443 before authentication, as HSTS and TLS SNI mismatches will trigger security warnings.
- Instruct users to test manual fallback URLs such as http://neverssl.com or http://captive.apple.com to trigger redirection.
Configuration Location: Wireless > Configure > Access control > Splash page
# Meraki Dashboard Configuration
1. Set Association Requirements to "Open (no encryption)"
2. Set Splash page to "Sign-on splash page / External captive portal"
3. In "Walled garden", add: *.purple.ai, *.purpleserver.net
4. Enable "RADIUS CoA (RFC 5176)" on port 3799*.purple.ai*.purpleserver.netEliminate Public WiFi Redirection Failures Across Your Estate
Purple's hardware-agnostic cloud guest WiFi platform eliminates captive portal drops, delivers sub-second splash page loading, and manages pre-auth walled gardens across Cisco Meraki, Aruba, Ruckus, and UniFi.
执行摘要
访客连接了您的 WiFi，但登录页面却无法加载。他们看到了“已连接，无互联网”的警告并选择放弃。对于场所运营总监和 IT 经理而言，这种失败直接降低了访客体验、增加了技术支持工单，并错失了收集第一方数据的机会，而这些数据正是对无线基础设施进行投资的合理依据。
本指南将详细解释 Captive Portal 检测在操作系统底层的实际工作原理，并指出导致大多数连接失败的六大根本原因。它提供了一个实用的、与厂商无关的排障框架，用于解决 DHCP 耗尽、DNS 拦截失败、围墙花园（Walled Gardens）不完整、被阻止的 HSTS 重定向、活跃的 VPN 冲突以及 MAC 地址随机化问题。
技术深挖：Captive Portal 检测的实际工作原理
要对 Captive Portal 进行排障，您必须首先了解 Captive Portal 在网络层面的实际作用。它不仅是一个登录页面，而是一个网络层的流量拦截机制。
当访客设备加入访客 SSID 时，它会通过 DHCP 接收一个 IP 地址。操作系统不会等待用户打开浏览器。相反，后台系统服务会立即向厂商控制的探测 URL 发送一个未加密的 HTTP GET 请求。Apple 设备会查询 captive.apple.com。Android 设备会查询 connectivitycheck.gstatic.com。Windows 设备会查询 msftconnecttest.com。Firefox 会查询 detectportal.firefox.com。
如果网络具有开放的互联网访问权限，这些探测会返回其预期的 HTTP 200 OK 响应，操作系统据此判定连接已激活。然而，在访客网络上，无线网关或控制器会在该 HTTP 探测到达互联网之前将其拦截。网关不会返回预期的响应，而是返回一个指向 Captive Portal 认证页面的 HTTP 307 Temporary Redirect（临时重定向）。操作系统检测到这种非预期的重定向，从而得知其处于 Captive Portal 限制之后，并打开一个沙盒浏览器窗口（Captive Network Assistant）来显示登录页面。
排障与风险规避：六大失败根本原因
当 Captive Portal 无法加载时，问题几乎总是由六种特定失败模式中的某一种引起的。
1. DHCP 地址池耗尽
这是高密度活动中的无形杀手。如果您正在举办一场有 2,000 人参加的会议，并使用标准的 /24 子网，那么您只有 254 个可用的 IP 地址。如果您的 DHCP 租约时间设置为默认的 24 小时，您的地址池将在开门后的几分钟内耗尽。在此之后的每次连接尝试都将在 Captive Portal 流程开始之前宣告失败。
解决方案： 对于人员流动率高的环境，将访客 DHCP 租约时间设置为 15 到 30 分钟之间。根据最高并发用户数（而不仅仅是平均出席人数）来规划子网大小。一个 /22 子网可提供 1,022 个可用地址，这是企业级场所推荐的最小规模。
2. DNS 拦截失败
Captive Portal 重定向依赖于网关拦截 HTTP 探测。然而，该探测首先需要进行 DNS 查询。如果您的 DNS 配置不允许未通过身份验证的客户端解析外部域名，则探测将永远无法触发。
解决方案： 确保您的防火墙策略明确允许来自未认证客户端的 DNS 查询（端口 53）。在测试设备上进行抓包分析，以验证您的 DNS 拦截是否正常工作。
3. 围墙花园（Walled Garden）配置不完整
围墙花园（认证前访问控制列表）定义了未认证的访客可以访问哪些外部域名。如果您的 Portal 登录页面从一个未包含在围墙花园中的 CDN 加载资源，该页面将呈现为空白屏幕。如果您通过 Google、Apple 或 Microsoft Entra ID 提供社交媒体登录，则这些提供商使用的每一个 OAuth 域名都必须列入白名单。社交身份提供商会定期更新其 CDN IP 范围和认证域名；半年前运行良好的围墙花园可能会在一夜之间失效。
解决方案： 安排每季度进行一次围墙花园审计。在您的硬件支持的情况下，使用通配符域名探听（Cisco Meraki、HPE Aruba、Ruckus 和 Juniper Mist 原生支持此功能）。作为我们云管理服务的一部分，Purple 会自动维护和更新这些围墙花园条目。
4. HSTS 重定向阻断
HTTP 严格传输安全（HSTS）是一种浏览器安全策略，它强制仅通过 HTTPS 连接到特定域名。如果访客设备尝试与预载了 HSTS 的域名进行通信，而您的网关试图拦截该 HTTPS 请求以重定向到 Portal 页面，浏览器将检测到证书不匹配。这将显示一条无法规避的安全警告，并完全阻断重定向。
解决方案： 切勿尝试对初始重定向进行 HTTPS 拦截。确保您的网关仅重定向未加密的 HTTP 探测。长期基于标准的解决方案是 RFC 8910，它定义了 DHCP Option 114。此选项允许您的 DHCP 服务器直接向客户端设备播发 Captive Portal URL，完全绕过了对 HTTP 重定向的需求。iOS 14 和 Android 11 及以上版本已原生支持此功能。
5. 客户端设备上激活了 VPN
VPN 会加密来自设备的所有流量，并在其到达您的网关之前将其路由通过外部隧道。您的网关永远无法检测到 HTTP 探测，因此绝不会触发 Captive Portal 检测顺序。访客既看不到登录页面，也无法访问互联网。
解决方案： 访客必须禁用 VPN，连接到门户，然后重新启用 VPN。对于前台工作人员来说，询问访客是否正在使用 VPN 应作为首要排障步骤。
6. MAC 地址随机化导致会话保持中断
现代 iOS 和 Android 设备默认使用随机 MAC 地址作为隐私保护功能。设备每次连接到网络时，可能会呈现不同的 MAC 地址。由于 Captive Portal 会话状态是根据 MAC 地址进行跟踪的，因此一小时前已通过身份验证的访客在设备 MAC 地址更改后可能会再次看到登录页面。
解决方案： 针对访客的解决方案是在其网络设置中针对您特定的 SSID 禁用“私有地址”。运营商侧的解决方案是实施基于配置文件的身份验证，例如通过 802.1X 部署 Passpoint 和 OpenRoaming，它在第 2 层使用凭据而非 MAC 地址进行身份验证，从而使随机化失效。
实施指南：构建高弹性架构
部署配置良好的 Captive Portal 需要主动做出架构决策。
- 在每次重大活动之前验证您的围墙花园（Walled Garden）。 最低要求的条目包括：您门户的 FQDN 和所有关联的 CDN 域名、Apple、Google、Windows 和 Firefox 的 Captive Portal 检测 URL，以及您支持的每个社交登录提供商的 OAuth 域名。
- 使用公共信任的 TLS 证书。 自签名证书会在每台设备上触发浏览器警告。请在证书过期前进行更新；证书过期是导致突然发生、覆盖全场馆的门户故障最常见的原因之一。
- 从全新的、未经身份验证的状态进行测试。 从之前已通过身份验证的设备测试门户将完全绕过门户，因为会话仍处于活跃状态。请始终从新设备，或从已忽略该网络并删除了 WiFi 配置文件的设备上进行测试。
- 调整空闲超时限制。 许多控制器默认采用 5 分钟的空闲超时，这对于在交互间隔进入睡眠模式的移动设备来说过于激进。在酒店和零售环境中，建议将空闲超时至少设置为 30 分钟。
投资回报率（ROI）与业务影响
Captive Portal 是一项成熟的技术，但它们也存在一些固有的复杂性。战略目标是迈向无缝且安全的身份验证。
基于 Passpoint 和 802.1X 构建的 OpenRoaming，可以帮助再次光临的访客自动、安全地连接 WiFi，而无需看到任何登录页面。在我们的 Connect 计划中，Purple 充当 OpenRoaming 的免费身份提供商。Premier Inn 和 Manchester Airports Group 等场所已经在使用它来为重复访客消除重新身份验证的麻烦，同时保持完全符合 GDPR 并进行第一方数据收集。通过减少连接失败，您可以直接增加收集的第一方数据量，从而提升客户忠诚度和个性化互动。
技术简报播客
在我们的 10 分钟技术简报中，听听我们的高级解决方案架构师对这些故障排除步骤的详细分析。
关键定义
Captive Portal
一种网络级流量拦截机制，它会限制互联网访问，直到用户在展示页面上完成所需操作（例如接受条款或提供凭据）。
企业场所保障访客访问安全并获取第一方数据的首要方法。
Walled Garden
一个认证前访问控制列表，用于定义未经验证的访客设备允许访问哪些外部 IP 地址或域名。
对于在用户完全通过身份验证之前允许其访问门户资产、CDN 和 OAuth 身份提供商至关重要。
Captive Network Assistant (CNA)
一个在检测到 Captive Portal 重定向时由操作系统自动打开的沙箱化、功能受限的浏览器窗口。
这是访客实际查看登录页面并与其进行交互的界面。
HSTS (HTTP Strict Transport Security)
一种 Web 安全策略机制，通过强制浏览器仅通过安全的 HTTPS 连接与网站进行交互，帮助保护网站免受中间人攻击。
HSTS 会阻止网关使用 HTTPS 拦截将用户重定向到 Captive Portal，如果配置不当，会导致连接失败。
DHCP Pool Exhaustion
DHCP 服务器已在其配置的子网中分配了所有可用 IP 地址的状态，从而导致新设备无法加入网络。
在体育场馆或会议等高密度环境中，导致“已连接但无互联网”错误的常见原因。
MAC Address Randomisation
现代移动操作系统中的一项隐私功能，可为每个 WiFi 网络生成随机 MAC 地址，从而防止跨不同位置进行追踪。
此功能会破坏 Captive Portal 上的会话持久性，如果访客的 MAC 地址发生轮换，则会迫使其重新进行身份验证。
OpenRoaming
一个 WiFi 网络联盟，允许用户自动、安全地连接到加入该联盟的网络，而无需输入凭据或与 Captive Portal 进行交互。
针对重复访客的 Captive Portal 的战略性替代方案，由 Purple 作为免费身份提供商提供支持。
RFC 8910 (DHCP Option 114)
一种允许 DHCP 服务器在分配 IP 地址期间，直接向客户端设备提供 Captive Portal URL 的标准。
这完全绕过了对 HTTP 重定向的需求，解决了由 HSTS 引起的问题，并提高了门户检测的速度。
应用实例
伦敦市中心一家拥有 350 间客房的酒店为访客 WiFi 运行单一的 /24 子网。在一次大型会议期间，400 名代表同时到达。20 分钟内，访客纷纷报告已连接但无法访问门户网站或互联网。
即时解决方案是将子网扩展到 /22，提供 1,022 个可用地址，并将 DHCP 租约时间从 24 小时缩短至 8 小时。长期解决方案是部署 Purple 的云管理 Captive Portal，该系统能够实时监控 DHCP 地址池利用率，并在地址耗尽前向网络团队发送警报。
一家拥有 200 家门店的大型连锁零售店在其访客门户上使用 Google 和 Facebook 社交登录。在 Google 更新其 OAuth 基础架构后，访客可以访问门户页面，但社交登录按钮显示空白屏幕。
IT 团队必须识别 Google 使用的新认证域名，并将其添加到 Walled Garden（认证前访问控制列表）中。为了在未来防止此类问题，他们应该使用通配符域名条目（例如 *.google.com），而不是硬编码特定的 IP 地址，并每季度审查一次 Walled Garden。
练习题
Q1. 一个体育场的 IT 主管报告说，在半场休息期间，数千名球迷尝试连接到访客 WiFi。部分用户成功加载了门户，但许多人报告说他们的设备卡在“正在获取 IP 地址”或在门户出现之前显示“已连接，无互联网连接”。最可能的架构缺陷是什么？
提示：考虑并发连接的数量与网络段上的可用资源。
查看标准答案
网络正在经历 DHCP 池耗尽。子网的规模可能设置得太小（例如 /24），无法应对巅峰期的并发用户负载，且 DHCP 租期可能设置得太长。推荐的解决方法是增加子网规模（例如增加到 /22 或 /21），并将 DHCP 租期缩短以匹配预期的逗留时间（例如，体育场设置为 3 小时）。
Q2. 一位访客连接到您的零售 WiFi 网络。在尝试加载一个热门网站时，其设备显示安全警告“您的连接不是私密连接”，并且 Captive Portal 从未出现。是什么机制导致了这一阻断？
提示：想想现代浏览器在安全连接上如何处理强制重定向。
查看标准答案
HSTS (HTTP Strict Transport Security) 阻断了重定向。访客尝试访问一个预加载了 HSTS 的域名（通过 HTTPS），而无线网关尝试拦截该安全连接以重定向到门户。浏览器检测到证书不匹配并阻断了连接。网关必须配置为仅拦截未加密的 HTTP 探测。
Q3. 您最近在 Captive Portal 上启用了 Google 和 Microsoft Entra ID 社交登录选项。访客反馈说门户页面可以加载，但点击登录按钮会导致超时。而在 IT 部门不受限制的员工网络上测试时，该门户工作完全正常。缺失了什么配置？
提示：考虑认证完成前访客网络的设备网络状态。
查看标准答案
Walled Garden（认证前访问控制列表）不完整。Google 和 Microsoft Entra ID 所使用的 OAuth 认证域名和 CDN 尚未被加入白名单。因为访客尚未通过认证，网关阻断了对这些外部域名的访问，导致社交登录过程超时。IT 团队必须将这些身份提供商的通配符条目添加到 Walled Garden 中。
常见问题
Why does public WiFi fail to redirect to the splash login page?
Public WiFi fails to redirect when the wireless controller or gateway cannot intercept cleartext HTTP requests (TCP port 80), when upstream firewalls drop DNS queries for captive portal probe URLs (such as captive.apple.com or connectivitycheck.gstatic.com), or when modern client browsers enforce HSTS on HTTPS requests before authentication. Allowing pre-authentication DNS and redirecting HTTP traffic resolves the issue.
How do client operating systems detect public WiFi captive portals?
Upon connecting to an open or public WiFi network, iOS fires HTTP requests via Captive Network Assistant (CNA) to captive.apple.com/hotspot-detect.html, Android queries connectivitycheck.gstatic.com/generate_204 via CaptivePortalLogin, and Windows probes msftconnecttest.com/connecttest.txt via NCSI. If the network returns an HTTP 302 redirect, the operating system launches the captive portal webview. If the probe domain fails to resolve or times out, the device marks the connection as having no internet.
Why do users see SSL certificate or HSTS warnings on public WiFi?
When an access point or gateway intercepts encrypted HTTPS requests (port 443) and presents its own self-signed or vendor certificate to force a splash page on public WiFi, modern web browsers detect a domain mismatch and block the connection with an HSTS or untrusted certificate error. Public WiFi networks should only intercept cleartext HTTP port 80 requests or implement RFC 8910 DHCP Option 114 to cleanly announce the portal URL.
What causes public WiFi captive portals to loop back to the login page?
Infinite login loops occur when the wireless access point or controller fails to receive or process the RADIUS Access-Accept packet or RFC 5176 Change of Authorization (CoA) disconnect/re-authenticate message on UDP port 3799. As a result, the controller maintains the client device in the pre-authentication walled garden role despite successful submission of guest credentials on the public WiFi network.
How does Purple eliminate public WiFi splash page redirection failures?
Purple operates as a cloud-delivered, 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.
继续阅读本系列
Ruckus Captive Portal 故障排除：WISPr 重定向、热点和 Walled Garden 检查清单
您将能够根据访客报告的症状诊断故障的 Ruckus Captive Portal，并按照设定的顺序进行修复。该顺序涵盖了热点 (WISPr) 登录 URL、Walled Garden、北向门户接口密码、RADIUS 认证与计费，以及 HTTPS 重定向证书。这些检查适用于 SmartZone、Ruckus One 和 Unleashed。
Ubiquiti UniFi captive portal故障排除：外部门户、热点与walled garden检查清单
使用此检查清单找出您的Ubiquiti UniFi captive portal无法正常工作的原因并进行修复。您将根据六种原因之一匹配症状，运行两项快速测试，并纠正外部门户服务器、预授权访问、访客子网限制、HTTPS重定向、控制器可达性或客户端设置。
HPE Aruba Captive Portal 故障排查：重定向、证书与 Walled Garden 清单
使用此清单，根据您看到的症状诊断故障的 HPE Aruba Captive Portal：无重定向、证书警告或访客永远无法上网。然后，您可以将故障定位到 DNS、DHCP、Walled Garden、重定向 URL、证书或 RADIUS。最后，在 Instant AP、Aruba Central 或移动控制器上应用修复方案。
对您的具体配置有疑问吗？
我们的团队与 80,000 多个场所的运营方、IT 经理和网络工程师保持合作。预约 20 分钟的通话，我们将为您展示同行是如何解决类似问题的。