跳至主要内容

为什么您的 iPhone 无法加载 Captive Portal:修复 Apple CNA 错误

排查并修复 iPhone 和 iOS 上 Captive Portal 弹出失败的问题。了解 Apple CNA、iCloud Private Relay 和 MAC 随机化如何破坏 WiFi 登录以及如何修复它们。

作者:Tom Hackett发布于 更新于
📖 10 分钟阅读536 字2 应用实例3 练习题6 关键定义

Video overview

收听本指南

查看播客转录
[片头音乐:欢快、现代的电子合成器流行乐,伴有清脆的钢琴声,奠定专业、科技前沿的基调] **主持人(资深顾问)**:您好,欢迎收听 Purple 技术简报。我是您的主持人。今天我们将深入探讨当今网络管理员、IT 经理和场所运营总监面临的最常见 - 坦率地说,也是最令人沮丧 - 的问题之一。 我们都经历过这种情况。您花了数周时间为您的酒店、购物中心或体育场规划、配置和部署了先进的访客 WiFi 网络。您拥有最新的接入点、强大的控制器以及准备好捕获访客数据并提高参与度的精美 splash 页面。但是随后,服务台的工单开始涌入。它们说的都是完全相同的一句话:"我已经在 iPhone 上连接了访客 WiFi,但登录页面无法加载。" 对于访客来说,您的 WiFi 只是坏了。但对于我们作为网络工程师和架构师来说,我们知道在 iOS 的底层正在进行一场复杂的技术博弈。今天,我们将详细剖析为什么您的 Captive Portal 无法在 iPhone 上加载、Apple 的后台检测逻辑是如何工作的,以及您可以在本季度在网络上实施的逐步缓解方案。 [短暂的过渡音乐起伏] **主持人**:让我们从技术深挖开始。为什么 iPhone 连接到访客 WiFi 却无法显示登录页面? 要理解这一点,我们必须了解 Apple 的 **Captive Network Assistant**(简称 **CNA**)。当 iPhone 关联到开放的 SSID 并通过 DHCP 获取 IP 地址时,它不会只等待用户打开浏览器。相反,后台系统守护进程会立即向一个非常特定的 URL 发起纯 HTTP GET 请求:`http://captive.apple.com/hotspot-detect.html`。 该后台探测使用名为 `CaptiveNetworkSupport` 的特定系统 User-Agent。CNA 守护进程正在寻找一个非常特定的响应。如果 Apple 的服务器返回 HTTP 状态码 **200 OK**,且主体内容完全是 "Success",则 iOS 会判定该网络具有无限制的互联网访问权限。它会静默地将 WiFi 确立为主路由接口,用户即可正常使用。 然而,如果您的网络网关拦截了该 HTTP 请求并返回了其他任何内容 - 例如 HTTP 302 或 307 重定向,或者自定义的 HTML 页面 - iOS 会立即识别出它处于 Captive Portal 之后。它会立即启动原生 **Websheet 应用**。这就是大家所熟悉的、显示您访客登录页面的滑出式模态窗口。 现在,出现了第一个主要的技术陷阱:**围墙花园(Walled Garden)**。 许多网络工程师在预认证访问控制列表(ACL)中犯了将 Apple 的成功验证域名(如 `captive.apple.com`)列入白名单的错误。他们认为:“嗯,这是 Apple 的域名,我应该放行它。”但如果你将其列入白名单,后台探测就会成功到达 Apple 的服务器并收到“Success”响应,iOS 就会认为不存在 Captive Portal。这样 Websheet 永远不会触发!与此同时,用户却被阻止访问任何其他网站。因此,规则第一条:**千万不要在你的围墙花园(Walled Garden)中将 captive.apple.com 列入白名单。** [简短的过渡音效] **主持人**:但是现代 iOS 的隐私功能呢?即使有完美的围墙花园,像 **iCloud Private Relay** 和**私有 MAC 地址**这样的功能也在改变游戏规则。 让我们来谈谈 iOS 15 中引入的 iCloud Private Relay。该功能通过双跳代理架构对 Safari 的 DNS 和 HTTP 流量进行加密和路由。当启用 Private Relay 的用户连接到你的访客 WiFi 时,后台 HTTP 探测会被封装在加密隧道内。由于你的网络网关无法检查或拦截此加密数据包,因此它无法注入重定向。探测会静默失败,而 iPhone 只会显示“无互联网连接”警告。没有门户,没有登录,只有糟糕的用户体验。 幸运的是,针对这一问题有一种程序化的网络级缓解措施。Apple 将 Private Relay 设计为尊重网络级阻断。如果你的本地 DNS 服务器对 Apple 的 Private Relay 域名(特别是 `mask.icloud.com` 和 `mask-h2.icloud.com`)返回 **NXDOMAIN** 响应,iOS 就会识别出该网络与 Private Relay 不兼容。它会立即显示系统提示,询问用户是否要针对此网络“在不使用 Private Relay 的情况下使用”。用户点击该选项的瞬间,加密隧道就会被旁路,HTTP 探测被拦截,你的 Captive Portal 就能完美加载。 接下来是**私有 MAC 地址**以及 iOS 18 中新增的**轮换 MAC 地址**。默认情况下,iPhone 会针对每个 SSID 随机化其 MAC 地址。在 iOS 18 中,即使连接到同一个网络,该地址也会定期轮换。如果你的无线控制器仅通过 MAC 地址来跟踪已认证的访客会话,那么突然的轮换会导致网关将该 iPhone 视为一个全新的、未认证的设备。访客会被突然断开连接,并被迫重新登录。 为了缓解这一问题,企业级场所必须告别简单的基于 MAC 的跟踪。像 **Purple** 这样的平台通过在浏览器会话中植入安全的持久性 Cookie 来解决此问题,或者更完美地,通过将场所过渡到 **Passpoint**(也称为 Hotspot 2.0)。Passpoint 使用安全的 802.1X 配置文件自动且安全地对再次到访的访客进行身份验证,而无需显示任何 Captive Portal 页面。它既安全又无缝,完全绕过了 CNA 的局限性。 [简短的过渡音乐起伏] **主持人**:现在,让我们讨论一下自定义 DNS 配置文件和本地 VPN。 许多技术用户会安装 NextDNS 或 AdGuard 等自定义 DNS 配置文件,以强制执行加密的 DNS-over-HTTPS。由于这些配置文件会绕过您本地由 DHCP 分配的 DNS 服务器,您的网关将无法对 `captive.apple.com` 进行 DNS 解析欺骗。同样,“始终启用”的 VPN 配置文件会在分配到 IP 的瞬间尝试建立加密隧道。如果 VPN 连接成功,它会绕过您的重定向;如果它被阻止,则会导致连接陷入死锁状态。 对于这些用户,最强大的手动备用方案是 **neverssl.com** 技巧。如果访客连接到了您的 WiFi 但 Portal 页面无法加载,请让他们打开 Safari 并在地址栏中输入 `neverssl.com`。由于该域名严格采用未加密的 HTTP 协议,网关一定会拦截其 80 端口的流量并强制加载重定向,从而绕过任何自定义 DNS 或 VPN 的干扰。 [音效:快速过渡风铃声] **主持人**:让我们对场所支持团队最常遇到的问题进行一次快速问答。 *问题一:为什么我的 iPhone 在 WiFi 名称下方用橙色显示“无互联网连接”?* **回答**:这意味着 iPhone 已完成 WiFi 关联并获取了 IP 地址,但后台的 CNA 探测未能收到 Apple 成功服务器的响应,且未能成功重定向,这通常是由于 iCloud 专用代理或处于启用状态的 VPN 引起的。 *问题二:我们能否在网络中完全禁用 CNA 微型浏览器?* **回答**:可以,大多数企业级无线局域网控制器(WLC)都有一项名为“CNA Bypass”或“Captive Portal Bypass”的设置。启用后,控制器会伪造 Apple 成功探测,告诉 iPhone 其已完全连接互联网。这可以阻止 Websheet 弹出,但它依赖于用户手动打开 Safari 来触发重定向,有时这反而会给用户带来更多困惑。 *问题三:什么是认证后探测问题?* **回答**:访客登录后,CNA Websheet 会运行二次探测以验证互联网接入。如果您的网关将他们重定向到了落地页,但继续阻止 Apple 的成功域名,则右上角的按钮会一直停留在“取消”状态。点击“取消”会导致他们断开 WiFi 连接。您必须确保在认证后可以完全访问 Apple 的成功域名。 [简短的过渡音乐起伏] **主持人**:最后,让我们来看看对现实业务的影响。 优化您的 Captive Portal 不仅仅是为了技术上的完美,更是为了实实在在的收益。我们最近与一家五星级奢华度假村集团合作,他们曾面临 35% 的访客 WiFi 连接失败率,导致每周收到超过 450 起前台投诉。通过重构其 Walled Garden 围墙花园、在 DNS 层级拦截 Private Relay 域名以强制进行本地路由,并部署 **Purple's Guest WiFi** 解决方案,他们在短短 30 天内使前台 WiFi 投诉工单减少了 **92%**。他们的宾客满意度飙升,并收集到了数千个经验证的访客画像。 如果您希望确保您的访客 WiFi 网络与 Apple 的 Captive Network Assistant 完美互动,同时最大化数据收集并最小化支持成本,请访问 **purple.ai**。我们的平台经过专门设计,开箱即可处理所有这些针对 iOS 的细微差异。 感谢您收听本次 Purple 技术简报。本周就去部署这些 Walled Garden 和 DNS 策略,静候您的支持工单彻底消失。我们下期再见,祝您的连接安全无忧,访客接入顺畅无阻。 [片尾音乐:轻快的电子合成器流行乐逐渐淡出]

核心系列的一部分:Captive Portal 指南 →

Interactive Network Tool

Apple iOS captive portal and CNA diagnostic advisor

Diagnose captive portal popup failures, white screens, SSL warnings, and iCloud Private Relay issues across iOS 14 to iOS 18 with controller-specific remediation scripts.

Critical

Apple CNA Probe Request Intercepted or Dropped Before HTTP 302

The Apple Captive Network Assistant (CNA) daemon failed to detect network captivity because probe HTTP GET requests to captive.apple.com/hotspot-detect.html were silently dropped or returned an unhandled status.

Detailed Protocol Breakdown (IOS_18)

Upon associating with an unauthenticated SSID, iOS issues an HTTP GET request to http://captive.apple.com/hotspot-detect.html expecting the string "<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>". If the network drops TCP port 80 or hijacks DNS without returning an immediate HTTP 302 redirect, iOS assumes internet connectivity is offline and suppresses the slide-over CNA sheet.

Pre-auth walled garden allowlist (never the Apple probe hosts):

*.purple.ai*.purplewifi.netfonts.googleapis.comfonts.gstatic.com

Reduce captive portal login failures with Passpoint and Purple

Provide instant, seamless onboarding for iOS and Android guest WiFi without CNA popup errors or manual browser logins.

Useful? Link to this tool

