企业无线网络投入使用了，AP也装好了，但用户一连上WiFi，Portal页面要么弹不出来，要么弹出来了点不了登录——这是很多项目上线后遇到的经典场景。集成商到现场排查，硬件全在线、信号满格、后台配置也看不出明显问题，但就是体验不对劲。以下从真实项目里总结出几个最容易忽略的原因，供排查时参考。

最常见的问题是DHCP分配延迟。用户连接SSID后，终端需要先从DHCP服务器拿到IP地址，才能拉取Portal页面。但有些设备的DHCP客户端行为比较保守，会先等几秒试探网络连通性，再去申请地址。如果DHCP响应慢，用户就会觉得连上WiFi之后页面半天不出来，反复尝试反而更容易出问题。解决这个问题可以在AC或网关侧把DHCP租约时间调长，同时确认DHCP地址池的地址数量够用——用户数量超过地址池大小时，新用户会拿不到地址，Portal页面自然出不来。

第二个容易被忽略的原因是浏览器拦截。现在的手机浏览器为了省流量和保护隐私，默认会拦截很多弹窗和重定向。用户在连锁酒店或商场连WiFi时习惯了自动弹出Portal，但如果在企业环境里，手机系统或者安全软件的设置不同，可能把认证重定向拦截掉，用户根本不知道有Portal页面这回事。需要提前在终端侧做一些兼容性测试，确认主流机型的默认设置下Portal页面能否正常弹出。如果无法控制终端配置，就需要在方案设计时考虑备选认证方式。

第三个原因是DNS配置错误。Portal认证的工作原理是基于IP地址的强制重定向——用户访问任何网站时，网关会把请求拦截下来，302重定向到Portal页面。但如果DNS解析出了问题，用户终端可能会先把域名解析成一个被劫持的地址，或者干脆解析失败，导致重定向链断裂。最直接的排查方式是在终端上ping一个外网域名，看返回的IP是不是Portal网关的IP。如果不是，先检查网关的DNS中继配置是否正确，再确认是否有人在路由器或防火墙侧做了异常的DNS转发。

第四个坑是Portal服务器本身性能不足。企业在选型时通常关注Portal页面的样式和功能，但容易忽略服务器端的并发处理能力。早高峰几百人同时进入大楼，30秒内所有人同时尝试连接无线网络——这个瞬间的认证请求量是平时的几十倍。如果Portal服务器只有单节点，没有做负载均衡，高峰期就会出现页面加载缓慢、认证超时、甚至服务器直接过载崩溃的情况。这个问题在项目测试阶段很难发现，因为测试场景的并发量远低于实际生产环境。建议在方案设计阶段做一轮压力测试，把认证系统的真实并发上限摸清楚。

还有一个不太容易想到的原因是证书问题。现在越来越多的企业要求Portal页面使用HTTPS，防止认证信息被中间人截获。但自签名证书在移动设备上会触发安全警告，用户看到"证书不可信"的提示往往不敢继续点击。解法是使用企业内部私有CA颁发的证书，在所有终端上提前批量推送根证书，这样既能保证加密，又不会触发浏览器的安全警告。