Timeout connessione Desktop remoto: 8 soluzioni che funzionano

Prima di tutto, localizza il guasto

“Desktop remoto non riesce a connettersi al computer remoto” dopo una lunga attesa è un timeout: nessuno ha risposto. Dal client, esegui:

Test-NetConnection 203.0.113.10 -Port 3389

TcpTestSucceeded : True significa che il percorso di rete è a posto e il problema riguarda l'autenticazione o i criteri di sessione. False significa che qualcosa tra te e l'host sta scartando il traffico: segui le soluzioni qui sotto nell'ordine indicato.

Soluzione 1 — Verifica che host e servizio siano attivi

Sul server (console, VNC o pannello del provider):

Get-Service TermService
Restart-Service TermService -Force

Verifica anche che Desktop remoto sia abilitato: System Properties > Remote, oppure controlla che fDenyTSConnections sia 0 in HKLM:\System\CurrentControlSet\Control\Terminal Server.

Soluzione 2 — Regole di Windows Firewall

Il gruppo di regole integrato “Desktop remoto” deve essere abilitato per il profilo di rete corrente:

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Se usi una porta personalizzata, la regola deve corrispondere: consulta la nostra guida alla porta RDP 3389 per i comandi New-NetFirewallRule esatti, e la guida al firewall via Criteri di gruppo per gli ambienti di dominio.

Soluzione 3 — Il firewall perimetrale del provider

Su un VPS o un server dedicato ci sono due firewall: quello di Windows e quello perimetrale del provider. Se le regole di Windows sembrano corrette ma la porta va ancora in timeout dall'esterno mentre netstat la mostra in ascolto, il colpevole è il filtro perimetrale: apri la porta dal pannello del provider o con un ticket di supporto.

Soluzione 4 — Incompatibilità NLA / CredSSP

Se il test TCP riesce ma il client dà errore durante il login, i livelli di patch non concordano su CredSSP oppure il client non è in grado di eseguire l'autenticazione a livello di rete (NLA). Aggiorna prima entrambe le macchine; solo come ultima risorsa, e temporaneamente, allenta NLA sull'host (SystemPropertiesRemote > deseleziona “Consenti connessioni solo da computer che eseguono NLA”).

Soluzione 5 — Criteri di limite temporale delle sessioni (la disconnessione per inattività)

Le sessioni che si connettono senza problemi ma cadono dopo alcuni minuti di inattività vengono terminate da un criterio, non dalla rete. In gpedit.msc:

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

• “Imposta limite di tempo per le sessioni di Servizi Desktop remoto attive ma inattive” → Mai
• “Imposta limite di tempo per le sessioni disconnesse” → Mai (o la durata di conservazione che preferisci)

Poi gpupdate /force e riconnettiti.

Soluzione 6 — Keep-alive contro i timer di inattività di NAT e VPN

I router domestici e i concentratori VPN scartano silenziosamente i flussi TCP che restano inattivi. Fai in modo che l'host invii keep-alive ogni 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

Usi RDP attraverso una VPN lato server? La nostra guida su come usare una VPN su un server RDP senza disconnessioni risolve la classica trappola “VPN attiva, RDP sparito”.

Soluzione 7 — MTU e collegamenti con perdita di pacchetti

I pacchetti grandi che non sopravvivono al percorso causano connessioni che si bloccano sulla barra di avanzamento. Testa con ping -f -l 1472 host; se si frammenta, abbassa la MTU dell'interfaccia a 1400 sul client, oppure lascia che il trasporto UDP (abilitato per impostazione predefinita da RDP 8.0) assorba la perdita.

Soluzione 8 — Limite di sessioni raggiunto

Windows client consente una sola sessione interattiva; i server senza licenze RDS consentono due sessioni amministrative. Un “timeout” subito dopo le credenziali può essere semplicemente un host pieno: disconnetti le sessioni obsolete con quser + logoff <id>.

Tabella riassuntiva sintomo → causa

Domande frequenti

Perché la mia sessione Desktop remoto si disconnette dopo un periodo di inattività?

La sta terminando un criterio di limite temporale della sessione: imposta i limiti di inattività e di disconnessione su Mai.

La sta terminando un criterio di limite temporale della sessione. In Criteri di gruppo, sotto Remote Desktop Session Host > Session Time Limits, imposta il limite per le sessioni inattive e quello per le sessioni disconnesse su Mai (o su un valore che ritieni accettabile), poi esegui gpupdate /force.

Cosa significano i codici di errore RDP 0x204 e 0x104?

Errori di connettività: il client non ha mai completato l'handshake con l'host.

Sono entrambi errori di connettività segnalati dai client Desktop remoto moderni: il client non ha mai completato l'handshake. Verifica che l'host sia acceso, che la porta 3389 (o la tua porta personalizzata) sia raggiungibile e che nessuna regola firewall o NAT stia scartando il traffico.

Un timeout indica sempre un problema di firewall?

Di solito, ma non sempre: un timeout significa pacchetti scartati, un rifiuto significa nessun listener.

No, ma è la causa più comune: un timeout significa che i pacchetti sono stati scartati in silenzio, comportamento tipico di un firewall, mentre un 'connessione rifiutata' istantaneo significa che la porta ha risposto ma nessun servizio è in ascolto. Gli errori DNS e gli errori di credenziali sono ancora altri tipi di guasto.

Come mantengo attiva una sessione RDP attraverso router NAT aggressivi?

Abilita KeepAliveEnable e KeepAliveInterval sull'host, così le sessioni silenziose sopravvivono al NAT.

Abilita i keep-alive sull'host: imposta KeepAliveEnable a 1 e KeepAliveInterval a 1 (minuto) nella chiave di registro Terminal Server, oppure usa il criterio di gruppo equivalente sotto Remote Desktop Session Host > Connections.

Se stai lottando con una connessione domestica instabile o con un server sovraffollato, la soluzione più pulita è a monte: un RDP Windows con CPU e RAM dedicate su un collegamento da datacenter non perde sessioni fin dall'inizio, ed è consegnato in circa 10 secondi dopo la conferma del pagamento.