简介：一套基于 ROS 热点（Hotspot）体系的网页认证界面源码包，面向需要为 MikroTik 路由器部署自定义认证登录页面的网络管理员、运维人员及 ROS 学习者。整个压缩包共包含七十一个文件，核心是十九个网页文件、二十一张 JPG 图片、十八张 PNG 图片和八个动态 GIF 图，另含样式表、脚本及协议定义文件，整体约九十五 KB，体积小巧、目录清晰，可直接替换 ROS 默认登录、注销、错误、重定向等页面，快速实现品牌化认证界面。目前已有三百零七人浏览学习。资源亮点在于完整覆盖了热点认证的前端交互逻辑：登录表单通过 MD5 脚本对密码加密传输，包含登录、注销、广告跳转、强制注销等多种页面场景，并附带 WISPr 协议参数定义文件，便于对接外部认证服务器或调整认证流程；界面素材以深色背景、按钮、横幅图片为主，便于二次修改并嵌入标识或服务条款。对希望理解 ROS 网页认证页面组成、定制公共无线网络门户的读者来说，这是一份可直接落地、按需调整的实用模板。

1. ROS Web 认证不是一扇门，而是两道门：先把整体地图画出来

先说清楚一件事：这里的 ROS 指的是路由器上的 RouterOS，不是机器人操作系统。把「ROS Web 认证」当成一个整体去复习时，最常出现的误区是只盯着某一个功能猛看，比如只研究登录页怎么写。梳理下来会发现，它实际上是「管理面」和「用户面」两条完全独立的链路：一条是管理员打开浏览器登录设备 Webfig 的管理认证，另一条是访客连上 Wi-Fi 后被重定向到认证页的 Hotspot 访客认证。前者管你能不能进设备，后者管你能不能上网。本文按「端口与账号 → Hotspot 链路 → 认证方式 → 易错点 → 自查清单」的顺序展开，适合正在备考认证、准备项目验收、或者要给公司访客网络做一次全面体检的人。把这两道门拆开看，后面所有参数都不会乱。

2. 管理面认证：Webfig 登录、HTTPS 与用户权限组的复习重点

2.1 服务端口三件套：www、www-ssl、来源限制

管理面 Web 认证的核心配置，全部集中在 IP 服务这张表里。默认情况下 Webfig 的 HTTP 端口是 80，HTTPS 端口是 443。但实际部署时很少有人真的把 80 留给管理面，因为 Hotspot 认证页也要占用 80 做重定向，两者在同一个接口上是冲突的。所以复习这一块时，心里要有一个默认结论：管理面的 HTTP 端口要么改掉，要么把管理面放到独立的管理网段。

/ip service set www port=8080 address=192.168.88.0/24 disabled=no /ip service set www-ssl port=8443 address=192.168.88.0/24 disabled=no /ip service print

这段命令里真正需要理解的是address这个参数。它表示只允许来自哪些网段的 IP 访问该服务，配置完成之后，不在范围内的地址会被直接拒绝。很多人复习时只记住改端口，忘了address本身也是一道访问控制的闸门。如果写成address=192.168.88.0/24，而管理员自己坐在一个 10 网段的办公室里，那第一次提交配置的瞬间，远程的 Webfig 就再也打不开了。端口是给外部看的入口，来源限制是给内部设的围栏，两个参数要一起看。

最容易忽略的是disabled=no这一步。新装或备份恢复时，服务默认可能是启用的，但如果哪次加固时被人执行过disable，Webfig 虽然还在服务列表里，实际上已经对浏览器关闭了。查这种问题不要只看端口通不通，先print看状态列。真正排查时最有效的做法是：先用默认 80 确认能登录，再改端口；改完端口不要立刻关掉旧端口，留一个会话做退路，确认新端口可用后再收紧。

2.2 账号与权限组：为什么不能一直用 admin

