访客 SSID 只是”另一个入口”

创建访客网络这件事，字面意思就是它的全部：换一个 Wi-Fi 名称和密码给客人用。这当然有价值，至少主网络的密码不用满世界传播。但需要理解的是，SSID 决定的只是设备”如何接入”无线网络，并不决定设备接入之后”能去哪里”。

设备连上之后，路由器仍要为它转发流量。配置得当的访客网络，应该只把流量送往互联网，而不允许访客设备触碰内网的私有区域。一旦缺少这条本地访问限制规则，第二个 SSID 通往的地方，可能和主网络完全一样。

另外还有一项设置决定访客之间能否互相通信，常见名称是客户端隔离、设备隔离或 AP 隔离；而限制访客访问主网络的选项，可能被叫作 LAN 访问、内网访问或网络隔离。

理清楚就是三件相互独立的事：访客 SSID 管的是接入方式，访客与内网之间的隔离负责挡住访客设备，客户端隔离负责让访客设备彼此隔开。

真正的风险在于”能被访问到”

没有做隔离，并不等于访客立刻就能翻遍家里所有文件和设备。设备本身仍有密码、权限和各自的安全设置挡在前面。但问题在于，这些设备原本就不应该出现在访客网络的可达范围内。一旦访客设备能”看见”内网，它就可以开始扫描有哪些设备在线、尝试打开本地管理页面、向任何有响应的服务发起连接。

作者特别澄清，这套逻辑并不是要人怀疑亲朋好友：可以信任来做客的人，但不必信任他们的手机。对方设备可能系统版本过旧、可能已被感染，也可能装了某个在后台悄悄扫描局域网的应用——这类情况比多数人以为的更常见。正确的隔离配置，直接把这种可能性从源头上抹掉。

设置项名字太乱，是最大的绊脚石

想确认自家访客网络到底处于什么状态并不难，但有个绕不开的麻烦：路由器厂商在设置项命名上各行其是。同一个功能，旧路由器可能叫”访问内网”，新路由器可能叫”允许本地访问”，也可能藏在 LAN 访问、网络隔离、访客权限这些名目之下。

因此，找到疑似相关的选项后不要急着勾选，先把说明看清楚。要找的是”阻止访客设备访问主网络”的那一项，而不是仅仅”阻止访客设备互相通信”的那一项——两者完全不是一回事。

五分钟自测：设完必须验证

设置完成后不要默认它已经生效，先做一轮测试。

用一台自己信得过的手机或笔记本连上新建的访客 Wi-Fi，确认能正常上网；接着在浏览器里尝试打开路由器的管理地址，再试着访问主网络中某台设备的本地 IP，比如 NAS 或台式机（这些地址可以在切换网络之前，从路由器的已连接设备列表里找到）。

还可以对这些设备执行 ping 测试，Windows 用户也可以看看它们是否出现在文件资源管理器的”网络”里。但不要只依赖其中某一种方式——部分设备会忽略 ping 请求，网络发现功能本身也时常失灵。

期望看到的结果是：访客设备能正常访问互联网，却看不到网络里的任何其他设备。

两层隔离都要打开

回到访客网络设置页面，先关掉所有名为”访问内网””允许本地访问””LAN 访问”之类的选项；如果路由器的表述方式相反，那就改为开启”网络隔离”。

接着，如果不希望访客设备之间也能互相通信，再开启客户端隔离、设备隔离或 AP 隔离。改完保存，然后重复上面那套测试流程。

有规则支撑，隔离才成立

访客 SSID 依然值得设置，它只是算不上一劳永逸的安全方案。换个名字、换个密码仅仅是开始，在路由器真正开始拦截本地访问之前，网络安全性并没有实质性的提升。

来源：How-To Geek《Most people set up guest Wi-Fi wrong, and their router proves it》，作者 Monica J. White

