企业官网建设流程全解析

简介：这套ROS Web认证资源包专为需要部署公共Wi-Fi认证的网络管理员准备，用于解决RouterOS热点登录页面定制与配置环节的常见难题。资源内含完整的认证页面前端素材，共71个文件，以HTML模板为主，覆盖登录、错误、重定向及状态展示等页面；配套的CSS样式与JavaScript脚本负责页面渲染和认证交互逻辑，多张JPG、PNG、GIF图片素材可用于品牌化界面设计，另附无线网关认证参数规范文件，方便理解认证网关的字段定义。整包压缩后仅95KB，非常轻量，可直接上传至ROS设备替换默认热点页面。目前已有307人学习下载。通过研究该资源包，读者能够快速掌握Hotspot认证页面的目录结构、文件关联与认证流程，还可参考内嵌脚本和样式代码，定制符合自身品牌需求的登录界面，同时避开认证跳转、参数传递等配置误区，从而提高公共网络接入管理的安全性与效率。适合具备一定RouterOS基础、正在配置Hotspot功能的网络技术人员学习参考。内容组织简明，便于按需取用。

1. ROS Web认证的整体面貌：从“被重定向”开始理解

一个未认证的终端发出HTTP请求后，它收到的不是目标网页，而是路由器返回的一张登录页；账号密码通过后，网络才重新“畅通”。这套机制通常被叫作ROS Web认证，在RouterOS里的对应实现是Hotspot。它看起来只是把访问控制搬到了浏览器里，但真正学起来会发现，它背后是一套“拦截—重定向—认证—放行”的完整链路，横跨IP编址、DHCP、DNS、网页服务、账户体系与防火墙规则六个方面。与其把它当成设备上的一个开关，不如把它理解为一个多模块协作的接入控制系统。这篇笔记就是按这个地图来组织的：先讲整体架构，再讲热点配置与认证源取舍，最后落在易错点和复习清单上。适合正在啃网络配置、负责无线覆盖或备考网络认证的人。

2. 认证架构三件套：网关、服务与用户链路

2.1 三层模型：网络层、服务层、账户层

从设备配置的视角看，Web认证不是单点功能，而是由三层独立且相互依赖的子系统构成。初学者习惯把/ip hotspot当成唯一入口，这是导致排查翻车的最初根源。

网络层的唯一职责是让终端“找得到网关”。终端接入后，DHCP要给出正确的IP地址、掩码与网关。RouterOS对应项是/ip address、/ip pool、/ip dhcp-server。如果这三处配置出现网段不一致，比如接口地址是10.20.30.1/24，而DHCP地址池写成了192.168.50.0/24，终端即使拿到了IP也ping不通网关。认证页面寄宿在网关IP上，终端连网关都不通，后面的一切都无从谈起。

服务层负责“把未认证流量导向登录页”。RouterOS的Hotspot服务器在某个接口上监听，并将未认证IP发起的TCP/80请求以DNAT形式重定向到本地页面服务。这一步看似只是改写了包的目标地址，实际还包含对会话标记的判断——已认证的客户端不会再命中重定向规则。

账户层处理“谁能拿到什么权限”，用户表、Profile、限速、会话时长全部在这一层完成。三层之间的关系可以简化为下面这张对照表：

复习时建议按这张表逆推：先让用户描述故障现象，再判断属于哪一层。这样比从头到尾翻配置快得多。

2.2 认证流程的完整时序：从终端请求到放行

一个完整的Hotspot认证周期，按时间展开共有七个环节。可以串成一句话来记：“拿地址、发请求、被重定向、载入页面、交凭据、建会话、放行。”每个环节都有明确的输入输出：

1. 终端上线并获取IP，DHCP服务器从/ip pool里分配地址，同时下发网关与DNS。
2. 终端发起HTTP请求，浏览器请求目标站点的TCP/80端口。
3. Hotspot判定该IP无有效会话，将请求重定向到登录页服务地址。
4. 浏览器请求登录页面，服务端返回login.html并填充会话参数。
5. 用户提交账号密码，RouterOS按照Profile中配置的方式校验。
6. 凭据验证通过后创建主机会话，在/ip hotspot host中建立记录。
7. 后续流量匹配会话标记，直接转发。

