Remote Desktop Verbindungstimeout: 8 Lösungen, die wirklich helfen

Zuerst den Fehler eingrenzen

„Remotedesktop kann keine Verbindung mit dem Remotecomputer herstellen“ nach langem Hängen ist ein Timeout: Nichts hat geantwortet. Führen Sie auf dem Client aus:

Test-NetConnection 203.0.113.10 -Port 3389

TcpTestSucceeded : True bedeutet, dass der Netzwerkpfad in Ordnung ist und das Problem bei der Authentifizierung oder der Sitzungsrichtlinie liegt. False bedeutet, dass etwas zwischen Ihnen und dem Host den Datenverkehr verwirft — arbeiten Sie die folgenden Lösungen der Reihe nach ab.

Lösung 1 — Prüfen, ob Host und Dienst laufen

Auf dem Server (Konsole, VNC oder Anbieter-Panel):

Get-Service TermService
Restart-Service TermService -Force

Prüfen Sie außerdem, ob Remotedesktop aktiviert ist: System Properties > Remote, oder kontrollieren Sie, ob fDenyTSConnections auf 0 steht unter HKLM:\System\CurrentControlSet\Control\Terminal Server.

Lösung 2 — Regeln der Windows-Firewall

Die integrierte Regelgruppe „Remotedesktop“ muss für Ihr aktuelles Netzwerkprofil aktiviert sein:

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Wenn Sie einen benutzerdefinierten Port verwenden, muss die Regel dazu passen — die genauen New-NetFirewallRule-Befehle finden Sie in unserem Leitfaden zum RDP-Port 3389, und für Domänenumgebungen im Firewall-Leitfaden per Gruppenrichtlinie.

Lösung 3 — Die Edge-Firewall des Anbieters

Auf einem VPS oder Dedicated Server gibt es zwei Firewalls: Windows und die Edge des Anbieters. Wenn die Windows-Regeln korrekt aussehen, der Port von außen aber weiterhin in ein Timeout läuft, während netstat ihn als lauschend anzeigt, ist der Edge-Filter der Schuldige — öffnen Sie den Port im Anbieter-Panel oder per Support-Ticket.

Lösung 4 — NLA-/CredSSP-Konflikt

Wenn der TCP-Test erfolgreich ist, der Client aber beim Anmelden einen Fehler meldet, passen die Patch-Stände bei CredSSP nicht zusammen oder der Client beherrscht keine Authentifizierung auf Netzwerkebene. Aktualisieren Sie zuerst beide Rechner; nur als letzten Ausweg und vorübergehend NLA auf dem Host lockern (SystemPropertiesRemote > Häkchen bei „Verbindungen nur von Computern mit NLA zulassen“ entfernen).

Lösung 5 — Sitzungszeitlimit-Richtlinien (die Leerlauf-Trennung)

Sitzungen, die sich problemlos verbinden, aber nach einigen Minuten Inaktivität sterben, werden von einer Richtlinie beendet, nicht vom Netzwerk. In gpedit.msc:

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

• „Zeitlimit für aktive, aber im Leerlauf befindliche Remotedesktopdienste-Sitzungen festlegen“ → Nie
• „Zeitlimit für getrennte Sitzungen festlegen“ → Nie (oder Ihre gewünschte Aufbewahrungsdauer)

Dann gpupdate /force ausführen und neu verbinden.

Lösung 6 — Keep-Alives gegen NAT- und VPN-Leerlauf-Timer

Heimrouter und VPN-Konzentratoren verwerfen stillschweigend TCP-Flows, die ruhig bleiben. Lassen Sie den Host jede Minute Keep-Alives senden:

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

Betreiben Sie RDP über ein VPN auf der Serverseite? Unser Leitfaden zur Nutzung eines VPN auf einem RDP-Server ohne Verbindungsabbruch löst die klassische Falle „VPN aktiv, RDP weg“.

Lösung 7 — MTU und verlustbehaftete Leitungen

Große Pakete, die den Pfad nie überstehen, führen zu Verbindungen, die am Fortschrittsbalken hängen bleiben. Testen Sie mit ping -f -l 1472 host; wird fragmentiert, senken Sie die MTU der Schnittstelle auf dem Client auf 1400 oder lassen Sie den UDP-Transport (seit RDP 8.0 standardmäßig aktiviert) den Verlust abfangen.

Lösung 8 — Sitzungslimit erreicht

Windows-Client-Versionen erlauben eine interaktive Sitzung; Server ohne RDS-Lizenzierung erlauben zwei administrative Sitzungen. Ein „Timeout“ direkt nach der Anmeldung kann schlicht ein voller Host sein — melden Sie verwaiste Sitzungen mit quser + logoff <id> ab.

Spickzettel: Symptom → Ursache

Häufig gestellte Fragen

Warum wird meine Remotedesktop-Sitzung nach Leerlauf getrennt?

Eine Sitzungszeitlimit-Richtlinie beendet sie — setzen Sie die Limits für Leerlauf und getrennte Sitzungen auf Nie.

Eine Sitzungszeitlimit-Richtlinie beendet sie. Setzen Sie in der Gruppenrichtlinie unter Remotedesktop-Sitzungshost > Sitzungszeitlimits das „Zeitlimit für Leerlaufsitzungen“ und das „Zeitlimit für getrennte Sitzungen“ auf Nie (oder einen für Sie akzeptablen Wert) und führen Sie dann gpupdate /force aus.

Was bedeuten die RDP-Fehlercodes 0x204 und 0x104?

Verbindungsfehler — der Client hat den Handshake mit dem Host nie abgeschlossen.

Beides sind Verbindungsfehler, die von den modernen Remotedesktop-Clients gemeldet werden: Der Client hat den Handshake nie abgeschlossen. Prüfen Sie, ob der Host läuft, Port 3389 (oder Ihr benutzerdefinierter Port) erreichbar ist und keine Firewall- oder NAT-Regel den Datenverkehr verwirft.

Bedeutet ein Timeout immer ein Firewall-Problem?

Meistens, aber nicht immer — ein Timeout bedeutet verworfene Pakete, eine Ablehnung bedeutet keinen Listener.

Nein, aber es ist die häufigste Ursache: Ein Timeout bedeutet, dass Pakete stillschweigend verworfen wurden, was typisches Firewall-Verhalten ist, während ein sofortiges „connection refused“ bedeutet, dass der Port geantwortet hat, aber nichts lauscht. DNS-Fehler und Anmeldefehler sind wiederum andere Fehlerarten.

Wie halte ich eine RDP-Sitzung über aggressive NAT-Router hinweg am Leben?

Aktivieren Sie KeepAliveEnable und KeepAliveInterval auf dem Host, damit ruhige Sitzungen NAT überstehen.

Aktivieren Sie Keep-Alives auf dem Host: Setzen Sie KeepAliveEnable auf 1 und KeepAliveInterval auf 1 (Minute) unter dem Registrierungsschlüssel Terminal Server, oder nutzen Sie die entsprechende Gruppenrichtlinie unter Remotedesktop-Sitzungshost > Verbindungen.

Wenn Sie mit einer instabilen Heimverbindung oder einem überbuchten Server kämpfen, liegt die sauberste Lösung vorgelagert: Ein Windows RDP mit dediziertem CPU und RAM an einer Rechenzentrumsanbindung bricht Sitzungen gar nicht erst ab — bereitgestellt etwa 10 Sekunden nach Zahlungsbestätigung.