Webfig 登录认证使用的账号体系和管理员账号是同一套。新的设备开机后只有一个用户，用户名 admin，很多人在快速搭建时连密码都懒得改。放在内网环境里也许短期没事，但只要设备有公网可达的接口，这就是一个随时可能被扫到的后门。复习时可以把账号体系拆成两层来记：用户是账号本身，用户组是权限集合。默认存在的组有 full、write、read、reboot 等，full 拥有全部策略权限，read 只能看不能改。

/user group add name=lowpolicy policy=read,reboot,winbox /user add name=ops password=strongpass group=lowpolicy /user set admin disabled=yes

这段命令演示的是最小权限思路：先建一个只包含读和重启权限的组，再建一个属于该组的账号，最后把 admin 禁用掉。policy参数里可选的权限项很多，常见的有 ssh、telnet、ftp、winbox、web 等登录方式，以及 read、write、policy、test 等功能权限。这里的细节在于：如果一个组没勾选 web，那么该组下的用户即使账号正确，也无法通过浏览器登录 Webfig。这属于权限策略里的隐形门槛，容易在「账号密码都对却登录失败」的排查中被忽略。

实际排错时，登录失败的记录可以在日志里看到。/log print where topics~"user"会输出账号登录相关条目，能看到是密码错误、账号被禁用、还是来源被拒。还有一种情况是locked状态，多次失败尝试后账号会被系统临时锁定，这时候账号显示是禁用的，改密码也没用，要手动解除锁定。权限组复习的关键记忆点是：一个用户能做什么，等于「账号状态」加「所在组的策略交集」加「服务来源限制」三者叠加，缺一条都登不进。

2.3 管理面 HTTPS 认证链：证书生成与浏览器信任

很多环境对 Webfig 的要求已经不止是「能登录」，而是「不能明文传输密码」。RouterOS 支持给 www-ssl 服务单独指定证书，使管理面走 HTTPS 加密。这里有一个常见的理解偏差：开启 HTTPS 不一定要向证书机构购买证书，设备自己生成的证书也能完成加密，只是浏览器不认识它，会弹安全警告。

/certificate add name=router-cert common-name=router.lan days=730 key-size=2048 /certificate sign router-cert /ip service set www-ssl certificate=router-cert disabled=no

第一条命令创建证书请求，第二条命令对证书进行自签名，第三条把证书绑定到 HTTPS 服务。common-name是证书里记录的主机名，浏览器检查证书时会对域名做比对。如果在地址栏输入 IP 访问，域名不匹配会导致警告更严重。理解这个流程的意义在于：HTTPS 链路「加密成功」和「浏览器信任」是两件事，前者由证书完成，后者需要客户端信任根证书。给固定办公机批量部署时，可以把自签证书导入系统信任库，以后打开 Webfig 就不会再弹警告；如果只是临时管理，选择「继续访问」也不影响实际使用。

这里还要注意一个先后问题：启用 www-ssl 不等于 www 自动关闭。很多管理员开了 HTTPS 后忘了关 HTTP，设备仍然同时暴露着一个明文管理口。等安全扫描发现端口 8080 还在响应时，才意识到两条腿都穿着裤子，其实一条都没系上。正确的加固顺序是：生成证书 → 开启 www-ssl → 用浏览器确认能通过 HTTPS 登录 → 再关闭 www 服务或把它的来源限制缩到最小。

3. 用户面认证：Hotspot 从接口到认证页的完整链路

3.1 先搭通道：地址池、DHCP 与 DNS 的先后顺序

Hotspot 的完整链路并不是从/ip hotspot add开始的，而是从用户设备能不能正常拿到 IP 讲起。访客手机连上 Wi-Fi 后，首先要通过 DHCP 获得一个地址，然后 DNS 查询要能走通，最后访问任意 HTTP 网站时被路由器拦截并重定向到认证页。这三个条件缺一个，认证页就弹不出来，用户只会看到「已连接但无法上网」。

/ip address add address=192.168.50.1/24 interface=bridge1 /ip pool add name=hs-pool ranges=192.168.50.10-192.168.50.200 /ip dhcp-server add name=hs-dhcp interface=bridge1 address-pool=hs-pool lease-time=10m /ip dhcp-server network add address=192.168.50.0/24 gateway=192.168.50.1 dns-server=192.168.50.1

这个顺序是固定的：地址池是 IP 的源头，DHCP 从池子里分配地址，DHCP network 告诉客户端网关和 DNS 是谁。其中最关键的是dns-server=192.168.50.1，它必须指向路由器自己。因为 Hotspot 的认证拦截本质上是靠 DNS 重定向实现的：未认证用户请求任何域名时，路由器会返回自己的 IP，于是浏览器访问的目标变成了认证服务器本身，认证页才能被加载出来。如果这里写成了外部 DNS 如 8.8.8.8，用户也能拿到 IP，但请求直接上传，不会被拦，认证页就永远不出现。

lease-time=10m是个贴近实战的参数。访客网络的地址池通常不大，如果租约时间太长，已经离开的人还会占用地址，导致新进来的人拿不到 IP。把租约缩短到 10 或 15 分钟，可以在不增加配置负担的情况下提高地址周转率。地址池的网段也要注意和管理网段分开，避免访客通过内网路由探测到核心交换设备。如果ranges写成了和管理网段重叠，认证成功之后用户拿到的地址会产生路由歧义，排查时非常费劲。

3.2 Hotspot 服务器本体：接口、地址池与 profile 参数

通道准备好之后，Hotspot 本体的配置其实非常短。核心命令只有一条：把接口加进 Hotspot，指定地址池和配置模板。但这一条命令背后的动作是「把该接口上所有未认证流量接管」，影响面很大，所以复习时要连 profile 一起看。

/ip hotspot add name=hotspot1 interface=bridge1 address-pool=hs-pool profile=default /ip hotspot profile set [ find name=default ] login-by=cookie,http-chap html-directory=hotspot-page

/ip hotspot add把 bridge1 变成认证边界，所有通过这个接口的流量在未认证前都会被策略控制。指定address-pool=hs-pool可以让认证后的会话地址从一个专门的池子里分配，而不是继续使用 DHCP 给的地址。profile参数绑定了登录方式、模板目录等批量配置。第二行命令修改的是默认模板，login-by=cookie,http-chap表示允许两种登录机制并存，html-directory=hotspot-page指定自定义登录页的存放目录。

认证页触发机制在手机和电脑上表现不同。手机连上 Wi-Fi 后会自动弹出网页，是因为系统会主动访问一个用于网络连通性检测的 HTTP 地址，路由器把那个请求重定向到登录页，系统检测到重定向就知道该弹认证窗了。电脑上没有这个过程，需要用户自己打开浏览器访问任意 HTTP 网站才能触发重定向。很多现场反馈「手机能弹，电脑不弹」，本质就是触发机制不同。

/ip hotspot里还有个重要参数one-host，默认开启。它的含义是每个 MAC 地址只能建立一个会话，防止用户把认证后的连接分享给其他设备。但代价是手机开了热点分享时会被切断，需要重新认证。如果场景允许共享网络，可以关闭这个参数。keepalive-timeout决定用户无流量多久后自动断开会话，默认值是几分钟到几十分钟不等，这个参数直接影响地址池的占用周期。

3.3 用户、套餐与限速：账号怎么建才不失控

Hotspot 的用户体系是独立的，和前面讲的管理员账号完全不搭界。访客账号的创建落在/ip hotspot user，限速和并发策略落在/ip hotspot user profile。两者分开配置，用户只负责账号本身，策略模板控制上网质量。

/ip hotspot user add name=guest001 password=passw0rd profile=vip limit-bytes-total=1G /ip hotspot user profile add name=vip rate-limit=10M/10M shared-users=2 session-timeout=30m

rate-limit=10M/10M的格式是「上传/下载」，注意不要写反。很多配置看起来上传限速没生效，其实是把顺序理解反了。shared-users=2表示同一个账号最多允许两个终端同时在线，一个账号给一家人用就是靠这个实现的。session-timeout=30m是单次会话时长，到时间后强制下线，重新登录可再用。limit-bytes-total=1G限制总流量，适合给临时访客一个明确的「用完即止」配额。

