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

Ejecutar --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 debe centrarse:

Verificaciones de Level — muestra si el servicio del agente y la tarea watchdog se encuentran en el estado esperado (Running / Ready). Si alguna muestra un problema, es muy probable que el AV/EDR haya puesto en cuarentena el binario del agente. El watchdog mantiene el servicio en ejecución en condiciones normales — si no lo está, algo externo lo detuvo.

Verificaciones de conexión — muestra el estado de online.level.io, agents.level.io, uptime monitor, y realtime client. Los tres primeros son verificaciones de ping (ICMP), mientras que realtime client informa la conexión en tiempo real separada del agente. Error: no ping stats significa que la verificació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 verificaciones de ping fallan.

Si --check muestra el servicio o watchdog que no está en el estado esperado, o si --check no se ejecuta en absoluto, compruebe si el binario de Level todavía está presente en el disco:

Si el binario no está presente, el AV/EDR lo eliminó. Level no tiene ningún mecanismo para eliminar su propio binario — si el ejecutable no está presente, 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 en torno al 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 — lo hacen de forma silenciosa, sin ninguna alerta visible.

Para corregir: Restaure el binario desde la cuarentena si es posible, y luego agregue las exclusiones apropiadas antes de reinstalar. Consulte Detecciones falsas de AV/EDR para 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 todavía está 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 Verificaciones de Level la sección se ve correcta pero Verificaciones de conexión muestran errores, compare las tres verificaciones de ping con realtime client:

El agente necesita acceso saliente a estas URL:

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.

CNAME de los endpoints de Ably: Los nombres de host de los endpoints de Ably son alias DNS. Incluya tanto los nombres de host de los endpoints como sus destinos CNAME al configurar las listas de permitidos de red y las exclusiones de descifrado SSL/TLS específicas de Ably.

Si realtime client reporta un error en una red filtrada, solicite 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 nuevamente y confirme que realtime client reporta Connected.

Puertos requeridos (solo salientes):

Si --check no apunta a una causa clara, póngase en contacto con el soporte de Level con: