Latency

GET/api/v1/latency

读取多个外部 Latency Agent 到指定公开 TCP 目标的历史。Cloudflare 自身延迟不在此响应中，应从 Status 或 Checks 获取。

查询参数

参数	必填	默认	范围	说明
target_id	是	—	公开 TCP 目标 ID	被探测目标
hours	否	24	1–168	历史窗口

curl -fsSL 'https://YOUR-API/api/v1/latency?target_id=vps-a&hours=24'

响应结构

{
  "ok": true,
  "target_id": "vps-a",
  "sources": [
    {
      "id": "home-shanghai",
      "name": "Shanghai Telecom",
      "kind": "external",
      "points": [
        {
          "checked_at": 1760000000,
          "latency_ms": 28.4,
          "ok": true
        }
      ]
    }
  ]
}

sources[]

每个来源对应后台创建并实际成功上报的 Latency 节点。创建节点记录本身不会产生数据；只有安装命令完成首次提交后，节点才会进入历史响应。

Status 中的 latency_sources 只保留仍在 stale 窗口内的最新来源，而本端点按 hours 返回保留期内历史。因此“历史里有旧点，但当前图例不显示节点”可能是节点已经停止上报。

排障顺序

如果前端只有 Cloudflare：

1. 后台检查节点是否启用且“最近上报”不是空；
2. 在 Latency 节点检查 systemd 服务和 journal；
3. 手动运行一次 --once，确认 accepted 大于 0；
4. 确认目标是启用的公开 TCP 目标，且没有隐藏公网地址；
5. 等待状态短缓存刷新，再检查本端点是否出现 sources。

部署新命令时应让安装器清理所有旧进程。旧 Agent 仅重启可能继续使用过期脚本、节点 ID 或 Token。