前段时间处理了一个酒店WiFi的投诉，投诉来自酒店集团的法务部门，对象是设备供应商。核心问题是：公安局来做检查，要调取某日某时段的上网日志，酒店方找到供应商，供应商折腾了两天，给出来的日志字段不完整，时间戳跟PMS记录对不上，最终无法证明有效留存。这件事后来以供应商赔偿整改收场。类似的事情我听到不止一起，日志留存这件事，真正做到位的酒店并不多。

日志留存的法规要求是什么

《网络安全法》第21条要求网络运营者采取技术措施，留存网络日志，留存时间不少于六个月。公安部令第82号（互联网安全保护技术措施规定）对互联网服务提供者提出了更具体的要求：留存用户注册信息、用户上网日志，包括上网时间、上网时长、分配的IP地址、用户访问的互联网地址或域名。

这些要求看起来很具体，但实际执行中有一个关键问题：什么算"有效"的日志？有些酒店在被查时，日志是有的，但字段残缺、时间不准、存储中断——这种日志在执法层面同样视为不合规。有效的日志，是指在核查时能够完整、准确地回答"谁在什么时间用什么设备上了网"这个问题。

哪些字段必须记录

最基础的日志字段应该包括：用户标识（证件号或认证账号）、设备标识（MAC地址）、分配的IP地址（含端口，如果做了NAT）、认证上线时间、认证下线时间、上行流量、下行流量。

更完整的日志还应该包括：认证方式（短信、PMS联动、密码等）、认证结果（成功/失败）、客户端设备类型（可选，通过User-Agent推断）、会话ID（用于关联同一客人的多次认证）。

如果酒店有条件做DNS日志，还可以记录用户访问的域名。这部分不是强制要求，但在某些高安全级别的场所是额外加分项。需要注意的是，DNS日志的存储量远大于认证日志，需要提前规划存储容量。

一个容易被忽视的字段是NAS-Port或AP标识——记录用户是通过哪个AP接入的。这个字段在定位信号问题和位置关联时很有用，但在核查中用得不多，属于"有更好、没有也可以"的层级。

存储方式的选择

日志存储方式大致分三类：本地存储、私有云（自建服务器）、第三方SaaS。

本地存储是最简单的方案，日志直接保存在AC或认证网关上。问题是：设备存储容量有限，超出后要么覆盖旧日志要么报错停止记录；设备故障会导致日志丢失；没有异地备份，火灾或盗窃情况下数据无法恢复。单纯依赖本地存储，6个月的留存很难可靠保证。

私有云方案是酒店集团或较大单体酒店常见的选择：在机房或云服务器上部署日志接收服务，各认证网关实时推送日志。这种方案可控性强，数据在自己手里，但需要有运维能力来维护服务器和存储。

第三方SaaS方案适合中小酒店：直接使用认证系统供应商提供的云端日志服务，日志自动上传，按需查询。优点是零运维，缺点是数据存在第三方，需要确认供应商的数据安全资质和合同条款（特别是合同终止后数据如何处理）。

时钟同步是基础中的基础

日志时间戳的准确性，是很多人忽视的基础问题。如果认证网关的系统时钟偏差了半小时，日志里的所有时间都是错的。在核查时，监管方拿到的日志时间和PMS入住时间对不上，就会产生"日志是否真实"的质疑。

解决方法很简单：配置NTP（网络时间协议）同步，让设备时钟自动与标准时钟服务器同步。但实际情况是，很多酒店的老设备没有默认开启NTP，或者网络环境限制了NTP服务器的访问，时钟一直在慢慢飘。定期检查设备时钟，是运维工作中不应该遗漏的一项。

日志查询的实际操作

日志留存下来之后，还需要能高效查询。监管核查时，通常会给出一个具体的时间段和查询条件（比如"请提供2025年12月1日14:00到16:00之间，IP地址为x.x.x.x的上网记录"），需要在较短时间内给出结果。

如果日志系统没有检索功能，或者检索性能很差，面对几百万条原始日志，人工查找是不现实的。建议在日志系统选型时，明确要求：支持按时间范围、IP地址、MAC地址、用户标识等字段检索；查询响应时间可接受；能导出标准格式（CSV或PDF）的查询结果。

有些供应商的系统，日志可以写入，但没有查询界面，需要登录数据库直接操作。这种情况在技术上不是不可行，但在现实中酒店运营方通常不具备这个能力，出事的时候找供应商，供应商不配合或者响应慢，就会出现文章开头那种局面。

定期审计与测试

日志系统不是装好就不管的。建议酒店建立一个简单的定期自查机制：每个月随机抽取几条上网记录，验证对应的日志是否完整存在；每季度检查一次总日志量，确认没有出现断档；每半年做一次模拟核查，走完"接到查询请求→从系统中导出结果→确认字段完整性"的完整流程。

这个自查机制不需要很复杂，但需要有人负责、有记录。遇到问题（比如某段时间日志缺失），要及时排查原因并整改，不要等到真正被查的时候才发现系统早就出问题了。