流量限制有三种写法：limit-bytes-total限制总字节数，limit-bytes-in和limit-bytes-out分别限制下载和上传方向。如果只想限制访客下大文件，可以只设limit-bytes-in。这些参数在到期后不会自动删除用户账号，只是流量额度耗尽后无法继续建立会话。想要真正的「到期失效」，需要配合 scheduler 定时禁用账号，或者写脚本扫描创建时间超过 N 天的用户批量禁用。

实际运维时最常见的失控场景是：建了一个临时访客账号，用完忘了删，长期留在用户表里。Wi-Fi 密码本身有被传开的可能，如果访客账号也长期有效，等于给非授权用户开了一个永久入口。复习时可以顺便养成习惯：账号创建时就在名称里带上日期，比如guest-0415，后续清理只看名字即可定位过期账号。

4. 认证方式与登录页定制：Cookie、试用、试用期限与参数对比

4.1 五种登录方式对比表

Hotspot 登录方式由login-by参数控制，它决定了未认证用户能通过什么途径通过认证。这里的关键是不要把所有方式混为一谈，每种方式在安全性、便利性和适用场景上的取舍完全不同。

正常场景下首选 http-chap，它通过挑战应答机制认证，密码不会在网络上明文传输。http-pap 虽然是明文，但作为临时排查手段仍有存在价值——当登录页调不出来时，临时切到 pap 模式可以判断是 CHAP 计算环节出了问题，还是模板本身有 bug。cookie 模式的实质是浏览器在认证成功后拿到一个带有效期的凭证，关掉浏览器再打开也不需要重新输密码。cookie-lifetime默认时间可以改，到期后自动失效，适合不想反复输入的访客。

mac-cookie 是最容易被高估的模式。它的逻辑是记录设备 MAC 地址，下次同一台设备来了直接放行。好处是「连上就能用」，坏处是 MAC 地址可以被工具伪造，而且它只能识别设备，识别不了人。放在办公室固定工位还行，放在对外营业场所等于免费送网。trial 模式则在完全不建账号的情况下允许用户试用一段时间，时长由trial-uptime控制。如果亲测发现用户试用结束后还能继续上网，优先怀疑是不是 cookie 和 trial 同时开启导致凭证互相覆盖。

4.2 登录页模板：变量、表单提交与回跳

登录页是用户能直接看到的唯一界面，也是复习 Hotspot 时最容易被细节绊倒的地方。RouterOS 的登录页本质是放在路由器文件系统里的 HTML 模板，模板里可以使用特定变量，路由器在渲染时会把变量替换成实际值。默认模板目录是hotspot，自定义目录由html-directory指定。

<form name="login" action="/login" method="post"> <input name="username" value="$(username)"> <input name="password" type="password"> $(if error)<span style="color:red">$(error)</span>$(endif) <input type="hidden" name="dst" value="$(dst)"> <button type="submit">登录</button> </form>

这段模板对应的是最精简的登录逻辑。action="/login"是固定的提交地址，改成其他路径会直接失败。$(username)和$(password)是用户输入的字段，RouterOS 会把表单数据交给认证处理流程，用户名密码从这个模板的 name 属性取值，不能随意改名。$(if error)是模板条件语法，有错误信息时才显示红色错误文字。$(dst)是回跳目标地址，用户原本想访问的网址会通过这个隐藏字段带进认证请求，认证成功后自动跳回原页面。

dst参数特别容易在定制模板时被删掉。很多运营人员会觉得它没什么用，删掉后页面干净一些。但用户会收到什么体验？在认证页填完账号密码点登录，一闪之后停在空白认证页上，用户不知道发生了什么，只能手动重新输入网址。保留dst并把它的值写回隐藏字段是最基础的体验底线。实站时还有一个判断技巧：模板目录用 Winbox 从 Files 里上传时，目录结构不能随便改，login.html必须放在指定目录根下，放错层级页面直接 404。

4.3 试用、白名单与到期续费：运营向的三个细节

