1 19/05/2026 10 min

Quando un server RDP Windows VPS “non risponde”, il problema raramente è solo “RDP rotto”. In pratica devi capire quale layer sta fallendo: DNS, raggiungibilità IP, porta 3389, servizio Remote Desktop Services, firewall di Windows, policy di autenticazione, oppure il provider che blocca il traffico a monte. Se salti questo ordine, finisci a cambiare impostazioni alla cieca e a perdere tempo.

La verifica corretta parte sempre da fuori verso dentro. Prima controlli se il VPS è raggiungibile sulla rete, poi se la porta RDP accetta connessioni, poi se Windows sta davvero ascoltando, infine se l’accesso fallisce per autenticazione, NLA o policy locali. Questo approccio riduce il rumore: un timeout di rete non si tratta come un errore di login, e un servizio fermo non si risolve con una modifica al client.

1. Capire se il problema è rete, porta o Windows

La prima domanda non è “RDP funziona?”, ma “dove si interrompe il flusso?”. Da una macchina esterna al VPS, verifica in quest’ordine: DNS, ICMP se consentito, TCP 3389, banner/handshake RDP, accesso credenziali. Se hai un pannello VPS, usa anche la console web del provider: è il modo più rapido per distinguere un problema di rete da un problema di sistema operativo.

Se il VPS ha un nome host, controlla che punti all’IP corretto. Un record DNS sbagliato ti fa inseguire un server diverso dal tuo. Se il nome non risolve o risolve verso un indirizzo inatteso, il test RDP è inutile finché non sistemi la risoluzione.

Comandi utili da una shell Linux o da Windows PowerShell:

nslookup vps.example.com

ping -c 3 203.0.113.10

nc -vz 203.0.113.10 3389
# oppure, da PowerShell
Test-NetConnection 203.0.113.10 -Port 3389

Interpretazione rapida: se DNS è corretto ma la porta 3389 è chiusa o filtra in timeout, il problema è quasi sempre firewall, security group del provider, servizio RDP non in ascolto, oppure un sistema saturo o bloccato. Se invece la porta risponde ma il client RDP fallisce dopo il contatto iniziale, la causa tende a stare su NLA, certificati, credenziali o policy di accesso remoto.

2. Verificare dal lato Windows se RDP sta ascoltando davvero

Una volta escluso il problema di rete esterna, entra nel VPS dalla console del provider o da accesso alternativo. Qui devi verificare che il servizio Remote Desktop Services sia attivo e che il sistema stia ascoltando sulla porta configurata. Non dare per scontato che la porta sia 3389: può essere stata cambiata per hardening o per una configurazione precedente.

Da PowerShell, controlla il servizio e il listener:

Get-Service TermService

netstat -ano | findstr :3389

Get-Process -Id (Get-NetTCPConnection -LocalPort 3389).OwningProcess

Se TermService non è in esecuzione, RDP non può accettare sessioni. Se il servizio è attivo ma non c’è alcun listener su 3389, controlla la configurazione della porta e i criteri locali. Se il listener esiste ma da fuori non raggiungi la porta, il problema è quasi certamente esterno al sistema: firewall di Windows, regole del provider o filtro a monte.

Puoi verificare la porta configurata anche dal registro o dalla policy, ma conviene prima leggere lo stato attuale. Il punto non è “forzare 3389”, è capire quale valore è realmente in uso:

reg query "HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber

Se il valore è diverso da 3389, il client deve puntare a quella porta. Se il provider espone solo 3389 o hai un firewall esterno rigido, cambiare la porta senza aggiornare il resto della catena ti lascia comunque fuori.

3. Controllare il firewall di Windows e le regole del provider

Il classico falso positivo è questo: in Windows tutto sembra corretto, ma il traffico viene bloccato dal firewall locale o dal pannello del VPS. Nei servizi cloud e nei VPS gestiti, spesso ci sono due livelli distinti: Windows Defender Firewall e firewall/security group lato provider. Devono essere entrambi coerenti.

Dal sistema Windows, verifica se esiste una regola abilitata per Remote Desktop:

Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object DisplayName, Enabled, Profile, Direction, Action

Se non vedi regole abilitate, o se il profilo attivo non è incluso, RDP può restare in ascolto ma irraggiungibile. In ambienti con hardening aggressivo, può esserci anche una regola personalizzata che limita l’accesso a un IP specifico o a una subnet amministrativa.