关于步骤3，这是整个机制的核心，也是最容易出偏差的地方。RouterOS并不能真正拦截HTTPS流量，它会在SSL握手阶段尝试干预；在很多部署里，HTTPS请求的回包会被丢弃或连接被重置，用户浏览器随后降级去请求HTTP页面，登录页这才出现。于是我们看到的现象就是“第一次打开网页失败，刷新一下弹登录页”。

步骤5的校验方式直接影响安全性。RouterOS Profile里的login-by支持http-chap、http-pap、https、cookie、trial五种方式的组合。默认Profile通常同时开启http-chap与cookie。其中http-pap是明文传输密码，除非只为兼容老旧设备，否则别单独开启；https让密码走SSL，安全等级最高，但代价是必须处理证书信任问题。

在服务端，可以通过两条命令观察流程走到哪一步：

# 查看主机状态，确认会话是否建立 /ip hotspot host print detail # 查看最近认证日志，观察步骤5是否报错 /log print where topics~"hotspot"

/ip hotspot host print detail输出的状态字段是关键：bypassed表示已放行，local表示本地用户通过认证，radius表示RADIUS认证通过，idle表示地址拿到了但还没有成功登录。日志里的登录失败会带有明确的用户名与原因，排查时不要忽略它。

2.3 数据面与转发链路上认证的挂载点

看到这里，你可能会有一个本质性疑问：Hotspot到底是怎么插入到数据路径里的？答案是它并不单独工作，而是依赖一组自动生成的防火墙规则。启用Hotspot时，RouterOS会在防火墙NAT表和过滤表里加入关键条目。用/ip firewall nat print就能看到类似下面的动作：

/ip firewall nat add chain=pre-routing dst-port=80 protocol=tcp action=redirect to-ports=80 comment="hotspot"

action=redirect与action=dst-nat的区别在于：redirect是把包引导到路由器自身的IP，而不是另一个远端地址。于是流量在pre-routing阶段就被改写成指向本地80端口，Hotspot页面服务才有机会接管。

Walled Garden机制也挂在这条链路上。它的意义是让用户在认证之前就能访问少数特定目标——典型场景是允许DNS解析、允许访问运营商的支付页面或公司门户。配置位置是：

# 允许未认证用户访问公司主页 /ip hotspot walled-garden add dst-host=portal.corp.example.com # 允许 DNS 服务 /ip hotspot walled-garden add dst-host=*.*.*.* dst-port=53 protocol=tcp /ip hotspot walled-garden add dst-host=*.*.*.* dst-port=53 protocol=udp

Walled Garden的本质是一份白名单，它作用于未认证会话的传输链路。如果你期望“某些IP在认证前就能通”，但忘了将DNS服务列入Walled Garden，终端会连域名都解析不了，登录页自然也无法加载。这是实际部署中很容易被忽略的一个点：保留DHCP之外的DNS流量，而不是只放行80端口。

数据面还有一个值得留意的是ACL与Profile的策略联动。Profile不只是限速用的，它也可以配置允许访问的地址段、允许的协议和端口。未认证流量受Walled Garden约束，认证之后的流量受Profile的ACL约束，两者并不互相覆盖。很多配置问题出在“认证通过后仍然访问不了某些站点”，原因往往就出在这个ACL上。

3. 热点认证实战：从默认模板到自定义登录页

3.1 开启Hotspot的最小步骤

开启Hotspot的方式有两种：交互向导和纯命令行。向导适合第一次上手，它会把地址池、DHCP、预热、证书、NAT规则一次性建好；但考试或系统复习时，推荐用命令行一步步创建，因为每个步骤都对应一个可记忆的概念。

下面是一套可在测试机上复现的最小配置。假设LAN侧接口为ether2，内网段为10.20.30.0/24：

