很多WiFi认证系统在设计阶段只关注认证能不能通过，对认证日志的记录不够重视。等系统上线一段时间，安全审计、合规检查、用户投诉追溯的时候，才发现日志字段缺这少那，根本查不清问题。日志不是事后补丁，而是认证系统的基础能力。字段设计得好，事后排查事半功倍；字段设计得不好，出了问题只能两眼一抹黑。

认证日志至少要记录哪些字段

一次完整的WiFi认证，日志里应该包含用户身份、终端标识、接入位置、时间、结果、授权信息等关键要素。具体来说，用户账号或手机号、终端MAC地址、接入AP名称或AP MAC、接入SSID、分配IP地址、认证开始时间、认证成功或失败时间、失败原因、认证方式（Portal、802.1X、短信等）、分配的VLAN、下发的ACL策略，这些都是必须字段。

还有一些字段看似不重要，实际排查时很有用。比如终端操作系统类型、浏览器版本、信号强度、终端漫游前的AP、漫游后的AP。这些信息可以帮助判断用户到底是在哪个位置接入的，是不是因为信号弱或者AP切换导致了认证异常。很多项目为了省存储空间，把这些辅助字段砍掉了，后面排查问题时就缺乏线索。

字段缺失的典型后果

没有记录认证失败原因的系统，运维人员看到用户连不上网，只能猜。是密码错了？是账号过期了？是Radius服务器没响应？是VLAN下发失败？日志里一句“认证失败”没有任何上下文，排错几乎无从下手。项目初期可能还能靠人工测试复现，系统规模大了之后，这种方式根本不可持续。

还有一种常见问题是MAC地址没记录。用户投诉时可能只提供了手机号或姓名，如果系统只按MAC地址索引，查不到对应记录。反之，如果用户只提供了MAC地址，但系统只按账号索引，同样查不到。认证日志必须同时建立多维度索引，账号、MAC、IP、手机号、时间都要能检索。

时间字段设计也容易被忽略。有的系统只记录认证结果时间，不记录请求发起时间，算不出认证延迟。有的系统时间戳精度只有秒，对于高并发场景，根本分不清同一秒内发生的多个事件。建议时间字段至少精确到毫秒，并统一使用NTP同步后的时间。

日志格式要便于后续分析

认证日志不要只存成文本文件，每天生成一堆log，想查的时候用grep翻半天。结构化的日志格式更利于分析和检索。比如JSON格式，每个字段有固定含义，可以导入ELK、日志服务、数据库做聚合分析。即使暂时没有能力上日志平台，也应该把关键字段结构化存储，为未来留接口。

日志内容要尽量自包含，不要依赖外部系统的状态来解释。比如失败原因不要只写“错误码1003”，而要写清楚“Radius服务器未响应，IP地址为X，端口1812，超时时间3秒”。这样即使日志被导出到第三方系统，仍然能看懂。

日志安全和合规要求

认证日志里包含大量敏感信息，比如手机号、账号、MAC地址、接入位置。日志存储要有权限控制，不能被普通运维人员随意下载。日志传输要加密，避免在网络中被窃听。日志保留期限要符合合规要求，比如等保2.0要求重要日志至少保存180天，某些金融行业要求保存更久。

日志篡改防护也很重要。认证日志一旦生成，不应该允许修改。数据库层面可以通过权限控制禁止修改和删除操作，文件层面可以使用WORM存储。审计人员检查时会关注日志的完整性，如果发现日志能被随意修改，合规检查结果就会受影响。

项目里的建议做法

在WiFi认证系统需求评审阶段，就把日志字段清单列出来，和甲方、安全团队、运维团队一起确认。不要等开发快结束了才想起来补日志。日志字段宁可多记，不要少记。存储成本相对合规风险和排错成本来说，是可以接受的。同时要做好日志查询工具，让一线运维能够快速按账号、MAC、IP、时间等维度检索。

认证日志是WiFi认证系统的黑匣子。设计好了，它是问题定位和合规审计的利器；设计不好，它只是一堆占磁盘空间的文本。甲方不一定会主动提出日志需求，但作为方案设计者，应该提前把这些字段想清楚。