RDP via CAPAM lento ou travando: diagnóstico definitivo e soluções práticas (UDP 3389, QoS, MTU, gravação de sessão)

Sessões RDP via CAPAM lentas ou congelando, apesar de CPU e memória baixas no servidor? Este guia prático mostra as causas mais prováveis, como medir objetivamente e as correções que devolvem a usabilidade rapidamente.

Índice

Visão geral do problema

Quando o acesso remoto passa por um CAPAM (gateway/proxy de acesso privilegiado), a rota deixa de ser direta. O caminho típico torna‑se Cliente → CAPAM → Servidor. Isso adiciona saltos de rede, encapsulamentos e, muitas vezes, features do próprio appliance (gravação de vídeo/keystrokes, inspeção de clipboard, políticas de redirecionamento) que geram sobrecarga. É comum ver CPU e memória “baixas” no host de destino e, ainda assim, a experiência estar ruim por latência, jitter, perda de pacotes, MTU/fragmentação ou por limitações do próprio CAPAM ou do cliente RDP.

Resposta direta

Rede é o principal suspeito — especialmente se o tráfego UDP do RDP (porta 3389/UDP ou, em cenários com gateway, 3391/UDP) está bloqueado e a sessão cai para TCP puro. Em paralelo, verifique carga no CAPAM, gravação de sessão, versão/firmware e políticas. Simplifique a sessão (resolução/cores/efeitos) e meça objetivamente perda e retransmissões. Faça um teste A/B: direto no servidor versus via CAPAM, para isolar o gargalo.

Causas prováveis por área

Área	Sinais típicos	Por que degrada
Rede	Saltos com perda > 1%, alta variância de ping, quedas intermitentes	RDP depende de entrega oportuna de gráficos e entradas; perda/jitter causam retransmissões e espera de janelas TCP
Transporte RDP	Queda para TCP apenas, ausência de tráfego UDP	Sem UDP, a experiência gráfica fica mais suscetível a latência e congestionamento
Próprio CAPAM	Uso elevado de CPU/IO, gravação de sessão habilitada, firmware antigo	Proxy adiciona cópia/transcodificação/armazenamento; firmware e políticas podem ampliar a latência
Cliente RDP/Display	Resolução 4K/escala alta, cliente antigo, efeitos visuais	Mais pixels para codificar; codecs antigos ou configurações “ricas” ampliam uso de banda e CPU
Logon/ambiente	Atrasos no logon, GPOs pesadas, mapeamentos lentos	Scripts, impressoras/unidades e antivírus no logon travam a sessão inicial
Servidor/host RDS	Retransmissões TCP, NIC/driver desatualizados, offloads problemáticos	Drivers e offloads mal ajustados geram latência e drops em rajadas

Checklist de trinta minutos para recuperar a usabilidade

Reduza a carga gráfica: diminua a resolução e a profundidade de cor para 16‑bit; desative papel de parede, animações, fontes suavizadas.
Desligue redirecionamentos para teste: discos, impressoras, áudio, smart cards.
Garanta o UDP: teste com UDP habilitado e desabilitado no cliente para comparar; verifique portas 3389/UDP (nativo) ou 3391/UDP (via gateway) ao longo do caminho.
Isolamento do CAPAM: faça um acesso direto temporário (mesma rede, mesmas contas) e compare.
Medições objetivas: pathping/tracert, captura leve no Wireshark, contadores no PerfMon por 5–10 minutos.
Alivie o appliance: pause gravação de sessão e verifique CPU/RAM/IO/latência nas interfaces.

Fluxo de diagnóstico prático

