企业官网建设流程全解析

想给家里宽带"讨个说法"，最靠谱的办法不是反复刷新测速页面，而是先攒一张连续几个星期的测速曲线。我把 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 和几种常见测速方式的对比

我简单做一个对比，表格未必覆盖所有情况，但基本能说明问题：

我并不是说网页测速没用。开发调试、临时排查时随手点一下很方便，但它的短板在于"不可积累"。我要做的本来就是长期监测，所以从一开始就排除了手动方案。

2.3 部署载体怎么选

MySpeed对硬件要求很低，只要能跑Docker的Linux设备都行。我建议按这个优先级考虑：

• 家里已有的常驻小主机、NAS、软路由：加一个容器最省事，不用额外养设备。
• 闲置的旧笔记本、旧迷你主机：装个Linux或直接跑Docker，性能完全够。
• 单板电脑（比如一百多块的ARM小板子）：功耗几瓦，7x24开机不心疼，是性价比最高的选择。

无论用哪种设备，有一条铁律必须遵守：测速设备用网线接到路由器或光猫的LAN口，不要用Wi-Fi连接。原因很简单，Wi-Fi本身就是一个不稳定的变量——微波炉干扰、楼上楼下信号、网卡驱动，都可能让测速曲线上下跳。你监测的是"宽带"的速度，不是"无线"的速度，所以接入方式必须先把无线这部分排除掉。实测中，同一台设备走Wi-Fi和走网线，结果能差30%以上，而且Wi-Fi的抖动会污染延迟数据，让看板上的异常曲线根本没法判断是运营商问题还是无线问题。

3. 从零部署：环境准备与Docker一键拉起

3.1 部署前先确认三件事

别看部署就一个容器的事，前期三件小事搞不定，后面会反复回来改：

1. 确认设备IP是固定的。最简单的方法是在路由器后台给这台设备做DHCP静态绑定，或手动指定一个保留地址。如果不固定IP，下次设备重新拨号，看板地址变了，你访问不到不说，家里其他自动化脚本也会跟着乱。
2. 确认一个空闲端口。MySpeed的Web界面默认监听某个固定端口，我习惯在宿主机上重新映射一个不常用的端口，比如9003。这样不会和家里已有服务（NAS管理页、其他容器）打架。映射完记得确认端口没被占用，端口冲突导致容器启动失败这个问题，我一开始就撞上过。
3. 确认数据目录的磁盘空间。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: - TZ=Asia/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 测速节点：直接影响结果的"隐藏开关"

这个坑特别大，必须单独拿出来说。同一个宽带套餐，选不同的测速节点，结果可能天差地远。原因很简单：测速节点就是你家宽带链接到的"另一端"，它如果距离远、跨网、拥塞，你的下行速度就会明显打折，但这个折不是你宽带的真实水平。

我的做法是：

1. 在可用节点列表里，优先选本地区域、且和宽带线路同一运营商体系的节点。
2. 选好之后固定下来，不要让它每次自动随机换。自动选节点虽然一般会选"当时最好"的，但"最好"每次都不同，会让曲线带上节点切换的噪声，没法连续比较。
3. 如果某次测速突然掉得离谱，先确认是不是节点的问题——手动换同区域的其他节点再测一次。我遇到过某个节点连续几天全线掉速，换节点后又恢复正常，说明那几天看板上的曲线看起来像"家里网速崩了"，其实是节点侧的事。

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 测速结果"虚低"，我的排查顺序

长期运行时，偶尔会遇到某次结果低得离谱。我的排查顺序是这样的：

1. 确认测速时段和自家负载有没有重叠：先看那几分钟家里有没有人打游戏、下大文件。很多人会忽略一个细节——测速本身就在占满带宽，如果同时有人用网，两边都会遭殃。
2. 确认测速节点是否异常：换一个同区域节点手动测一下。如果手动测速正常，那是节点问题，不是宽带问题。
3. 确认设备本身没有在跑任务：哪怕是我选的常驻设备，也可能因为系统更新、日志清理占用CPU。极端情况下设备满载，也会让测速引擎测出偏低数字。
4. 确认不是光猫或路由器的定时重启窗口：我观察过好几次，光猫在凌晨自动重启的间隙，测速结果会断崖式下跌。如果你的看板在某个固定时间点每天准时掉速，先别怪运营商，去光猫后台看看定时重启设置。

这套顺序跑一遍，能挡住九成的"假异常"。

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，麻烦你看一下这条链路"。对解决实际问题来说，这种方式比任何翻来覆去地刷新测速页面都管用。