执行摘要

iOS设备(iPhone和iPad)上的Captive Portal登录失败是酒店、零售、医疗保健和企业环境中客用WiFi连接投诉的主要原因之一。当iOS设备与开放式或基于Web认证的无线网络关联时,Apple的**Captive Network Assistant (CNA)**守护进程会发起一系列后台HTTP探测。如果这些探测被阻止、路由错误或未被正确拦截,Captive Portal引导页面将无法加载,导致用户无法访问互联网,也无法通过显而易见的方式进行登录。

本技术指南详细介绍了Apple CNA检测的底层原理,分析了关键的iOS隐私功能 - 包括iCloud Private Relay、私有WiFi地址(MAC地址随机化)以及加密DNS - 并为网络工程师和场所运营商提供了逐步的缓解策略。

在iOS上饱受客用WiFi连接流失的困扰?

Purple的云管理客用WiFi平台可自动处理Apple CNA探测、iCloud Private Relay和MAC地址随机化,在所有iOS和Android设备上提供无缝的Captive Portal接入体验。

探索 Purple 客用 WiFi →

技术深潜

Apple的检测逻辑与探测机制

当iPhone连接到无线接入点时,iOS网络堆栈会立即调度一个名为captivenetworkd的守护进程。该守护进程向预定义的Apple验证URL发送明文HTTP GET请求,其中包括:

  • http://captive.apple.com/hotspot-detect.html
  • http://www.apple.com/library/test/success.html
  • http://gsp1.apple.com/pep/gcc
+-------------------+       HTTP GET captive.apple.com       +----------------------+
|   iPhone (iOS)    | -------------------------------------> |  Network Controller  |
+-------------------+                                        +----------------------+
          |                                                             |
          | <--- HTTP 302 Redirect (https://portal.purple.ai) ---------+
          |
          v
[ Launch CNA Websheet ] ---> [ Render Purple Captive Portal ]

该守护进程会评估HTTP响应状态和正文:

  1. 成功响应(HTTP 200,包含 <HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>"):操作系统判定该网络提供无限制的互联网访问。不显示任何欢迎页面。
  2. 重定向响应 (HTTP 302 / 307):网络网关拦截 Port 80 HTTP 请求并将客户端重定向到 Captive Portal URL。iOS 识别出此重定向并启动 CNA Websheet(一种专门的模态浏览器窗口)。
  3. 连接超时或重置:如果网关丢弃 Port 80 数据包或未能回答 DNS 查询,则探测超时。iOS 会在设置中的 SSID 名称下方显示“无互联网连接”警告,但无法显示登录页面。

认证后探测(“完成”按钮挑战)

用户在欢迎页面上提交凭据或接受服务条款后,无线局域网控制器 (WLC) 会将客户端 ACL 状态更新为“已认证”。CNA 守护进程会立即向 captive.apple.com 发起后续 HTTP 探测。

如果第二次探测返回 HTTP 200 "Success",CNA Websheet 右上角的按钮将从“取消”变为“完成”。如果网络在认证后未能立即允许带外 HTTP 访问,该按钮将一直停留在“取消”,点击它可能会导致设备完全断开与 WiFi 网络的连接。


iOS 特有的干扰因素

1. iCloud 专用代理

iCloud 专用代理是在 iOS 15 中推出的一项 Apple 服务,旨在保护网页浏览隐私。启用后,Safari 和未加密的 HTTP 流量将被加密并通过两个独立的互联网代理进行路由:

[ iPhone ] === 加密的 QUIC/TLS ===> [ Apple 入口代理 ] ---> [ 出口代理 ] ---> [ 网络目标 ]
  • 问题所在:专用代理通过 Oblivious DNS-over-HTTPS (ODoH) 加密 DNS 请求,并通过 QUIC (UDP Port 443) 传输 HTTP 流量。由于本地网关路由器无法检查或拦截加密的 QUIC 流量,因此它们无法注入标准的 HTTP 302 重定向。
  • 影响:指向 captive.apple.com 的初始 HTTP 探测被通过隧道传输绕过本地网关,导致连接超时且无法显示欢迎页面。

2. 私有 MAC 地址和轮换标识符

从 iOS 14 开始并在 iOS 18 中得到扩展,Apple 默认启用私有 WiFi 地址。iOS 不使用设备的永久硬件 MAC 地址,而是为每个 SSID 生成一个随机的 MAC 地址。

  • 问题所在:在使用基于 MAC 的会话授权(其中已认证用户根据 MAC 地址被允许 24 小时的访问权限)的网络上,MAC 轮换会导致网络网关将返回的设备视为新的、未认证的客户端。
  • 影响:用户会反复看到 Captive Portal 欢迎页面,从而导致糟糕的用户体验并产生前台支持工单。

3. 加密 DNS 配置文件 (DoH / DoT)

拥有自定义 iOS 配置描述文件(如 NextDNS、Cloudflare 1.1.1.1 或企业 MDM DNS 设置)的用户会直接通过加密的 HTTPS (DoH) 或 TLS (DoT) 向外部解析器发送所有 DNS 查询。

  • 问题所在:本地网络 DNS 服务器无法拦截或欺骗针对 captive.apple.com 或不存在域名的 DNS 请求。
  • 产生影响:初始 DNS 解析会完全绕过本地控制器,从而导致无法触发 Captive Portal 重定向。

实施与缓解指南

围墙花园(认证前 ACL)设计

为确保在 iOS 上可靠地呈现 Captive Portal,网络工程师必须精准配置认证前围墙花园访问控制列表 (ACL):

规则类型 目的地 / 域名 目的
允许 *.purple.ai, *.purpleshield.com 允许未认证的客户端访问 Purple 门户基础设施和资产。
拦截 发往任何目的地的 HTTP (TCP 端口 80) 拦截明文 HTTP 网页流量以触发 302 重定向。
阻断 / NXDOMAIN mask.icloud.com, mask-h2.icloud.com 返回 NXDOMAIN 以表明本地网络上 iCloud 专用代理不可用。
切勿加入白名单 captive.apple.com, www.apple.com 绝不能加入白名单。加入白名单会导致探测成功,而无法启动门户。

WLC 配置分步步骤(以 Cisco Catalyst / Meraki 为例)

  1. 配置 DNS 拦截:设置 DHCP 服务器,将网关 IP 地址分配为未认证客户端的首选 DNS 服务器。
  2. 配置专用代理信令:在本地 DNS 服务器上添加 DNS 重写规则:
    mask.icloud.com      IN A 0.0.0.0 (或 NXDOMAIN)
    mask-h2.icloud.com   IN A 0.0.0.0 (or NXDOMAIN)
    
    当 iOS 收到针对这些主机的 NXDOMAIN 时,会弹出系统提示:“此网络阻止 iCloud 专用代理。您要在不使用专用代理的情况下使用此网络吗?” 轻点 在不使用专用代理的情况下使用 即可恢复标准的门户重定向。
  3. 配置会话超时:根据 IP/MAC 地址对设置网关会话超时,或清除持久性授权 Cookie。

对您的具体配置有疑问吗?

我们的团队与 80,000 多个场所的运营方、IT 经理和网络工程师保持合作。预约 20 分钟的通话,我们将为您展示同行是如何解决类似问题的。

最佳实践与行业标准

大规模管理访客无线接入需要遵守现代网络标准:

  • 过渡到 WPA3-Personal (OWE):传统的访客门户运行在开放、未加密的 SSID 上。企业级场馆应采用机会性无线加密 (OWE) (IEEE 802.11aq),以便在无需密码的情况下提供个性化加密。
  • 符合 PCI DSS 和 GDPR 规范:访客门户必须将访客流量与 PCI DSS 支付网络隔离。在收集联系信息时,门户必须提供明确且未勾选的 GDPR 同意复选框 - 这一切都可以通过 WiFi Analytics 平台轻松管理。
  • 部署 Passpoint (Hotspot 2.0):为了彻底消除 Captive Portal 的摩擦,场所可以部署 Passpoint (Hotspot 2.0)。Passpoint 使用蜂窝网络式的身份验证,通过预装的配置文件安全且自动地连接 iOS 设备,从而完全绕过 CNA 守护进程。

故障排除与风险缓解

终端用户自我修复路径

  1. 针对该网络禁用 iCloud 专用代理:打开 设置 > WiFi,点击网络名称旁边的 (i) 图标,然后关闭 限制 IP 地址跟踪。
  2. 禁用私有 WiFi 地址:在同一个网络设置菜单中,如果需要基于 MAC 的访问,请关闭 私有 WiFi 地址。
  3. 通过 Safari 强制门户重定向:打开 Safari 并输入普通的 HTTP 地址: http://neverssl.com 由于 neverssl.com 不使用 HTTPS,本地路由器将可靠地拦截该请求并加载门户。

网络工程师诊断路径

                  [ iPhone 连接到访客 SSID ]
                                  |
                                  v
                        [ 已分配 DHCP IP? ]
                        /                   \
                     (否)                   (是)
                      /                       \
        [ 检查 DHCP 地址池 ]             [ 是否解析 captive.apple.com? ]
                                        /                             \
                                     (否)                             (是)
                                      /                                 \
                         [ 检查 DNS ACL ]                   [ Apple 是否在白名单中? ]
                                                             /                       \
                                                          (是)                      (否)
                                                           /                           \
                                              [ 从围墙花园中移除 ]               [ 端口 80 是否重定向? ]
                                                                               /                   \
                                                                            (否)                   (是)
                                                                             /                       \
                                                                 [ 修复 WLC 重定向 ]     [ CNA 网页加载 ]

投资回报率(ROI)与业务影响

优化 iOS 访客 WiFi 的入网体验对场所运营和业务指标有着直接、可衡量的影响。

酒店业案例研究:五星级度假酒店集团

  • 面临挑战:一家拥有 12 家物业的奢华酒店集团的访客 WiFi 连接失败率高达 35%,导致每周产生 450 多起前台投诉。
  • 实施:IT团队重构了其围墙花园,禁用了基于MAC的会话跟踪,并部署了具有优化CNA处理功能的 Purple的Guest WiFi 解决方案。
  • 成效:在前台,与WiFi相关的投诉在30天内下降了 92%。客户满意度(CSAT)评分提高了 18分,且该场所在第一季度收集了40,000个新验证的电子邮件地址。

零售案例研究:全国性购物中心运营商

  • 挑战:一家拥有45家购物中心的零售运营商在提升访客参与度方面面临困难,因为iCloud专用代理(Private Relay)导致40%的 iOS 设备无法加载 Captive Portal。
  • 实施:实施了网络级的专用代理拦截(对Apple的代理域名返回NXDOMAIN以强制进行本地路由)并部署了 WiFi Analytics。
  • 成效:Portal完成率从 58% 飙升至 94%。营销团队通过本地化的零售媒体活动将收回的Portal广告位变现,每季度创造了额外的 $120,000 广告收入。

相关资源

对于部署企业级访客无线网络的网络团队,这些资源提供了更深层次的技术背景:

Purple的 Guest WiFi 平台为全球的 酒店餐饮、零售、医疗保健 以及 交通运输 场所提供服务,大规模提供针对CNA优化的访客登录体验。

关键定义

Apple Captive Network Assistant (CNA)

一个 iOS 和 macOS 操作系统守护进程,用于探测互联网连接并在检测到 Captive Portal 时自动启动受限的 WebKit 模态框 (WebSheet)。

控制在连接到访客 WiFi 时,iPhone 上是否自动出现登录欢迎页面。

金丝雀探测 URL

客户端操作系统请求的轻量级 HTTP 端点(例如 http://captive.apple.com/hotspot-detect.html),用于验证无限制的互联网可达性。

如果探测响应被修改或重定向,操作系统将触发其 Captive Portal 处理程序。

RFC 8908 Captive Portal API

一个 IETF 标准协议,提供一个 API 端点,设备可以通过该端点利用 JSON 查询网络受限状态、场馆条款和剩余会话时间。

用结构化、加密安全的受限网络检测取代传统的 HTTP 劫持。

DHCP Option 114 (Captive-Portal)

一个 DHCP 选项 (RFC 8910),在初始第 3 层地址分配期间将 RFC 8908 Captive Portal API 的 URI 传递给客户端设备。

在获取 IP 期间立即向 iOS 14+ 发出受限信号,从而绕过 DNS 篡改。

iCloud Private Relay

一项 Apple 隐私服务,通过双跳加密代理架构路由 Safari 流量和未加密的 DNS。

可以屏蔽预认证 DNS 查询,除非本地网络发出明确的网络损伤信号(NXDOMAIN)。

专用 WiFi 地址(MAC 随机化)

iOS 14+ 中的一项隐私功能,每个 SSID 会生成一个唯一的随机 MAC 地址,以防止跨场所的物理追踪。

如果 MAC 地址在会话中期或重新认证期间发生轮换,可能会导致 RADIUS 计费会话去同步化。

应用实例

一家部署了 Cisco Catalyst 9800 WLC 的豪华酒店发现,在连接到开放的 Guest WiFi SSID 时,iPhone 访客用户从未收到 Captive Portal 欢迎页面。而 Android 和 Windows 笔记本电脑则能立即加载该门户。网络团队应如何诊断并修复 Apple CNA 检测问题?

  1. 检查预认证重定向 ACL:验证 Cisco 9800 重定向 ACL 是否拒绝(放行)UDP 53 DNS 并允许 TCP 80 HTTP 以触发重定向。2. 检查 Apple 探测白名单:确保在重定向前的预认证围墙花园(walled garden)中未将 captive.apple.com 列入白名单;将其列入白名单会导致 iOS 认为互联网已开通并阻止弹出门户。3. 验证 HTTP 302 与 307:配置 WLC webauth 参数图以返回带有门户 FQDN 的 HTTP 302 Found 重定向。4. 禁用 HTTPS 拦截:确保端口 443 HTTPS 流量被丢弃或拒绝,而不是使用不受信任的证书进行劫持。5. 部署 DHCP Option 114:在访客 DHCP 池中添加 option 114 ascii https:///api/v1/capport,以便进行原生的 iOS 14 - 18 检测。
考官评语: Apple 设备依赖于对来自 captive.apple.com 的 Success 令牌的严格匹配。如果探测域名在围墙花园中被过早允许通行,iOS 会错误地假设互联网已开通,并且永远不会触发 WebSheet。

体育场网络管理员观察到 iOS 17 和 iOS 18 用户遇到了无限登录循环:出现 CNA 页面,用户接受条款并点击“连接”,模态框关闭,但 30 秒后模态框重新打开并再次要求登录。根本原因和解决方法是什么?

  1. RADIUS 会话跟踪:在 iOS 17/18 上,如果配置了私有 WiFi 地址,则会使用轮换的 MAC 地址,或者设备可能会在模态框退出时重新协商 DHCP。2. RADIUS CoA 配置:验证控制器是否在 UDP 端口 3799 上处理 RFC 3576 RADIUS 授权变更 (CoA) 断开连接,以便在认证后立即删除预认证 ACL。3. 会话超时与宽限期:将 MAC 认证绕过 (MAB) 缓存超时增加到 1440 分钟(24 小时),并提供 15 分钟的租约宽限期。4. 围墙花园 OAuth 资源:验证所有 OAuth 端点(Google、Apple、Microsoft)以及字体/样式表是否都在围墙花园中,以便会话在关闭 WebSheet 之前完全加载完毕。
考官评语: 无限重定向循环通常源于 RADIUS CoA 延迟,即当 iOS 发送其登录后验证探测时,控制器尚未将客户端状态从预认证更新为已认证。

练习题

Q1. 为什么尝试重定向 HTTPS(端口 443)流量会导致 iOS 设备上出现 Captive Portal 错误,而不是打开展示页面?

提示:考虑 TLS 加密、证书验证和 HSTS 如何保护网络流量。

查看标准答案

HTTPS 在客户端浏览器和目标 Web 服务器之间建立端到端加密的 TLS 隧道。当无线网关尝试拦截端口 443 并提供重定向时,网关提供的 SSL/TLS 证书与请求的主机名(例如 google.com 或 apple.com)不匹配。iOS 强制执行 HTTP 严格传输安全(HSTS),导致 Safari 和 WebKit 中断连接并显示严重的安全警告,而不是执行重定向。

Q2. 企业访客网络应该如何处理 iCloud 私密代理,以确保 iOS 设备上顺畅地进行 Captive Portal 重定向?

提示:查看 Apple 关于 mask.icloud.com DNS 响应的官方网络指南。

查看标准答案

网络管理员应配置其本地递归 DNS 服务器,针对域名 mask.icloud.com 和 mask-h2.icloud.com 返回 NXDOMAIN 响应(或 DNS 解析失败)。当 iOS 收到这些金丝雀域名的 NXDOMAIN 响应时,它会显示系统警报,告知用户该网络不支持私密代理,并干净地回退到标准的 DNS 和 HTTP 探测处理。

Q3. 与传统的 DNS 和 HTTP 劫持技术相比,部署 RFC 8908 Captive Portal API 有什么优势?

提示:思考协议的清晰度、第 3 层信令以及用户体验。

查看标准答案

RFC 8908 提供了一个标准化的 JSON REST API,通过 DHCP Option 114 或 IPv6 路由器通告进行通信。客户端操作系统直接通过 HTTPS 查询该 API 以了解网络是否处于受限状态、获取门户登录 URL、检查剩余配额并接收场所品牌通知,而不是拦截用户的网络流量。这消除了 SSL 证书警告,支持密码管理器,并维护了浏览器的安全完整性。

常见问题

为什么我的 Captive Portal 在 iPhone 上无法弹出?

当 Apple Captive Network Assistant (CNA) 无法完成对 http://captive.apple.com/hotspot-detect.html 的探测时,iPhone 上的 Captive Portal 将无法弹出。常见原因包括:1) 认证前防火墙拦截了 UDP 端口 53 DNS;2) 网络在 Walled Garden 中过早地将 captive.apple.com 设为白名单;3) 网关尝试进行 HTTPS 拦截,而不是 HTTP 302 重定向;或 4) iCloud Private Relay 干扰了 DNS 解析。

如何强制在 iOS 上显示 WiFi 登录屏幕?

要在 iPhone 上手动触发 Captive Portal:1) 打开 Safari 浏览器并访问纯文本 HTTP URL,例如 http://captive.apple.com、http://neverssl.com 或 http://1.1.1.1;2) 进入设置 > WiFi,点击网络旁边的信息 (i) 图标,确保“自动加入”和“自动登录”均已开启;3) 关闭 WiFi 并重新打开,以触发 CNA 探测守护进程。

Apple 设备必须将哪些域名纳入 Walled Garden 白名单?

为了支持 Apple iOS 和 macOS 的 Captive Portal 检测和资源加载,请将以下域名加入 Walled Garden 白名单:captive.apple.com、www.airport.us、appleiphonecell.com、*.apple.com、*.purple.ai、*.purplewifi.net,以及登录页面上使用的任何第三方 OAuth 提供商域名(例如 accounts.google.com)或 CDN 资源。

RFC 8908 是如何解决 iOS Captive Portal 问题的?

RFC 8908 (Captive Portal API) 和 RFC 8910 (DHCP Option 114) 在 DHCP IP 租约协商期间直接将 Captive Portal URL 传递给 iOS。这使得 iOS 14+ 能够直接在第 3 层即时识别网络受限状态,而无需依赖脆弱的 HTTP 重定向或 DNS 劫持。

MAC 地址随机化对 Captive Portal 身份验证有何影响?

iOS 私有 WiFi 地址针对每个 SSID 使用唯一的 MAC 地址。如果设备轮换其 MAC 地址,或者会话缓存严格与物理 MAC 地址绑定且没有 RADIUS 计费宽限期,用户可能会被迫重复进行身份验证。通过配置 24 小时的租约宽限期并部署 Passpoint (Hotspot 2.0) 可以解决此问题。

对您的具体配置有疑问吗?

我们的团队与 80,000 多个场所的运营方、IT 经理和网络工程师保持合作。预约 20 分钟的通话,我们将为您展示同行是如何解决类似问题的。