Confirme o básico
- Serviços de Área de Trabalho Remota ativos no host (TermService).
- Cliente RDP atualizado (MSTSC ou cliente moderno).
Teste de rede ponta a ponta
- Cliente → CAPAM e CAPAM → Servidor com latência e perda.
- Ideal: latência média < 80 ms, jitter < 15 ms, perda < 1%. Acima disso, a experiência degrada visivelmente.
A/B com e sem CAPAM
- Se direto é fluido e via CAPAM é ruim, foque no appliance e nos links ao redor dele.
Verifique transporte UDP
- Se não houver tráfego UDP, investigue bloqueio na rede, política do cliente (“desligar UDP”) ou limitação do CAPAM.
Ajuste cliente e sessão
- Resolução/cores/efeitos, redirecionamentos, codecs gráficos.
Olhe servidor e NIC
- Drivers, offloads e MTU coerentes em todo o caminho.

Comandos úteis para medir e comparar

Windows

pathping CAPAM_FQDN
pathping SERVIDOR_FQDN

tracert -d CAPAM\_FQDN
tracert -d SERVIDOR\_FQDN

ping -n 50 CAPAM\_FQDN
ping -n 50 SERVIDOR\_FQDN

netsh interface ipv4 show subinterfaces
ping -f -l 1472 CAPAM\_FQDN   # teste de MTU (ajuste o -l até não fragmentar)

Test-NetConnection SERVIDOR\_FQDN -CommonTCPPort RDP

Para UDP use ferramentas como PsPing (Sysinternals) ou iPerf3

Get-Counter '\TCPv4\Segments Retransmitted/sec'
Get-Counter '\Network Interface(\*)\Output Queue Length'

Linux e macOS

tracepath CAPAM_FQDN
mtr -rwzbc 100 CAPAM_FQDN
ping -c 50 CAPAM_FQDN

iPerf3 entre CAPAM e servidor (quando permitido)

iperf3 -c SERVIDOR -u -b 10M -l 1200 -t 30

Captura rápida (Wireshark/tcpdump)

sudo tcpdump -i eth0 'tcp port 3389 or udp port 3389 or udp port 3391'

Como confirmar se a sessão está usando UDP

Dentro da sessão do MSTSC, clique no indicador de qualidade (barrinhas) na borda superior; o painel de status exibe Transport: UDP ou TCP.
No Wireshark/tcpdump, filtre por udp.port==3389 || udp.port==3391 e verifique pacotes fluindo ambos os sentidos.
Se só houver tcp.port==3389, você está em TCP puro.

Políticas e ajustes do RDP

Política no cliente

Verifique se o cliente não está forçando TCP:

Política: Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Connection Client → Turn Off UDP On Client
Teste: habilite e desabilite em ambientes controlados para comparar.

Política no servidor

Permita que o servidor use ambos os transportes:

Política: Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections → Select RDP transport protocols (use “TCP e UDP”).

Ambiente gráfico e codecs

Políticas úteis: em Remote Desktop Session Host → Remote Session Environment, avalie:
- Prioritize H.264/AVC 444 graphics mode (nem todos os CAPAM suportam; teste ligado e desligado).
- Use hardware graphics adapters for all Remote Desktop Services sessions.
- Configure H.264/AVC hardware encoding.
Nota: alguns CAPAM não gravam bem quando AVC 444 está ativo, causando atraso. Se via CAPAM piorar, teste o modo bitmap clássico.

Modelo de arquivo RDP otimizado para redes hostis

Crie um .rdp de teste com parâmetros minimizando tráfego e funcionalidades periféricas:

session bpp:i:16
use multimon:i:0
screen mode id:i:2
redirectclipboard:i:0
redirectprinters:i:0
redirectdrives:i:0
redirectsmartcards:i:0
audiocapturemode:i:0
audiomode:i:2
disable wallpaper:i:1
disable full window drag:i:1
disable menu anims:i:1
disable themes:i:1
networkautodetect:i:0
bandwidthautodetect:i:0
enablecredsspsupport:i:1
compression:i:1
bitmapcachepersistenable:i:1

Use esse arquivo apenas para diagnóstico. Se a experiência melhorar significativamente, reintroduza recursos aos poucos até encontrar o limitante.

Ajustes no lado do servidor e da NIC

