Timeout de connexion Bureau à distance : 8 correctifs efficaces

D'abord, localiser la panne

« Le Bureau à distance ne peut pas se connecter à l'ordinateur distant » précédé d'une longue attente est un timeout : rien n'a répondu. Depuis le client, exécutez :

Test-NetConnection 203.0.113.10 -Port 3389

TcpTestSucceeded : True signifie que le chemin réseau est bon et que le problème vient de l'authentification ou d'une stratégie de session. False signifie que quelque chose entre vous et l'hôte rejette le trafic — appliquez les correctifs ci-dessous dans l'ordre.

Correctif 1 — Vérifier que l'hôte et le service sont actifs

Sur le serveur (console, VNC ou panneau de l'hébergeur) :

Get-Service TermService
Restart-Service TermService -Force

Vérifiez aussi que le Bureau à distance est activé : System Properties > Remote, ou contrôlez que fDenyTSConnections vaut 0 sous HKLM:\System\CurrentControlSet\Control\Terminal Server.

Correctif 2 — Règles du Pare-feu Windows

Le groupe de règles intégré « Remote Desktop » doit être activé pour votre profil réseau actuel :

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Si vous utilisez un port personnalisé, la règle doit lui correspondre — consultez notre guide du port RDP 3389 pour les commandes New-NetFirewallRule exactes, et le guide du pare-feu par stratégie de groupe pour les environnements de domaine.

Correctif 3 — Le pare-feu périphérique de l'hébergeur

Sur un VPS ou un serveur dédié, il y a deux pare-feux : celui de Windows et celui de l'hébergeur en périphérie. Si les règles Windows semblent correctes mais que le port expire toujours depuis l'extérieur alors que netstat le montre à l'écoute, c'est le filtre périphérique qui est en cause — ouvrez le port dans le panneau de l'hébergeur ou via un ticket support.

Correctif 4 — Incompatibilité NLA / CredSSP

Si le test TCP réussit mais que le client échoue pendant l'ouverture de session, les niveaux de correctifs divergent sur CredSSP ou le client ne prend pas en charge l'authentification au niveau du réseau (NLA). Mettez d'abord à jour les deux machines ; en dernier recours seulement, et temporairement, assouplissez NLA sur l'hôte (SystemPropertiesRemote > décochez « N'autoriser que les connexions provenant d'ordinateurs exécutant NLA »).

Correctif 5 — Stratégies de limite de durée de session (la déconnexion pour inactivité)

Les sessions qui se connectent bien mais meurent après quelques minutes d'inactivité sont fermées par une stratégie, pas par le réseau. Dans gpedit.msc :

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

• « Définir le délai d'expiration des sessions Services Bureau à distance actives mais inactives » → Jamais
• « Définir le délai d'expiration des sessions déconnectées » → Jamais (ou la durée de rétention de votre choix)

Puis gpupdate /force et reconnectez-vous.

Correctif 6 — Keep-alives contre les minuteurs d'inactivité NAT et VPN

Les routeurs domestiques et les concentrateurs VPN abandonnent silencieusement les flux TCP qui restent inactifs. Faites envoyer par l'hôte un keep-alive chaque minute :

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

Vous faites passer RDP par un VPN côté serveur ? Notre guide pour utiliser un VPN sur un serveur RDP sans déconnexion résout le piège classique « VPN actif, RDP perdu ».

Correctif 7 — MTU et liaisons avec pertes

Des paquets volumineux qui ne survivent jamais au trajet provoquent des connexions qui restent bloquées sur la barre de progression. Testez avec ping -f -l 1472 host ; s'il y a fragmentation, abaissez la MTU de l'interface à 1400 côté client, ou laissez le transport UDP (activé par défaut depuis RDP 8.0) absorber les pertes.

Correctif 8 — Limite de sessions atteinte

Un Windows client n'autorise qu'une session interactive ; les serveurs sans licence RDS en autorisent deux administratives. Un « timeout » juste après la saisie des identifiants peut simplement signifier un hôte plein — fermez les sessions obsolètes avec quser + logoff <id>.

Aide-mémoire symptôme → cause

Foire aux questions

Pourquoi ma session Bureau à distance se déconnecte-t-elle après une période d'inactivité ?

Une stratégie de limite de durée de session la ferme — réglez les limites d'inactivité et de déconnexion sur Jamais.

Une stratégie de limite de durée de session la ferme. Dans la stratégie de groupe, sous Remote Desktop Session Host > Session Time Limits, réglez la limite de session inactive et la limite de session déconnectée sur Jamais (ou une valeur qui vous convient), puis exécutez gpupdate /force.

Que signifient les codes d'erreur RDP 0x204 et 0x104 ?

Des échecs de connectivité — le client n'a jamais terminé la négociation avec l'hôte.

Ce sont deux échecs de connectivité signalés par les clients Bureau à distance modernes : le client n'a jamais terminé la négociation. Vérifiez que l'hôte est allumé, que le port 3389 (ou votre port personnalisé) est joignable et qu'aucune règle de pare-feu ou de NAT ne rejette le trafic.

Un timeout signifie-t-il toujours un problème de pare-feu ?

Souvent, mais pas toujours — un timeout signifie des paquets rejetés, un refus signifie qu'aucun service n'écoute.

Non, mais c'est la cause la plus fréquente : un timeout signifie que les paquets ont été rejetés silencieusement, ce qui est le comportement d'un pare-feu, tandis qu'une « connexion refusée » instantanée signifie que le port a répondu mais que rien n'écoute. Les erreurs DNS et les erreurs d'identifiants sont encore d'autres types de pannes.

Comment maintenir une session RDP active derrière des routeurs NAT agressifs ?

Activez KeepAliveEnable et KeepAliveInterval sur l'hôte pour que les sessions silencieuses survivent au NAT.

Activez les keep-alives sur l'hôte : réglez KeepAliveEnable sur 1 et KeepAliveInterval sur 1 (minute) sous la clé de registre Terminal Server, ou via la stratégie de groupe équivalente sous Remote Desktop Session Host > Connections.

Si vous luttez contre une connexion domestique instable ou un serveur survendu, le correctif le plus propre se situe en amont : un RDP Windows avec CPU et RAM dédiés sur une liaison datacenter ne coupe tout simplement pas les sessions — livré environ 10 secondes après confirmation du paiement.