运营场景里还有三个细节，考试和实战都容易考到。第一个是试用期参数。/ip hotspot profile set default trial-uptime=10m就是给每个未认证设备 10 分钟免费试用。注意试用逻辑是按设备算的，不是按账号算，同一台设备用完一次后不会自动刷新。假如用户清理浏览器缓存再回来，有可能重新获得一次试用，这是机制本身的特性，不能当 bug 查。

第二个是免认证白名单，叫做 Walled Garden。它的作用是让某些目标地址在未认证时也能访问，典型场景是：用户还没登录就让他看到运营商公告、App 下载页面或者特价广告。

/ip hotspot walled-garden add dst-host=portal.example.com /ip hotspot walled-garden add dst-host=*.example.com action=allow

这段命令把指定的域名或域名后缀加入免认证访问列表。dst-host=*.example.com可以匹配主域名下的所有子域名。这个功能放在网络里是折中方案：既要锁网，又不能把用户所有访问都掐死。最容易踩坑的是白名单里的域名只能精确写，如果用户访问的页面里引用了其他域名的资源，比如 CSS 和图片在另一个域名，那这些资源仍会被拦截，页面会以「半残缺」状态渲染出来。

第三个细节是到期续费。Hotspot user 本身不支持「到期时间」字段，想要真正实现按天/按周售卖，通常用 scheduler 定期跑脚本：检查所有 hotspot 用户的创建时间，超过设定天数的自动禁用。脚本判断用户状态是否disabled而不是删除，这样用户可以到前台续费，重新启用即可生效。这套策略比手动逐个清账号省力得多，也是把 Hotspot 从「临时搭建」推向「日常运营」的分水岭。

5. 易错点清单：ROS Web 认证最常踩的 5 个翻车现场

5.1 管理面 www 与 Hotspot 抢 80 端口

易漏点：Webfig 的 HTTP 服务默认占用 80 端口，Hotspot 的认证重定向也依赖 80 端口，两套功能在同一接口上会冲突。

为什么容易漏：因为配置前后跨度大。很多人先是正常用 80 登录管理界面，后来才加 Hotspot，加完发现登录页弹不出来，第一反应是去查防火墙规则，不会想到是端口被占了。如果管理面 Webfig 还挂在 80 上，Hotspot 的重定向请求会被设备当作管理服务请求处理，用户访问任意 HTTP 网站拿到的是 Webfig 的登录界面，而不是 Hotspot 认证页。

怎么补：把两者分开。推荐做法是管理面的 HTTP 端口改成 8080 或 8443，Hotspot 继续用 80 做重定向。改完在浏览器里访问新端口的 Webfig 测试登录正常后，再做 Hotspot 的验证。如果设备有多个接口，也可以让管理面只监听管理网段接口，Hotspot 只挂在业务接口上，用接口隔离代替端口隔离。

5.2 改端口或加来源限制后自己先失联

易漏点：远程操作时，执行完/ip service set www port=8080 address=192.168.88.0/24之后，当前 SSH 连接不会断，但浏览器里的 Webfig 已经进不去了。

为什么容易漏：因为命令本身执行成功，没有报错，人在潜意识里会默认「配置已生效」。但生效和可达是两件事：端口改了，原本 80 的页面已关停；来源限制加了，自己 IP 不在白名单内。这两个条件里只要中一个，远程管理就断线了，而且断了之后在办公室外很难救回来。

怎么补：养成「先开后关」的习惯。改端口前先用注释记住新端口，改完不急着关旧服务，开一个新会话验证新端口可达，确认没问题再关旧端口。加来源限制时，先把当前出口 IP 以ip cloud或外网地址查询方式确认在允许范围内，再应用address参数。教训是：永远不要在一次远程会话里同时改端口和来源限制两件事，一次只改一项，每项确认后再做下一项。

5.3 DHCP 的 DNS 没指向路由器，认证页死活弹不出来

易漏点：认证页无法弹出时，检查 DHCP 配置里dns-server的值，它必须指向路由器自己的地址，而不是任何外部公共 DNS。

