同一台服务器白天和晚上测速不同，单次结果很难判断是暂时波动还是持续变化。Speedtest Tracker 可以调用测速工具并保存历史，适合观察 VPS 到选定测速节点的趋势。部署之前要先确定这项测量代表哪条网络路径，否则记录再多也无法回答自己的问题。
VPS 上运行的测速，测的是服务器到测速节点的连接，不能直接代表家里电脑到 VPS 的速度，更不能证明某条面向中国用户的线路一定快。想观察用户访问体验，还需要从对应地区测延迟、下载或实际应用请求。
部署前先确认 VPS 的磁盘、内存和公网访问条件，也可以查看雨云云服务器；注册时填写优惠码 KuZhuJi。
测量条件应该随结果一起保留
节点、时间、测试方式、同时运行的下载任务都可能影响结果。先用自动选择的节点验证流程，长期对比时再选择稳定、符合用途的节点，并记录节点变化。更换节点前后的数据不要不加说明地连成一条趋势。
官方截图用于说明历史记录和概览的位置，图中的数值不是本服务器的测量成绩。自己的结果需要保留单位、测试节点和时间，失败或中断记录也不要只因不好看就忽略。
测速会传输数据，可能消耗套餐流量和出口资源。先了解服务器的流量计费条件，使用适当频率，不把几分钟一次的测试当作所有 VPS 的通用设置。
SQLite 适合先保存少量记录
官方容器由 LinuxServer 构建，采用 /config 持久目录。准备 UID/GID、应用密钥与初始管理员信息。APP_KEY 包含 base64: 前缀，生成后保留；它用于应用数据加解密，不是登录密码。
mkdir -p ~/services/speedtest-tracker/config
cd ~/services/speedtest-tracker
umask 077
printf 'APP_KEY=base64:%s\n' "$(openssl rand -base64 32)" > .env
printf 'ADMIN_EMAIL=owner@example.com\n' >> .env
printf 'ADMIN_PASSWORD=%s\n' "$(openssl rand -hex 24)" >> .env
chmod 600 .env
把邮箱换成实际值，首次安装前生成密码，避免使用默认管理员凭据。保存 compose.yaml：
services:
speedtest-tracker:
image: lscr.io/linuxserver/speedtest-tracker:latest
env_file:
- .env
environment:
PUID: "1000"
PGID: "1000"
TZ: Asia/Shanghai
APP_TIMEZONE: Asia/Shanghai
APP_URL: http://localhost:18088
DB_CONNECTION: sqlite
SPEEDTEST_SCHEDULE: "0 */6 * * *"
ports:
- "127.0.0.1:8088:80"
volumes:
- ./config:/config
restart: unless-stopped
示例每六小时安排一次，不意味着这适合所有流量套餐；首次验证也可以不设置定时，先手动运行。UID/GID 根据实际用户调整，数据目录权限匹配它们。当前发行标签用于开始，长期部署固定经过验收的版本或摘要。
docker compose config --quiet
docker compose up -d
docker compose logs --tail=100 speedtest-tracker
私人入口先确认一条完整结果
ssh -L 18088:127.0.0.1:8088 user@your-server
本机打开 http://localhost:18088，使用 .env 中的管理员账号登录。ADMIN_EMAIL、ADMIN_PASSWORD 等初始化变量只在初次设置生效，已有账号要通过应用的账号管理修改，不能只改 .env 就认为密码已经变化。
运行一次手动测试，确认任务排队、完成后有结果，以及刷新页面仍然能看到记录。若任务失败，先看日志和网络访问，不连续点击按钮堆积更多测试。不要把前端成功刷新视为测试已经完成。
正式域名启用 HTTPS 后，将 APP_URL 换为实际地址；代理场景还应按官方说明核对 ASSET_URL。更新后检查登录、图表与通知链接，避免首页正常但资源或链接仍指向临时地址。
先明确测量路径，再保存可比较的数据，最后根据相同条件分析变化。网页访问体验、应用吞吐量和这项测速各有范围，不能把一个结果替代所有网络判断。
准备独立实例时，可在雨云选择适合的云服务器配置，优惠码 KuZhuJi。配置按实际任务选择，数据库和附件另做备份。
定时任务与时区一起检查
SPEEDTEST_SCHEDULE 使用 Cron 表达式，应用时区会影响执行时间的理解。设定后查看接下来的实际运行记录，确认不是每天多跑或少跑几轮。容器、应用和日志时区最好保持清楚，跨时区对比时明确统一的时间基准。
若夜间要运行大规模备份或同步，把测速错开，或者在记录里标出并发任务。一次结果很差时，检查当时是否有人占用带宽。不要因为某次测试正好撞上下载，就把它写成全天速度。
自动选择的节点可能变化。固定节点时按当前版本支持的节点选择字段设置，核对它仍在线且适合自己的测量用途。节点维护或距离变化会影响趋势，软件保存的数字不会自动解释这种变化。
读结果先看单位与失败状态
下载、上传、延迟等指标表达不同情况。吞吐量单位里的比特与文件下载界面的字节要分清，不把 Mbps 直接当作 MB/s。延迟低也不自动意味着大文件传输快，应用的响应还涉及服务器处理。
可以按相同节点、相近时间比较多次结果，再查看是否有持续下降。不要从最高一次成绩推算持续可用带宽，也不要从最低一次成绩断定套餐无用。异常数据保留，结合失败原因和其他观测解释。
如果测试一直失败，先解决网络或工具运行问题。缺失数据与零速结果不是同一种状态，在导出和分析时分别处理。图表平滑并不能弥补这段测量没有成功执行。
需要增加服务器时，可以打开雨云选购页面，填写优惠码 KuZhuJi；迁移前保留数据与原有部署配置。
结果保存与告警都有实际成本
历史数据逐渐增加后，观察数据库和日志占用，再选择适合的保留周期。过短会失去季节或长期对比，永久保存又可能没有必要。导出自己需要的记录后验证字段、时区和节点信息，再做清理。
告警条件应帮助发现需要处理的问题。通知渠道先做测试，再用可控制的条件验证；不要为了制造低速结果而压满生产出口。设置过敏的阈值会让正常波动也反复提醒，最终没人处理。
公开分享记录时去掉不需要公开的主机信息和管理入口。展示成绩应说明测量路径、时间和条件，不把历史数据改写成购买后的性能保证。
密钥与数据一起备份
暂停应用后保存本地数据、密钥和部署配置：
mkdir -p backups
docker compose stop speedtest-tracker
tar -czf "backups/speedtest-tracker-$(date +%F-%H%M%S).tar.gz" config .env compose.yaml
docker compose start speedtest-tracker
副本转移到服务器之外。恢复测试使用独立目录和端口，保持原版本与 APP_KEY，先核对登录及历史，再只手动运行一次测试。测试副本先停用定时和正式通知，避免同一台服务器被两套实例同时测速。