Wenn ein Gerät in Level als offline angezeigt wird, aber tatsächlich eingeschaltet und verbunden ist, liegt die Ursache fast immer an AV/EDR-Interferenz oder einer Firewall, die die ausgehenden Verbindungen des Agenten blockiert. Beginnen Sie mit dem --check Befehl — er identifiziert den genauen Fehlerpunkt ohne Rätselraten.

Ausführen --check auf dem betroffenen Gerät, während es Netzwerkzugang hat. Es testet jeden Teil der Konnektivität des Agenten zu Level und meldet genau, wo der Fehler liegt.

Die zwei Abschnitte, auf die Sie sich konzentrieren sollten:

Level-Prüfungen — zeigt an, ob der Agentendienst und die Watchdog-Aufgabe im erwarteten Zustand sind (Running / Ready). Wenn einer von beiden ein Problem zeigt, gibt --check allein nicht den Grund an. AV/EDR-Interferenz ist eine mögliche Ursache, sollte aber nur dann als Ursache betrachtet werden, wenn es Belege für eine Erkennung, Blockierung oder Quarantäne gibt. Der Watchdog hält den Dienst unter normalen Bedingungen am Laufen — wenn dies nicht der Fall ist, hat etwas Externes ihn gestoppt.

Verbindungsprüfungen — zeigt den Status von online.level.io, agents.level.io, uptime monitor, und realtime client. Die ersten drei sind Ping-(ICMP-)Prüfungen, während realtime client meldet die separate Echtzeitverbindung des Agenten. Error: no ping stats bedeutet, dass die Ping-Prüfung keine ICMP-Antworten erhalten hat. Wenn der Realtime-Client Connected, hat der Agent weiterhin seine Echtzeitverbindung, auch wenn eine oder mehrere Ping-Prüfungen fehlschlagen.

Wenn --check zeigt den Dienst oder Watchdog nicht im erwarteten Zustand, oder wenn --check überhaupt nicht ausgeführt werden kann, prüfen Sie, ob die Level-Binärdatei noch auf dem Datenträger vorhanden ist:

Wenn die Binärdatei fehlt, zeigt das allein nicht den Grund. Betrachten Sie AV/EDR nur dann als Ursache, wenn es Belege für eine Erkennung, Blockierung oder Quarantäne gibt, z. B. einen Eintrag im Quarantäne- oder Aktivitätsprotokoll Ihrer Sicherheitssoftware. Wenn kein solcher Beleg vorhanden ist, ist die Ursache nicht festgestellt; senden Sie die vollständige --check Ausgabe (falls ausgeführt) und was Sie auf dem Datenträger gefunden haben, an den Level-Support.

Zur Untersuchung: Überprüfen Sie das Quarantäneprotokoll und den Aktivitätsverlauf Ihrer Sicherheitssoftware rund um den Zeitpunkt, als das Gerät offline ging. Suchen Sie nach Aktionen, die gegen level.exe oder verwandte Prozesse. Einige Produkte — SentinelOne, ESET und bestimmte Defender-Konfigurationen — tun dies still ohne sichtbare Warnung.

Zur Behebung, nur wenn Ihre Sicherheitssoftware eine Erkennung, Blockierung oder Quarantäne von Level anzeigt: Stellen Sie die Binärdatei aus der Quarantäne wieder her, falls möglich, und fügen Sie dann die entsprechenden Ausschlüsse hinzu, bevor Sie neu installieren. Siehe AV/EDR-Falscherkennung für Ausschlusspfade, Zertifikatsdetails und eine Windows Defender-Automatisierung, die Sie auf Geräten bereitstellen können. Wenn die Binärdatei noch vorhanden ist, aber der Dienst gestoppt ist und es keine Belege für eine Erkennung oder Blockierung gibt, sind Ausschlüsse allein dadurch nicht angezeigt; senden Sie die vollständige --check Ausgabe an den Level-Support.

Wenn der Level-Prüfungen Abschnitt fehlerfrei aussieht, aber Verbindungsprüfungen Fehler anzeigen, vergleichen Sie die drei Ping-Prüfungen mit realtime client:

Der Agent benötigt ausgehenden Zugriff auf diese URLs:

Das Zulassen eines Hostnamens erlaubt nicht immer die Echtzeitverbindung. Ein Inhaltsfilter, eine Firewall oder ein Proxy kann den WebSocket-Datenverkehr dennoch blockieren, prüfen, umschreiben oder schließen.

Ably-Endpunkt-CNAMEs: Die Endpunkt-Hostnamen von Ably sind DNS-Aliase. Schließen Sie sowohl die Endpunkt-Hostnamen als auch ihre CNAME-Ziele ein, wenn Sie Netzwerk-Zulassungslisten und Ably-spezifische SSL/TLS-Entschlüsselungsausschlüsse konfigurieren.

Wenn realtime client einen Fehler in einem gefilterten Netzwerk meldet, bitten Sie den Netzwerkadministrator oder den Filteranbieter:

Diese Einstellungen sind Fehlerbehebungsanforderungen für gefilterte Netzwerke. Ein Realtime-Client-Fehler beweist allein nicht, dass die Filterung die Ursache ist. Führen Sie nach einer Änderung der Netzwerkrichtlinie --check erneut und bestätigen, dass realtime client meldet Connected.

Erforderliche Ports (nur ausgehend):

Wenn --check nicht auf eine klare Ursache hinweist, wenden Sie sich mit folgenden Informationen an den Level-Support: