Häufige Fragen

In dieser Reihenfolge vorgehen: erst Version, dann Datenquelle, zuletzt Zugangsdaten und Cache. Wenn eine Fehlermeldung Passwörter, Sessions, Agent-Installationsbefehle oder Dritt-Secrets enthält, nicht in ein öffentliches Issue einfügen.

Systemupdate zeigt HTTP 429

Der Worker hat beim Lesen des offiziellen GitHub-Raw-Manifests ein Upstream-Rate-Limit getroffen; das ist kein Agent-Fehler. Seit 1.0.38 nutzen Update-Checks einen Sechs-Stunden-Erfolgscache, zusammengeführte parallele Anfragen und ein 15-Minuten-Fehler-Backoff. Ist die offizielle Quelle nicht verfügbar, wird der letzte erfolgreiche Cache verwendet; beim Kaltstart dient das vertrauenswürdige, mit dem Deployment gebündelte Manifest.

• „Verwende bereitgestellte Version / Cache-Ergebnis" ist eine sichere Degradierung.
• Nicht wiederholt aktualisieren oder die Retry-Frequenz erhöhen.
• Prüfen, dass /api/health, /update-manifest.json und /bin/VERSION dieselbe Version zeigen.
• Self-Hosted-Updates laufen über den NIE-SLA Online Update-Workflow des Deployment-Repositories; kein GitHub-Token-Feld nötig.

Zugriff über *.workers.dev

Selbst gehostete Deployments können standardmäßig die *.workers.dev-Adresse nutzen — ein frisches Ein-Klick-Deployment hat meist noch keine Domain und dies ist sein Haupteinstieg. Wenn du nach dem Binden einer eigenen Domain den parallelen Hostnamen nicht behalten möchtest (er würde Ratenbegrenzungen und Schutzmaßnahmen deiner Domain umgehen), füge die Textvariable ALLOW_WORKERS_DEV = false unter Worker → Settings → Variables and Secrets hinzu und speichere; die offizielle Produktionsseite deaktiviert die workers.dev-Route zusätzlich auf Konfigurationsebene. Prüfe außerdem den Pfad: die öffentliche Statusseite ist /, der Admin-Eingang ist dein konfigurierter ADMIN_PATH (nicht /admin).

404 nach Änderung des Admin-Pfads

Wenn ADMIN_PATH gespeichert ist, funktioniert der alte Einstieg sofort nicht mehr. Öffnen Sie „Worker-URL + neuer Pfad". Der Pfad ist keine Authentifizierung; die echte Grenze bleiben Passwort, kurze Session und optionales TOTP.

Agent veröffentlicht, aber Knotenversion unverändert

Agents pollen die Update-Policy; sie aktualisieren nicht alle im Moment der Release-Erstellung. Prüfen Sie agent_version, Online-Zustand und Manager-Status im Panel, dann auf dem Knoten:

sudo cftz status
sudo cftz log 100

Sehr alte Versionen können den aktuellen Manager oder die vollständige Verifikationskette vermissen; führen Sie den neuesten für diesen Knoten generierten Installationsbefehl erneut aus. Verwenden Sie nicht den Befehl eines anderen Knotens; sein Token ist Einzelknoten.

BusyBox-Knoten scheitern bei NQ/IP mit setpriv-Argumentfehlern

1.0.49-1.0.50 reichte GNU-setpriv --reuid/--regid-Argumente an BusyBox weiter; der spätere direkte Privilegienabstieg behob den Start, entzog NQ aber Raw-Socket-, Latenz- und Routenprobes, was „Aufgabe erfolgreich, aber Latenz alles 0, Rückroute NoData" ergab. Upgrade auf v1.0.58+: NQ und IP-Unlock laufen direkt unter dem Root-only-Manager, ohne nstatus-task, no_new_privs oder User Namespaces. Die Metriksammlung läuft weiter als unprivilegierter nstatus-Dienst; der Manager akzeptiert nur die zwei festen Aktionen und erzwingt Skript-SHA-256, private Verzeichnisse, keine Symlinks, festen PATH, Timeouts und Ausgabelimits.

v1.0.59 hob das NQ-Tiefenprüfungslimit von 30 auf 60 Minuten, damit langsame Platten während HardwareQuality nicht zu früh abbrechen; IP-Unlock bleibt bei 10 Minuten.

