Si un appareil apparaît hors ligne dans Level alors qu'il est en réalité allumé et connecté, la cause est presque toujours une interférence AV/EDR ou un pare-feu bloquant les connexions sortantes de l'agent. Commencez par la commande --check — elle identifie le point d'échec exact sans conjectures.

Exécuter --check sur l'appareil concerné pendant qu'il dispose d'un accès réseau. Elle teste chaque aspect de la connectivité de l'agent avec Level et indique précisément où se situe l'échec.

Les deux sections sur lesquelles se concentrer :

Vérifications Level — indique si le service de l'agent et la tâche watchdog sont dans l'état attendu (Running / Ready). Si l'une ou l'autre présente un problème, l'AV/EDR a très probablement mis en quarantaine le binaire de l'agent. Le watchdog maintient le service en cours d'exécution dans des conditions normales — s'il ne fonctionne pas, quelque chose d'externe l'a arrêté.

Vérifications de connexion — affiche l'état de online.level.io, agents.level.io, uptime monitor, et realtime client. Les trois premières sont des vérifications ping (ICMP), tandis que realtime client indique la connexion en temps réel distincte de l'agent. Error: no ping stats signifie que la vérification ping n'a reçu aucune réponse ICMP. Si le client en temps réel est Connected, l'agent conserve toujours sa connexion en temps réel même lorsqu'une ou plusieurs vérifications ping échouent.

Si --check indique que le service ou le watchdog n'est pas dans l'état attendu, ou si --check ne s'exécute pas du tout, vérifiez si le binaire Level est toujours présent sur le disque :

Si le binaire est manquant, l'AV/EDR l'a supprimé. Level ne dispose d'aucun mécanisme pour supprimer son propre binaire — un exécutable manquant signifie que votre logiciel de sécurité l'a mis en quarantaine ou supprimé.

Pour investiguer : Consultez le journal de quarantaine et l'historique d'activité de votre logiciel de sécurité autour de la période à laquelle l'appareil s'est mis hors ligne. Recherchez toute action entreprise contre level.exe ou les processus associés. Certains produits — SentinelOne, ESET et certaines configurations de Defender — le font silencieusement, sans alerte visible.

Pour corriger : Restaurez le binaire depuis la quarantaine si possible, puis ajoutez les exclusions appropriées avant de réinstaller. Voir Fausses détections AV/EDR pour les chemins d'exclusion, les détails du certificat et une automatisation Windows Defender que vous pouvez déployer sur plusieurs appareils. Si le binaire est toujours présent mais que le service est arrêté, les mêmes étapes d'exclusion s'appliquent — l'antivirus bloque probablement l'exécution plutôt que de supprimer le fichier.

Si la section Vérifications Level semble correcte mais Vérifications de connexion affichent des échecs, comparez les trois vérifications ping avec realtime client:

L'agent a besoin d'un accès sortant vers ces URL :

Autoriser un nom d'hôte n'autorise pas toujours la connexion en temps réel. Un filtre de contenu, un pare-feu ou un proxy peut toujours bloquer, inspecter, réécrire ou fermer le trafic WebSocket.

CNAME des points de terminaison Ably : Les noms d'hôte des points de terminaison Ably sont des alias DNS. Incluez à la fois les noms d'hôte des points de terminaison et leurs cibles CNAME lors de la configuration des listes d'autorisation réseau et des exclusions de déchiffrement SSL/TLS spécifiques à Ably.

Si realtime client signale une erreur sur un réseau filtré, demandez à l'administrateur réseau ou au fournisseur de filtrage de :

Ces paramètres sont des exigences de dépannage pour les réseaux filtrés. Une erreur de client en temps réel ne prouve pas, à elle seule, que le filtrage en est la cause. Après avoir modifié la politique réseau, exécutez --check à nouveau et confirmez que realtime client indique Connected.

Ports requis (sortants uniquement) :

Si --check n'indique pas de cause claire, contactez le support Level avec :