RDP Monster

Timeout de conexión de Escritorio remoto: 8 soluciones que funcionan

Timeout de conexión de Escritorio remoto: 8 soluciones que funcionan

Primero, localiza el fallo

“Escritorio remoto no puede conectarse al equipo remoto” tras una espera larga es un timeout: nada respondió. Desde el cliente, ejecuta:

Test-NetConnection 203.0.113.10 -Port 3389

TcpTestSucceeded : True significa que la ruta de red está bien y el problema es la autenticación o una directiva de sesión. False significa que algo entre tú y el host está descartando el tráfico: sigue las soluciones de abajo en orden.

Solución 1 — Confirma que el host y el servicio están activos

En el servidor (consola, VNC o panel del proveedor):

Get-Service TermService
Restart-Service TermService -Force

Confirma también que Escritorio remoto está habilitado: System Properties > Remote, o comprueba que fDenyTSConnections vale 0 en HKLM:\System\CurrentControlSet\Control\Terminal Server.

Solución 2 — Reglas del Firewall de Windows

El grupo de reglas integrado “Escritorio remoto” debe estar habilitado para tu perfil de red actual:

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Si usas un puerto personalizado, la regla debe coincidir con él: consulta nuestra guía del puerto RDP 3389 para los comandos exactos de New-NetFirewallRule, y la guía del firewall por directiva de grupo para entornos de dominio.

Solución 3 — El firewall perimetral del proveedor

En un VPS o servidor dedicado hay dos firewalls: el de Windows y el perimetral del proveedor. Si las reglas de Windows parecen correctas pero el puerto sigue dando timeout desde fuera mientras netstat lo muestra a la escucha, el culpable es el filtro perimetral: abre el puerto en el panel del proveedor o mediante un ticket de soporte.

Solución 4 — Desajuste NLA / CredSSP

Si la prueba TCP tiene éxito pero el cliente falla durante el inicio de sesión, los niveles de parches no coinciden en CredSSP o el cliente no puede hacer autenticación a nivel de red. Actualiza primero ambas máquinas; solo como último recurso, y de forma temporal, relaja NLA en el host (SystemPropertiesRemote > desmarca “Permitir solo conexiones desde equipos que ejecuten NLA”).

Solución 5 — Directivas de límite de tiempo de sesión (la desconexión por inactividad)

Las sesiones que conectan bien pero mueren tras minutos de inactividad las está cerrando una directiva, no la red. En gpedit.msc:

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits

  • “Establecer límite de tiempo para sesiones de Servicios de Escritorio remoto activas pero inactivas” → Nunca
  • “Establecer límite de tiempo para sesiones desconectadas” → Nunca (o la retención que prefieras)

Después, gpupdate /force y vuelve a conectar.

Solución 6 — Keep-alives contra los temporizadores de inactividad de NAT y VPN

Los routers domésticos y los concentradores VPN descartan en silencio los flujos TCP que permanecen inactivos. Haz que el host envíe keep-alives cada minuto:

Set-ItemProperty "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name KeepAliveEnable -Value 1
Set-ItemProperty "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name KeepAliveInterval -Value 1
Restart-Service TermService -Force

¿Usas RDP a través de una VPN en el lado del servidor? Nuestra guía para usar una VPN en un servidor RDP sin desconexiones resuelve la clásica trampa de “VPN activa, RDP perdido”.

Solución 7 — MTU y enlaces con pérdidas

Los paquetes grandes que nunca sobreviven a la ruta provocan conexiones que se quedan colgadas en la barra de progreso. Prueba con ping -f -l 1472 host; si fragmenta, baja la MTU de la interfaz a 1400 en el cliente, o deja que el transporte UDP (habilitado por defecto desde RDP 8.0) absorba la pérdida.

Solución 8 — Límite de sesiones alcanzado