MakeUseOf 撰稿人 Gavin Phillips 为此做了一组对照测试：先跑 Ookla 测速，同时让 WinMTR 在后台记录，空闲状态跑五分钟，再在测速运行时跑一次，最后补上 Waveform 的缓冲膨胀（bufferbloat）测试。他那条线路的 Ookla 成绩是下行 617.5Mbps、上行 577.7Mbps，足够快，但这远不是全部真相。

第一步：先把测速页上最小的那行字看完

延迟是往返一次所需的时间，页面加载是否“秒开”、通话是否自然、游戏是否跟手，都由它决定，而吞吐量几乎管不着——1Gbps 的线路照样可能延迟高得难受。多数测速工具其实会给出延迟值，只是它被排版成结果页上最小的一行字。这个数字越低越好，超过 100ms 就会明显影响在线服务，尤其是网络游戏。

在上述测试中，Waveform 测得空闲延迟 34ms，WinMTR 显示每一跳约 9 到 11ms，属于不会拖累游戏的水平。

第二步：换一个会报抖动和丢包的测速工具

抖动指的是每次 ping 之间的波动幅度，而不是某一次 ping 的数值。平均延迟漂亮却抖动剧烈，正是视频通话忽然卡顿、对局中莫名掉帧的元凶。测试中 Waveform 记录的抖动只有 4.1ms，看着平平无奇；但最初那次 Ookla 上行延迟 10ms、抖动 11ms，峰值却冲到 298ms——平均值把问题抹平了，体感却是不稳定。

丢包则是干脆没送到、需要重传的数据，直接对应通话冻结和跳帧。麻烦的是，Ookla、谷歌自带测速、Netflix 的 Fast 等主流工具通常都不显示丢包。想看这两项，可以改用 Cloudflare 的测速页（speed.cloudflare.com），它会同时给出抖动、丢包等信息。

第三步：跑一次满载测试，看延迟涨多少

测速工具默认测的是单台设备的独享速度。一台设备在线时它相当准，可到了晚上八点、全家人同时看剧打游戏开语音，画面就完全不同了——这类网络拥塞，普通测速根本不衡量。

缓冲膨胀测试正是用来补这一课的：它在把带宽压满的同时观察延迟涨幅。测试中，负载一上来，Waveform 记录到下行延迟增加 29ms、上行增加 5ms，仍能拿到 A 级；WinMTR 的满载追踪也印证了这一点，每一跳的最差值都随之上升（其中一跳从 60ms 涨到 72ms），但各跳平均值几乎没变。

第四步：用 WinMTR 定位是哪一段出问题

WinMTR 是一款免费开源工具，相当于把 ping 和 traceroute 合成一个界面，能实时看到数据经过的每一跳，从而判断速度是在哪一段被拖慢的。用法是先在空闲状态跑上五分钟做基线，再一边跑测速一边记录，两份数据对照着看。

注意：某一跳 100% 丢包，未必是线路坏了

测试中每一次 WinMTR 追踪都会出现一跳显示 100% 丢包，单看那一行足以让人以为线路已经瘫痪，可测速全程顺利完成。原因在于 ping 和 traceroute 走的是 ICMP 协议，而许多路由器会限速甚至直接忽略发给自己的 ICMP 请求——因为回应这些请求会挤占它转发流量的本职资源——但真正的数据包仍会照常走另一条内部路径转发。只要追踪能跑到最后一跳且末跳有正常数据，中间这种“黑洞跳”就不必紧张。

拿到数据之后怎么办

重点看延迟和抖动两项。如果测速数字很大，但延迟和抖动同样很高，说明问题出在别处：可能是路由器设置需要调整，可能是无线环境下路由器摆放位置不合适，也可能是链路上某一跳出现拥塞，那就不是用户这端能解决的了。

另外一定要多测几次。同一条线路，这一次测出来像是着了火，下一次可能各项指标都平顺得很。测速给出的那个大数字并非毫无意义，只是当连接“感觉很黏”时，还得靠上面这些指标才能找到真正的原因。

来源：MakeUseOf