当前显示的是演示数据，不是你的真实节点
本页会先尝试读取同目录下的 status.json。没读到就退回到演示数据，
所以你现在看到的在线/延迟都是模拟生成的。
接上真实数据的方法见本页第 03 节——把探测脚本放到监控机上跑就行。
01
当前状态
状态怎么定的：
正常 — 延迟 < 120ms 且丢包率 < 2%
降级 — 延迟 120–250ms，或丢包率 2–10%（能连，但会卡）
离线 — 连续探测超时，或丢包 > 10%
维护中 — 你手动标记的，不算故障
这四个等级是
给用户看的措辞，比"丢包率 7.3%"更容易理解，也避免了用户拿精确数字来质疑你。
02
节点清单
覆盖 – 个国家 / – 个城市。点表头可排序，输入可搜索。
03
接上你自己的真实数据
页面读的是同目录下这个 status.json。你只要让某个进程定期把它写对就行，
不需要后端、不需要数据库。
一个关键取舍：延迟从哪儿测
从你自己的监控机 ping 各节点，测到的是监控机到节点的延迟，不是用户到节点的。
两者可能差很多。所以更诚实的做法是多区域部署几个探测点（美西、欧洲、新加坡各一台），
取各地区结果的平均值，并在页面上写明"延迟为探测点均值，仅供参考"。
别把单一探测点的数字当成用户体验——那是给自己挖坑。
跑起来只要三步：
把脚本放到一台监控机上，编辑开头的目标清单（国家代码-城市代码 与 IP 的对应表）
先手动跑一次，确认生成的 status.json 内容对
加一条 crontab：*/5 * * * * /path/status-probe.sh >/dev/null 2>&1，然后让 Web 服务器把这个文件暴露出去
负载字段需要节点本地配合（脚本默认填
null，页面显示"—"）。
想显示真实负载，就在节点上跑一个只返回
{"load":42} 的小 HTTP 服务，脚本里会去取。