Introducción
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 --check — identifica el punto exacto de fallo sin necesidad de suposiciones.
ℹ️ NOTA: En la mayoría de los casos, Level funciona sin ningún cambio en el firewall. Los requisitos de red que se indican a continuación solo aplican si está en una red restrictiva y experimenta activamente problemas de conectividad.
Solución de problemas sin conexión
Paso 1: Ejecutar la comprobación de diagnóstico
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.
🖥️ NOTA DE PLATAFORMA:
Windows:
& 'C:\Program Files\Level\level.exe' --checkmacOS:
sudo /usr/local/bin/level --checkLinux:
sudo /usr/local/bin/level --check
Las dos secciones en las que debe concentrarse:
Comprobaciones de Level — muestra si el servicio del agente y la tarea del watchdog se encuentran en el estado esperado (Running / Ready). Si alguna muestra un problema, lo más probable es que AV/EDR haya puesto en cuarentena el binario del agente. El watchdog mantiene el servicio en funcionamiento en condiciones normales — si no lo está, algo externo lo detuvo.
Comprobaciones de conexión — muestra el estado de online.level.io, agents.level.io, uptime monitor, y realtime client. Cualquier fallo aquí apunta a una ruta de red bloqueada.
Paso 2: Interferencia de AV/EDR
Si --check muestra el servicio o el watchdog en un estado inesperado, o si --check no se ejecuta en absoluto, compruebe si el binario de Level sigue presente en el disco:
🖥️ NOTA DE PLATAFORMA:
Windows: busque
level.exeenC:\Program Files\Level\macOS: busque
levelen/Applications/Level.app/Contents/MacOS/levelLinux: busque
levelen/usr/local/bin/level
Si el binario falta, AV/EDR lo eliminó. Level no tiene ningún mecanismo para eliminar su propio binario — un ejecutable faltante 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 se desconectó. 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 corregir: Restaure el binario desde la cuarentena si es posible, luego agregue 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.
⚠️ ADVERTENCIA: Si reinstala el agente sin agregar exclusiones primero, AV/EDR volverá a eliminar el binario. Agregue las exclusiones antes de reinstalar. Tenga también en cuenta: Las detecciones de AV/EDR contra Level están basadas en comportamiento, no en firmas. Esto significa que el mismo software de seguridad puede ejecutarse en 50 dispositivos y solo marcar Level en algunos — depende de lo que estaba haciendo el agente en el momento en que se activó la detección, no de una actualización de definiciones. No asuma que un dispositivo limpio significa que sus exclusiones están funcionando correctamente.
Paso 3: Verificar el acceso a la red
Si la sección Comprobaciones de Level se ve correcto pero Comprobaciones de conexión muestran fallos, el agente está en ejecución pero no puede comunicarse con los servidores de Level. El problema es un firewall o proxy que bloquea las conexiones salientes.
El agente necesita acceso saliente a estas URLs:
URL | Propósito |
| Comunicación del agente con Level |
| Comprobaciones de estado de conectividad |
| Actualizaciones del agente |
| Instalación inicial del agente |
| WebSocket en tiempo real para la API de Level |
| Almacenamiento de archivos para automatizaciones |
| Relay TURN (usado cuando falla P2P) |
| STUN (usado cuando falla P2P) |
| Recopilación de registros para solución de problemas |
💡 CONSEJO: Para firewalls que admiten reglas con comodines, *.level.io y *.twilio.com cubren las entradas de Level y Twilio mencionadas anteriormente.
Puertos requeridos (solo salientes):
Puerto | Protocolo | Propósito | Notas |
80 | TCP | HTTP | Conectividad básica |
443 | TCP | HTTPS | Tráfico principal del agente |
3478 | TCP & UDP | TURN | Usado cuando falla P2P |
5349 | TCP | TURN TLS | Solo como último recurso de reserva |
10,000–60,000 | UDP | Puertos de relay TURN | Asignados por Twilio cuando se usa TURN |
ℹ️ NOTA: Los puertos 3478, 5349 y el rango UDP solo son necesarios cuando no se pueden establecer conexiones P2P. Comience con 80 y 443 — eso cubre la gran mayoría de los escenarios. Consulte Solución de problemas de Relay/P2P si las conexiones remotas específicamente están fallando.
Paso 4: Contactar con el soporte
Si --check no apunta a una causa clara, contacte con el soporte de Level con:
La salida completa de
--checkSoftware AV/EDR en uso (nombre y versión)
Cualquier software de firewall o proxy entre el dispositivo e internet
Preguntas frecuentes
El dispositivo estaba en línea ayer y acaba de desconectarse. ¿Por dónde empiezo? Ejecute
--checkprimero. Si no se ejecuta en absoluto, compruebe silevel.exe(Windows) o ellevelbinario (macOS/Linux) sigue presente en el disco — si no está, AV/EDR lo eliminó. Si el binario está ahí pero--checkmuestra el servicio detenido o fallos en la comprobación de conexión, consulte Detecciones falsas de AV/EDR para la investigación del registro de cuarentena y los pasos de exclusión.En este momento no tengo ninguna forma de acceder al dispositivo de forma remota. ¿Qué puedo hacer? Si Level es su única herramienta de acceso remoto en el dispositivo, necesitará acceso físico o fuera de banda (iDRAC, iLO, KVM, etc.) para investigar. Una vez que tenga acceso, ejecute
--checkpara identificar la causa antes de hacer cualquier otra cosa.¿Necesito abrir todos estos puertos en mi firewall? No, a menos que esté experimentando problemas. La mayoría de las redes funcionan solo con los puertos 80 y 443 salientes. Los puertos TURN (3478, 5349) y el rango UDP solo son relevantes si las conexiones P2P están fallando — consulte Solución de problemas de Relay/P2P antes de abrir puertos adicionales.
La salida de --check parece correcta pero el dispositivo sigue apareciendo sin conexión en Level. La consola puede tardar un minuto o dos después de que se restablezca la conectividad. Si no se actualiza, el problema puede ser intermitente — intente ejecutar
--checknuevamente cuando vuelva a aparecer el estado sin conexión para detectar el fallo en el momento.

