Si un dispositivo aparece sin conexión en Level pero en realidad está encendido y conectado, la causa casi siempre es una interferencia de AV/EDR o un firewall que bloquea las conexiones salientes del agente. Comience con el comando --check — identifica el punto exacto del fallo sin necesidad de conjeturas.

Ejecute --check en el dispositivo afectado mientras tiene acceso a la red. Prueba cada parte de la conectividad del agente con Level e informa exactamente dónde se produce el fallo.

Las dos secciones en las que concentrarse:

Comprobaciones de Level — muestra si el servicio del agente y la tarea watchdog están en el estado esperado (Running / Ready). Si alguna muestra un problema, el AV/EDR probablemente ha puesto en cuarentena el binario del agente. El watchdog mantiene el servicio en ejecución en condiciones normales; si no lo hace, algo externo lo detuvo.

Comprobaciones de conexión — muestra el estado de online.level.io, agents.level.io, uptime monitor, y realtime client. Las tres primeras son comprobaciones de ping (ICMP), mientras que realtime client informa la conexión en tiempo real separada del agente. Error: no ping stats significa que la comprobación de ping no recibió respuestas ICMP. Si el cliente en tiempo real está Connected, el agente mantiene su conexión en tiempo real incluso cuando una o más comprobaciones de ping fallan.

Si --check muestra el servicio o el watchdog no en el estado esperado, o si --check no se ejecuta en absoluto, compruebe si el binario de Level sigue presente en el disco:

Si falta el binario, el AV/EDR lo eliminó. Level no tiene ningún mecanismo para eliminar su propio binario; un ejecutable que falta significa que su software de seguridad lo puso en cuarentena o lo eliminó.

Para investigar: Revise el registro de cuarentena y el historial de actividad de su software de seguridad alrededor del momento en que el dispositivo quedó sin conexión. Busque cualquier acción tomada contra level.exe o procesos relacionados. Algunos productos —SentinelOne, ESET y ciertas configuraciones de Defender— hacen esto de forma silenciosa sin ninguna alerta visible.

Para solucionar: Restaure el binario desde la cuarentena si es posible y, a continuación, añada las exclusiones adecuadas antes de reinstalar. Consulte Detecciones falsas de AV/EDR para conocer las rutas de exclusión, los detalles del certificado y una automatización de Windows Defender que puede implementar en todos los dispositivos. Si el binario sigue presente pero el servicio está detenido, se aplican los mismos pasos de exclusión: es probable que el AV esté bloqueando la ejecución en lugar de eliminar el archivo.

Si la sección Comprobaciones de Level parece correcto pero Comprobaciones de conexión muestran fallos, compare las tres comprobaciones de ping con realtime client:

El agente necesita acceso saliente a estas URLs:

Permitir un nombre de host no siempre permite la conexión en tiempo real. Un filtro de contenido, firewall o proxy puede seguir bloqueando, inspeccionando, reescribiendo o cerrando el tráfico WebSocket.

Si realtime client reporta un error en una red filtrada, pida al administrador de red o al proveedor de filtrado que:

Estos ajustes son requisitos de solución de problemas para redes filtradas. Un error del cliente en tiempo real no prueba por sí solo que el filtrado sea la causa. Después de cambiar la política de red, ejecute --check de nuevo y confirme que realtime client reporta Connected.

Puertos requeridos (solo salientes):

Si --check no señala una causa clara, contacte con el soporte de Level con: