企业官网建设流程全解析

简介：ROS Web认证是RouterOS中用于公共无线网络接入控制的重要功能，常应用于咖啡厅、图书馆等透明认证场景。这份资源包聚焦该功能的落地实现，面向网络管理员、WiFi运营人员及ROS学习者，帮助理解从认证服务器配置、热点接口创建到登录页面定制与认证后策略设定的完整链路。压缩包内共71个文件，以HTML登录/错误/注销页面、JPG/PNG/GIF图片素材、CSS样式、JS脚本及WISPAccessGatewayParam.xsd等组成，总计约95KB。其中HTML页面覆盖登录、重定向、状态、注销等关键环节，可清晰看到认证流程中的跳转与错误提示逻辑；图片素材用于界面品牌化展示，CSS与JS脚本则负责样式布局和交互逻辑。目前已有306人浏览学习。通过该包可直接获取完整的Hotspot认证页面模板，无需从零绘制页面，便于对照ROS 5.20及以上版本快速开展实验；资源附带的页面结构也适合二次开发，可在此基础上增加广告展示、用户数据收集、带宽限制与日志审计等高级能力。

1. ROS WEB认证：不是买网关，而是一台路由就能撑起访客门户

做 WiFi 覆盖项目实施的时候，最容易被业主追问的一件事就是：访客网络怎么做到“一打开网页就弹登录页”？很多朋友第一反应是买独立的认证网关，一台动不动两三千，还得单独维护一套后台。实际上，在 ROS（RouterOS）设备上把 WEB 认证做起来，并不需要额外硬件，它自带的 hotspot 功能就是完整的门户认证体系——打开网页自动重定向到本地登录页，输账号密码或点试用按钮，通过后放行上网。这个资源包就是把 ROS 上的 WEB 认证从零到上线讲透的一套笔记加模板：适合正在做无线覆盖的集成商、门店网络管理员，以及被甲方要求“访客上网必须弹认证页”的施工调试人员。我最初也以为这东西很玄学，真正拆完一遍才发现，坑有，但路径是清晰的。

2. hotspot 建模型：先搞清认证链路再动手

想不翻车，得先理解 ROS 的 WEB 认证不是“网关拦截”那一套，而是“重定向 + 放行”的组合拳。我见过不少人上来就在防火墙里加规则，折腾两天没效果，就是因为没搞明白 hotspot 的四个环节：分配 IP、劫持 HTTP 请求、展示登录页、认证后放行。这一章先把链路讲透，再给一套可以直接敲进终端的基础配置。

2.1 认证链路的四个参与者

当一台手机连上 ROS 的 WiFi，它的流量路径大概是这样的：先通过 DHCP 拿到一个内网 IP，此时它访问任何网站，ROS 都会把这个请求截住，直接重定向到内网的一个 HTTP 登录页（默认路径是 /hotspot/login）。用户在页面里提交账号密码或者点“免费上网”按钮，ROS 校验通过后，把该 IP 加入一个“已认证”的列表里，之后的流量就不再被重定向，正常转发到外网。

这里有个关键点：ROS 并不是通过修改网关或者防火墙来拦截未认证用户的。它更像一个“页面关卡”，利用的是 HTTP 重定向机制。所以你会发现，未认证用户其实能拿到 IP，能 ping 通网关，但只要打开浏览器访问任何 HTTP 站点，就会被“拽”到登录页。这也是为什么很多刚接触 ROS 的人会疑惑：明明设备已经连上 WiFi 了，为什么打开网页看到的是路由器自己的页面。

这套机制的好处是，客户端零配置，不需要装任何软件，也不用改手机或电脑的网络设置。对比 PPPoE 拨号认证或者说 802.1X，hotspot 对访客最友好，这也是它适合门店、展厅、酒店的原因。坏处也很明显：如果用户访问的是 HTTPS 站点，比如直接输入 https://example.com，ROS 没法直接劫持，手机可能弹“网络需要登录”的系统提示，或者干脆页面打开失败——这个问题我放到第 5 章避坑里细讲。