Dal lato provider, cerca nel pannello voci come Firewall, Security Groups, Network ACL o Access Rules. L’obiettivo è semplice: la porta TCP 3389 deve essere consentita dal tuo IP di amministrazione, o almeno dalla rete da cui lavori. Se la regola è troppo restrittiva, il client vedrà timeout. Se è troppo aperta, hai un’esposizione inutile e facile da scandagliare.

Per una verifica rapida del comportamento dal punto di vista esterno, usa un test di connessione porta e guarda se il tentativo cade in timeout o rifiuto immediato:

Test-NetConnection 203.0.113.10 -Port 3389

Se il risultato mostra TcpTestSucceeded : False con timeout, il traffico viene filtrato o non arriva al listener. Se ricevi Connection refused, la porta è raggiungibile ma nessun processo sta ascoltando. Questa distinzione ti evita diagnosi sbagliate.

4. NLA, credenziali e policy: quando la porta risponde ma l’accesso fallisce

Se il client RDP arriva alla finestra di autenticazione ma poi fallisce, il layer di rete è già superato. A quel punto devi verificare Network Level Authentication, account autorizzati, password scadute, lockout e policy locali. Qui il sintomo cambia: non hai più un problema di connettività pura, ma di accesso remoto.

Le cause più comuni sono queste: l’utente non è nel gruppo Remote Desktop Users, l’account è bloccato, la password è scaduta, oppure una policy locale o di dominio impedisce l’accesso via RDP. In un VPS standalone, la verifica è più semplice; in un server joined a dominio, devi considerare anche GPO e criteri di sicurezza applicati centralmente.

Controlli rapidi da console Windows:

net localgroup "Remote Desktop Users"

net user NOME_UTENTE

secedit /export /cfg C:\Temp\secpol.cfg

Se usi NLA, il client deve supportarla. I client moderni lo fanno, ma in ambienti misti o con software datato può comparire un errore di compatibilità. Disabilitare NLA è una misura temporanea e va trattata come rischio: abbassa il livello di protezione dell’accesso remoto. Se la usi per emergenza, documenta il rollback e riattivala appena possibile.

Per controllare lo stato di NLA dal registro o dalle impostazioni di sistema, puoi verificare questa chiave:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication

Valore 1 indica NLA abilitata, 0 disabilitata. Se devi intervenire, fallo solo dopo aver confermato che il problema è davvero di compatibilità o autenticazione, non di rete. Un cambio fatto per sbaglio qui può peggiorare l’esposizione del server senza risolvere nulla.

5. Leggere i log giusti invece di andare per tentativi

I log ti dicono se il server vede il tentativo di connessione, se lo rifiuta, o se non riceve niente. Per RDP, i riferimenti utili sono il Visualizzatore eventi e i log di TerminalServices. Se il sistema è stato toccato da poco, i log sono spesso il modo più veloce per distinguere errore di autorizzazione, handshake TLS e blocco di rete.

Nel Visualizzatore eventi cerca questi canali: Applications and Services Logs > Microsoft > Windows > TerminalServices-RemoteConnectionManager e TerminalServices-LocalSessionManager. Gli eventi di errore o warning in corrispondenza del tuo tentativo sono molto più utili di una generica schermata “non riesco a connettermi”.

Se vuoi fare una verifica rapida da PowerShell:

Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" -MaxEvents 20 | Select-Object TimeCreated, Id, LevelDisplayName, Message

Get-WinEvent -LogName "System" -MaxEvents 50 | Where-Object {$_.ProviderName -match "TermService|Schannel|Tcpip"} | Select-Object TimeCreated, Id, ProviderName, Message

Se compaiono errori Schannel, la parte TLS/certificato può essere coinvolta. Se trovi eventi di login negato, il problema è di account o policy. Se non c’è nulla in corrispondenza del test esterno, il traffico non arriva proprio al servizio: torna a firewall, provider o routing.

6. Verificare saturazione, risorse e blocchi del sistema

Un VPS sotto forte pressione può sembrare “irraggiungibile” anche se la rete è sana. CPU al 100%, RAM esaurita, disco pieno o I/O bloccato possono rendere la sessione RDP lentissima o farla fallire durante l’handshake. Se la macchina risponde solo dalla console ma non da RDP, la causa può essere interna e non di rete.

Dal Task Manager o da PowerShell controlla almeno CPU, memoria e spazio disco. Una verifica rapida:

