酒店宾馆无线实名认证设备的选型，大部分人的关注点集中在价格、品牌和有没有通过公安认证这几个方面。这些当然是基本的筛选条件，但只靠这几个维度做决策，上线以后可能会遇到各种想不到的问题。下面讲的几个技术参数，是我们在实际项目中反复被坑过之后总结出来的，选型的时候值得多看一眼。

并发认证处理能力远比你想象的重要

很多设备的规格书上写的"最大支持用户数"是静态值，意思是系统里可以注册这么多用户。但酒店宾馆的认证场景跟企业办公不一样，酒店每天都有大量的新用户做首次认证，而且集中在下午入住高峰和晚上上网高峰这两个时间段。

真正需要关注的是"每秒并发认证数"——也就是设备在短时间内处理首次认证请求的能力。一个两百间客房的酒店，下午四五点钟入住高峰的时候，可能有二三十个房间同时在办理入住的客人开始连WiFi。如果设备的认证处理能力只有每秒一两个请求，高峰期就会出现排队现象，住客看到认证页面卡住或者超时。

建议在选型POC阶段做一个压力测试：模拟目标酒店规模的并发认证请求，看实际的处理时延和成功率。设备规格书上的数据跟实测数据之间的差距，有时候大得超出你的预期。

Portal重定向的兼容性和稳定性

这个参数看起来有点偏门，但它是酒店宾馆无线实名认证能不能被住客"感知为正常速度"的核心。目前主流的认证触发方式是HTTP重定向：住客连上WiFi后打开浏览器访问任意HTTP页面，网关把这个请求重定向到认证页面。

问题在于不同手机系统、不同浏览器对HTTP重定向的处理方式不一样。iOS设备对Portal探测有自己的机制，安卓不同厂商的定制ROM又有不同的实现。有些网关在iOS上重定向很顺畅，到了某些安卓手机上就不弹认证页面。这不是网关坏了，是兼容性没做好。

选型的时候最好能把目前市面上主流的一二十款手机机型拿来做一轮兼容性测试。如果供应商说"我们支持所有主流设备"但没有具体的兼容性报告，建议留个心眼。

HTTPS环境下的认证能力

前几年这个问题还不算严重，因为大部分网页还是HTTP的，重定向好做。但最近两三年HTTPS的普及率已经很高了，很多用户的手机浏览器默认首页都是HTTPS的。如果用户连上WiFi后第一个打开的页面是HTTPS的，传统的HTTP重定向方式就不起作用了——浏览器会拒绝中间人重定向。

这意味着认证网关需要支持一些更现代的技术手段来做认证触发，比如TCP拦截加临时HTTP连接建立、或者利用操作系统层面的Portal探测机制来做引导。选型时确认一下设备对HTTPS环境下的认证触发有什么方案，有没有落地的案例。

PMS对接的实际能力而不是"支持对接"四个字

基本上所有做酒店宾馆无线实名认证的厂商都会说"我们支持PMS对接"，但"支持对接"这四个字背后的实际差异可以非常大。有的厂商只是说可以做定制开发，有的厂商有现成的标准化对接模块但没有在目标PMS上做过验证，有的厂商确实做过对接但对接的深度只到"读取客人姓名"这个级别。

选型的时候建议问清楚这样几个问题：你们对接过哪几个PMS品牌？对接的字段有哪些（姓名、证件号码、房间号、入住时间、离店时间）？数据同步是实时的还是定时的？如果PMS换了版本你们的对接模块要不要重新开发？这些问题如果答得含糊，那"支持对接"就只是个标签。

本地冗余和离线运行能力

酒店宾馆的互联网出口出问题是常有的事，尤其是中小型宾馆用的那种运营商宽带，稳定性谈不上多好。如果认证网关的认证逻辑依赖云端服务，出口一断，住客就没法上网。这就形成了一个很糟糕的悖论：WiFi是好的，但因为认证服务器在云端连不上，所以住客用不了WiFi。

所以认证网关必须具备本地离线运行的能力：即使跟云端管理平台断了，本地的认证服务也能继续正常工作至少一段时间。这个本地运行能力包括认证流程、日志记录和通道放行。日志可以在链路恢复后再同步到云端，但不能因为链路断了就影响实时认证。

酒店宾馆无线实名认证的技术选型，贵的不一定对，便宜的不一定省。关键是要把上面这些实际运行中容易出问题的技术参数搞清楚，而不是只看牌子、看价格、看认证资质。上线以后一年不出问题，比前期省下的几万块钱值钱多了。 还有一个选型时值得关注的参数是设备的管理方式。有些设备只支持本地Web管理，出个问题只能远程到那台机器上去操作；有些设备支持云管理平台，可以在一个统一的后台管理所有门店的设备。对于连锁酒店或者有多家门店的宾馆来说，云管理平台的价值在做运维的时候会被放大很多倍。做系统升级、策略调整或者故障排查的时候，如果不能远程集中操作，要一家家门店跑过去，运维成本是不可接受的。