# 1. 创建内网地址池 /ip pool add name=hs_pool ranges=10.20.30.100-10.20.30.200 # 2. 给接口配置IP /ip address add address=10.20.30.1/24 interface=ether2 # 3. 为访客网段创建DHCP服务器 /ip dhcp-server add name=hs_dhcp interface=ether2 address-pool=hs_pool lease-time=10m # 4. 创建Hotspot服务器，挂到同一接口 /ip hotspot add name=hs_main interface=ether2 address-pool=hs_pool profile=default # 5. 添加一个测试用户 /ip hotspot user add name=test01 password=test2024 profile=default

步骤2的10.20.30.1/24是Hotspot登录页寄宿地址。步骤3中的lease-time=10m决定DHCP租约时长；如果租约太短，终端在认证完成后因为租约到期重取IP，会丢掉会话上下文，不得不重新登录。步骤4里address-pool=hs_pool与步骤1的池子必须一致；这里有个常被忽略的点：/ip hotspot add并不会自动替你修正地址池的矛盾，如果写错网段也不会有明显报错，只会表现为登录后数据不通。

配置完成后，默认Profile和默认页面文件已经能提供一次完整认证流程。若想修改默认页面，在RouterOS里，Hotspot页面存放在一个隐含的HTML目录中，用/ip hotspot profile set [ find default=yes ] html-directory=hotspot来指向它。如果你通过/file上传了自定义文件，记得确认目录下的文件名大小写和路径完全一致，否则会返回404。

3.2 登录页、重定向与Cookie的作用域

默认情况下，RouterOS会为登录页附带一组模板变量，在渲染时用当前会话信息替换。自定义登录页几乎都会用到下面几个变量：

基于这些变量，一个最小的自定义登录页可以写成这样：

<!DOCTYPE html> <html> <head><meta charset="utf-8"><title>访客登录</title></head> <body> <form name="login" action="$(link-login-only)" method="post"> <input type="hidden" name="dst" value="$(link-orig)" /> <label>账号<input name="username" value="$(username)" /></label> <label>密码<input name="password" type="password" /></label> <button type="submit">登录</button> </form> <p style="color:red">$(error)</p> </body> </html>

写完后上传并刷新浏览器即可生效。这里有个常见的坑：RouterOS会自动保留一个login.html.bak作为前一个版本的备份。如果你改坏了新页面，手动把.bak重命名回login.html就能恢复。每次覆盖上传前，先在本地留一份副本，避免多次修改后连备份也被新版本覆盖。

Cookie在登录成功后写回到浏览器，表示“这台设备已经认证过”。默认的Profile策略里，Cookie与主机会话是配合使用的：浏览器带Cookie访问页面，服务端比对Cookie与IP/MAC是否符合，符合则放行。若用户清空了Cookie，但主机会话仍然存在，终端还是能上网；反过来，如果会话被/ip hotspot host remove手动清除了，即使Cookie还在，用户也会被引导到登录页。理解Cookie与主机会话的独立性，是判断“要不要重新登录”的关键。

还有一件事：默认的登录页面只依赖HTTP。如果你在Profile里开启了use-ssl=yes并提供证书，登录与静态资源都可能走HTTPS。这时要重新检查自定义页面中的资源引用方式，不能用绝对HTTP路径，否则会发生混合内容加载问题，第5章会专门展开。

3.3 用户账户体系与Voucher管理

Hotspot的用户账户不单纯是账密，每个用户挂在一个Profile下，并可以叠加多个消费限制。常见命令与参数含义如下：

# 限制累计在线2小时、累计流量1G的访客 /ip hotspot user add name=guest01 password=pwd01 \ limit-uptime=2h limit-bytes-total=1G profile=visitor # 将某个账户绑定到指定MAC，避免借号 /ip hotspot user add name=staff01 password=pwd02 \ mac-address=AA:BB:CC:DD:EE:FF profile=staff