Drivers atualizados de NIC/GPU e firmware do host.
Offloads de rede: teste ativar/desativar RSS, LSO/LSOV2, RSC. Em alguns drivers essas funções introduzem latência sob bursts curtos do RDP.
MTU consistente em todas as interfaces; detecte com ping -f -l e ajuste em subinterfaces se necessário.
DNS/AD: latência e falhas na resolução atrasam logon e perfis.
PerfMon sugerido por 10 minutos:
- TCPv4\Segments Retransmitted/sec (picos são maus sinais)
- Network Interface(*)\Output Queue Length (> 2 indica congestão)
- RemoteFX Graphics(*)\Average encoding time, Frames Skipped/sec (por rede)
- Terminal Services\Active Sessions
- Processos rdpencoder.exe e dwm.exe com uso alto podem indicar gargalo de codificação.

Diagnóstico de QoS e conformidade de MTU

Verificação	Comando ou indicador	Correção
Marcações QoS não esperadas	Captura com Wireshark (DSCP no IP)	Ajustar políticas para não rebaixar RDP; evitar “policing” agressivo
Fragmentação no caminho	`ping -f -l` até achar o maior payload sem fragmentar	Alinhar MTU na WAN, CAPAM e hosts; evitar encapsulamentos sem ajuste de MTU
UDP bloqueado	Sem pacotes em `udp/3389` ou `udp/3391`	Liberar ACLs/Firewalls; checar políticas do CAPAM e do gateway

Impacto do CAPAM e o que ajustar

Gravação de sessão: consome CPU/IO. Pause para teste e observe melhora imediata.
Inspeção de conteúdo/clipboard: pode introduzir latência ao interceptar canais virtuais.
Capacidade do appliance: verifique número de sessões simultâneas, limites de throughput, discos e rede.
Versão/firmware: versões antigas podem não suportar bem AVC/UDP.
TLS inspection entre cliente e CAPAM ou CAPAM e servidor pode afetar handshakes e até bloquear UDP em alguns modos.

Otimizando logon e GPO

Teste com perfil limpo e sem scripts.
Mapeamentos: adie impressoras/unidades, use políticas assíncronas quando possível.
Relatório: gpresult /h c:\temp\gpo.html; confira tempos de aplicação no log GroupPolicy/Operational.
Antivírus/EDR: exclua caminhos temporários de perfil e processos de sessão quando suportado e seguro.

Resultados esperados e metas de qualidade

Latência média: < 80 ms é confortável; 80–150 ms aceitável com UDP; > 150 ms já exige concessões de qualidade.
Jitter: < 15 ms, picos curtos < 30 ms.
Perda: < 1–2% em janelas de 50–100 pacotes.
Retransmissões TCP: valores baixos e estáveis; picos correlacionam com engasgos visuais.

Plano de teste estruturado

Baseline direto sem CAPAM (quando possível) com sessão “leve” e .rdp otimizado.
Via CAPAM com a mesma configuração. Compare métricas de rede e sensação de uso.
Ative gráficos avançados (AVC 444) e observe; se piorar visivelmente via CAPAM, mantenha bitmap clássico para sessões gravadas.
Reintroduza redirecionamentos um a um (áudio, impressoras, discos, smart cards) verificando impactos.

Quando escalar

Perda de pacotes persistente > 1–2% ou jitter instável com quedas visíveis.
CAPAM no limite de CPU/RAM/IO ou com alertas de fila.
Teste direto estável e via CAPAM ruim: envolva rede e fornecedor do CAPAM com evidências.

Pacote de evidências para a equipe de rede ou fornecedor

Resultados de pathping e mtr entre Cliente↔CAPAM e CAPAM↔Servidor.
Capturas curtas mostrando presença ou ausência de udp/3389 ou udp/3391.
Contadores do PerfMon exportados (blg) com eventos de engasgo.
Gráficos de utilização do CAPAM e configuração de gravação/inspeção.
Versões de firmware/cliente/driver e janelas de manutenção disponíveis.