2.2 用命令行拉起一套可用 hotspot

有了概念，下面直接给一套我常用的基础配置脚本。适用场景：ROS 设备有一个内网桥接接口（比如 bridge1），WAN 口接光猫或上级路由，内网需要弹认证页。

# 1. 创建一个地址池，用来给访客分配 IP /ip pool add name=pool_hotspot ranges=192.168.10.10-192.168.10.200 # 2. 在桥接接口上建立 DHCP 服务，网关指向 ROS 内网 IP /ip dhcp-server add name=dhcp_hotspot interface=bridge1 \ address-pool=pool_hotspot lease-time=30m # 3. 创建 hotspot profile，指定登录页模板目录 /ip hotspot profile add name=profile_hotspot \ hotspot-address=192.168.10.1 \ html-directory=hotspot \ dns-name=portal.local # 4. 在接口上启用 hotspot /ip hotspot add name=hotspot_net interface=bridge1 \ address-pool=pool_hotspot profile=profile_hotspot

代码说明：第一行先建地址池，我习惯把访客网段单独划出来，避免和办公网冲突。第二行 DHCP 服务的lease-time=30m表示租约 30 分钟，对于访客网络足够，太长了会导致 IP 池被长期占用。第三行的hotspot-address=192.168.10.1是登录页绑定的路由器 IP；html-directory=hotspot指定了登录页模板从 ROS 文件系统的 hotspot 目录读取，后续换皮肤就是改这个目录下的文件。第四行真正把 hotspot 挂到 bridge1 上，这时你再拿手机连 WiFi 打开网页，应该能看到默认的登录页了。

配置完成后，别忘了加一条 NAT 规则，否则用户认证成功也上不了网：

# 访客流量出外网时必须做 NAT 伪装 /ip firewall nat add chain=srcnat action=masquerade out-interface=ether1

out-interface=ether1要改成你设备实际的 WAN 口名称，可以是ether1、pppoe-out1或wan1，具体用/interface print查看。这一步很多人漏掉，结果认证页能弹、账号能过，就是上不了网，十有八九是 NAT 没配或者配错了接口。

2.3 页面回传了什么给路由器

搞明白链路后，还有一个核心问题：登录页到底是怎么把用户输入交给 ROS 的？这套交互逻辑在你后面改页面模板时非常关键。

默认的 hotspot 登录页是一个 HTML 表单，用户输入用户名和密码，点击提交后，表单数据通过 POST 方式发回给 ROS 内置的 HTTP 服务。表单里最关键的两个字段是username和password，另外还有一个隐藏字段dst，它记录了用户原本想访问的网址，认证成功后 ROS 会根据dst把用户跳回原页面。

<!-- 登录表单的核心结构 --> <form name="login" action="$(link-login-only)" method="post"> <input name="username" type="text" placeholder="账号"/> <input name="password" type="password" placeholder="密码"/> <input name="dst" type="hidden" value="$(link-orig)"/> <button type="submit">登录</button> </form>

代码说明：action="$(link-login-only)"这个变量会在页面发给客户端时被 ROS 自动替换为完整的登录接口地址，所以不用写死 IP。$(link-orig)也是模板变量，代表用户原始访问的目标网址。除了这两个，常用的变量还有$(error)用于显示错误提示，$(chap-id)和$(chap-challenge)用于 CHAP 加密认证。这里有一个常见误解：有人以为用户密码是明文传给 ROS 的，其实 ROS 支持 CHAP 挑战响应机制，密码不会直接明文传输。如果你后续二次开发登录页，尽量保留 CHAP 相关逻辑，否则在部分设备上认证会失败。

3. 二开登录页：改出一张能上线的中文门户

ROS 默认的登录页很简陋，白底黑字配个默认 logo，拿到现场肯定过不了甲方这关。好在它的模板机制非常简单，本质就是一套 HTML + CSS 文件，放在 hotspot 目录下，改完就能生效。这一章讲清楚模板包的结构、三个必改的细节，以及改完不生效的缓存原因。