Seit v1.0.64 werden NQ-Optionen (HardwareQuality y/f/v/n, IPQuality y/n, NetQuality y/l/n, Rückroute y/n) pro Aufgabe in der UI gewählt, einzeln und in Batches; NQ-Aufgaben haben kein externes Timeout, und der Queue-Ablauf behält eine 7-Tage-Gnadenfrist.

v1.0.66 behob Batch-NQ, das auf alten Agents bei ~600 s per exit 124 beendet wurde: Der Worker sendet für Agents vor v1.0.64 erneut ein 3600-Sekunden-Kompatibilitätslimit; v1.0.64+-Agents haben weiterhin kein externes Timeout.

v1.0.67 behob Batch-NQ/IP-Dialoge, die nach „Queue bestätigen" nicht schlossen, fehlende Toasts und nicht startende VPS: Batches erstellen Aufgaben jetzt 5 auf einmal, das Frontend schließt den Dialog sofort mit Queue-Hinweis, und das Batch-Anfragen-Timeout stieg auf 60 s.

v1.1.0 wechselte zu Dezimalversionen (1.1.0): Backup-Vorschau/Wiederherstellung erhielt Low-Frequency-D1-Rate-Limiting, und Aufgaben-Timeouts weisen jetzt darauf hin, dass „die Anfrage serverseitig noch laufen kann, später aktualisieren".

v1.1.1 ergänzte für NQ-/IP-Unlock-Aufgaben einen erzwungenen Stopp: bereits in der Warteschlange stehende Aufgaben werden sofort abgebrochen, laufende Aufgaben beendet der neue Agent nach Erkennung des Abbruchkennzeichens als gesamte Skript-Prozessgruppe; Tabelle und Detaildialog zeigen einen „Stopp erzwingen"-Button und den Status „Wird gestoppt".

v1.1.2 bevorzugt auch im öffentlichen Status und im Admin-Panel die Unlock-Daten aus dem NodeQuality-Bericht, sodass ein vollständig entsperrter NQ-Bericht nicht mehr durch einen älteren IP.Check.Place-Fehler überschrieben wird. 中国 wird rot angezeigt; gesperrte/fehlgeschlagene/nur-Mitglieder-Status erscheinen im roten Badge.

v1.1.3 behob NQ-Komponenten-Downloads auf Netzen wie Tencent Cloud: Das statische Skript behält die offizielle GitHub-Quelle, fällt bei Fehlern auf getestete Mirrors zurück und erzwingt SHA-256. Der Agent-Task-Runner erhielt Instanzzuordnung und einen 30-Minuten-Heartbeat-Fallback; die doppelte GET-Route /api/agent/tasks wurde behoben.

v1.1.4 ergänzt im NQ-Dialog die Beschleunigungsquelle (auto / EdgeOne China / Cloudflare Ausland). Das geprüfte Skript verwendet bevorzugt den öffentlichen NIE-Proxy-Accelerator und fällt auf offizielle Quellen/Mirrors zurück; die SHA-256-Prüfung bleibt unverändert.

v1.1.5 lädt die von HardwareQuality intern heruntergeladenen Geekbench-5-Pakete ebenfalls über den gewählten NIE-Proxy-Accelerator; die Whitelist ergänzt cdn.geekbench.com.

v1.1.6 entfernt EdgeOne aus den NQ-Dialogen; übrig bleiben „Standard" und „Cloudflare Ausland". Alte eo-Aufgaben fallen automatisch auf den Standard zurück.

v1.1.7 authentifiziert die Upload-API vor dem Parsen des Bodys. Der damalige statische Budgettest deckte nur den Basisverkehr ab; spätere Produktionsdaten zeigten, dass Probes, Durable Objects und Scheduler-Laufzeit unterschätzt wurden. Er ist daher keine Garantie für 100 Nodes.

v1.1.8 behob Ziel-IDs mit &: Der Worker löst Original-ID, normalisierte ID und Scan-Treffer auf, sodass metrics, pings, config und location beim Originalziel ankommen.

v1.1.9 behob gelegentliche Querverläufe beim schnellen Wechsel der Metrik-Zeiträume, ließ TCP-Ping- und Latency-Kurven bei Paketverlust brechen und gestaltete die Admin-Probe-Liste neu.

v1.1.10 ergänzte den Schalter „Endpoint-Kontinuität" in der Chart-Symbolleiste: Latency und TCP Ping brechen standardmäßig bei Verlust oder Fehler, der Schalter verbindet über Nullwerte hinweg und die Wahl wird im Browser gespeichert.

v1.1.11 stellte die bisherige Tabellenform der Admin-Probe-Liste wieder her und entfernte die zu breiten Monitoring-Blöcke; Informationsdichte und Aktionsbereich entsprechen wieder dem Stand vor 1.1.8.

v1.1.12 senkte die Gesamttaktung der Probes: 3-Sekunden-Einzel-Timeout, Status-Snapshots alle 2 Minuten, regionale Latenz alle 3 Minuten und automatische 10-Minuten-Degradierung bei wiederholt fehlschlagenden Zielen. NQ-Berichtsbilder nutzen Edge-Caching, das Cancel-Polling von Agent-Tasks wechselte von festen 2 Sekunden auf 5-10-Sekunden-Backoff, und D1-Aggregat-Caching mit neuen Indizes wurde ausgeliefert.

v1.1.18 brachte die 300-Sekunden-Darstellung, WS-Wiederverwendung, stündliche R2-Pufferung und Cache/304-Unterstützung; v1.1.22 ergänzte die Batch-Ping-API, sodass ein öffentliches Panel die vollständige Ping-Historie aller VPS mit einer Anfrage lesen kann. Maßgeblich bleiben Manifest und Release-Datensatz des Ziel-Deployments.

IPv6 und Cloudflare-Probes

„Agent online, aber CF-Latency schlägt fehl" ist meist ein Richtungsproblem: Agent-Meldungen beweisen nur ausgehendes Netz; ob Cloudflare den Port der VPS erreicht, ist ein separater Pfad. Kernpunkte:

• IPv6 im Host-Feld ohne [] eintragen; den Port ins Port-Feld.
• Wörtliche IPv6 kann von Cloudflare abgelehnt werden; versuchen Sie eine DNS-only-AAAA-Domain für dieselbe Adresse.
• Proxy (Orange Cloud) nicht aktivieren: AAAA löst zu Cloudflare-Proxy-Adressen auf, und Workers-TCP-Sockets verbieten Verbindungen zu Cloudflare-IPs.
• Von einer anderen öffentlichen IPv6 mit nc -6 -vz Domain Port verifizieren.

Vollständige Fehlersuche im IPv6-Thema dieser Dokumentation.

NQ-Bilder fehlen oder veraltet

• Network- und Return-Route-Bilder werden vom Worker gerendert und hochgeladen; bei Image-Host-Fehler fällt die UI auf den Textbericht zurück, die Aufgabe gilt nicht als fehlgeschlagen.
• Öffentliche Bild-URLs sind Same-Origin-Proxys; der Upstream-Host wird nie exponiert.
• Die Kette läuft über den offiziellen öffentlichen Broker; normale Deployments können und müssen kein eigenes NQ_IMGBED_URL/NQ_IMGBED_TOKEN konfigurieren.
• Nur Berichte nach Wirksamwerden der Konfiguration werden verarbeitet; alte Berichte werden nicht nachgeladen.

Externer Latency-Knoten zeigt „noch nicht gemeldet"

Die Knotenaufzeichnung zu erstellen ist kein Deployment. Prüfen Sie: Der neueste vollständige Befehl des Knotens lief auf der richtigen Maschine; die Installationsausgabe enthielt accepted; der Dienst ist aktiv; Logs haben keine dauerhaften 401/403/TLS/DNS-Fehler. Alte Knoten müssen mit dem vollständigen Befehl neu installiert werden, nicht nur neu gestartet.

Browser-CORS-Fehler bei der öffentlichen API

curl funktioniert, aber der Browser nicht: Die Origin fehlt in DEVELOPER_API_ORIGINS. Fügen Sie die vollständige Origin (https://status.example.com) hinzu, ohne Pfad, ohne *. Produktion muss HTTPS sein; HTTP nur für lokale Entwicklung.

Backup und Wiederherstellung

• Wiederherstellung erfordert Vorschau und ein Bestätigungswort; Merge und Replace werden unterstützt.
• Der Worker behält ein R2-Snapshot vor der Wiederherstellung; bei Fehlern Snapshot behalten und Logs prüfen, statt wiederholt zu klicken.
• Agent-Tokens sensibler Backups werden bei der Wiederherstellung neu verpackt, sodass Knoten nach einem Account-Wechsel weiter authentifizieren.
• Normale Backups enthalten keine Tokens; Hochfrequenz-Historie ist nicht im JSON; bei Migration das ursprüngliche R2 wiederverwenden.

Anzeige der Festplattenkapazität

agent_metrics.vps_info.total_disk_gb ist die Kapazität des Root-Dateisystems, nicht eine Summe der Mounts; Bind-Mounts desselben Geräts werden nicht doppelt gezählt.

Themes und Canvas-Themes

In der aktuellen Version sind nur Theme-Pakete offen; es gibt keinen Plugin-Runtime. Ein CSS-Theme nur für Farben und Abstände; ein Canvas-Theme für die vollständige Neugestaltung von Layout, Interaktion oder Charts der öffentlichen Seite. Canvas-Themes laufen in einer Sandbox-Iframe ohne Same-Origin-Zugriff, lesen den öffentlichen Zustand nur über das Nachrichtenprotokoll und können weder Netz noch Host-Seite direkt erreichen.

• Uploads starten deaktiviert; ein Administrator prüft das SHA-256 und aktiviert manuell. Deaktivieren stellt sofort die Original-UI wieder her.
• Keine type: "plugin"-ZIPs verteilen; Plugin-Upload und Plugin-Nachrichtenprotokoll älterer Tutorials waren in der aktuellen Version nie offen.
• Ein separates Panel nutzt die öffentliche v1-API, wird auf eigener Domain betrieben und braucht eine exakte DEVELOPER_API_ORIGINS-Allowlist.

Kostenloser Rahmen

Der Economy-Modus nutzt standardmäßig 15-Minuten-Intervalle für gesunde Ziele und Agent-Batches, 10 Minuten für Tasks, tägliche normale Update-Prüfungen und etwa 2 Minuten für fehlerhafte Ziele. Das reduziert Requests und Unbound für 100 VPS deutlich gegenüber dem alten 5-Minuten-Modell; Metriken können bis zu 15 Minuten alt sein. Dashboard-Alarme für Workers, Durable Objects, D1-Zeilen und R2-Operationen bleiben erforderlich.

Aktueller Stand (1.1.93): Telemetriepuffer und Probe-Historie liegen in gemeinsam genutzten Durable Objects, D1-Schreibvorgänge dienen nur noch als Fallback. Bei der realen 5-Minuten-Meldung bleiben Workers, Durable Objects, D1 und R2 innerhalb des kostenlosen Kontingents (D1 gelesene Zeilen ist das knappste Budget). Für exakte Anteile das Nutzungsmodell zusammen mit der Cloudflare-Abrechnung der Zielbereitstellung verwenden statt das alte statische 100-Knoten-Budget fortzuschreiben.

Ein Knoten erreicht Cloudflare / Fastly / Akamai nicht

Manche Netze erreichen Cloudflare-CDN-Endpunkte nicht; Installation, Meldungen und Auto-Updates schlagen fehl. Richte auf einem Host, der die Seite erreicht, ein reines TCP-Relay ein (TLS/SNI/Host werden unverändert durchgereicht — keine Domain, kein Zertifikat, kein CDN nötig):

sudo apt install -y socat
sudo systemd-run --unit=nie-sla-relay socat TCP-LISTEN:443,fork,reuseaddr TCP:sla.niekaixiang.com:443

Beschränke Port 443 per Firewall auf die IP des Zielknotens und erstelle die Unit nach einem Neustart neu. Zeige dann auf dem eingeschränkten Knoten die beiden offiziellen Hostnamen auf das Relay und führe den generierten Installationsbefehl aus:

echo "<relay-ip> sla.niekaixiang.com api-sla.niekaixiang.com" | sudo tee -a /etc/hosts
curl -fsS https://sla.niekaixiang.com/api/health

TLS-Prüfung, Host und Download-Basis der Updates bleiben die offizielle Domain; Meldungen, Aufgaben, WebSocket und Auto-Updates laufen über das Relay. Wenn nur IPv6 oder ein Alternativport erreichbar ist, teste zuerst curl -6 -fsS https://<domain>/api/health bzw. curl -fsS https://<domain>:8443/api/health.

Installer akzeptiert kein --token mehr (ab 1.1.65)

Damit das Token nicht in ps und Shell-History auftaucht, lehnen setup.sh, install-mac.sh und quick-install.sh --token ab und verlangen die Umgebungsvariable oder die interaktive Eingabe:

NIE_SLA_AGENT_TOKEN='...' sudo -E bash setup.sh --non-interactive

Vom Panel erzeugte Ein-Klick-Befehle nutzen bereits Umgebungsvariablen und Einmal-Zugangsdaten.

Proxy-Prüfungen bleiben offline oder laufen in den Timeout

Prüfe zuerst die Version des ausführenden Agenten des Ziels. Bis 1.1.53 fehlt der Reality-Handshake-Pufferfix aus 1.1.57: Reality-Knoten laufen exakt nach 5 Sekunden in stage=connect / timeout (Handshake und erstes Byte bleiben -). Aktualisiere den ausführenden Knoten auf v1.1.57+ (Deploy-Befehl erneut ausführen) oder wähle einen bereits aktualisierten Agenten. Scheitern danach weiterhin alle Proben, prüfe den Freigabelink und die Parameter erneut (Reality Public Key und Short ID sind Pflicht).

Das Panel zeigt eine neue Version, aber es wird nie aktualisiert

Online-Updates für Ein-Klick-Deployments laufen als NIE-SLA Online Update-Workflow im Deployment-Repository auf GitHub Actions und prüfen alle 6 Stunden die offizielle stabile Version. Der Workflow läuft nicht im Worker; der Worker kann sich nicht selbst aktualisieren, und die Update-Karte im Panel zeigt nur die Versionen an.

Zeigt der Actions-Tab „Get started with GitHub Actions“ (gar keine Workflows), hat das Ein-Klick-Deployment den Workflow nicht ins Repository kopiert. Installiere ihn einmal im Browser (die Update-Logik bleibt immer im offiziellen Repository, das ist ein einmaliger Schritt):

1. Öffne den Actions-Tab des Deployment-Repositories → klicke auf set up a workflow yourself;
2. Füge den folgenden Ausschnitt ein und klicke auf Commit changes;
3. Wähle danach links NIE-SLA Online Update → Run workflow.

name: NIE-SLA Online Update
on:
  workflow_dispatch:
  schedule:
    - cron: "17 */6 * * *"
permissions:
  contents: write
jobs:
  update:
    uses: 3257085208/NIE-SLA/.github/workflows/nie-sla-update.yml@main

Bleibt ein Deployment auf einer alten Version, prüfe der Reihe nach:

1. Ist Actions aktiviert? Repository → Settings → Actions → General, Workflows zulassen (neue oder geforkte Repositories haben Actions oft deaktiviert).
2. Gibt es Läufe? Im Actions-Tab sollten geplante „NIE-SLA Online Update“-Läufe stehen. Gar keine Läufe: nutze den Installations-Ausschnitt oben; danach startet Run workflow sofort einen Lauf.
3. Fehlerprotokoll lesen (letzter Schritt des fehlgeschlagenen Laufs):
   • no online-update baseline: Repository-Inhalt entspricht nicht der offiziellen Basis seiner Version; einmal manuell synchronisieren;
   • Deployment files differ from the official … baselines: Änderungen außerhalb der offiziellen Version (nur wrangler.jsonc darf abweichen);
   • Abhängigkeits- oder Build-Fehler: einmal vom neuesten Branch neu starten.
4. Cloudflare-Build abwarten: Nach dem Push braucht Cloudflare Workers Builds noch etwa 1–3 Minuten; Panel hart neu laden und „Nach Updates suchen“ drücken.

Ohne GitHub Actions manuell aktualisieren: Repository auf die neueste offizielle Version synchronisieren und npm run deploy ausführen, oder direkt mit der neuesten Ein-Klick-Vorlage neu deployen (bringt auch die neuesten Durable-Object-Bindings und die interne Secret-Bereitstellung).