Speedtest Tracker 自建网络测速记录：宽带跑稳后，用 cpolar 给客户远程验收时延和带宽

Speedtest Tracker 自建网络测速记录宽带跑稳后用 cpolar 给客户远程验收时延和带宽宽带最烦人的地方不是慢而是“偶尔慢”。客户说晚上开会卡家里人说直播掉帧运营商测速又刚好正常。这个时候只截一张测速图没什么说服力连续几天的下载、上传、时延、抖动曲线才有用。这篇我用 Speedtest Tracker 搭一个本地测速记录面板Docker Compose 部署、定时测速、看历史趋势再用 cpolar 临时把 Web 面板开放给客户、家人或远程同事验收。重点是宽带质量留痕不是状态页也不是系统监控。为什么我更喜欢持续测速而不是临时跑一次临时跑一次 speedtest只能证明“这一分钟网还行”。网络问题很多都出现在固定时间段晚上高峰期、上行打满时、NAS 备份时、直播推流时甚至是某个房间 Wi-Fi 干扰严重时。Speedtest Tracker 的价值就在这里它把每次测速结果保存下来面板里能看到下载、上传、Ping、抖动这些指标的历史变化。你不用靠记忆描述“昨晚好像卡了”直接把曲线拿出来看。我常用它做三类事情宽带安装或提速后连续跑一天看实际带宽是否稳定远程办公环境验收看会议时段的 Ping 和抖动是否异常给客户交付小型网络环境时用历史图证明链路质量而不是口头解释。这篇只使用演示数据。真实客户环境里不要把公网 IP、公司名称、内网网段、设备名称写进截图或备注里。准备目录和 APP_KEY演示机器只需要装好 Docker 和 Docker Compose。NAS、迷你主机、Linux 服务器都行Mac 或 Windows 也能用 Docker Desktop 跑起来。先建一个目录mkdir -p ~/speedtest-tracker-demo cd ~/speedtest-tracker-demoSpeedtest Tracker 需要APP_KEY做应用加密。生成一个新的 keyecho base64:$(openssl rand -base64 32 2/dev/null)复制输出结果后面填到.env。这个值不要发给别人也不要写进截图。它不是后台登录密码但属于应用密钥泄露后需要重新生成并更新配置。用 Docker Compose 部署 Speedtest Tracker这里我用 MariaDB 做数据库原因很简单数据和应用分开后面迁移、备份、清理都更顺手。安全边界也明确Web 面板只绑定127.0.0.1数据库端口不映射到宿主机。新建.envcat .env EOF PUID1000 PGID1000 TZAsia/Shanghai APP_KEYbase64:把刚才生成的APP_KEY放这里 APP_URLhttp://127.0.0.1:8080 DB_DATABASEspeedtest_tracker DB_USERNAMEspeedtest_tracker DB_PASSWORD请替换为一段长随机数据库密码 EOF再写docker-compose.ymlservices: speedtest-tracker: image: lscr.io/linuxserver/speedtest-tracker:latest container_name: speedtest-tracker restart: unless-stopped ports: - 127.0.0.1:8080:80 environment: - PUID${PUID} - PGID${PGID} - TZ${TZ} - APP_KEY${APP_KEY} - APP_URL${APP_URL} - DB_CONNECTIONmariadb - DB_HOSTdb - DB_PORT3306 - DB_DATABASE${DB_DATABASE} - DB_USERNAME${DB_USERNAME} - DB_PASSWORD${DB_PASSWORD} volumes: - ./config:/config depends_on: db: condition: service_healthy db: image: mariadb:11 container_name: speedtest-tracker-db restart: unless-stopped environment: - MYSQL_DATABASE${DB_DATABASE} - MYSQL_USER${DB_USERNAME} - MYSQL_PASSWORD${DB_PASSWORD} - MYSQL_RANDOM_ROOT_PASSWORDtrue volumes: - speedtest-db:/var/lib/mysql healthcheck: test: [CMD, healthcheck.sh, --connect, --innodb_initialized] interval: 10s timeout: 5s retries: 5 volumes: speedtest-db:划重点ports只写了127.0.0.1:8080:80。这表示宿主机本机能访问http://127.0.0.1:8080局域网其他机器不能直接扫到这个端口。数据库服务db没有ports字段所以 MariaDB 只在 Compose 内部网络里给应用访问不暴露到宿主机。启动服务docker compose up -d查看容器状态docker compose ps浏览器打开http://127.0.0.1:8080第一次进入后台后按页面引导创建管理员账号。这里不要使用真实生产账号也不要在教程、聊天记录、截图里展示密码。我的做法是给演示环境创建一个单独管理员账号密码用密码管理器生成验收结束后立刻改密或删除演示账号。先跑一次手动测速确认数据能入库服务起来后不急着开放给别人看先在本机跑通一次完整测速。进入面板后执行一次手动 Speedtest等待结果落库。一次结果里我会重点看四个值Download下行带宽影响下载、视频播放、会议接收画面Upload上行带宽影响直播推流、云盘同步、会议发言画面Ping基础时延越低越适合远程桌面、游戏、实时会议Jitter抖动代表时延波动视频会议卡顿经常和它有关。很多人只盯着下载速度其实远程办公更容易被上传和抖动坑。比如下行跑满 800 Mbps看起来很漂亮但上传只有 20 Mbps家里同时开云盘同步和视频会议体验照样糟糕。配置定时测速让曲线自己长出来手动测速只是开胃菜真正有价值的是定时任务。进入 Speedtest Tracker 的设置页面找到 Speedtest 或 Schedule 相关配置打开 scheduled tests设置执行频率。我的演示配置一般这样做普通家庭宽带每 30 分钟跑一次客户验收窗口每 15 分钟跑一次连续观察半天到一天长期留痕每 1 小时跑一次减少对网络和测速服务的打扰。如果面板支持指定测速服务器可以选离客户业务区域更接近的节点。不要为了好看专门挑最快节点验收时反而容易失真。客户关心的是实际业务体验测速节点应当和使用场景接近。设置好后等它自动跑几轮。结果页会逐渐积累数据Dashboard 里能看到趋势图Results 页面能筛选历史记录。Speedtest Tracker 还支持导出选中结果为 CSV交付报告或留档时很方便。怎么读这几条曲线看曲线时我不会只看峰值。峰值漂亮不代表网络稳定真正要看的是“低谷”和“波动”。下行带宽如果偶尔掉到套餐的一半以下需要结合时间点排查是不是晚高峰是不是有人在下载大文件是不是路由器 QoS 限速。上传带宽如果波动大要重点看云盘、监控录像、直播推流、NAS 异地备份这些上行业务。Ping 的绝对值能反映距离和链路质量但抖动更能解释“为什么平均速度不低会议还是卡”。如果 Ping 在 20ms 到 30ms 之间小幅波动体验通常稳定如果一会儿 20ms一会儿飙到 150ms视频会议、远程桌面、游戏都会感到明显顿挫。验收时我会截三类图最近一次测速结果、24 小时趋势图、异常时间段的 Results 列表。这样沟通效率很高客户能看到结论也能看到原始记录。用 cpolar 临时开放 Web 面板本地面板确认无误后再用 cpolar 开临时入口。这里的逻辑是Speedtest Tracker 仍然只监听127.0.0.1:8080公网访问能力交给 cpolar 隧道验收结束就关掉。启动临时隧道cpolar http 8080cpolar 会生成一个公网访问地址。把这个地址发给客户、家人或远程同事他们就能打开 Speedtest Tracker 面板查看测速历史。更稳妥的做法是专门创建一个临时演示账号只给查看测速结果需要的权限。验收对象只需要看曲线和结果不需要改系统设置、改数据库配置、改通知渠道。没有细粒度权限时就在现场共享屏幕或短时开放管理员账号验收后马上改密。这里千万不要把数据库端口开放出来也不要为了省事把 Docker socket 挂进容器。Speedtest Tracker 不需要控制 Docker挂载 Docker socket 只会扩大风险面。数据库也只给应用容器访问外部验收看 Web 面板就够了。演示数据和真实数据要分开这类网络测速数据看起来不敏感但截图里经常会带出环境信息公网出口区域、运营商、测速节点、时间规律、备注说明。如果是客户环境我建议只用演示数据写教程真实验收报告单独保存不混进公开文章。面板开放前我会做一遍清理检查页面上有没有客户名称、项目代号、内网地址检查账号头像、邮箱、通知配置有没有暴露真实信息检查 Results 列表里备注是否包含工单号或联系人检查截图是否只展示必要指标。如果只是给家人看宽带是否达标问题不大如果给客户验收就按交付资料处理。少给权限、少开时间、少暴露配置是最省心的安全策略。加一个阈值提醒定位异常更快Speedtest Tracker 支持阈值提醒和应用内通知。演示环境里可以设置一个简单规则下行低于套餐标称值的 70%、上传低于标称值的 70%、Ping 或抖动超过自己能接受的范围时记录一次提醒。这不是为了做状态页而是为了缩短排查时间。比如客户说“昨晚 9 点很卡”你打开历史记录如果 9 点附近有测速失败、上传低谷、抖动尖峰就能把问题范围缩小到那段时间再去查路由器、运营商、Wi-Fi 干扰或上行业务。我不建议一上来就接生产通知群。演示阶段用应用内通知就够了避免把测试告警刷到团队群里。等验收流程稳定再决定是否接邮件、Webhook 或其他通知渠道。常见坑端口和密码别图省事第一个坑是 Web 端口直接写成8080:80。这样局域网其他设备都能访问面板放在公司网络或客户现场并不合适。演示部署统一写127.0.0.1:8080:80需要外部验收时用 cpolar 短时开放。第二个坑是数据库端口暴露到宿主机。Compose 内部服务名db已经能让应用访问数据库不需要把数据库端口直接映射到宿主机。数据库一旦暴露弱密码、误扫、误连都会变成麻烦。第三个坑是演示账号用完不处理。很多临时开放事故不是工具本身的问题而是“临时”变成了“长期”。客户看完之后隧道没关、账号没改密、截图继续在群里转这才危险。临时开放后的收尾清单验收完成后我会按这个清单收尾关闭 cpolar 隧道确认公网地址已经无法访问修改临时演示账号密码或直接删除演示账号确认 Speedtest Tracker Web 端口仍然只绑定127.0.0.1确认 MariaDB 没有对宿主机暴露端口确认没有公开 Docker socket、数据库密码、APP_KEY和客户确认测速数据是否保留、导出 CSV或按约定清理清理公开截图里的客户名称、公网地址、备注信息。写到这里这套流程就很完整了Speedtest Tracker 负责持续测速和历史曲线Docker Compose 保证部署可复现cpolar 只负责短时远程验收。宽带质量这种东西别只靠一张截图说话让数据自己跑出来沟通会轻松很多。