Get-Volume | Select-Object DriveLetter, SizeRemaining, Size

Get-Counter '\Processor(_Total)\% Processor Time' -SampleInterval 1 -MaxSamples 5

Get-Counter '\Memory\Available MBytes'

Se il disco di sistema è quasi pieno, anche il logging e la gestione delle sessioni possono degradare. Se la memoria è insufficiente, il servizio può diventare instabile. In presenza di saturazione, la soluzione non è “ritentare il login” all’infinito: prima liberi risorse, poi verifichi il servizio, poi riprovi il collegamento.

7. Sequenza pratica di troubleshooting, senza saltare i passaggi

Se devi fare una diagnosi veloce su un VPS Windows RDP, usa questa sequenza. È ordinata dal meno invasivo al più specifico, e ti evita di cambiare impostazioni quando basta leggere un log o fare un test di porta.

  1. Verifica il nome host e l’IP pubblico con nslookup o dal pannello del provider.
  2. Testa la porta 3389 da una rete esterna con Test-NetConnection o nc.
  3. Entra dalla console web del provider e controlla TermService e il listener su 3389.
  4. Leggi le regole del firewall di Windows e quelle del provider.
  5. Controlla se l’utente è autorizzato a fare RDP e se NLA crea un blocco.
  6. Esamina i log di Terminal Services e gli eventi di sistema in corrispondenza del tentativo.
  7. Se il sistema è saturo, libera risorse o pianifica un reboot controllato dalla console, non dal client RDP.

Questa sequenza funziona perché separa i problemi di trasporto da quelli di autenticazione. Il client RDP può mostrare messaggi simili per cause molto diverse, ma i test di rete e i log del server ti dicono subito in quale direzione andare.

8. Caso tipico: porta aperta, ma schermo nero o sessione che si chiude subito

Questo scenario è frequente: la porta 3389 risponde, il login sembra partire, poi ottieni schermo nero, disconnessione o finestra che si chiude. Qui il problema spesso non è il firewall. Le cause più comuni sono profilo utente corrotto, driver grafici/accelerazione remota, policy di sessione, o un problema del servizio grafico di Windows dopo aggiornamenti o reboot incompleti.

Prima di toccare la configurazione RDP, guarda se il comportamento è riproducibile con un altro account amministrativo. Se un secondo account entra correttamente, il problema sta nel profilo o nei permessi del primo account. Se nessun account entra, torna ai log di sistema e ai servizi correlati.

In questi casi, la console del provider è ancora più utile: se il desktop locale funziona ma RDP no, hai una differenza tra sessione grafica locale e remota. Questo restringe il campo a policy, shell, profili utente o componenti grafici, non alla rete.

9. Hardening minimo per non ritrovarti nello stesso guaio

Una volta ripristinata la connettività, conviene mettere in ordine il perimetro. RDP esposto su Internet senza restrizioni è un bersaglio prevedibile. Non serve paranoia, serve disciplina operativa: limita l’accesso, tieni un canale di emergenza, e conserva un metodo alternativo per entrare nel VPS se RDP smette di funzionare.

Le misure ragionevoli sono queste: consenti 3389 solo da IP fidati, lascia NLA attiva salvo emergenza, usa account amministrativi separati dalle utenze ordinarie, e verifica che il provider non stia esponendo il servizio a una rete più ampia di quella prevista. Se il pannello supporta una VPN o un bastion host, è spesso una scelta migliore dell’apertura diretta di RDP su Internet.

Se cambi porta RDP, documenta il cambio nel runbook e nel pannello del provider. Una porta non standard non è una misura di sicurezza forte, ma può ridurre il rumore automatico. Non sostituisce firewall, NLA o restrizioni IP.

10. Conclusione operativa: cosa guardare per primo

Per verificare la connettività a un server RDP Windows VPS, il percorso corretto è sempre lo stesso: DNS, porta, listener, firewall, autenticazione, log, risorse. Se la porta non risponde, non perdere tempo sui credenziali. Se la porta risponde ma l’accesso fallisce, non cambiare il firewall a caso. Se il server è saturo, non confondere il degrado prestazionale con un guasto di rete.

La parte più utile, in pratica, è avere un test esterno ripetibile e una console di emergenza del provider. Con questi due strumenti puoi capire in pochi minuti se il problema è fuori dal server o dentro Windows. Tutto il resto viene dopo.