3.1 从模板包找到正确文件

先看 ROS 文件系统里的 hotspot 目录，正常情况下里面有这几个关键文件：login.html（登录页）、logout.html（注销页）、error.html（错误提示页）、redirect.html（跳转中页）、alive.html（保活页面）。资源包里打包的也是这套结构，你只需要把整个文件夹传到 ROS 的 Files 列表里，路径保持hotspot即可。

如果你手头没有现成的模板包，也可以把 ROS 设备上正在用的默认模板导出来学习结构，但不建议直接在默认文件上改，否则后期升级容易覆盖。我一般会复制一份改名为hotspot_custom，然后修改 profile 里的html-directory指向新目录，这样出问题随时切回默认模板。

# 复制默认模板目录为自定义目录 /file copy hotspot hotspot_custom # 修改 hotspot profile 指向新模板目录 /ip hotspot profile set profile_hotspot html-directory=hotspot_custom

代码说明：第一行在文件系统层面复制了整套模板；第二行把 profile 的html-directory改成hotspot_custom，意味着此后生成的认证页都从新目录读取。这个做法的价值在于留了一条后悔药——改坏了直接把 profile 指回hotspot就能恢复，不需要重新上传文件。

3.2 改版：三个必改细节

实际操作中，登录页改版不需要重写整个页面，抓住三个点就能快速落地。第一是品牌区，把页面顶部的文字和 logo 换成现场客户的信息；第二是按钮文案和表单样式，让它适配手机端竖屏操作；第三是增加用户协议勾选项，这在酒店、商场场景基本是刚需。

<!-- 改版后的登录页核心片段 --> <div class="brand"> <!-- 替换为客户 logo --> <img src="logo.png" alt=""/> <!-- 替换为项目名称 --> <h1>访客免费上网</h1> </div> <form name="login" action="$(link-login-only)" method="post"> <input name="username" type="text" placeholder="手机号/账号"/> <input name="password" type="password" placeholder="密码"/> <label> <input type="checkbox" id="agree" required/> 已阅读并同意《用户上网协议》 </label> <input name="dst" type="hidden" value="$(link-orig)"/> <button type="submit">连 接</button> </form>

代码说明：注意我加了id="agree"的勾选框，并且设置了required，作用是让用户必须勾选协议后才能提交表单，前端拦截。但这个只是体验层，真正的合规审核还要靠后台日志。action和dst这两个变量必须保留，它们是认证交互的通道。按钮文案我改成“连 接”两个字，避免手滑误操作。如果你不需要账号密码、只需要访客一键上网，也可以直接把username和password两个输入框换成隐藏域，在页面加载时填固定值，配合后文第 4 章的试用账号方案使用。

这里要特别提醒：CSS 和图片文件也要放在同一个模板目录下，ROS 的内置 Web 服务器只对hotspot-address对应的目录提供服务。引用路径尽量用相对路径，比如logo.png、css/style.css，不要写死成http://192.168.10.1/logo.png，否则内网 IP 一变页面就挂。

3.3 模板缓存与多语言变量

很多人在改完 login.html 后遇到一个诡异现象：文件传上去了，但手机打开登录页看到的还是旧页面。这个现象的根源是 ROS 内置 Web 服务器对模板文件有内存缓存，尤其是 HTML 文件的头部信息。解决方式有两个：一是在浏览器端开无痕模式强制重新加载，二是把模板目录复制一份换新名字，再让 profile 指向新目录，相当于物理刷新。

此外，ROS 模板引擎支持简单的语言变量机制，$(lang)会根据客户端的浏览器语言设置返回不同的文本。如果你只需要中文界面，可以直接把页面文案写死成中文；但如果业主后面要加英文版，就需要注意不要写死。

# 查看当前 hotspot 用户列表中是否有在线用户 /ip hotspot active print

