很多人把 Portal 认证理解成弹一个页面，把 Radius 理解成某个后台协议，两者混着说。实际它们是同一件事的两段：用户在浏览器里看到和操作的那一整段，和接入设备与认证平台之间一问一答的那一整段。分清这两段，排障时就知道该看哪里，验收时也知道该分别验什么。混在一起的结果是页面打不开也去查账号，账号不对也去查页面，时间全耗在错误的方向上。
用户看得见的那一跳
Portal 这一段负责的是把用户引到认证页、把页面推给他、接收他在页面上填的信息、以及在认证通过之后让他正常上网。它面对的是人和浏览器，所以要考虑页面加载速度、终端兼容、失败提示写得清不清楚。这一段出问题，用户的直接感受是页面弹不出来、页面卡住、或者填完没反应。它和账号对不对无关，账号全对，页面出不来一样上不了网。
设备背后的那一问
Radius 这一段用户完全看不到。终端发来的认证请求由接入设备转给认证平台，平台核对身份之后回一个接受或者拒绝的结果，同时把这台终端该拿到的策略一起带回去，由设备执行。它面对的是设备和报文，所以要考虑的是请求能不能到、响应快不快、字段有没有缺失。这一段出问题，用户的感受是页面能弹出来、信息也填了，但一直提示认证失败或者转圈。
授权参数是随结果一起下发的
认证平台回的不只是一个通过或者不通过。这个终端能用多少带宽、属于哪个网段、有效期多长、要不要做额外限制，这些参数通常跟着认证结果一起下发给接入设备，由设备在具体链路上执行。所以策略生效的真正位置在设备侧，平台只是告诉设备该怎么执行。理解这一点很重要：平台上看策略配好了，不代表链路上就生效了，两者之间还隔着一次下发和设备侧的执行能力。
计费是另一条线
认证是一次动作，计费是一条会话。用户通过认证之后，计费侧开始建一条会话，中间会有周期性的更新，用户离线或者被踢下线时这条会话结束。在线时长和流量都从这条线里出来。它和认证共用身份和会话标识，但不是同一件事。项目里经常出现认证正常但计费对不上，或者反过来，原因就是这两条线各自的配置和状态没对上，而不是认证本身出了问题。
两段断掉的症状不一样
分清楚症状能省大量时间。Portal 这一段失效，典型表现是页面弹不出来、页面加载不出来、提交之后没响应，这时候已在线的用户通常不受影响，因为他们已经通过认证了。Radius 这一段失效，典型表现是页面能正常打开、信息能填，但提交之后一直失败或者超时，这时候已在线的用户也可能受影响，取决于设备侧是不是每次都要回平台校验。看现象先归到哪一段，再往下查。
排查时要分开看两类记录
对应地，记录也要分开看。认证记录里有请求有没有到平台、到了哪一步、卡在什么环节，这是判断 Radius 这一段的主要依据。页面推送和点击这类数据反映的是 Portal 这一段的情况。排障时先看认证记录，因为请求到没到平台是最硬的事实，它能直接把问题切分成网络与设备侧、还是平台侧。只盯着页面改重试，往往是在没有事实依据的情况下试错。
验收时两段都要单独写
验收清单里这两段应该有各自的条目。Portal 这一段至少验：不同终端能不能弹出页面、页面加载控制在多少时间内、失败提示是否明确。Radius 这一段至少验：认证请求能不能稳定到达、成功率在什么水平、下发策略是否真的在设备侧生效、强制下线能不能执行。把它们写成一条总的认证是否可用，等于把两类完全不同的问题压成一个判断，出问题的时候没法定位责任。
压力点也要分开看
两段的压力来源不同。Portal 这一段更靠近前端，并发高的时候先吃紧的是页面推送和请求接收；Radius 这一段更靠近后端，先吃紧的是身份校验和策略下发。做容量观测时如果只盯一个总的认证量，就看不出是哪一段先到瓶颈，容易加错资源。所以建议两段的请求量和耗时分开采集、分开看趋势，哪一段先出现拐点，扩容和优化就先动那段。具体能到什么量级，要按项目实际的硬件和拓扑去压测，不能拿资料上的数字直接当结论。
有的项目只走一段
并不是每个项目都完整跑这两段。有些场景下接入设备自带简单的认证能力，只需要平台做账号校验，页面由设备自己出；也有些场景只需要确认放不放行，不需要复杂的策略下发。这种简化没有错，但要知道简化掉了什么：通常是策略的灵活性和统一管理的粒度。项目初期为了快速上线做简化可以，只要把简化带来的限制写清楚，后面业务复杂起来时才知道该补哪一段。
把分工写进方案里
最后一点很实际：方案文档里应该明确画出这两段的分界，写清楚哪一段由谁负责、出问题找谁。多厂商参与的项目尤其如此，接入设备是一家的，认证平台是另一家的，出了问题两边都说是对方那一段。提前把分界和判据写下来，争议时就有一条共同认可的依据，而不是各执一词靠现场试。