公共场所WiFi验收，最容易卡住的不是信号而是合规
做了几个酒店和商场的 WiFi 项目后复盘，真正让交付延期、迎检不通过的，往往不是覆盖和吞吐，而是实名认证和日志留存这两块。它们属于"设计阶段不规划、交付时必返工"的典型。
下面是我踩过的坑和落地时真正要盯住的点。各地网安对字段口径和留存周期会略有差异，最终以当地最新要求为准。
一、实名认证：核心是 Portal 认证 + 实名信息绑定
链路不复杂，但每一步都要落到实地：
flowchart LR A[用户连上WiFi] --> B[网关拦截未认证流量] B --> C[强制302跳转Portal认证页] C --> D{选择认证方式} D --> E[短信验证码] D --> F[微信一键登录] D --> G[身份证号+姓名核验] D --> H[酒店房号+姓名] E & F & G & H --> I[认证服务器校验] I --> J[绑定 身份↔IP↔MAC] J --> K[放行上网] K --> L[后续行为挂在该实名身份下]
用户连上 WiFi，网关把未认证流量拦下来，强制 302 跳到认证页；页面提供多种入口，用户完成一种认证后，网关把身份标识和 IP、MAC 的对应关系记下来，之后的上网行为全部挂在这个实名身份之下。
认证入口至少要做这几种，别只上一种：
- 短信验证码：最通用，手机场、餐饮都吃得开。
- 微信一键登录：OAuth 授权拿 openid，商场类场景转化率高。
- 身份证号 + 姓名核验：对接实名核验接口，政务、酒店刚需。
- 酒店房号 + 姓名：住客场景，和 PMS 联动最顺。
踩过的坑：某酒店项目上线时只做了短信验证码，验收前夜网安要求演示"非住客也能实名"，房号核验还没接，连夜对接 PMS 接口，差点误了迎检窗口。建议进场就把客户能提供的实名维度列全，缺接口的提前排期。
认证服务器建议独立部署，和 Portal 页面解耦。页面要按不同客户品牌换皮，认证方式还得不断加，解耦之后改页面不动认证逻辑，扩展新方式时只动后端。
实名绑定关系落库的表结构，参考下面这个：
CREATE TABLE user_auth_session ( id BIGINT PRIMARY KEY AUTO_INCREMENT, identity_type VARCHAR(16) NOT NULL COMMENT 'sms/wechat/idcard/room', identity_id VARCHAR(64) NOT NULL COMMENT '手机号/openid/身份证/房号', real_name VARCHAR(32) DEFAULT NULL, ip_addr VARCHAR(64) NOT NULL COMMENT '分配的上网IP', mac_addr VARCHAR(32) NOT NULL COMMENT '终端MAC', nas_ip VARCHAR(64) NOT NULL COMMENT '网关/AC地址', login_at DATETIME NOT NULL, logout_at DATETIME DEFAULT NULL, online_sec INT DEFAULT 0, KEY idx_ip (ip_addr), KEY idx_mac (mac_addr), KEY idx_login (login_at) ) COMMENT='实名认证与会话绑定';
二、日志留存是硬指标，不是可选项
按公安部 82 号令及公共场所无线上网安全管理要求，上网日志留存不少于 180 天，字段至少覆盖：实名信息、上下线时间、分配 IP、MAC、访问目标地址。
字段 |
说明 |
踩坑提醒 |
实名信息 |
手机号 / 身份证 / 微信 openid，至少一种 |
只存 openid 不关联实名也会被挑 |
上下线时间 |
登录与退出时间戳 |
异常掉线也要记，不能只记登录 |
分配 IP |
本次会话上网 IP |
同时存 IPv6 更稳 |
MAC 地址 |
终端 MAC |
必须和 IP 成对 |
访问目标 |
域名或 IP:端口 |
纯粹只记认证成功绝对不够 |
会话时长 |
在线时长 |
用于异常长连接审计 |
设计时盯三点：
- 全量采集。别只记认证成功，上下线、掉线、分配回收都要进库，否则检查时调不出完整链路。
- 加密存储。日志库落盘加密，访问走最小权限，防止被篡改或泄露——这既是合规线也是安全底线。
- 能按标准格式导出。最好做成一键导出，检查时现场就能调出最近一段时间的记录，别临时写 SQL。
一键导出脚本参考（按公安常用 CSV 口径）：
import csv, pymysql, datetime def export_recent(days=7, out=None): conn = pymysql.connect(host='auth-db', user='audit', password='***', db='wifi_portal', ssl={'ca': '/etc/ssl/ca.pem'}) sql = """SELECT identity_id, ip_addr, mac_addr, nas_ip, login_at, logout_at, online_sec FROM user_auth_session WHERE login_at >= DATE_SUB(NOW(), INTERVAL %s DAY)""" with conn.cursor() as cur: cur.execute(sql, (days,)) rows = cur.fetchall() out = out or f"audit_{datetime.date.today()}.csv" with open(out, 'w', newline='', encoding='utf-8-sig') as f: w = csv.writer(f) w.writerow(['实名标识','IP','MAC','网关IP','上线','下线','时长(秒)']) w.writerows(rows) print(f"exported {len(rows)} rows -> {out}")
三、安全防护要在线跑，不是摆设
网关得具备入侵防御、恶意 URL 过滤、异常流量监测，并且规则库持续更新。这部分在迎检时会被核实是否真的在线运行，关着或没更新都算不达标。
建议把规则库版本和最后更新时间也写进巡检记录，检查时直接翻。
四、交付前自测清单
四点全过，迎检才有底气：
- 实名方式覆盖多种（短信 / 微信 / 身份证 / 房号至少两种以上）
- 日志能留存满 180 天，且一键导出可用
- 防护策略处于在线运行状态，规则库为近期版本
- 有值班响应机制，异常能及时处置
五、如果认证服务上云，几个能省事的点
落到阿里云上，认证服务器用 ECS 独立部署，日志归档进 OSS 并开启服务端加密，检索和夜间巡检可用日志服务（SLS）接一份；入口防护可叠加云防火墙做 URL 过滤和异常流量识别。这套组合省掉了自己维护加密存储和备份的活，但要确认留存周期和导出格式仍满足当地网安口径，别因为上云反而丢了字段。