代码说明：改完模板后，建议先在 ROS 命令行执行这条命令确认 hotspot 服务是活的，只要 active 列表能正常输出（哪怕为空），就说明服务进程没问题，再去排查页面缓存。这算是一个快速分层定位的技巧：先确认服务状态，再查页面，最后查客户端。

4. 认证策略配置：用户、时长与绑定的调配

登录页能弹出来，只是第一步。真正让这套 WEB 认证能交付的，是后面的认证策略——哪些人可以免认证、哪些人要限时、限时多久、流量要不要封顶。这一章从三个层面讲配置：试用账号、固定账号、免认证名单。

4.1 三种常见认证策略配置

门店场景最常用的是“免费试用 X 小时”，酒店场景则偏向固定账号密码，还有一些展厅需要区分“普通访客”和“VIP 用户”。这三者在 ROS 里的实现方式都很直接，核心是 profile 和 user 的配合。

# 1. 创建“试用” profile：每位用户最长在线 2 小时，空闲 10 分钟强制下线 /ip hotspot user profile add name=profile_trial \ session-timeout=2h idle-timeout=10m \ shared-users=1 # 2. 创建“VIP” profile：不限时长，但限速 10Mbps 下行 / 2Mbps 上行 /ip hotspot user profile add name=profile_vip \ rate-limit="10M/2M" # 3. 添加一个试用账号，允许同一账号最多 1 人同时在线 /ip hotspot user add name=trial01 password=123456 \ profile=profile_trial # 4. 添加一个 VIP 账号 /ip hotspot user add name=vip01 password=888888 \ profile=profile_vip

代码说明：session-timeout=2h表示用户从认证成功那一刻起，最多在线 2 小时，时间到了会被强制下线，重新打开网页需要再次认证。idle-timeout=10m表示用户空闲 10 分钟没有流量，也会踢下线，这个参数特别适合门店场景——客人走了手机还挂着 WiFi，会白白占用 IP 资源。shared-users=1限制同一个账号只允许一台设备在线，防止一个账号被到处转发给其他人用。rate-limit="10M/2M"的写法是下行速率/上行速率，这是 ROS 的固定格式，顺序别搞反，否则限速效果完全不对。

4.2 IP binding 免认证的边界

设备免认证，比如收银机、广告屏、打印机，不应该走登录页流程，否则哪天这些终端重启了没人去点认证，业务就断了。ROS 里通过 IP binding 实现免认证，核心是理解type=bypassed与type=regular的区别。

# 让收银机（MAC 地址举例）完全跳过认证 /ip hotspot ip-binding add mac=00:0C:29:AB:CD:EF \ type=bypassed comment="cashier" # 让打印机设备免认证，但依然记录在线状态 /ip hotspot ip-binding add mac=00:1E:58:11:22:33 \ type=regul ar comment="printer"

代码说明：type=bypassed是真正意义上的免认证，设备拿到 IP 后直接放行，既不弹登录页，也不进 active 列表。type=regular则比较微妙，它会让设备免弹窗，但 ROS 仍然会在 hotspot 的 active 表里记录这个设备的在线信息，方便你审计。实际使用中，我建议收银终端用bypassed，打印机会用regular，理由是打印机需要被监控在线状态，避免“显示在线但实际罢工”的情况。

这里必须提醒一个边界问题：ip-binding只对 MAC 地址有效。如果现场的设备 MAC 会变（比如手机开启随机 MAC 地址），绑定就失效了。所以免认证名单只推荐给固定位置的硬件设备，不建议给员工的个人手机做 MAC 免认证。

4.3 记住登录状态：Cookie 与 MAC 方案

给访客用的网络，最烦的就是用户连上 WiFi 后，过一会儿唤醒手机又要重新认证。ROS 提供两个办法缓解：Cookie 记住登录状态，或者按 MAC 地址免认证一段固定设备的网络入口。

# 查看当前会话表，确认设备是否还在线 /ip hotspot active print # 手动把某个 IP 踢下线 /ip hotspot active remove [find user="trial01"]