Erros comuns que prolongam o incidente

Confiar apenas em CPU/RAM “baixas” no servidor e ignorar a rede.
Comparar maçãs com laranjas: testar com resolução 4K via CAPAM e 1080p direto.
Alterar vários fatores ao mesmo tempo, tornando impossível identificar a causa raiz.
Não registrar métricas; sem números, não há como provar onde está o problema.

Resumo rápido

Atualize o cliente, simplifique a sessão (resolução/cores/efeitos) e confirme serviços. Meça rede com foco em latência, jitter e perda, garanta UDP 3389, isole CAPAM vs. host, reduza políticas/pesos (gravação, redirecionamentos, GPOs). Use Network Monitor/Wireshark e Performance Monitor para encontrar o gargalo e aplique tuning de RDSH e NIC.

Guia de ações detalhadas passo a passo

Primeiras ações no cliente

Atualize o MSTSC ou cliente moderno do Windows.
Use o .rdp de diagnóstico desta página e avalie a melhora.
Teste com Detecção automática de qualidade desligada.

Testes direcionados de transporte

Habilite UDP no cliente e no servidor; se a rede bloquear, o RDP usará apenas TCP.
Faça A/B forçando UDP desligado no cliente (política) e compare a responsividade.

Isolamento do CAPAM

Conecte direto ao host na mesma rede ou via VPN interna apenas pelo tempo de teste.
Se a sessão direta for estável, concentre‑se na capacidade/políticas do CAPAM e nos links adjacentes.

Medições objetivas

Ping, pathping, traceroute e captura de 60–120 segundos para ver retransmissões e perda.
PerfMon com contadores de TCP, NIC, RemoteFX/Graphics e Terminal Services.

Redirecionamentos e canais virtuais

Desative temporariamente discos, impressoras, áudio e smart cards. Esses canais são sensíveis a perda e atrasos e podem travar a sessão em redes instáveis.

Servidor e NIC

Atualize drivers; valide offloads e MTU; evite TLS inspection quebrando o handshake do RDP.

Perguntas frequentes

CAPAM sempre bloqueia UDP?
Não. Alguns proxies suportam UDP nativamente; outros operam apenas com TCP ou UDP por porta separada. Verifique as capacidades do seu fornecedor e as políticas aplicadas.

Como sei se a degradação vem da gravação de sessão?
Pause a gravação por alguns minutos (se permitido) e compare a responsividade. Se houver melhora imediata, reavalie política, bitrate e armazenamento.

Resolução alta sempre piora?
Quase sempre em redes com perda/jitter. Comece com 1280×720 ou 1600×900 em 16‑bit; se estável, suba gradualmente.

QoS ajuda ou atrapalha?
Ajuda quando bem configurada, mas policing agressivo causa descartes e jitter. Prefira queueing e prioridades equilibradas, medindo o efeito.

Exemplo de roteiro de restauração

Aplicar perfil leve no cliente e desativar redirecionamentos.
Garantir UDP liberado Cliente↔CAPAM↔Servidor.
Realizar teste direto sem CAPAM e comparar.
Se via CAPAM continuar ruim, pausar gravação e coletar métricas do appliance.
Atualizar drivers/firmware relevantes e revisar offloads.
Consolidar evidências e, se necessário, escalar com relatórios.

Indicadores de sucesso após correções

Responsividade imediata a teclado e mouse, sem “borrachas”.
Vídeo/janelas fluindo sem quadros perdidos frequentes.
PerfMon sem picos de retransmissão e filas de saída.
Uso estável de CPU no CAPAM após otimizações de gravação.

Conclusão

O caminho para resolver RDP lento via CAPAM passa por três eixos: rede estável com UDP ativo, appliance dimensionado e ajustado e sessão RDP simplificada e observável. Com medições objetivas e testes A/B, é possível isolar rapidamente o gargalo e aplicar correções duradouras, mantendo segurança e produtividade.