酒店WiFi认证Portal认证的设计里，有一个环节经常被忽略：住客还没认证的时候，网络应该放行什么。大多数人的直觉是"没认证就不给上网"，但实际运营中，未认证状态下的网络策略，直接影响认证流程能不能顺畅走完，也影响住客在特殊情况下能不能找到帮助。这一块想清楚了，认证体验会顺很多。
先讲一个最基本的事实：住客要完成认证，就得能访问到认证页面。也就是说，认证服务器和认证页面的地址，在住客未认证的时候必须是可以访问的。这看起来是废话，但在实际项目里，偶尔会出现认证页面地址被网络策略挡住的情况，结果就是住客连上WiFi，什么页面都打不开，包括认证页面。所以未认证状态的放行名单里，第一项一定是认证系统自身的访问路径。
第二项要考虑的，是住客在紧急情况下需要的入口。酒店场景里，住客可能遇到各种问题：找不到前台电话、WiFi连不上想求助、需要看酒店的入住须知。这些需求在未认证状态下如果完全被掐断，住客就只能干瞪眼。比较稳妥的做法，是放行酒店自己的信息页面或者紧急联系页面，让住客在没认证的时候也能看到酒店的基本信息和联系方式。这一条做得好，前台接到的"我上不了网怎么办"的电话都能少一些。
第三项是合规相关的考虑。很多酒店在认证页面上展示合规声明，说明上网需要实名认证、日志留存等要求。未认证状态下，这些信息页面应当是可以被访问的，这样住客在决定认证之前，能先了解为什么要认证。一些酒店还会把当地监管要求的提示放在这一步，让住客心里有数，减少认证过程中的疑虑。
放行名单定下来以后，剩下的流量在未认证状态下默认是拦截的。这里要注意一个原则：放行要白名单化，不能图省事把整段地址都放开。放行范围控制得越精确，网络的安全边界就越清晰。比如放行认证服务器和酒店信息页面，就只放行这两个具体的地址，而不是放开一大片。白名单化的好处是，即使有人想在未认证状态下钻空子，也没有可乘之机。
还有一个跟无感知认证相关的细节。住客在认证有效期内再次连接，走的是无感知放行，不弹页面。这种情况下住客同样会经历"没看到认证页面"的阶段，但网络实际已经通了。酒店运营人员要能区分这两种状态：一种是未认证、只放行白名单；另一种是已认证、全部放行。区分清楚了，处理住客疑问的时候才不会搞错方向。
另外，未认证状态下的放行策略，要考虑跟酒店的其他业务隔离。比如酒店的办公网络、后台管理系统、监控系统，这些系统通常不应该出现在住客未认证可访问的范围内。放行名单里只放住客认证和住客服务所需的最小集合，其他一律不放，这是酒店WiFi认证Portal认证方案里网络隔离的基本要求。
酒店WiFi认证Portal认证之前放行什么，答案可以概括成三句话：放行认证本身需要的路径，放行住客紧急求助和获取信息的入口，放行合规声明等必要提示。其余流量在白名单之外。把未认证状态设计成"够用、可控、不裸奔"，认证流程才能顺畅，住客体验和网络安全才能兼顾。
放行名单里具体放什么，可以列一个参考清单。第一是认证系统自身的地址，包括认证页面、认证服务器交互所需的地址；第二是网络基础服务，比如地址解析（DNS）相关的服务，终端要能正常解析域名才能打开认证页面；第三是酒店自己的信息页面和紧急联系入口；第四是必要的合规提示页面。这个清单之外的内容，未认证状态下默认不放行。清单要写成文档，实施的时候逐项核对，别靠口头交代。
白名单的粒度也要注意。同一个地址段里如果既有需要放行的服务，又有不需要放行的内容，尽量精确到具体地址，不要图省事放一整段。酒店网络里设备不少，办公系统、后台管理、监控这些都不应该出现在住客未认证可访问的范围内。区域之间做好隔离，住客未认证时能碰到的东西越少，酒店的网络就越安全。
还有一类设备要单独考虑：哑终端。酒店的机顶盒、智能设备、办公设备这些不方便做浏览器认证的终端，通常走白名单或者哑终端认证机制，认证通过以后长期在线，不需要反复认证。这类设备的白名单策略要跟住客的未认证放行策略分开管理，别混在一起。哑终端该放的放，住客该拦的拦，两条线各管各的，管理才清晰。
未认证状态的放行策略定好以后，要写进酒店的网络管理制度里，并让相关运维人员知道。哪天网络策略调整，先看看会不会动到认证链路和未认证放行名单，别为了堵一个漏洞，把认证流程也堵死了。