代码说明：在默认的登录模板里，如果你勾选了“记住我”之类的选项，ROS 会给浏览器种一个 Cookie，之后同一浏览器再次连接时，ROS 检测到有效 Cookie 就直接放行，不再弹登录页。这个方案适合手机、平板这类固定终端。还有一种是基于 MAC 的“无感认证”，本质上就是给该设备单独加一条 IP binding，但它与页面弹窗流程有冲突，只适合特定设备，不建议大面积使用。很多实施人员在这块会犯一个错误：以为只要设置 session-timeout 足够长，用户就不会频繁掉线。实际上 ROS 的 session 机制还受 idle-timeout 影响，一个客人把手机放桌上不用，20 分钟后就掉线了，回来唤醒手机又要重新认证，体验很差。正确做法是：对访客用session-timeout控制总时长，对员工设备用 IP binding 或 Cookie 免认证，两条腿走路。

5. 避坑：ROS hotspot 的五个翻车现场

这一章把我在实施过程中真正踩过、也帮别人排查过的问题集中写出来。每条都按“现象 → 原因 → 解决”来写，希望对你有实际帮助。这些问题如果只看配置手册，基本查不出答案，得结合真实场景才能定位。

5.1 现象：认证成功但上不了网

用户能弹出登录页、输入账号密码后也提示认证成功，但打开任何网页都是转圈或报错。排查发现，用户 IP 已经在 active 列表里，但流量出不去。

原因：通常是 NAT 规则缺失或接口匹配错误。认证只解决了“是否允许上网”的问题，真正的流量转发是靠防火墙 NAT 实现的。很多模板里会把出接口写成ether1，但 ROS 的接口名在部分设备上是wan或pppoe-out1，只要名字对不上，流量就卡在路由器内部。

解决：用/ip firewall nat print查看现有 NAT 规则，确认out-interface与/interface print里的 WAN 口名称一致。不一致的话，修改或删除重建规则。如果直连光猫拨号的是 ROS 自身，out-interface就要写成拨号接口名。

5.2 现象：苹果手机连上 WiFi 后不弹认证页

iPhone 连上网络后，打开任意网页没有出现登录页面，系统也没有“需要登录网络”的提示。安卓手机在同一网络下却一切正常。

原因：iOS 的 Captive Portal 检测机制比较特殊，它通过发送特定请求探测网络是否需要认证。如果 ROS 的 hotspot 页面加载太慢，或者 HTTPS 跳转异常，iOS 会认为“当前网络无需认证”，直接放行——但它其实什么都没认证，用户还是上不了网，体验就是“能连 WiFi 但打不开网页”。

解决：给 profile 设置一个简单的dns-name，比如portal.local，并确保 ROS 的 DNS 服务正常响应。同时把登录页的首屏内容尽量压缩，避免加载一个大图导致 iOS 检测超时。如果条件允许，把 ROS 系统升级到较新版本，对 iOS 的兼容性会好很多。现场临时处理时，可以让用户在浏览器手动输入http://portal.local打开登录页。

5.3 现象：改了登录页文件但不生效

上传了新的 login.html，覆盖了 hotspot 目录里的旧文件，但手机打开看到的还是旧页面。

原因：ROS 内置 Web 服务对模板文件有缓存，尤其是 HTML 文件头。覆盖上传后，服务进程还在用旧的内存副本。这个现象在很多设备上都会发生，不是文件没传成功。

解决：在 ROS 命令行用/file print确认文件大小和时间戳确实变了，然后重启 hotspot 服务，或者把 profile 的html-directory临时切到另一个目录再切回来。更省事的办法是直接给目录换个新名字（比如hotspot_v2），改 profile 指向它，相当于强制刷新整套模板。

5.4 现象：微信内置浏览器登录后空白页

用户在微信里点击聊天中的链接，打开登录页，输入账号密码提交，然后就出现白屏，什么都加载不出来。换 Safari 或 Chrome 却正常。

