认证通过之后系统写了什么：四元组与会话 ID 的产生

176号令的检查方式变了之后，很多场所才发现一个隐蔽的问题：认证页面在弹、住客也在连，但检查人员输入一个手机号，系统拉不出这个人的完整上网记录。

问题不在“有没有认证”，而在认证通过那一刻系统写了什么。Portal页面上客人点完“同意并认证”，对客人来说是上网开始了，对系统来说只是一段数据的开始。认证通过那一刻写下来的东西，决定了后面能不能把一次上网行为追溯到一个具体的人。这一段常被当成“实现细节”忽略，出问题也基本出在这。

认证通过那一刻，系统要落两样东西

第一类是认证记录：谁、用什么方式、什么时候、在哪个终端上完成的认证；
第二类是会话标识：这次上网过程在后续日志里的对应编号。
前者回答"是不是本人"，后者回答"哪些流量是这个人的"。两样缺一，日志就只是一堆没有主人的访问记录。

工程上最容易犯的错是只留第一类——认证记录齐全，行为日志也在，但两者对不上号，结果就是查得到访问记录、查不到是谁。

四元组：把人、终端、地址、时间钉在一起

认证通过后写入的四元组，作用是把一次上网的四类关键标识绑定：账号标识（手机号或证件号）、终端 MAC、终端 IP、上线时间。四项一起出现，"谁在什么时间用哪台设备从哪个地址上网"才成立。

为什么必须绑成一组而不是四条独立记录：IP 会变、MAC 可换、时间会重叠。酒店场景里同一个 IP 在退房后立刻分配给下一位客人，如果只靠 IP 关联，两个人的上网记录会串在一起。四元组的价值就在于把这段"占用关系"限定在一个时间区间内。具体字段以实际对接版本的接口文档为准，但四项缺一，追溯链就断。

会话 ID：认证记录与行为日志的接头

云日审侧做的是会话 ID 与行为日志在云端关联。这一句里的关键是"在云端"——场所本地不部署日志服务器，行为日志汇聚到云端后，按会话 ID 与认证记录对齐。

对接时要确认三件事：

会话 ID 在认证侧生成还是在日志侧生成；

同一个人重连 WiFi、跨天在线时是否复用同一会话；

会话结束后，认证记录与行为日志的关联关系保留多久。

第三点尤其容易漏——认证记录留到了，关联关系没了，等同于没留。

写入失败会怎样：认证成功但没落地

这是最隐蔽的一类故障：客人正常上网、体验无感，系统侧写入却失败了。

常见诱因有三：认证通过后放行动作先执行、写入动作后执行，中间进程异常导致写入丢失；高并发入住时写入队列积压，记录延迟落地；终端在未完成写入前断线。

排查建议：认证成功数与会话落库数按小时比对，两者差值异常即为故障信号，不要等迎检时才发现日志有洞。

运营商场景里，写入动作落在插件上

运营商组网的场所，认证与写入由云 Portal 插件承接——它以插件形态与运营商光猫对接，不改变光猫原本的宽带接入与转发功能，负责 Portal 页面推送、多通道核验（短信、证件含护照及港澳台居民证件、微信）以及四元组的写入。写入后的数据在云端留存与关联，门店侧不新增日志服务器，也不新增存储设备。

自建网络的场所，同一套能力落在智慧光迅通密一体方案的梦想网关上，认证、日志留存与安全防护在同一个设备上完成。

两种场景的差别在承载位置，不在数据结构——这也是跨场景排查时能共用一套字段清单的原因。

交付前建议确认的四条

1. 四元组的四项字段在对接文档中逐项列明，不写"等"；

2. 会话 ID 的生成方、复用规则、关联保留时长写进接口约定；

3. 认证成功数与会话落库数的比对机制在验收时实测一次；

4. 认证失败与写入失败的告警分别配置，不要合并成一条"认证异常"。

常见问题 FAQ

Q1：Portal 认证通过后，系统会写入哪些关键数据？

A1：主要是账号标识（手机号或证件号）、终端 MAC、终端 IP、上线时间构成的四元组，以及用于后续关联的会话 ID；具体字段以实际对接版本的接口文档为准。

Q2：认证记录和行为日志是怎么对上的？

A2：通过会话 ID 在云端关联。行为日志汇聚到云端后按会话 ID 与认证记录对齐，场所本地不部署日志服务器。

Q3：换光猫或更换终端后，之前的会话数据还在吗？

A3：已在云端留存的日志由云端管理，门店侧更换设备不涉及日志迁移；新设备的认证与写入仍由云 Portal 插件按策略执行。