Windows cliente permite una sesión interactiva; los servidores sin licencia RDS permiten dos sesiones administrativas. Un “timeout” justo después de las credenciales puede ser simplemente un host lleno: cierra las sesiones obsoletas con quser + logoff <id>.

Chuleta síntoma → causa

SíntomaCausa más probableSolución
Se cuelga y luego timeoutDescarte por firewall (Windows o perimetral)Soluciones 2-3
“Rechazada” al instanteServicio caído / puerto incorrectoSolución 1, guía del puerto
Muere al estar inactivaGPO de límite de tiempo de sesiónSolución 5
Muere al azar durante el usoTemporizador de inactividad NAT/VPN, enlace con pérdidasSoluciones 6-7
Falla justo tras el inicio de sesiónCredSSP/NLA o límite de sesionesSoluciones 4, 8

Preguntas frecuentes

¿Por qué mi sesión de Escritorio remoto se desconecta tras estar inactiva?

Una directiva de límite de tiempo de sesión la está cerrando: pon los límites de inactividad y de sesión desconectada en Nunca.
Una directiva de límite de tiempo de sesión la está cerrando. En la directiva de grupo, bajo Host de sesión de Escritorio remoto > Límites de tiempo de sesión, pon el 'límite de sesión inactiva' y el 'límite de sesión desconectada' en Nunca (o un valor que aceptes) y ejecuta gpupdate /force.

¿Qué significan los códigos de error RDP 0x204 y 0x104?

Fallos de conectividad: el cliente nunca completó el handshake con el host.
Ambos son fallos de conectividad que notifican los clientes modernos de Escritorio remoto: el cliente nunca completó el handshake. Comprueba que el host está activo, que el puerto 3389 (o tu puerto personalizado) es accesible y que ninguna regla de firewall o NAT está descartando el tráfico.

¿Un timeout significa siempre un problema de firewall?

Normalmente, pero no siempre: un timeout significa paquetes descartados; un rechazo, que nada escucha.
No, pero es la causa más habitual: un timeout significa que los paquetes se descartaron en silencio, que es el comportamiento típico de un firewall, mientras que una 'conexión rechazada' instantánea significa que el puerto respondió pero nada escucha. Los errores de DNS y de credenciales son, a su vez, fallos distintos.

¿Cómo mantengo viva una sesión RDP a través de routers NAT agresivos?

Activa KeepAliveEnable y KeepAliveInterval en el host para que las sesiones inactivas sobrevivan al NAT.
Activa los keep-alives en el host: pon KeepAliveEnable en 1 y KeepAliveInterval en 1 (minuto) bajo la clave de registro Terminal Server, o la directiva de grupo equivalente bajo Host de sesión de Escritorio remoto > Conexiones.

Si estás peleando con una conexión doméstica inestable o un servidor sobrevendido, la solución más limpia está aguas arriba: un RDP Windows con CPU y RAM dedicadas en un enlace de centro de datos directamente no pierde sesiones, y se entrega en unos 10 segundos tras la confirmación del pago.

Adrien Roche — Editor de infraestructura y hosting

Ingeniero de sistemas con más de 10 años operando flotas de Windows Server y Linux. Adrien mantiene la documentación de infraestructura de rdp.monster y escribe nuestras guías sobre RDP, hosting VPS, administración de servidores, redes y herramientas de privacidad.

Regístrate en nuestro programa de revendedores

Tus datos

Si tienes alguna pregunta, contact us by clicking here !
Nombre y apellidos(Obligatorio)
Introduce tu correo electrónico; debes tener una cuenta en manager.rdp.monster !

Tu empresa

Introduce la dirección de tu sitio web si tienes uno
Explica brevemente cómo vas a vender los servicios a tus clientes. Por ejemplo, hablando con gente en foros.

¡Usamos cookies!

Utilizamos cookies para mejorar tu experiencia de navegación, mostrar anuncios o contenido personalizados y analizar nuestro tráfico. Al hacer clic en «Aceptar», consientes nuestro uso de cookies.