limit-uptime是累计在线时长上限，达到后强制下线；limit-bytes-total是双向累计流量上限；mac-address表示该用户只允许从指定MAC设备登录。三者都是可选的，若都不设置，账户将长期有效，适合办公专用的固定账号。

批量生成Voucher也是热点场景的常用操作。一张Voucher本质上就是一个一次性有效的限时账户，常见需求是“生成50个一次性账号，每个用2小时”。RouterOS脚本可以这样写：

:for i from=1 to=50 do={ /ip hotspot user add name=("v".$i) password=("v".$i."pw") \ limit-uptime=2h comment=("voucher-batch-".$i) }

name=("v".$i)用循环变量拼出不同用户名，password同理，comment字段记录批次便于后续按备注删除。需要回收这批账号时，应使用/ip hotspot user remove [find comment~"voucher-batch"]，而不是逐条手工删。此时，如果用户正在线，删除用户并不会立刻清除会话，还需到/ip hotspot host里把对应主机会话也清除，才算完成回收。

从这个细节可以看出，账户层存在“用户记录”和“会话记录”两个并行的实体。前者描述凭证，后者描述当前在线状态。很多管理员只删用户不删会话，结果设备还能继续上网，等到超时才掉线，造成“已经删除的账号还能上网”的错觉。

4. 认证源的取舍：本地库、RADIUS与MAC免认证

4.1 三种认证形式的对比

Hotspot后端认证源主要有三套：本地用户库、RADIUS服务器、MAC免认证。很多人以为选一个就行，但实际上它们可以同时启用，按顺序配合工作。

简单说一下适配场景：本地用户库适合终端数量少、没有统一账户管理部门的场景，配置快、零外部依赖；RADIUS适合需要统一结算、集中审计与动态下发策略的规模化网络；MAC免认证严格来说不算身份认证，它只是绕过登录环节，常用于打印机、监控头、广告屏等无头设备。三者对比见下表：

“同时启用”是一个容易漏掉的知识点。Profile里的use-radius=yes一旦打开，RouterOS会优先向RADIUS服务器发请求；当RADIUS服务器无响应或超时时，才回落到本地用户库。若你原本同时维护着本地用户和RADIUS，又希望策略清晰，记得分工：把关键用户放在RADIUS，把应急本地账号保留在本地库，并定期检查本地库是否有过期账号，避免成为后门入口。

4.2 RADIUS集成要点

RADIUS的接入配置并不复杂，难点在属性正确与链路稳定。两条核心命令：

# 定义一个供Hotspot使用的RADIUS客户端 /radius add service=hotspot address=10.0.0.5 secret=sharedsecret timeout=300ms # 让默认Profile去询问RADIUS /ip hotspot profile set [ find default=yes ] use-radius=yes

timeout=300ms表示单个RADIUS请求的等待阈值，超时会触发重试。若RADIUS服务器在异地、链路往返超过300ms，即便服务器正常，用户也会感到登录缓慢。建议先用ping统计平均RTT，再把timeout设成RTT的2～3倍，同时通过retry参数设置有限次数的重试，避免因网络抖动触发大量并发重试。

RADIUS返回的关键属性决定了策略是否生效。最常打交道的两个：

错误的表现形式很隐蔽：用户能登录但带宽和默认用户完全一样，没有任何报错。此时要在RADIUS服务器侧查看Access-Accept包里是否真的携带了这些属性，并核对值与格式。比如Mikrotik-Rate-Limit的规范写法是rx-rate[/tx-rate][/tx-burst-rx][/tx-burst-tx]，举一个正确示例：

Mikrotik-Rate-Limit = 10M/10M/1M/1M

含义是下行10M、上行10M，突发上限1M队列。若写成10M这样的单值，RouterOS可能识别不出完整的限速策略。调试时，在RouterOS侧执行这条命令看RADIUS日志：

/log print where topics~"radius"

日志中能看到Access-Request与Access-Accept的交互记录。若连请求都没有，先排查service=hotspot是否匹配、密钥是否一致、网络是否通。

4.3 MAC免认证的适用边界

