Latency

GET/api/v1/latency

Liest die Historie mehrerer externer Latency-Agents zu einem öffentlichen TCP-Ziel. Die eigene Latenz von Cloudflare steht nicht in dieser Antwort; nutzen Sie Status oder Checks.

Query-Parameter

Parameter	Pflicht	Standard	Bereich	Zweck
target_id	ja	—	öffentliche TCP-Ziel-ID	geprüftes Ziel
hours	nein	24	1–168	Historienfenster

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

Antwortstruktur

{
  "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[]

Jede Quelle ist ein im Admin-Panel erstellter Latenzknoten, der tatsächlich Ergebnisse eingereicht hat. Die Aufzeichnung zu erstellen erzeugt keine Daten; der Knoten kommt erst nach Abschluss der ersten Übermittlung seines Installationsbefehls in die Historie.

Wenn target_id fehlt, das Ziel nicht existiert oder deaktiviert ist, kann die Kompatibilitätsimplementierung HTTP 200 mit ok: false und error liefern. Clients müssen JSON-ok prüfen.

latency_sources in Status behält nur die neuesten Quellen im Frischefenster; dieser Endpoint liefert Historie innerhalb von hours. „Alte Punkte in der Historie, aber kein Knoten in der Legende" bedeutet meist, dass der Knoten nicht mehr meldet.

Fehlersuche-Reihenfolge

Zeigt das Frontend nur Cloudflare:

1. Prüfen, dass der Knoten aktiviert ist und im Panel ein aktuelles „letzter Bericht" hat.
2. systemd und Journal auf dem Knoten prüfen.
3. --once manuell ausführen und accepted > 0 bestätigen.
4. Bestätigen, dass das Ziel ein aktiviertes öffentliches TCP-Ziel ohne verborgene Adresse ist.
5. Auf das kurze Status-Cache-Refresh warten, dann sources hier prüfen.

Neue Installationsbefehle lassen den Installer alte Prozesse aufräumen; ein alter Knoten bloß neu zu starten kann weiterhin veraltete Skripte, Knoten-IDs oder Tokens verwenden.

Standard-Cache 30 s mit target_id und hours im Key. Nur externe Quellen werden geliefert; aktuelle Cloudflare-Latenz kommt aus Status und Historie aus Checks.