为什么容易漏：因为配置 Hotspot 的直觉是把「上网」和「域名解析」分开看，很多人认为给客户端下发一个外部 DNS 是更快的方案。但实际上 Hotspot 就是靠 DNS 接管来实现重定向的：客户端请求www.example.com，被路由器应答为「去访问 192.168.50.1」，然后载荷落到认证页。如果 DNS 指向外部服务器，域名解析绕过了路由器，重定向根本没机会触发。

怎么补：确认/ip dhcp-server network里的dns-server字段写的是网关 IP，而不是 8.8.8.8 之类的外部地址。改完 DHCP 配置后，客户端设备要退出 Wi-Fi 重新连接，让老配置的租约过期才能拿到新 DNS。验证方法很简单：连上 Wi-Fi 后在浏览器访问任意 HTTP 网站，能弹出认证页即成功；如果页面能正常打开不跳转，说明 DNS 逃逸了。

5.4 认证成功却回不到原目标页：dst 参数被砍

易漏点：用户输入账号密码认证成功，却落在一个空白认证页上，而不是原本想访问的网站。原因多半是模板里删掉了dst隐藏字段。

为什么容易漏：定制登录页时，看表单代码并排着几个字段，dst既没有可见的页面效果，删掉也不会报错，于是顺手下掉了。但它是携带「用户初始访问地址」的字段，认证完成后路由器要靠这个值跳转回去。没有它，RouterOS 只能把用户扔到认证服务器首页。

怎么补：模板里保留这一行：<input type="hidden" name="dst" value="$(dst)">。调试时也可以通过手动构造 URL 验证：访问http://192.168.50.1/login?dst=http://www.example.com，认证成功后观察浏览器地址栏是否跳回 example。这类问题不需要大改，加回字段重新上传模板即可。模板上传后要确认html-directory指向的是新目录，否则改了半天，系统读的还是旧文件。

5.5 mac-cookie 被当成高安全方案

易漏点：对外访客网络开启mac-cookie之后，设备第二次连接免密放行，运营方容易把这种模式当成「安全又方便」，实际上它的安全等级很低。

为什么容易漏：MAC 地址对普通用户来说不可见、不可改，看起来是个稳定的身份标识。但在技术层面，MAC 地址在无线链路里是明文传输的，抓包工具可以直接看到合法设备的 MAC，再伪造一个相同 MAC 的虚拟接口，就能在未授权的情况下复用该设备的免认证资格。更常见的场景是用户把手机热点打开，热点转发了其他设备的数据，多媒体台上显示的是手机 MAC 而实际用的是一屋子人。

怎么补：区分场景再决定是否启用。室内固定工位、可控人员进出的办公区，mac-cookie合理且省心。商场、咖啡厅、展厅这类完全开放的区域，改用cookie或http-chap强制每次都输入账号密码更稳妥。如果一定要用mac-cookie，把mac-cookie-lifetime调短，并配合one-host限制单设备会话数，降低被借用的风险。

6. 复习自查：按这个顺序走一遍，基本不会漏

复习到最后，建议不要按知识点零散记忆，而是按「一次完整配置的先后顺序」建立操作型记忆。以下清单覆盖管理面和用户面的核心动作，照着走一遍可以快速暴露知识盲点。

配完再做一轮快速验证。先在命令行里发一个 HTTP 请求，看是否有 302 重定向：

curl -I http://example.com curl -I http://192.168.50.1/login

第一条命令在不认证时应返回重定向，第二条命令应返回 200。两条都符合，说明 Hotspot 拦截链路是通的；反过来的话，重点查 DNS 有没有外逃。再模拟一次手机行为：断开 Wi-Fi 重连，触发系统连通性检测，确认认证页弹出，最后用账号登录并观察回跳。

记得有次给某公司搭访客网络，调了快半小时，认证页在电脑上就是弹不出来。后来把 DHCP 租赁信息打出来，发现客户端拿到的 DNS 是外网地址，改掉后秒弹。从那以后我每次配 Hotspot 都强制走一遍上面的清单，从地址池开始一项项勾，再不用在日志里原地打转。希望这份梳理和清单能帮你把「ROS Web 认证」这个方向的坑提前填平。

本文还有配套的精品资源，点击获取