MAC免认证是Hotspot里最容易被误解的功能。它的配置方式简短：

# 指定MAC完全免认证 /ip hotspot ip-binding add mac=AA:BB:CC:DD:EE:FF type=bypassed # 指定MAC禁止接入 /ip hotspot ip-binding add mac=AA:BB:CC:DD:EE:F0 type=blocked

type的可选值有bypassed、blocked和regular。regular意味着按正常认证流程走。bypassed的效果是该设备不会看到登录页，流量直接放行。它很适合部署在网络内部的打印服务器、电子屏、监控主机等无人值守设备。

但这套方案有两个明显的边界。第一，免认证判断基于源MAC，而终端如果位于另一台NAT路由器后面，RouterOS看到的MAC是外层设备的接口MAC，不是内网设备的真实MAC，白名单形同虚设。第二，bypassed并不保证该设备能访问全部网络资源——它仍然受Walled Garden与Profile ACL约束。一个典型的翻车案例是：给监控摄像头设了bypassed，但忘了在Walled Garden里放行NTP服务器地址，摄像头时间失步，录像分段异常。排查时不能只盯着认证状态，还要看策略列表。

实际项目里建议把MAC免认证划分出一个专用Profile，并在其中显式放行它需要的目的地址与端口；同时为每一条绑定记录加comment，标注设备型号与负责人。这样到期回收时，按comment批量查找即可。

5. 易漏点与易错点：配置后连不上时的排查方向

5.1 易漏点：HTTPS证书与混合内容导致登录页异常

易漏点：开启HTTPS登录后，自定义页面中引用的静态资源仍写在HTTP路径上，浏览器以混合内容为由拦截脚本，登录功能失灵。

为什么漏：RouterOS默认生成的是自签证书，浏览器本来就不信任；再加上页面资源走HTTP，登录页会被浏览器标记为不安全。用户在看问题时只会觉得“页面能打开，按钮没反应”，很少会想到是浏览器策略在起作用。也有反向情况：页面本身是HTTP，但某个资源写死了HTTPS，同样会加载失败。

怎么补：自定义页面里的资源一律用相对路径引用，即css/style.css而不是http://ip/css/style.css；静态资源全部放到Hotspot的html目录中与页面同源。上线前用浏览器开发者工具的Network面板检查有没有混入HTTP请求，有则改掉。生产环境则建议把设备证书换成受信任CA签发的正式证书，并在Profile里开启use-ssl=yes，让用户走HTTPS登录，避免密码明文传输。

提示：修改login.html之前，先把原文件另存为一份副本；RouterOS虽然会自动生成.bak，但多次保存改动后.bak会被新版本覆盖。

5.2 易错点：地址池、DNS与网关的配置顺序错位

易漏点：接口地址、DHCP地址池、Hotspot地址池三段参数不在同一个网段，结果是终端拿到地址、也能看Wi-Fi信号，但永远打不开登录页。

为什么漏：Hotspot在创建时会把地址池锁到特定网段。你单独改DHCP的地址池或给接口换IP，不会自动同步Hotspot。更隐蔽的是DNS：设备开启了Hotspot后，默认会劫持未认证终端的DNS解析，把域名解析往登录页引导；若你手工指定了外部DNS或Walled Garden未放行DNS，终端浏览器一直显示“正在解析”，登录页迟迟不出。

怎么补：配置后用三条命令自查：

/ip address print /ip dhcp-server print /ip hotspot print

对比接口IP所在网段、DHCP分配网段与Hotspot的address-pool是否一致。终端侧再用一条ipconfig命令核对实际拿到IP。若要用固定DNS，记得把对应IP加入Walled Garden。

5.3 易错点：防火墙规则优先级与“先命中”原则

易漏点：手写的NAT规则放在Hotspot自动规则前面，先命中了流量，认证页不再出现。

为什么漏：RouterOS的防火墙规则按顺序从上到下匹配，同一链内首条匹配生效。很多网络配置者习惯把action=masquerade的NAT规则排在最前面，这会让内网流量直接出去，Hotspot重定向根本没有机会介入。规则多了以后，这种冲突很难一眼发现，被人称为“配置玄学”并不夸张。

