- El estado «no está listo» suele deberse al servicio/daemon o a puertos bloqueados.
- 5938 TCP/UDP es clave; reiniciar y habilitar teamviewerd/servicio lo resuelve a menudo.
- En empresas, usa políticas e informes para auditar conexiones entrantes.
Si al abrir TeamViewer te aparece el aviso «No está listo. Compruebe su conexión» y ni siquiera ves tu ID ni puedes establecer contraseña, no estás solo. Es un problema relativamente común que confunde porque el resto de aplicaciones sí tienen Internet, pero TeamViewer actúa como si estuviera offline.
La buena noticia es que suele tener solución rápida si sabes dónde mirar: servicio/daemon de TeamViewer, puertos de salida (5938 TCP/UDP) y, en entornos corporativos, políticas y auditoría para entender quién se conecta a qué. En esta guía reunimos lo que mejor funciona según los casos reportados y documentación oficial, con explicaciones claras para Windows y Linux.
Qué significa el aviso «No está listo. Compruebe su conexión»
El mensaje indica que el cliente no puede establecer comunicación con la infraestructura de TeamViewer, por lo que no obtiene un ID ni permite crear sesión. A efectos prácticos, el programa queda en un estado “a la espera” de red, aunque el sistema sí tenga conexión a Internet.
Los síntomas típicos son: no aparece el ID local, no se genera contraseña y cualquier intento de conexión falla desde el inicio. El bloqueo suele ser causado por el propio sistema (servicio/daemon caído) o por el entorno de red (puertos o filtrado).
Causas frecuentes que explican el bloqueo
- Servicio o daemon de TeamViewer detenido o no habilitado. En Linux es muy común que el proceso “teamviewerd” no esté activo tras una instalación o actualización; en Windows, el servicio de TeamViewer puede quedar en estado “Detenido”.
- Restricciones de red o puertos incompletos. TeamViewer utiliza preferentemente el puerto 5938 y puede usar UDP además de TCP; si tu cortafuegos o un proxy intermedio filtra esa salida, el cliente queda “no listo”.
- Firewall local o antivirus con reglas demasiado agresivas. Un perfil restrictivo puede bloquear la aplicación o su servicio, impidiendo que negocie con los servidores de TeamViewer.
- Configuración corporativa o políticas mal aplicadas. En entornos gestionados, la asignación de dispositivos y políticas de administración puede condicionar el comportamiento del cliente y su capacidad para aceptar conexiones entrantes.
Aunque parezca un problema de Internet genérico, casi siempre se reduce a uno de estos puntos: servicio/daemon, puertos/firewall o configuración corporativa.
Puertos y conectividad: qué debes saber
La mayoría de incidencias reportadas surgen en torno al puerto 5938 (TCP y también UDP), que es el canal preferente de TeamViewer. Si lo tienes bloqueado a la salida o inspeccionado por un dispositivo de seguridad, el cliente puede quedarse en bucle sin preparar el ID.
Si te preguntas si “han cambiado los puertos” recientemente, la respuesta general es no: 5938 sigue siendo el puerto principal. Cuando no está disponible, el software intenta alternativas como 443 o 80 por TCP, pero el rendimiento y la fiabilidad pueden resentirse y, en escenarios con DPI/filtrado, ni el fallback funciona.
Recomendación práctica: verifica que tu firewall permite tráfico saliente por 5938 TCP y, si es posible, UDP, hacia Internet; si además tu red inspecciona TLS, añade excepciones para el dominio y tráfico de TeamViewer según tus políticas.
El daemon de TeamViewer en Linux: la causa oculta más habitual
En distribuciones como Debian, Ubuntu, Mint, Arch o Manjaro, muchas veces el fallo es tan simple como que el demonio “teamviewerd” no está arrancado o no se habilitó en el arranque. El cliente gráfico depende de ese servicio para obtener el ID y comunicarse con los servidores.
Solución rápida en Debian/Ubuntu/Mint y derivadas: reinicia y habilita el daemon con systemd; también puedes usar el propio comando de TeamViewer para el daemon.
sudo systemctl status teamviewerd
sudo systemctl restart teamviewerd
sudo systemctl enable teamviewerd
teamviewer --daemon status
teamviewer --daemon restart
Solución en Arch, Manjaro y derivadas: los comandos con systemd son equivalentes y suelen resolver el problema al instante.
sudo systemctl status teamviewerd
sudo systemctl restart teamviewerd
sudo systemctl enable teamviewerd
Importante: tras reiniciar el servicio, cierra y abre TeamViewer o reinicia el equipo; la primera conexión puede tardar alrededor de 1 minuto en prepararse.
Windows: comprueba el servicio y el entorno
En Windows, el equivalente al daemon es el servicio “TeamViewer”, que debe estar en estado “En ejecución” y con inicio “Automático”. Si se detuvo, el cliente no generará ID ni permitirá conectarte.
Pasos recomendados: abre el Administrador de servicios (services.msc), localiza “TeamViewer”, pulsa en “Iniciar” o “Reiniciar” y deja el tipo de inicio en Automático. Si te resulta más cómodo, reinicia el servicio desde una consola con privilegios.
net stop TeamViewer
net start TeamViewer
Si el servicio no arranca, revisa tu antivirus/firewall y prueba una reinstalación limpia de TeamViewer. Asegúrate de no arrastrar configuración corrupta y, si estás en una red corporativa, confirma que no haya una política que impida su ejecución.
Firewall y seguridad: reglas mínimas para evitar el error
Para que TeamViewer esté “listo”, necesita salidas a Internet sin bloqueo severo del puerto 5938 (TCP/UDP) y, como respaldo, 443/80 TCP. En firewalls perimetrales o EDR, crea reglas explícitas para el ejecutable y el servicio.
En equipos con inspección SSL/TLS, considera una excepción para el tráfico de TeamViewer. Ciertos dispositivos de seguridad rompen la negociación si interceptan el túnel, lo que se traduce en el aviso de que no hay conexión lista.
¿No aparece tu ID ni puedes poner contraseña?
Ese comportamiento suele estar ligado directamente al estado del servicio/daemon. Sin proceso en segundo plano, el cliente no “habla” con la nube y no hay ID.
- Linux: reinicia y habilita “teamviewerd” con systemctl o con el comando “teamviewer –daemon restart”.
- Windows: inicia o reinicia el servicio “TeamViewer” desde services.msc o con net stop/start.
- Red: valida que 5938 TCP/UDP salga sin bloqueo y que no haya un proxy rompiendo la conexión.
- Tras los cambios: reinicia TeamViewer o el equipo y espera hasta 1 minuto a que se genere el ID.
Si tras esto sigue sin ID, plantéate una reinstalación y revisa políticas corporativas que afecten al cliente.
¿Ha cambiado TeamViewer los puertos?
La consulta es frecuente cuando se abre 5938 en TCP y UDP y aun así no conecta: en general no hay cambios de puerto. Lo habitual es que el bloqueo esté en un punto intermedio de la red o en la inspección de tráfico.
Verifica que la regla de 5938 es realmente efectiva a la salida y no solo entrante, y que el dispositivo de seguridad no reescribe o filtra ese flujo. Si forzaste el uso de proxy, prueba también sin proxy para descartar.
Entornos gestionados: informes de conexiones entrantes
Si administras varios equipos, puede interesarte activar informes de conexiones “a este dispositivo” para saber quién se conectó y cuándo. Esta función forma parte de las políticas de configuración gestionadas desde el Administrador de TeamViewer Remote.
Licencias y disponibilidad: los informes de conexiones entrantes a dispositivos están disponibles con planes Corporate o Tensor. Comprueba tu plan para ver si incluye esta función.
Cómo configurar una política de informes para dispositivos
- Abre TeamViewer Remote en el escritorio o la versión web e inicia sesión con tu cuenta de TeamViewer.
- Accede a Configuración del administrador desde la barra de herramientas principal. En el primer inicio de sesión, tendrás que aprobar dispositivos, apps y navegadores no usados antes con tu cuenta.
- En Administración de dispositivos, entra en Políticas y crea o edita una política. Ponle un nombre, selecciona el producto y añade la configuración “informe de conexiones a este dispositivo”.
- Activa la opción y marca “Aplicar parámetros” según tus preferencias, y guarda la política.
Muy importante en despliegues por grupos: al actualizar una política aplicada a un grupo, asegúrate de que también quede aplicada a cada dispositivo dentro del grupo.
Para ello, selecciona los dispositivos, pulsa Editar, luego Editar políticas y, en “Heredar política del grupo”, elige la política actualizada con “Informar conexiones a este dispositivo”. Solo así el informe cubrirá todos los equipos deseados.
Una vez activados los informes, un administrador verá quién se conecta a los dispositivos asignados a su cuenta después de cada sesión. Según la licencia, podrás usar filtros por Usuario, ID de origen, Dispositivo de destino, Grupo o Rango de fechas.
Los informes pueden imprimirse directamente o exportarse a CSV para integrarlos en tus herramientas de reporting.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.