有的 ，参考：

4. RADIUS的基本消息交互流程

用户、RADIUS客户端和RADIUS服务器之间的交互流程如图1-3所示。

图1-3 RADIUS的基本消息交互流程

消息交互流程如下：

(1)     用户发起连接请求，向RADIUS客户端发送用户名和密码。

(2)     RADIUS客户端根据获取的用户名和密码，向RADIUS服务器发送认证请求包（Access-Request），其中的密码在共享密钥的参与下利用MD5算法进行加密处理。

(3)     RADIUS服务器对用户名和密码进行认证。如果认证成功，RADIUS服务器向RADIUS客户端发送认证接受包（Access-Accept）；如果认证失败，则返回认证拒绝包（Access-Reject）。由于RADIUS协议合并了认证和授权的过程，因此认证接受包中也包含了用户的授权信息。

(4)     RADIUS客户端根据接收到的认证结果接入/拒绝用户。如果允许用户接入，则RADIUS客户端向RADIUS服务器发送计费开始请求包（Accounting-Request）。

(5)     RADIUS服务器返回计费开始响应包（Accounting-Response），并开始计费。

(6)     用户开始访问网络资源。

(7)     用户请求断开连接。

(8)     RADIUS客户端向RADIUS服务器发送计费停止请求包（Accounting-Request）。

(9)     RADIUS服务器返回计费结束响应包（Accounting-Response），并停止计费。

(10)     通知用户结束访问网络资源。

1.1.7  Portal认证流程

直接认证和可跨三层Portal认证流程相同。二次地址分配认证流程因为有两次地址分配过程，所以其认证流程和另外两种认证方式有所不同。

1. 直接认证和可跨三层Portal认证的流程（CHAP/PAP认证方式）

图1-3 直接认证/可跨三层Portal认证流程图

直接认证/可跨三层Portal认证流程：

(1)     Portal用户通过HTTP/HTTPS协议访问外部网络。HTTP/HTTPS报文经过接入设备时，对于访问Portal Web服务器或设定的免认证地址的HTTP/HTTPS报文，接入设备允许其通过；对于访问其它地址的HTTP/HTTPS报文，接入设备将其重定向到Portal Web服务器。Portal Web服务器提供Web页面供用户输入用户名和密码。

(2)     Portal Web服务器将用户输入的信息提交给Portal认证服务器进行认证。

(3)     Portal认证服务器与接入设备之间进行CHAP（Challenge Handshake Authentication Protocol，质询握手认证协议）认证交互。若采用PAP（Password Authentication Protocol，密码认证协议）认证则直接进入下一步骤。采用哪种认证交互方式由Portal认证服务器决定。

(4)     Portal认证服务器将用户输入的用户名和密码组装成认证请求报文发往接入设备，同时开启定时器等待认证应答报文。

(5)     接入设备与RADIUS服务器之间进行RADIUS协议报文的交互。

(6)     接入设备向Portal认证服务器发送认证应答报文，表示认证成功或者认证失败。

(7)     Portal认证服务器向客户端发送认证成功或认证失败报文，通知客户端认证成功（上线）或失败。

(8)     若认证成功，Portal认证服务器还会向接入设备发送认证应答确认。若是iNode客户端，则还需要进行以下安全扩展功能的步骤，否则Portal认证过程结束，用户上线。

(9)     客户端和安全策略服务器之间进行安全信息交互。安全策略服务器检测客户端的安全性是否合格，包括是否安装防病毒软件、是否更新病毒库、是否安装了非法软件、是否更新操作系统补丁等。

(10)     安全策略服务器根据安全检查结果授权用户访问指定的网络资源，授权信息保存到接入设备中，接入设备将使用该信息控制用户的访问。

步骤(9)、(10)为Portal认证安全扩展功能的交互过程。

2. 二次地址分配认证方式的流程（CHAP/PAP认证方式）

图1-4 二次地址分配认证方式流程图

二次地址分配认证流程：

(1)～(7)同直接/可跨三层Portal认证中步骤（1）～（7）。

(8)     客户端收到认证通过报文后，通过DHCP获得新的公网IP地址，并通知Portal认证服务器用户已获得新IP地址。

(9)     Portal认证服务器通知接入设备客户端获得新公网IP地址。

(10)     接入设备通过DHCP模块得知用户IP地址变化后，通告Portal认证服务器已检测到用户IP变化。

(11)     当Portal认证服务器接收到客户端以及接入设备发送的关于用户IP变化的通告后，通知客户端上线成功。

(12)     Portal认证服务器向接入设备发送IP变化确认报文。

(13)     客户端和安全策略服务器之间进行安全信息交互。安全策略服务器检测客户端的安全性是否合格，包括是否安装防病毒软件、是否更新病毒库、是否安装了非法软件、是否更新操作系统补丁等。

(14)     安全策略服务器根据用户的安全性授权用户访问指定的网络资源，授权信息保存到接入设备中，接入设备将使用该信息控制用户的访问。

步骤(13)、(14)为Portal认证扩展功能的交互过程。

一、整体流程分 4 大阶段

1. 重定向阶段（用户触发，设备劫持 HTTP）
2. Portal 页面推送阶段（你最关心的部分）
3. Portal 认证交互阶段（Portal 协议报文）
4. RADIUS 认证 & 授权放行阶段

二、阶段 1：重定向（用户第一次上网）

1. 终端：GET http://www.baidu.com
2. 接入设备（交换机 / AC）拦截 80 端口：
   • 不转发，直接回：
     plaintext

     HTTP/1.1 302 Found Location: http://<iMC-Portal-IP>:8080/portal?userip=10.40.98.3&nasip=172.16.1.250
3. 终端收到 302，自动访问 iMC Portal 地址。

这个阶段 还没有 Portal 协议报文，只有 HTTP 302。

三、阶段 2：Portal 页面推送（你最关心的部分）

报文 1：终端 → iMC（HTTP GET 认证页面）

报文 2：iMC → 接入设备（PORTAL_FAST_AUTH_QUERY(48)）

报文 3：接入设备 → iMC（PORTAL_FAST_AUTH_RESPONSE(49)）

• 如果没开快速认证 / MAC 未绑定：返回 允许推送页面
• 如果开了快速认证：返回 直接放行，不弹页面（你之前的故障点）

报文 4：iMC → 终端（HTTP 200 OK，下发登录页面）

四、阶段 3：Portal 认证交互（输入账号密码后）

报文 5：终端 → iMC（HTTP POST 账号密码）

报文 6：iMC → 接入设备（REQ_AUTH (3) 认证请求）

报文 7：接入设备 → iMC（CHAP 挑战（可选））

报文 8：iMC → 接入设备（CHAP 应答）

五、阶段 4：RADIUS 认证 & 放行

报文 9：接入设备 → iMC RADIUS（Access-Request）

报文 10：iMC → 接入设备（Access-Accept）

报文 11：接入设备 → iMC（AUTH_SUCCESS (11) 认证成功）

报文 12：iMC → 终端（HTTP 跳转成功页）

六、关键总结（对应你日志）

• PORTAL_FAST_AUTH_QUERY(48) = iMC 查设备：要不要免认证？
• 如果设备回 49 允许推送页面 → 正常弹页
• 如果开了 fast-auth → 设备直接放行，不弹页（你之前的问题）

iMC做Portal认证时，推送认证页面的阶段是整个流程中最核心的部分，它由一系列HTTP和Portal协议的报文交互构成。

为了方便你理解和排查问题，我把这个阶段的标准流程整理成了下面的表格。

📡 iMC Portal认证推送页面阶段的完整报文交互流程

完成以上步骤后，用户即可在推送的页面上输入用户名和密码，进入后续的认证交互阶段。

其中，iOS等终端的“ Captive Portal 主动探测”逻辑是常见原因之一。为了快速检测网络连通性，苹果等设备在连接Wi-Fi后会自动向captive.apple.com等特定检测域名发起请求。接入设备会拦截此流量并触发重定向，这也就解释了为什么用户还没打开浏览器，Portal认证页面却能自动弹出了。它不是一种必然故障，而是由Portal触发的主动弹出。

💡 实际排错中的关键日志对比

为了让你更直观地理解报文交互的时机，下表对比了正常认证流程与因“快速认证”导致页面无法弹出的情况，这对你之前的排查非常有参考价值。