原因：微信内置浏览器的 UA 被 ROS 判断为某种不支持的设备，跳转逻辑走了错误的模板分支。更常见的诱因是登录页引用了外部 CSS/JS 文件，而微信内置浏览器的过滤机制屏蔽了部分外部请求，导致页面样表加载失败，看起来像白屏。

解决：登录页不要依赖外部资源，所有 CSS 和 JS 尽量内联到单个 HTML 文件里。另外可以在 ROS 的 hotspot profile 里关闭对微信 UA 的特殊处理（如果版本支持的话）。我这里再补一个与之类似的坑：如果登录页用到了 HTTPS 的图片或字体链接，在用户未认证状态下，ROS 是无法代理 HTTPS 请求的，这些资源自然加载失败。

5.5 现象：连上后没几分钟就被踢下线

用户第一次认证成功，过了大概 5-10 分钟，手机熄屏后再打开，发现又要重新认证。

原因：绝大多数情况是idle-timeout设得太短。ROS 的会话机制里，空闲超时是独立于总时长的，只要用户没有流量，到达空闲阈值就会被踢。比如idle-timeout=10m，你手机放桌上 10 分钟不动，回来自动被下线。另外，如果 ROS 开启了keepalive-timeout，且用户设备的系统休眠切断了连接，也可能触发提前失效。

解决：调整 strategy，对访客场景把idle-timeout设到 30 分钟以上，或者直接给“免认证”设备使用 IP binding，绕开会话超时机制。在调试阶段，可以用/ip hotspot active print实时观察每个会话的建立时间和空闲时间，判断是被哪种超时踢掉的。

6. 验证与发布：让客户心服口服的验收流程

配置做完了，坑也避了一轮，最后要面对的是交付现场。这一章分享我每次做完 ROS WEB 认证项目后必走的一套验收流程，既能在客户面前演示完整链路，也能在出问题时快速定位是哪一层出的岔子。

6.1 三个终端的验收路径

我会准备三台设备：一台安卓手机、一台苹果手机、一台 Windows 笔记本。安卓手机的验收路径是：连 WiFi → 打开浏览器访问任意 http 网页 → 被重定向到登录页 → 输入试用账号 → 通过后回到原网页。苹果手机的验收路径和安卓类似，但要多观察一步：系统是否弹出“需要登录网络”的横幅，如果没有，按 5.2 的排查思路处理。Windows 笔记本则要看认证成功后，能否正常访问内网打印机或其他局域网资源，避免出现“能上网但打印不了”的尴尬。

6.2 从 ROS 侧确认认证状态

客户端测试之外，必须学会从 ROS 侧确认状态。在用户认证成功后，执行以下命令：

# 查看全部在线认证用户，确认 IP、MAC、登录账号 /ip hotspot active print # 查看认证日志，确认是哪个账号、哪个接口放的行 /log print where topics~"hotspot"

代码说明：active print输出的每一行代表一个当前在线会话，列中包含用户 IP、MAC、登录名、登录时间、空闲时间等关键信息。log print则能查看到认证通过的记录，确认 auth 状态是 OK 还是 failed。这两条命令共同构成了现场排查的第一手证据，比任何网速测试都直观。

再补一个演示时的小技巧：用表格给客户整理一份验收记录，每台设备测试什么、预期结果是什么、实际结果是什么，逐项打勾。这样做的好处是，后期如果出现“用户说打不开网页”的投诉，你可以快速回溯是哪类设备、哪个时间段、是否认证成功的记录。

我自己的习惯是，每次做完这类项目，交付后一周内还会远程连上设备看一次/ip hotspot active print的在线数量和日志错误，确认没有异常掉线和频繁重认证的情况。这个习惯是在某一次展会现场翻车后养成的——当时演示时一切正常，第二天设备重启后 hotspot 服务没自启，全场访客都连不上网，从那以后我每次交付完都把 hotspot 服务的开机自启项检查一遍，确认enabled=yes才走人。希望这套笔记和模板包能帮你少走这些弯路，把 ROS WEB 认证做成一个真正稳定的交付项。

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