酒店WiFi合规认证，技术上不是一台设备的事，是一条链路。

很多甲方以为买一套Portal认证系统就合规了，或者以为装一台能记录IP的路由器就能过公安检查。实际上合规审计检查的不是一个功能点，而是一套能力体系：谁能上网、怎么确认身份、终端是什么、用什么IP、访问了什么、存了多久、能不能快速查出来。这链条上每个环节缺一个，合规就打折。

这篇文章就从技术实现角度，把酒店WiFi合规的核心链路拆解清楚。不是讲概念，是讲每个环节具体要做什么、选型时要注意什么坑。

第一环：认证准入——先把"谁"搞清楚

认证是合规的第一道关。不做认证的酒店WiFi，日志里只有IP地址和MAC地址，没有手机号这类实名标识，出了事根本追溯不到人。所以酒店WiFi合规的前提是先上一套认证系统。

酒店场景下最常见的认证方式是短信认证。技术流程是：客人连接SSID后被强制重定向到Portal页面，在页面输入手机号，系统发送验证码，验证码正确后分配上网权限。这个流程有几个技术点需要注意。

Portal页面需要支持定制。酒店都有品牌要求，Portal页面要能放酒店Logo、换上自家色调、添加服务说明，最好还能接入会员系统或者对接营销入口。这部分能力因厂商差异比较大，选型时不能光看价格，要看Portal的定制自由度。

短信通道的稳定性直接影响认证成功率。客人收不到验证码是最常见的投诉来源，跟短信通道供应商的质量直接相关。主流做法是接入多家运营商短信通道做冗余，防止单一通道出问题导致大面积认证失败。另外要注意的是，短信认证需要跟三大运营商谈对接，有些地区还有本地的短信网关要求，方案设计前最好先确认清楚。

对于有PMS系统的酒店，PMS对接认证是更优方案。技术逻辑是：客人办理入住后，PMS把房号和入住信息推送给认证系统，认证系统生成对应的上网凭证，客人连接WiFi后无需额外操作，直接就能用。这种方式对客人体验更好，酒店管理端也能直接关联上网记录和房间信息。但PMS对接需要跟PMS厂商开放接口，不同PMS系统的接口标准不一样，对接工作量视具体PMS品牌而定，常见的如西软、千里马、住哲等都有成熟的对接方案。

第二环：终端识别与IP分配——把"设备"搞清楚

认证确认了"谁"，接下来要确认"用什么设备接入的"。这一环主要采集两个标识：MAC地址和IP地址。

MAC地址是终端网卡的物理地址，全球唯一，是日志追溯的关键字段之一。MAC采集需要在AP侧或交换机侧完成，不是所有认证系统都能原生支持，需要确认AP或交换机是否开放MAC上报接口。更复杂的情况是，现在很多手机有随机MAC功能（iOS和Android新版本都有），连接WiFi时先发送一个随机MAC，认证通过后才发送真实MAC。这个机制会干扰日志里的设备识别准确性，需要在Portal认证流程里增加一步"终端真实MAC上报"的触发逻辑。

IP地址分配和记录也是关键。DHCP服务器分配的地址要跟认证会话绑定，日志里要同时记录"哪个手机号在哪个时间段用了哪个IP地址"。这需要认证系统和DHCP服务之间有状态同步机制，不是简单的日志流水。

第三环：上网日志留存——把"行为"记录下来

这是合规的核心。很多人以为"日志"就是一个记录上网时间的流水账，实际上完整的上网日志要包含多个字段。

基础日志字段包括：认证账号（手机号或房号）、终端MAC地址、分配IP地址、认证上线时间、认证下线时间、AP或接入点位置信息。这些字段由认证计费系统原生生成，不需要额外采集。

进阶日志字段包括：访问的URL、访问的域名、DNS查询记录、流量大小、上网时长细粒度记录。这些字段需要日志审计系统通过流量镜像或旁路采集来实现，认证计费系统本身一般不记录HTTP层的详细内容。

这里有个重要的选型判断点：酒店实际需要的是基础日志还是深度日志？

如果酒店所在地没有强制要求细粒度URL记录，基础认证日志就能满足82号令和网络安全法的要求。V7统一认证计费系统内置的日志模块可以满足这类需求，不需要额外采购日志服务器，成本和运维复杂度都低很多。

如果酒店需要做等保三级测评，或者当地公安网安部门明确要求提供URL访问记录，就需要部署独立的日志审计系统。这类系统通过核心交换机做流量镜像，可以采集全量的上网行为日志，包括访问了哪些网站、搜索了什么关键词（如果有HTTPS解密能力的话）。但深度日志方案的成本和运维门槛都高很多，数据存储量也大，需要提前规划好存储容量。

无论哪种方案，日志留存周期是硬指标：82号令要求不少于60天，网络安全法要求不少于六个月，实际执行取较长者。存储规划要一步到位。

第四环：日志上报与检索——把"追溯"能力交付出去

日志存下来了，还要能在被要求时快速查出来。这是很多方案容易忽略，但检查时必然过不去的一环。

检索能力分两个层面：一是酒店自己能查，二是能按要求导出。

酒店自己能查，要求认证系统或日志系统有配套的查询界面，支持按时间段、按账号、按IP、按MAC等多种条件检索。能查到什么粒度，取决于前面第三环采集了什么字段。采集的是基础日志，查询就只能是基础字段；采集了URL日志，查询才能精确到具体访问记录。

按要求导出，主要是配合公安网安部门的协查要求。82号令里明确提到，经营者应当为公安机关依法维护国家安全和侦查犯罪的活动提供技术支持和协助。这个"协助"在操作层面就表现为：公安发协查函过来，酒店要在规定时间内提供指定时间段内指定账号的上网记录。这个过程考验的是日志系统的检索和导出效率。

部分地区的公安网安部门还要求酒店定期推送日志到指定平台，也就是"日志上报"。上报有固定的格式要求（行业里叫"32号令格式"），推送频率和推送字段有具体规范。这块需要在方案设计阶段就跟当地公安网安部门确认清楚，不同地区的要求差异比较大，有些地方只要求留存备查，有些地方要求定期推送。

一条完整链路的核心设备选型要点

说完四个环节，再来梳理一下每个环节的选型关注点。

认证网关是整个链路的核心，建议选型时重点看这几个指标：支持的并发认证数（跟酒店规模匹配）、支持的认证方式种类（短信/PMS/MAC/微信）、Portal定制自由度、日志导出格式和接口能力、是否支持多运营商线路接入。有些酒店有多家运营商宽带接入，认证网关要能支持多线路负载均衡和链路冗余切换。

AP设备主要影响无线体验，合规能力主要看MAC上报和流量镜像支持。选型时要确认AP能否把终端MAC地址和关联信息上报给认证网关，以及能否配合日志系统做流量镜像采集。

日志系统的选型要看三个数字：采集字段数、存储容量、检索性能。采集字段数决定能查到什么；存储容量决定能存多久；检索性能决定需要查的时候能不能快速出结果。

整体方案选型时，还有一个容易被忽略的点：各设备之间的联动能力。认证网关、AP、日志系统最好出自同一技术体系或者有明确的兼容对接方案。多厂商拼凑的方案，出了故障定位难度大，各厂商互相推诿的情况在行业里并不少见。

先做认证——搞清楚谁在上网；再做标识——搞清楚用什么设备；从这两个环节自然生成基础日志；最后搭检索和上报能力——确保日志能用、能查、能交付。这条链路建完整了，酒店WiFi的合规能力才算真正落地。

方案贵不贵重要，但更重要的是方案对不对。选了一套跑不起来的花架子，不如选一套能用的基础方案。