OpenWRT 下实现 Portal 认证：调试要点与常见坑

OpenWRT 这类开源路由器系统，用 Captive Portal（ captive portal 强制门户）机制就能自己做 Web 认证，不必依赖商用控制器，适合小场点与 DIY 网关。

一、原理

未认证终端连上网络后，发出的 HTTP 请求被 iptables 规则拦截并重定向到一个本地登录页；用户输账号（或点”同意上网”）后，网关把该 MAC/IP 加入放行列表，之后流量正常转发。核心就是”未认证→拦截→认证→放行”的链路控制。

二、常见实现

轻量方案如 NoDogSplash：规则简单、资源占用小，适合咖啡馆、小店”点击同意”式放行。功能更全的方案如 CoovaChilli：可与外部 RADIUS/Portal 对接，支持账号、时长、计费，接近商用体验。两者都跑在 OpenWRT 上，用 iptables + 轻量服务进程实现，对路由器性能要求不高。

三、落地注意

HTTPS 站点无法被”注入”重定向，需靠 DNS 拦截或首次 HTTP 探测触发；放行列表按 MAC 或 IP 管理，超时自动回收；多 SSID 时把访客 SSID 单独走 Portal、内网 SSID 直连，隔离更干净。小网络用 OpenWRT + 轻量 Portal 性价比很高，但要考虑并发与稳定性上限。

一、调试必须分层，别一上来就改配置

按「终端能拿到地址 → 能解析域名 → 能访问放行白名单 → 被重定向到登录页 → 认证后放行」五层逐段验证，每段都有明确判据：地址看 DHCP 日志、解析看 dig、重定向看浏览器是否跳到你的登录页、认证后看是否能出网。这样能把「不弹窗」「弹窗不通过」「过了不能上网」三类问题分开，不会互相干扰。

二、HTTPS 这一层的现实

浏览器默认优先 HTTPS，透明重定向对加密流量无效，所以常见做法是：放行少量 HTTP 探测地址，让客户端在连通性检测时先命中 HTTP 从而触发跳转；或在登录页用引导方式提示用户切换。效果上，个别终端仍会出现「连上但不弹任何页面」，解决办法是在 DNS 层做提示，或对这类终端提供口令直连通道。

三、三个高频坑

四、稳定性与可维护

嵌入式资源有限，客人集中认证时可能 CPU 打满。实践建议：给放行列表设上限与超时回收、限制单 IP 的认证频率、把日志分级落盘、配置与放行列表自动备份、并为「路由器重启后策略自动恢复」这件事写一条自检（很多人重启后策略全丢）。