酒店 WiFi 实名认证系统上线之后不是就万事大吉了，日常运维中各种小问题层出不穷。有些是系统本身的 bug，有些是网络环境变化导致的，还有一些纯粹是操作层面的问题。把常见故障分类整理清楚，遇到的时候能快速定位，不至于手忙脚乱。

住客能连上 WiFi 但打不开认证页面

这是前台接到最多的投诉类型。客人说"连上了但没网"，其实不是没网而是 portal 页面没有弹出来或者加载失败。可能的原因有好几种：

DNS 解析异常是最常见的。portal 页面的域名如果用的是供应商提供的二级域名（比如 xxx.auth.example.com），而酒店的 DNS 配置有问题——要么指向了错误的 DNS 服务器、要么 DNS 缓存了旧的错误记录——就会导致页面打不开。快速验证方法是用手机浏览器直接访问 portal 页面的 IP 地址，如果能打开说明问题在 DNS 层面。

还有一种是防火墙或安全策略误拦截。某些企业客人的设备上装了安全软件或者公司策略限制了非白名单域名的访问，portal 页面的域名不在白名单里就被拦住了。这种情况下需要客人临时关闭安全软件或者在白名单里加上 portal 域名才能解决，对一线人员来说解释成本很高。

验证码收不到或收得很慢

短信通道的问题在酒店行业特别普遍。因为很多酒店用的是第三方短信服务商而不是直连运营商的通道，中间多了一层转发的延迟和不稳定性。

高峰期（晚上 8 到 11 点）短信延迟会明显增加，因为全国各地的短信量都在这个时间段达到峰值。如果供应商的通道容量不够用，排队等待的时间可能超过一分钟，等得不耐烦的客人就直接放弃了。

还有一种情况是手机号被运营商的垃圾短信拦截机制给拦截了。某些号段或者新开的号码容易被误判为营销号码，导致来自认证系统的正常验证码也被一起拦截。这种问题从酒店端很难排查出来，往往要靠客人自己去查短信拦截记录才发现。

认证成功后无法上网

这类问题的排查范围比前两类广得多，因为"不能上网"可能发生在网络链路的任何一层。

最常见的原因是 DHCP 地址池耗尽。如果认证系统的地址分配策略配置不当（比如租期太长不释放），大量已离线的设备仍然占着 IP 地址，新认证的设备拿不到可用 IP 就上不了网。重启一下 DHCP 服务通常能暂时缓解，但根本解决方案是调整地址分配策略和租期设置。

还有一类跟 NAT 或路由有关。某些认证网关在完成认证之后需要把用户的流量从"隔离 VLAN"切换到"业务 VLAN"，这个切换过程如果出了故障（比如 ACL 规则写错了、VLAN 间路由没配通），用户虽然显示"认证成功"但实际上还是在一个隔离的网络里，出不去外网。

系统本身报错或无响应

认证网关硬件故障、存储空间满了、日志进程崩溃、数据库连接池耗尽……这些属于系统层面的严重故障。特点是影响范围广——不是某个房间或某个客人的问题，而是所有正在尝试认证的人全部受影响。

处理这类故障的首要任务是快速恢复服务而不是精确定位根因。大多数认证网关都支持热备模式（主备双机自动切换），如果部署了的话主设备故障时备机会自动接管，住客感知不到明显中断。如果没有做热备就只能尽快重启设备或者联系供应商远程支持。

日志相关的问题

这类问题平时不影响住客使用，但在检查和审计的时候会暴露出来。比如日志突然停止写入（磁盘满或日志进程挂了）、日志时间戳不准确（NTP 不同步导致）、日志字段缺失（系统升级后格式变了但查询工具没更新）等。

建议每天早上花五分钟看一下认证后台的仪表盘：昨天的认证量是否在正常范围？日志文件大小增长是否符合预期？有没有异常的错误告警？这五分钟的检查能避免绝大多数"到了检查时候才发现问题"的尴尬局面。

建立故障处理手册

不管什么规模的酒店，建议维护一份简单的故障处理手册。不需要很厚，覆盖最常见的十种故障就够了：每种故障写清楚现象描述、可能原因（按概率排序）、排查步骤、解决方案和 escalation 条件（什么时候该升级找供应商）。

这份手册最大的价值不在于每次照着操作，而在于降低心理压力。前台小姑娘第一次遇到"客人说连不上网"的情况可能会慌，但如果有一份手册告诉她先检查哪三件事，她的应对效率会高很多，转给 IT 的信息也会更准确。