从接入到入库：一次上网在云 Portal 与云日审之间的时序

176号令的检查方式变了之后，运营商代建项目最先暴露的问题不是“对接没做好”，而是“这两项能力原本就不在交付清单里”。

运营商组网交付的是宽带接入和组网方案——光猫装了、线路通了、WiFi能上了，但光猫只覆盖WAN侧配置、WiFi参数与固件升级，不管用户身份，也不产出上网行为日志。实名认证和日志留存，从来不在运营商组网方案的交付范围里。176号令施行之后，这个缺口从“行业惯例”变成了合规风险。

补法分两段：智慧光迅云Portal以插件形态补上认证能力，云日审在云端补上日志关联与留存能力。这两段不是两个独立模块的拼装，而是同一条时间线上的前后两段——前一段决定“是谁”，后一段决定“做了什么”，中间靠会话ID串起来。把这条时间线从T0走到T6走一遍，各环节的责任界面和容易断的点也就清楚了。

T0：终端接入，光猫不做认证

客人连上 WiFi，光猫完成的是宽带接入与转发——它本身不具备实名认证与日志留存能力。运营商光猫的管理通道（TR069）只覆盖 WAN 侧配置、WiFi 参数与固件升级，不管用户身份，也不产出上网行为日志。这是运营商组网场景的起点事实，也是后面所有补强动作的前提。

T1：门户推送，插件接管

云 Portal 以插件形态与运营商光猫对接，不改变光猫的宽带接入与转发功能，只负责把认证页面推送到未认证的终端。对集成来说，这一段的验收点是：未认证终端是否被正常拦截并推送页面，已认证终端的转发是否不受影响。

T2：多通道核验

客人在页面上选择认证方式。云 Portal 支持短信、证件（含护照及港澳台居民证件）、微信等多通道核验。涉外酒店务必确认证件通道可用——外籍客人卡在认证这一步，是最容易被投诉的环节。通道异常处理与降级策略属于认证策略配置，由 EaaS 云管纳管。

T3：放行，同时写入四元组

核验通过后发生两件事：终端被放行上网；系统写入四元组（账号标识、终端 MAC、终端 IP、上线时间）并生成会话 ID。这两件事必须绑定——只放行不写入，客人体验完全正常，日志侧却是空的，这类故障在监控上几乎无感。

T4：行为采集与上传

终端上网期间产生的访问记录与流量数据被采集上传。采集侧要确认的字段是：手机号或证件号、MAC、IP、上线时间、访问 URL、上下行流量。字段缺失在这一段发生，后面无法补救。

T5：云端关联，按会话 ID 对齐

行为日志汇聚到云端后，云日审按会话 ID 与认证记录在云端关联。这一步是"认证"与"日志"真正合并的地方，也是追溯能力的来源：同一个会话 ID 下，认证记录与行为记录构成一条完整链条。场所本地不部署日志服务器，关联与留存都在云端完成。

T6：留存与导出

关联后的日志按滚动留存不少于 180 天保存，具体周期以属地公安机关要求为准。需要核查时，按手机号或按时间段导出完整行为清单。至此，一次上网过程才算走完全程。

时序上最容易断的三个点

按现场经验，T3 放行与写入不同步、T4 字段缺失、T5 会话关联失效是三处高发断点。三者的共同特征是都不影响客人上网，只能通过数据侧比对发现：认证成功数与会话落库数比对、字段空值率统计、抽样按手机号回溯——三条检查项建议写进验收清单。

176号令要求的是“可审计、可取证的完整证据链”。证据链不是某一段单独建成的，是从T0到T6每一段都不断、每一段都留得住。把这条时间线当作交付的主线，而不是把认证和日志当成两个模块分别验收，运营商代建项目才算真正把合规能力交到了位。

FAQ

Q1：运营商光猫为什么不能直接做实名认证？

A1：光猫承担的是宽带接入与转发，TR069 管理通道只覆盖 WAN 侧配置、WiFi 参数与固件升级，不具备用户身份核验与上网日志留存能力，需要由云 Portal 与云日审插件补齐。

Q2：云 Portal 会改变光猫的原有功能吗？

A2：不会。它以插件形态对接，不改变光猫的宽带接入与转发功能，只负责 Portal 页面推送、多通道核验与四元组写入。

Q3：认证记录和上网行为是怎么合到一起的？

A3：通过会话 ID 在云端关联，由云日审完成，场所本地不部署日志服务器。