Tempo limite do RDP: 8 correções que funcionam de verdade

Primeiro, localize a falha

“A Área de Trabalho Remota não consegue conectar-se ao computador remoto” com uma longa espera é um tempo limite: nada respondeu. No cliente, execute:

Test-NetConnection 203.0.113.10 -Port 3389

TcpTestSucceeded : True significa que o caminho de rede está correto e que o problema é de autenticação ou de política de sessão. False significa que algo entre você e o host está descartando o tráfego — siga as correções abaixo pela ordem.

Correção 1 — Confirme que o host e o serviço estão ativos

No servidor (console, VNC ou painel do provedor):

Get-Service TermService
Restart-Service TermService -Force

Confirme também que a Área de Trabalho Remota está ativada: System Properties > Remote, ou verifique se fDenyTSConnections está em 0 sob HKLM:\System\CurrentControlSet\Control\Terminal Server.

Correção 2 — Regras do Firewall do Windows

O grupo de regras integrado “Remote Desktop” tem de estar ativado para o seu perfil de rede atual:

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Se usa uma porta personalizada, a regra tem de corresponder a ela — consulte o nosso guia da porta RDP 3389 para os comandos New-NetFirewallRule exatos, e o guia de firewall por Group Policy para ambientes de domínio.

Correção 3 — O firewall de borda do provedor

Num VPS ou servidor dedicado existem dois firewalls: o do Windows e o de borda do provedor. Se as regras do Windows parecem corretas mas a porta continua a expirar do exterior enquanto o netstat mostra que está à escuta, o culpado é o filtro de borda — abra a porta no painel do provedor ou por ticket de suporte.

Correção 4 — Incompatibilidade NLA / CredSSP

Se o teste TCP tem sucesso mas o cliente falha durante o login, os níveis de atualização discordam quanto ao CredSSP ou o cliente não consegue fazer Network Level Authentication. Atualize primeiro as duas máquinas; só como último recurso, e temporariamente, relaxe o NLA no host (SystemPropertiesRemote > desmarque “Permitir conexões apenas de computadores que executam NLA”).

Correção 5 — Políticas de limite de tempo de sessão (a desconexão por inatividade)

Sessões que conectam bem mas morrem após alguns minutos de inatividade estão a ser encerradas por política, não pela rede. Em gpedit.msc:

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

• “Definir limite de tempo para sessões ativas mas inativas dos Serviços de Área de Trabalho Remota” → Nunca
• “Definir limite de tempo para sessões desconectadas” → Nunca (ou o valor de retenção que preferir)

Depois execute gpupdate /force e reconecte.

Correção 6 — Keep-alives contra temporizadores de inatividade de NAT e VPN

Roteadores domésticos e concentradores de VPN descartam silenciosamente fluxos TCP que ficam sem tráfego. Faça o host enviar keep-alives a 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

Está a usar RDP através de uma VPN do lado do servidor? O nosso guia sobre usar uma VPN num servidor RDP sem desconexão resolve a clássica armadilha “VPN ligada, RDP perdido”.

Correção 7 — MTU e ligações com perdas

Pacotes grandes que nunca sobrevivem ao caminho provocam conexões que ficam presas na barra de progresso. Teste com ping -f -l 1472 host; se houver fragmentação, reduza a MTU da interface para 1400 no cliente, ou deixe o transporte UDP (ativo por padrão desde o RDP 8.0) absorver a perda.

Correção 8 — Limite de sessões atingido

O Windows cliente permite uma sessão interativa; servidores sem licenciamento RDS permitem duas sessões administrativas. Um “tempo limite” logo após as credenciais pode ser simplesmente um host cheio — encerre sessões obsoletas com quser + logoff <id>.

Sintoma → causa: tabela rápida

Perguntas frequentes

Por que a minha sessão de Área de Trabalho Remota desconecta após ficar inativa?

Uma política de limite de tempo de sessão está a encerrá-la — defina os limites de inatividade e de desconexão para Nunca.

Uma política de limite de tempo de sessão está a encerrá-la. No Group Policy, em Remote Desktop Session Host > Session Time Limits, defina o 'limite de sessão inativa' e o 'limite de sessão desconectada' para Nunca (ou um valor que aceite) e execute gpupdate /force.

O que significam os códigos de erro RDP 0x204 e 0x104?

Falhas de conectividade — o cliente nunca concluiu o handshake com o host.

Ambos são falhas de conectividade reportadas pelos clientes modernos de Área de Trabalho Remota: o cliente nunca concluiu o handshake. Verifique se o host está ligado, se a porta 3389 (ou a sua porta personalizada) está acessível e se nenhuma regra de firewall ou de NAT está a descartar o tráfego.

Um tempo limite significa sempre um problema de firewall?

Geralmente, mas não sempre — um tempo limite significa pacotes descartados, uma recusa significa que nada está à escuta.

Não, mas é a causa mais comum: um tempo limite significa que os pacotes foram descartados em silêncio, o que é comportamento de firewall, enquanto uma 'conexão recusada' imediata significa que a porta respondeu mas nada está à escuta. Erros de DNS e erros de credenciais são falhas de outra natureza.

Como manter uma sessão RDP ativa através de roteadores NAT agressivos?

Ative KeepAliveEnable e KeepAliveInterval no host para que sessões silenciosas sobrevivam ao NAT.

Ative os keep-alives no host: defina KeepAliveEnable como 1 e KeepAliveInterval como 1 (minuto) na chave de registro do Terminal Server, ou a Group Policy equivalente em Remote Desktop Session Host > Connections.

Se está a lutar com uma ligação doméstica instável ou com um servidor sobrevendido, a correção mais limpa está a montante: um RDP Windows com CPU e RAM dedicados num link de datacenter simplesmente não derruba sessões — entregue em cerca de 10 segundos.