想给家里宽带讨个说法最靠谱的办法不是反复刷新测速页面而是先攒一张连续几个星期的测速曲线。我把 MySpeed 部署到家里一台7x24小时开机的常驻设备上让它定时自动测速做成一个24小时测速看板网速好坏终于有了连续的、带时间戳的数据也能当成跟运营商沟通时的正经证据。这篇文章就是我从选型、部署、调参到长期运行踩坑的完整记录适合手里有NAS、小主机或旧电脑想搞清楚自家网络真实水平的朋友。1. 为什么为了一张网速曲线值得折腾一台常驻设备1.1 你测出的速度和真实体验常常是两套数据大多数人判断家里网速的方式是打开浏览器随便找个测速页面点一下。结果数字好看就继续用数字难看就刷新再来一次。但这里有个根本性问题网页测速测的是此时此刻、这台设备、这条链路的状态而你抱怨的是经常卡、有时候好有时候坏的整体体验。两者根本不是一个维度。拿我自己举例。家里宽带标称300M白天测速基本都在280M以上数字很漂亮。可一到晚上8点到11点视频会偶尔缓冲在线会议偶尔断断续续。白天无论怎么测速都重现不了这个问题因为高峰期拥堵发生在运营商出口和区域接入网白天那些链路根本没压力。你手动测一百次只要每次都在白天测结论就永远是网络没问题。单个时间点的测速还有一个隐患它容易被人为操作掩盖。测速前特意关掉其他设备、靠近路由器、关掉所有抢占带宽的任务测出来的就是理论最快速度不是日常真实速度。这种测法对用户自己没坏处但如果你想拿它判断要不要投诉运营商或是不是该换路由器那就用错地方了。1.2 人工手动测速的三个盲区手动测速的主要问题归纳起来是三个盲区测不准时段我不是24小时都有空更不会凌晨三点起来测速但恰恰是深夜的曲线能区分运营商高峰拥塞和我家路由器老化这两种完全不同的故障成因。没有历史一次测速是孤立的数字测完就没了。网络问题时有时无想回头比对某天、某周的变化靠手动记录根本不现实。环境变量太多用手机测Wi-Fi信号稍微抖一下数字就掉一半用电脑测后台一个备份任务跑起来结论完全废掉。每次测速的环境不统一结果之间根本没有可比性。1.3 一张24小时看板能回答的具体问题把测速工具放到家里的常驻设备上让它固定间隔自动跑攒出连续曲线之后很多以前靠猜的问题就有了明确答案晚高峰到底掉到多少是掉20%还是掉60%曲线上的坑是不是和家里某台设备定时任务的时间重合重启路由器之后速度是不是真的恢复了运营商所谓的深夜维护在你的曲线上能不能看到对应的窗口升级宽带套餐之后实际数字有没有变化这些问题只要有数据曲线基本一眼就能看出来。这也是我最终决定上24小时看板的核心原因我不想在和宽带客服沟通时只能靠感觉我想给他们一张带时间戳的图。2. MySpeed的测速原理以及同类方案里我为什么选它2.1 它到底是怎么工作的MySpeed是一个自托管的测速监控工具。它不需要你打开浏览器而是跑在一台常驻设备上按你设定的时间间隔自动调用内置的测速引擎对指定的测速节点做一次完整测速下载、上传、延迟、抖动然后把结果写进SQLite数据库最后通过Web界面把历史数据渲染成趋势图。理解它的定位很重要它测的不是某台电脑连上某个网站的速度而是你家宽带这条链路从常驻设备到测速节点的传输能力。因为常驻设备固定在同一个位置、用同一根网线、跑同一种测速流程所以每次结果之间的差异主要来自运营商链路和设备状态而不是你换个地方坐着导致的Wi-Fi波动。这就保证了数据的可对比性——测量条件一致曲线才有分析价值。MySpeed的内部结构并不复杂Web界面负责配置和展示一个定时调度负责触发测速SQLite负责存储。整个逻辑类似于手机定个闹钟每半小时自动测一次速再把结果记在本子上只不过它把这些全部自动化了还顺手把图表画好。2.2 和几种常见测速方式的对比我简单做一个对比表格未必覆盖所有情况但基本能说明问题方案是否自动连续测速历史数据环境一致性部署成本适合场景浏览器网页测速否需手动基本没有差设备、Wi-Fi都在变零临时确认一下路由器后台自带测速通常只能手动触发大多不保存较好但受路由器自身性能影响零快速看个大概自己写脚本定时测速可以需要自己存较好中等要自己搭图表喜欢从零折腾MySpeed这类自托管看板可以默认支持SQLite长期保存好固定设备固定条件低一个容器搞定想持续观察、留存证据我并不是说网页测速没用。开发调试、临时排查时随手点一下很方便但它的短板在于不可积累。我要做的本来就是长期监测所以从一开始就排除了手动方案。2.3 部署载体怎么选MySpeed对硬件要求很低只要能跑Docker的Linux设备都行。我建议按这个优先级考虑家里已有的常驻小主机、NAS、软路由加一个容器最省事不用额外养设备。闲置的旧笔记本、旧迷你主机装个Linux或直接跑Docker性能完全够。单板电脑比如一百多块的ARM小板子功耗几瓦7x24开机不心疼是性价比最高的选择。无论用哪种设备有一条铁律必须遵守测速设备用网线接到路由器或光猫的LAN口不要用Wi-Fi连接。原因很简单Wi-Fi本身就是一个不稳定的变量——微波炉干扰、楼上楼下信号、网卡驱动都可能让测速曲线上下跳。你监测的是宽带的速度不是无线的速度所以接入方式必须先把无线这部分排除掉。实测中同一台设备走Wi-Fi和走网线结果能差30%以上而且Wi-Fi的抖动会污染延迟数据让看板上的异常曲线根本没法判断是运营商问题还是无线问题。3. 从零部署环境准备与Docker一键拉起3.1 部署前先确认三件事别看部署就一个容器的事前期三件小事搞不定后面会反复回来改确认设备IP是固定的。最简单的方法是在路由器后台给这台设备做DHCP静态绑定或手动指定一个保留地址。如果不固定IP下次设备重新拨号看板地址变了你访问不到不说家里其他自动化脚本也会跟着乱。确认一个空闲端口。MySpeed的Web界面默认监听某个固定端口我习惯在宿主机上重新映射一个不常用的端口比如9003。这样不会和家里已有服务NAS管理页、其他容器打架。映射完记得确认端口没被占用端口冲突导致容器启动失败这个问题我一开始就撞上过。确认数据目录的磁盘空间。MySpeed的数据是SQLite体积很小但日志和Docker镜像会占空间。给容器数据目录单独分一个路径比把数据随便埋在某个大杂烩目录里更好管理备份也清晰。3.2 用Docker Compose把它拉起来我当时的docker-compose大致长这样不同版本参数可能有变化以官方README为准services: myspeed: image: germannewsmaker/myspeed:latest container_name: myspeed restart: unless-stopped ports: - 9003:5216 volumes: - ./myspeed-data:/storage environment: - TZAsia/Shanghai启动命令就一条docker compose up -d几点说明restart: unless-stopped必须加。这台机器要7x24自己跑没有这个策略宿主机重启一次测速就停一天。端口映射我写成9003:5216左边是宿主机访问端口右边是容器内部端口。容器内部端口以官方镜像实际配置为准版本更新后可能有变化用之前看一眼官方文档最稳妥。数据目录./myspeed-data放在独立路径下后面备份就备份这一个目录不用从容器文件系统里翻。TZ设置时区时间不对的话看板上的时间轴会和你实际生活对不上分析曲线会非常别扭。3.3 首次打开界面和初始化设置启动完浏览器访问http://你的设备IP:9003就能看到MySpeed的Web界面。首次打开之后先去设置页面把下面几项填好测速间隔先按默认值跑通后面再细调。测速节点选靠近你、且和你宽带线路同网段的节点这个对结果影响非常大后面单独讲。图表展示如果首页图表还没出图不用慌让它先跑几次测速积累数据。第一次测速特别慢是正常的——它会先建立完整基线包含延迟测试、下载、上传。我当时第一次跑完差不多等了两分钟图表上才出现第一个点。后面每次测速就在几十秒级别不会这么磨叽。提示部署完先别急着调各种参数让默认设置跑完几次测速确认曲线在正常出数再开始动配置。否则配置问题和网络问题混在一起排查起来非常痛苦。4. 从单次测速变成全天候监测的关键设置4.1 测速间隔怎么定最合适MySpeed的价值核心在定时触发间隔设置是里面最重要的一项。太密浪费流量、影响家人用网太稀曲线毛刺太多看不出趋势。我自己的建议分两档每30分钟一次适合大多数家庭。一天48个点曲线足够平滑能看出晚高峰、凌晨波动又不会频繁到打扰人。每2小时一次如果家里对带宽敏感有人打游戏、开会、看直播或者用的是流量受限的网络就调稀一点保留基本趋势就好。网上也有人直接设成5分钟一次我个人觉得没太大必要。宽带链路在分钟级别不会突然劣化除非运营商在反复调度。5分钟一次的曲线虽然更精密但对家庭网络诊断来说信息量并没有比30分钟一次多多少反而多花十几倍的测速流量。晚高峰的波动通常以半小时为粒度变化30分钟采样的时间分辨率足够抓住它了。4.2 测速节点直接影响结果的隐藏开关这个坑特别大必须单独拿出来说。同一个宽带套餐选不同的测速节点结果可能天差地远。原因很简单测速节点就是你家宽带链接到的另一端它如果距离远、跨网、拥塞你的下行速度就会明显打折但这个折不是你宽带的真实水平。我的做法是在可用节点列表里优先选本地区域、且和宽带线路同一运营商体系的节点。选好之后固定下来不要让它每次自动随机换。自动选节点虽然一般会选当时最好的但最好每次都不同会让曲线带上节点切换的噪声没法连续比较。如果某次测速突然掉得离谱先确认是不是节点的问题——手动换同区域的其他节点再测一次。我遇到过某个节点连续几天全线掉速换节点后又恢复正常说明那几天看板上的曲线看起来像家里网速崩了其实是节点侧的事。4.3 数据保留、备份与清理MySpeed把数据存在SQLite里每30分钟一条记录一年下来也就一万多行文件大小在几十MB量级基本不用担心膨胀。但正因为大家都觉得它小反而容易忽视备份。我自己的习惯是把myspeed-data目录做个定时备份同步到NAS或另一块盘每周一次就够。磁盘空间不是问题但如果强迫症发作可以定期清理掉旧节点产生的冗余记录。后续想深入分析直接把数据目录下的SQLite文件拷出来用桌面数据库工具打开就行。表结构很直白一般有记录时间、下载、上传、延迟、抖动这些字段。按小时分组求平均就能得到我家宽带周一到周日每天的平均曲线这种更宏观的报表。5. 看板怎么读四个指标和三种典型异常曲线5.1 下载、上传、延迟、抖动分别说明什么看板首页通常会同时显示四条曲线下载、上传、延迟响应时间、抖动延迟的波动幅度。很多人只盯着下载看其实其他三个指标才是体感卡顿的主要来源下载决定你看视频、下文件、开网页的速度。大多数人关心的网速其实就是它。上传决定你视频会议、直播、传大文件的速度。家里有人开视频会上行带宽被占满下载也会连带变慢——因为网络传输的确认报文走的是上行通道。延迟从你家到测速节点的往返时间。它影响游戏、Web页面的即时响应。下载很快但延迟很高打游戏照样卡。抖动延迟的起伏幅度。延迟本身不高但忽高忽低就是抖动大通常表现为语音断断续续视频偶尔卡一下。这个指标最容易被忽视但它和Wi-Fi干扰、设备资源争抢关系密切。用生活化的比喻来说下载是车道宽度延迟是从家到公司的路程抖动是路上红绿灯和堵车的随机程度。车道宽不代表不堵路程短也不代表一路绿灯——四个指标是互相独立的维度都得看。5.2 三种典型异常曲线的解读方法根据我大半年观察自家看板的经验常见异常曲线大致有这几类每类的成因指向完全不同第一类白天平稳晚高峰掉速。曲线出现明显的饭点塌陷比如18:00到23:00持续走低。这种多半是运营商出口或区域接入网拥塞和家里设备关系不大。判断方法很简单看掉速的时间是否每天都稳定在同一窗口。如果连续多日都是同一个时段掉基本可以肯定是共用链路问题。报修时把连续几天的曲线截图发出去比单次测速有说服力得多。第二类随机出现的孤立深坑。某一次测速突然掉到平时的三分之一下一条又恢复正常。这种通常是偶发因素造成的测速节点临时抖动、某台设备刚好在跑大流量任务、Wi-Fi信道突然被干扰。遇到孤立点我的原则是先看它有没有复现单独一个点不值得下结论。第三类整体趋势逐步恶化。连续几周的平均速度缓慢下降晚高峰的坑越来越深。这种情况要警惕往往不是运营商的问题而是家中链路某处硬件老化或过热光猫用了太久、网线水晶头氧化、路由器长期运行性能衰减。看板的价值恰恰在于能暴露缓慢恶化——单次测速看不出来自己体感也未必明显但曲线会诚实地告诉你趋势在变差。5.3 和路由器后台数据交叉验证看板告诉你什么时候慢但想知道是谁造成的最好再配合路由器后台的实时流量统计。具体做法发现看板有异常下滑时立刻登录路由器后台看当前各终端的实时上下行带宽。如果当时恰好有一台设备在跑大流量比如NAS同步、手机系统更新那这次的坑大概率是自家设备抢占不算链路问题。反过来如果所有终端都没什么流量偏偏看板显示掉速那链路出问题的嫌疑就大多了。这种先排除自家因素再下结论的流程是跟运营商报修时最拿得出手的证据。我自己报修过两次一次提交了晚高峰连续一周的曲线一次结合路由器后台截图说明非高峰时段没有明显流量但速度依然低。两次都让维修人员带了针对性的设备上门而不是在我家门口做一遍拨号重启的例行公事。6. 长期运行踩坑实录数据、网络和资源占用6.1 容器重启后数据不在了MySpeed部署本身不难跑起来之后的各种坑才是真正的隐藏关卡。我遇到的第一个坑是某天设备断电重启起来之后看板发现历史数据全没了只剩几条刚生成的新记录。原因非常简单容器启动时如果没挂载数据目录或者挂载路径写错了数据就写在容器的临时文件系统里容器一删、一重启目录就没了。Docker容器的文件系统默认不可持久化这是新手最容易踩的坑。解决办法就是前面compose里做的把数据目录通过volume挂载到宿主机的./myspeed-data并且确认容器启动日志里没有挂载失败的报错。验证方法也很容易跑完几次测速后去myspeed-data目录看有没有数据库文件生成。如果容器删掉重建之后历史数据还在说明挂载成功了。6.2 测速结果虚低我的排查顺序长期运行时偶尔会遇到某次结果低得离谱。我的排查顺序是这样的确认测速时段和自家负载有没有重叠先看那几分钟家里有没有人打游戏、下大文件。很多人会忽略一个细节——测速本身就在占满带宽如果同时有人用网两边都会遭殃。确认测速节点是否异常换一个同区域节点手动测一下。如果手动测速正常那是节点问题不是宽带问题。确认设备本身没有在跑任务哪怕是我选的常驻设备也可能因为系统更新、日志清理占用CPU。极端情况下设备满载也会让测速引擎测出偏低数字。确认不是光猫或路由器的定时重启窗口我观察过好几次光猫在凌晨自动重启的间隙测速结果会断崖式下跌。如果你的看板在某个固定时间点每天准时掉速先别怪运营商去光猫后台看看定时重启设置。这套顺序跑一遍能挡住九成的假异常。6.3 常驻测速对家人和其他设备的占用很多人会担心这么频繁地测速会不会把家里网搞得更卡我的实际感受是单次测速花不了多长时间默认流程跑下来也就十几秒到几十秒而且只在设定好的时刻触发不会一直在后台跑。设成每30分钟一次相当于每半小时抢十几秒带宽对日常使用影响非常小。但有一个特殊情况如果测速间隔设得太密比如5分钟一次而且每次测速的下行带宽很大那么在某些关键时刻比如刚好赶上家人打游戏测速就会成为抢占带宽的那个讨厌鬼。所以我前面才反复强调默认30分钟就好别为了曲线好看牺牲全家人的体验。另外常驻设备的功耗和发热也要留意。单板电脑功耗在几瓦级别旧笔记本稍高一些但只要通风正常都没问题。担心温度的话把设备放在通风处偶尔看下系统温度——毕竟7x24开机跑半年以上散热出问题的情况也不是没有。7. 让看板从记录工具变成家庭网络运维助手7.1 配合HTTP监控做故障告警MySpeed自己的Web界面不会主动通知你网速崩了但你可以拿它做一个变通的告警用一个外部监控探针定时检查http://你的设备IP:9003是否还能正常响应。如果页面打不开说明设备或看板挂了如果页面能打开但测速曲线连续几次都是零或极低说明链路可能出了问题。再进一步可以把看板地址和测速数据接进自己的告警体系。比如让监控脚本在连续3次测速结果低于套餐带宽的50%时往你常用的IM工具里推一条消息。这样你不用每天蹲在看板前盯曲线异常出现时系统会主动告诉你。这个玩法本质上就是把被动记录变成主动告警需要动手写一点简单脚本但绝对值得。7.2 把数据导出做长期趋势分析你可能不满足于看板自带的图表想回答更宏观的问题这个月家里平均网速比上个月快还是慢周末晚高峰和平日差多少直接导出SQLite数据就能算。工具上随便选一个能打开SQLite文件的桌面数据库软件就行。打开文件后找到存储测速记录的那张表确认字段名一般会有时间戳、下载、上传、延迟、抖动然后写几句SQL做分组统计。以按小时求平均下载速率为例思路大致是SELECT strftime(%H, ts) AS hour, AVG(download) AS avg_download FROM speedtest_results GROUP BY hour ORDER BY hour;不同版本的表名和字段名可能不完全一样但思路是一样的。把这些按小时的平均值画出来你就能得到一份我家宽带全天各时段的速度画像——这比单看某一天的曲线稳定得多也是向运营商反映晚高峰长期不达标的最有力材料。7.3 报修时怎么利用看板数据最后说一个非常实用的场景报修。以前报修网络问题维修师傅上门的第一句话通常是现在测速多少你说刚才测了还行问题就陷入死循环师傅上门时网络恰好恢复了他没法复现故障只能让你再观察观察。有了24小时看板之后我的做法变成发现问题时立刻保存几天的异常曲线截图注明时间窗口最好再附上路由器后台的流量记录证明排除自家设备占用。把这些材料理好不管上门的是哪位师傅都能直接看到问题长什么样、发生在什么时段。实测用这套材料报修对话的质量完全不一样——从我觉得慢变成数据在这里每天20点到23点下载平均掉到X麻烦你看一下这条链路。对解决实际问题来说这种方式比任何翻来覆去地刷新测速页面都管用。