做过几个项目之后就会发现，WiFi认证系统出问题的地方，往往不是核心功能本身，而是部署环境里那些看起来不起眼的配置细节。尤其是在多AP场景下——不管是一个楼层几十个吸顶AP，还是一个园区覆盖上百个AP——如果前期有几个参数没拉齐，上线之后就会出现各种稀奇古怪的现象：有的区域认证页面弹不出来，有的位置能认证但过一会就掉线重新跳Portal，还有些地方干脆连SSID都搜不到。

AP的网关指向和认证服务器的网络可达性

这是多AP部署里最容易出问题也最容易排查不到的一个点。大部分WiFi认证系统的认证流程是这样的：终端关联AP拿到IP之后，在完成认证之前，所有HTTP请求被重定向到Portal认证页面。这个重定向动作通常由AC或者网关设备完成。但如果AP上行链路里的某个中间设备没有正确配置网关地址，或者认证服务器的IP不在终端的可达网段内，就会出现终端能拿IP但打不开认证页面的情况。

我们遇到过的一个现场案例是这样的：一个酒店项目，大堂区域的AP认证一切正常，但三楼客房的AP死活弹不出认证页面。排查到最后，发现是三层交换机上少了一条静态路由，导致三楼AP的终端虽然拿到了DHCP分配的IP，但到认证服务器的路由不可达。在二层交换机上补了那一条路由之后，问题立刻消失。这个事情说明，AP数量越多、网段划分越复杂，路由可达性就越需要提前拉通验证，不能等到部署完了才发现。

Portal URL的DNS解析路径

另一个容易被忽略的点是DNS。终端在完成认证之前，发出的第一个HTTP请求会被重定向到Portal页面。这个Portal页面的URL通常是一个域名，终端需要先做DNS解析。如果DNS服务器配置不当——比如DHCP下发的DNS不是公网DNS，而是内部DNS，但这个内部DNS又没有Portal域名的解析记录——终端就会卡在DNS解析这一步，看起来就是"认证页面一直在加载但永远打不开"。

解决方式也简单，两条路：要么DHCP下发的DNS直接指向一个能解析Portal域名的DNS，要么在内部DNS上手动加一条Portal域名的A记录。但关键是，在多AP部署中，不同VLAN的DHCP配置可能不一样，每个VLAN都要检查DNS下发是否一致。项目现场最常见的情况是：测试环境用的VLAN配的DNS是对的，但生产环境另一个VLAN配的DNS是错的，上线之后只有部分楼层出问题，排查方向很容易被误导。

AC和认证服务器之间的NAS-Port-ID传递

做RADIUS认证的WiFi认证系统，AC在转发Radius请求时，会在报文里带上NAS-Port-ID这个属性，告诉认证服务器"这个终端是从哪个AP、哪个SSID上来的"。这个属性对于计费系统、位置溯源、故障定位都很重要。但有相当数量的AC设备，默认配置里NAS-Port-ID的格式和认证服务器期望的不一致，或者干脆就没带。

比如某些品牌的AC，默认的NAS-Port-ID格式是"AP的MAC地址+SSID编号+Radio编号"，但认证服务器期望的是"AP名称+VLAN号"。格式不匹配不会导致认证失败，但会导致认证日志里丢掉关键的位置信息，事后出了问题根本不知道终端连的是哪个AP。在多AP环境中部署之前，必须先用一个测试AP把NAS-Port-ID的格式确认好，和认证服务器端对齐字段解析逻辑，不然上线之后日志就是一堆废数据。

多SSID场景下的认证策略隔离

一个WiFi认证系统如果只服务单一SSID，配置相对简单。但如果同时存在多个SSID——比如员工网络一个SSID、访客网络一个SSID、内部设备网一个SSID——每个SSID的认证方式可能不同：员工用802.1X、访客用短信认证、设备网用MAC白名单。这时候需要特别注意认证策略在AC上的隔离配置。

真实的问题场景是：某些AC设备上，如果不同SSID配置了不同的认证模板但在同一个AP Group下，可能会出现模板串扰——访客SSID下的终端走到了员工的RADIUS服务器上去做认证。表面上看起来是"认证失败了"，但根因是AC把认证请求送到了错误的目标。排查起来非常花时间，因为从终端侧看到的就是"认证失败"，看不出是送到了哪个RADIUS。部署前应该把所有SSID的认证模板映射关系拉出来审一遍，确认没有交叉引用，并且每个SSID绑定了正确的认证方式和正确的RADIUS服务器地址。

终端漫游时的认证状态保持

多AP部署中终端在AP之间漫游是常态。如果WiFi认证系统不支持快速漫游或者认证状态保持，每次漫游切换AP时终端都会被要求重新认证。这在酒店和校园场景里体验非常糟糕，用户走在走廊里，从一个AP覆盖区域走到另一个AP覆盖区域，WiFi就断了，被重新弹Portal。

关键参数有两个：一个是PMK缓存，一个是OKC（Opportunistic Key Caching）。802.1X认证方式下，如果AC支持PMK缓存，终端漫游到另一个AP时不需要重新走完整的EAP认证流程，只需要走四步握手，漫游时间可以控制在几十毫秒以内。Portal认证方式下，通常依赖AC上的在线用户表来判断终端是否已经认证过——终端切换AP时，AC通过查询在线用户表，如果发现这个MAC地址已经处于认证通过状态，就不会再次弹Portal。但这个机制的可靠性高度依赖于AC实现在线用户表的更新速度，有的AC在AP切换时有几百毫秒到几秒的延迟，终端在这段时间里就会感受到"断了又连上"的体验。

这些配置细节，单个拿出来都不是什么高大上的技术问题。但多AP环境就是一个放大镜，它们会被成倍放大。部署前把上面这几点逐一验证过，能省掉上线后至少一半的故障工单。