Si un appareil apparaît hors ligne dans Level mais est en réalité sous tension 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 exact de défaillance sans devinettes.
ℹ️ REMARQUE: Dans la plupart des cas, Level fonctionne sans aucune modification de pare-feu. Les exigences réseau ci-dessous s'appliquent uniquement si vous êtes sur un réseau restrictif et rencontrez activement des problèmes de connectivité.
Dépannage des appareils hors ligne
Étape 1: Exécutez la vérification de diagnostic
Exécutez --check sur l'appareil affecté tandis qu'il a accès au réseau. Elle teste chaque partie de la connectivité de l'agent à Level et signale exactement où se trouve la défaillance.
🖥️ REMARQUE PLATEFORME:
Windows:
& 'C:\Program Files\Level\level.exe' --checkmacOS:
sudo /usr/local/bin/level --checkLinux:
sudo /usr/local/bin/level --check
Les deux sections sur lesquelles se concentrer:
Vérifications Level — montre si le service d'agent et la tâche de surveillance sont dans l'état attendu (Running / Ready). Si l'un d'eux montre un problème, AV/EDR a très probablement mis en quarantaine le binaire de l'agent. La surveillance maintient le service en fonctionnement dans les conditions normales — si ce n'est pas le cas, 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. Tout échec ici pointe vers un chemin réseau bloqué.
Étape 2: Interférence AV/EDR
Si --check montre que le service ou la surveillance ne sont 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:
🖥️ REMARQUE PLATEFORME:
Windows: cherchez
level.exedansC:\Program Files\Level\macOS: cherchez
levelà/Applications/Level.app/Contents/MacOS/levelLinux: cherchez
levelà/usr/local/bin/level
Si le binaire est manquant, AV/EDR l'a supprimé. Level n'a 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 enquêter: Vérifiez le journal de quarantaine et l'historique des activités de votre logiciel de sécurité autour du moment où l'appareil s'est déconnecté. 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 Faux positifs AV/EDR pour les chemins d'exclusion, les détails des certificats 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'AV bloque probablement l'exécution plutôt que de supprimer le fichier.
⚠️ AVERTISSEMENT: Si vous réinstallez l'agent sans ajouter d'exclusions au préalable, AV/EDR supprimera à nouveau le binaire. Ajoutez les exclusions avant de réinstaller. À noter également: Les détections AV/EDR contre Level sont basées sur le comportement, pas sur la signature. Cela signifie que le même logiciel de sécurité peut s'exécuter sur 50 appareils et ne signaler que Level sur quelques-uns — cela dépend de ce que l'agent faisait au moment où la détection a été déclenchée, pas d'une mise à jour de définition. Ne supposez pas qu'un appareil propre signifie que vos exclusions fonctionnent correctement.
Étape 3: Vérifiez l'accès réseau
Si la section Vérifications Level semble saine mais que Vérifications de connexion montrent des défaillances, l'agent est en cours d'exécution mais ne peut pas atteindre les serveurs Level. Le problème est un pare-feu ou un proxy bloquant les connexions sortantes.
L'agent a besoin d'accès sortant à ces URL:
URL | Objectif |
| Communication de l'agent avec Level |
| Vérifications de l'état de connectivité |
| Mises à jour d'agent |
| Installation initiale de l'agent |
| WebSocket en temps réel pour l'API Level |
| Stockage de fichiers pour les automatisations |
| Relais TURN (utilisé quand P2P échoue) |
| STUN (utilisé quand P2P échoue) |
| Collecte de journaux pour le dépannage |
💡 CONSEIL: Pour les pare-feu qui supportent les règles génériques, *.level.io et *.twilio.com couvrent les entrées Level et Twilio ci-dessus.
Ports requis (sortants uniquement):
Port | Protocole | Objectif | Notes |
80 | TCP | HTTP | Connectivité de base |
443 | TCP | HTTPS | Trafic d'agent principal |
3478 | TCP & UDP | TURN | Utilisé quand P2P échoue |
5349 | TCP | TURN TLS | Recours de dernier ressort seulement |
10,000–60,000 | UDP | Ports de relais TURN | Alloués par Twilio quand TURN est utilisé |
ℹ️ REMARQUE: Les ports 3478, 5349 et la plage UDP ne sont nécessaires que lorsque les connexions P2P ne peuvent pas être établies. Commencez par 80 et 443 — cela couvre la grande majorité des scénarios. Voir Dépannage Relais/P2P si les connexions à distance échouent spécifiquement.
Étape 4: Contactez le support
Si --check ne pointe pas vers une cause claire, contactez le support Level avec:
La sortie complète de
--checkLogiciel AV/EDR utilisé (nom et version)
Tout logiciel de pare-feu ou de proxy entre l'appareil et Internet
FAQ
L'appareil était en ligne hier et vient de se déconnecter. Par où commencer? Exécutez d'abord
--check. S'il ne s'exécute pas du tout, vérifiez silevel.exe(Windows) ou le binairelevel(macOS/Linux) est toujours présent sur le disque — s'il a disparu, AV/EDR l'a supprimé. Si le binaire est présent mais que--checkmontre que le service est arrêté ou que les vérifications de connexion échouent, consultez Faux positifs AV/EDR pour l'enquête sur le journal de quarantaine et les étapes d'exclusion.Je n'ai aucun moyen d'accéder à l'appareil à distance en ce moment. Que puis-je faire? Si Level est votre seul outil d'accès à distance sur l'appareil, vous aurez besoin d'un accès physique ou hors ligne (iDRAC, iLO, KVM, etc.) pour enquêter. Une fois que vous avez accès, exécutez
--checkpour identifier la cause avant de faire autre chose.Dois-je ouvrir tous ces ports dans mon pare-feu? Non, à moins que vous rencontriez des problèmes. La plupart des réseaux fonctionnent avec seulement 80 et 443 sortants. Les ports TURN (3478, 5349) et la plage UDP ne sont pertinents que si les connexions P2P échouent — consultez Dépannage Relais/P2P avant d'ouvrir des ports supplémentaires.
La sortie --check semble correcte mais l'appareil affiche toujours hors ligne dans Level. La console peut être en retard d'une minute ou deux après la restauration de la connectivité. Si elle ne se met pas à jour, le problème peut être intermittent — essayez d'exécuter
--checkà nouveau quand l'état hors ligne se reproduit pour attraper l'échec.