怎么补：查看/ip firewall nat print，把Hotspot自动生成的action=redirect规则移动到前端位置，或保证前置规则的作用范围不覆盖需要认证的网段。这里提供一个通用检查习惯：每当新增了防火墙规则后，用/ip firewall nat print过一遍列表，看看是否有新规则挡在认证规则之前。对于过滤链也需要确认一条chain=input规则允许访问本地80/443端口，否则登录页服务不可达。

5.4 易漏点：会话超时与重新认证逻辑

易漏点：用户被“踢下线”后重新打开网页又要求登录，这不是账号密码过期，而是会话层的超时参数在起作用。

为什么漏：账户有效期与会话闲置超时是两个维度。账户有效期写在用户记录里，控制累计使用时长；会话闲置超时写在Profile的keepalive-timeout里。管理员只改了用户有效期，没动keepalive-timeout，于是一段静默时间后会话被回收。用户在Wi-Fi信号满格的情况下被要求再输账号，体验非常差，也容易被误判为“网络不稳定”。

怎么补：根据访客网络的真实需要设置合适的会话闲置时长。若希望访客一直保持在线，把keepalive-timeout调大或设成永不；若希望空闲回收，则针对性设短。考试或复习时，要能分清楚“会话过期”和“用户过期”两套判断逻辑，对应的查看命令分别是/ip hotspot host print与/ip hotspot user print。

注意：bypassed不等于“完全不受控”，它只是免去了认证步骤，流量策略依旧生效。

5.5 易错点：MAC免认证与Walled Garden的叠加副作用

易漏点：给设备设为bypassed后以为它会一直畅通，但实际它仍受Walled Garden和Profile ACL的限制，某些地址访问不通。

为什么漏：前面提到过，bypassed只跳过认证交互，不改变流量过滤策略。如果没在Walled Garden里放行该设备要访问的目标，它依然被困在受限环境中，问题表象却是“网络已连接但某些应用异常”，容易把排查方向带偏到应用层。

怎么补：排查这类问题时，按“先认证、后策略”的顺序分解：看主机状态是否显示bypassed，再检查Walled Garden列表和目标地址是否匹配，最后检查该主机会话对应的Profile ACL。若设备需要访问任意地址，建议单独建一个名为allow-all-bypass的Profile，并在其ACL中放行全部，而不是在默认Profile里做看似“全局”的调整。

6. 复习清单：从配置到排错的完整自查路径

6.1 五个先检查

复习时，我常用一张“五查表”来检查配置是否健康：

6.2 三类故障的排查路径

当用户反馈“连上了但上不了网”时，我习惯按下面的路线图走，每一步都有对应的观察命令：

1. 先看终端IP与网关，确认DHCP是否下发正确地址；不通则回到网络层。
2. 看是否弹出登录页；不弹则检查NAT规则、input规则和Hotspot服务。
3. 看认证是否成功；用/ip hotspot host print确认会话状态。
4. 认证成功仍无法上网；检查masquerade规则、Walled Garden、DNS。
5. 依旧异常；最终检查Profile限速与ACL策略。

这套排查路线能避免一半以上的“翻车”——因为大部分故障都出在1、2步，而不是认证环节。

6.3 一个沿用至今的习惯

说到这儿，我讲一个自己的排查习惯。以前我调试Hotspot毫无章法，经常在用户列表、地址池和NAT规则里来回翻，结果越调越乱。后来逼着自己把整个流程拆成三步：先看网络层，把地址池和接口地址对齐；再看服务层，确认NAT重定向规则在正确位置；最后看账户层，才去动用户与Profile。每次调试完，还强制自己用手里的终端完整走一遍登录流程，并在ROS侧把主机会话打印出来看一眼。从那以后，我每次配置前都会强制走一遍“先看接口、再看规则、最后看用户”的顺序，思路就再没乱过。希望帮到你。

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