RustDesk-Server: alle Stolpersteine im Überblick

Ein RustDesk-Server OSS besteht aus zwei kleinen Diensten und einem Schlüsselpaar. Die Installation ist in wenigen Minuten erledigt. Die Fehlerbilder danach sind dafür unangenehm indirekt: Der Dienst läuft, die Ports antworten, und trotzdem geht kein Client online. Oder er geht online und nach dem nächsten Neustart ist der gesamte Gerätebestand ausgesperrt.

Diese Sammlung ist für den Moment gedacht, in dem Sie ein solches Symptom vor sich haben und nicht die Einrichtungsanleitung erneut durchlesen wollen. Sie enthält alle zehn Punkte, auch die drei folgenreichsten, die im Hauptbeitrag zur Einrichtung bereits stehen. Wer die Einrichtung noch vor sich hat, liest besser dort weiter und kommt hierher zurück, sobald etwas nicht wie beschrieben funktioniert.

Alle Angaben beziehen sich auf den Stand RustDesk Server 1.1.16 vom 20. Juli 2026.

1. Kein Client wird jemals online

Symptom: Der Server läuft, TCP-Verbindungen funktionieren, aber es taucht nie ein Client online auf.

Ursache: Port 21116 wurde nur für TCP freigegeben. Über 21116/UDP laufen jedoch ID-Registrierung und Heartbeat. Die Dokumentation hebt diesen Punkt eigens hervor.

Prüfung:

ufw status

Beide Regeln müssen erscheinen, die TCP-Freigabe und die eigenständige UDP-Regel für 21116. Für die TCP-Seite von außen zusätzlich rustdesk-utils doctor <hostname>.

Lösung: Neben der TCP-Freigabe zwingend ufw allow 21116/udp setzen.

2. Der Schlüssel überlebt den Neustart nicht

Symptom: Nach jedem Neustart des Containers sind alle Clients ausgesperrt. Der Schlüssel hat sich geändert, die Datenbank ist leer.

Ursache: Das Volume ist falsch gemappt. id_ed25519, id_ed25519.pub und db.sqlite3 landen im Container statt im Host-Verzeichnis und werden bei jedem Start neu erzeugt. Die FAQ beschreibt genau diesen Fall, inklusive der Beobachtung, dass db.sqlite3 bei jedem Docker-Neustart neu erzeugt wurde.

Prüfung:

ls -l ./data/id_ed25519 ./data/id_ed25519.pub
docker compose restart hbbs
ls -l ./data/id_ed25519 ./data/id_ed25519.pub
docker logs hbbs | grep -i "key"

Die Zeitstempel dürfen sich nicht ändern, und im Log muss Private key comes from id_ed25519 stehen, nicht Private/public key written to.

Lösung: Das Mapping der offiziellen oss.yml verwenden, also ./data:/root beim klassischen Image. Achtung beim Mischen von Anleitungen: Das s6-basierte Image im Repository hat WORKDIR und VOLUME auf /data, nicht auf /root. Wer das Mapping vom falschen Beispiel abschreibt, verliert die Schlüssel. Welches Verzeichnis Ihr Image tatsächlich nutzt, klärt docker exec hbbs pwd.

3. Zwei Serverprozesse gleichzeitig

Symptom: Der Client meldet Key mismatch, obwohl der eingetragene Schlüssel nachweislich stimmt. Der Fehler tritt sporadisch auf, mal ja, mal nein.

Ursache: Es laufen zwei hbbs-Prozesse, typisch einer per Docker und einer per systemd oder aus einer alten Paketinstallation. Die offizielle FAQ dokumentiert dazu mehrere Fälle und weist besonders auf den Wechsel von OSS zu Pro hin. Auch vergessene Testinstanzen in anderen Netzen zählen, einer der dokumentierten Fälle betraf einen im Büro stehen gebliebenen Server neben dem produktiven in der Cloud.

Prüfung: Die FAQ nennt den Befehl wörtlich.

ps aux | grep hbbs

Genau ein Prozess ist zulässig.

Lösung: Alle Instanzen bis auf eine abschalten. Das gilt hostübergreifend, nicht nur auf der Maschine, auf der Sie gerade angemeldet sind.

4. Gefälschte Client-IPs in den Logs

Symptom: IP-basierte Sperren und Rate-Limits greifen nicht, die in den Logs vermerkten Adressen sind unglaubwürdig.

Ursache: Die WebSocket-Ports 21118 und 21119 sind direkt aus dem Internet erreichbar. hbbs und hbbr vertrauen dort den Headern X-Real-IP und X-Forwarded-For ungeprüft. Die Installationsanleitung benennt die Konsequenz ausdrücklich: Wer 21118 oder 21119 direkt erreicht, kann mit gefälschten Headern eine beliebige IP-Adresse vortäuschen, IP-basiertes Rate-Limiting und Blocking umgehen und die protokollierten Adressen verfälschen.

Prüfung: Von einem externen Host rustdesk-utils doctor <hostname> ausführen. Für 21118 und 21119 muss dort ERROR stehen, sofern Sie den Web-Client nicht anbieten.

Lösung: Die Doku ist eindeutig: Nutzen Sie den Web-Client nicht, halten Sie 21118 und 21119 geschlossen. Nutzen Sie ihn, stellen Sie einen Reverse Proxy davor, der X-Real-IP selbst setzt, und begrenzen Sie die beiden Ports per Firewall auf diesen Proxy.

5. Der Server ist von außen erreichbar, aus dem eigenen LAN aber nicht

Symptom: Externe Clients verbinden sich problemlos. Clients im selben LAN kommen über Domain oder öffentliche IP nicht auf den Server.

Ursache: NAT Loopback, auch Hairpin NAT genannt. Der Router kann Pakete nicht aus dem LAN über die eigene WAN-Adresse zurück ins LAN routen. Die Dokumentation formuliert das als harte Voraussetzung: Server und Clients müssen entweder die lokale IP-Adresse benutzen oder eine Firewall haben, die NAT Loopback unterstützt und aktiviert hat.

Prüfung: rustdesk-utils doctor <domain> einmal aus dem LAN und einmal von außen ausführen. Weichen die Ergebnisse ab, ist es NAT Loopback.

Lösung: Die Doku nennt drei Wege und bewertet den ersten als beste Langzeitlösung. NAT Loopback im Router aktivieren, einen lokalen DNS-Eintrag auf die LAN-IP setzen, oder als Notlösung Einträge in der hosts-Datei.

6. Host-Networking greift nicht

Symptom: Verbindungsprobleme im Container-Betrieb, oder in den Logs erscheint als Quelladresse durchgehend 172.17.0.1 statt der echten Client-IP.

Ursache: --net=host beziehungsweise network_mode: host funktioniert laut Doku nur unter Linux. Unter Windows sind sudo und --net=host wegzulassen.

Prüfung: docker logs hbbs ansehen und auf die protokollierte Quell-IP achten.

Lösung: Die Doku sagt es direkt: Entfernen Sie --net=host, wenn Sie auf Ihrer Plattform Verbindungsprobleme haben. Dann müssen Sie die Ports allerdings per -p mappen, einschließlich 21116/udp.

7. Address in use in einer Neustartschleife

Symptom: hbbs startet dauerhaft neu, im Log steht Error: Address in use.

Ursache: Auf demselben Host ist zusätzlich der RustDesk-Client installiert und hat den Direktzugriff auf Port 21118 aktiviert. Die FAQ führt genau diesen Portkonflikt auf.

Prüfung:

ss -tulpn | grep -E '2111[4-9]'

Das zeigt, welcher Prozess den Port hält.

Lösung: Den Client vom Serverhost entfernen oder dessen Direktzugriffsport ändern.

8. Ein zweiter Relay wird nicht akzeptiert

Symptom: Ein zusätzlicher hbbr auf einem zweiten Host wird von den Clients nicht genutzt.

Ursache: Der separate Relay braucht dasselbe Schlüsselpaar wie der hbbs. Die Dokumentation stellt id_ed25519 und id_ed25519.pub als Voraussetzung voran.

Prüfung: docker logs hbbr auf dem zweiten Host. Erwartet werden Private key comes from id_ed25519, eine Key:-Zeile mit demselben Wert wie beim hbbs und Listening on tcp :21117.

Lösung: Beide Dateien per scp in das Volume-Verzeichnis des Relay-Hosts kopieren, dann hbbr mit -k _ starten. Die Doku merkt an, dass ein solcher Relay keine Lizenz benötigt und mit der Open-Source-Version identisch ist.

9. Peers stehen wochenlang fälschlich auf online

Symptom: Geräte werden als online angezeigt, obwohl sie seit Wochen aus sind. Betrifft Server vor 1.1.16.

Ursache: Ein i32-Overflow in der Offline-Berechnung. Die Release-Notes benennen den Bereich präzise: Peers, die 24,9 bis 49,7 Tage offline waren, wurden fälschlich als online gemeldet.

Prüfung: Welchen Stand Ihre Container tatsächlich fahren, klärt der Blick auf das verwendete Image.

docker image inspect rustdesk/rustdesk-server:latest --format '{{.Id}} {{.Created}}'

Lösung: Auf 1.1.16 oder neuer aktualisieren.

docker compose pull
docker compose up -d

Sichern Sie vorher das data-Verzeichnis mit id_ed25519, id_ed25519.pub und db.sqlite3. Ohne diese Sicherung wird aus einem Upgrade der Schlüsselverlust aus Punkt 2.

10. Serverbetrieb unter Windows

Symptom: Instabile Verbindungen oder gar kein Betrieb.

Ursache: Die Dokumentation bewertet die Windows-Sicherheitsrichtlinien als schwierig und schreibt ausdrücklich, dass bei nicht funktionierendem Setup oder instabilen Verbindungen auf einen Linux-Server migriert werden soll. Die GUI-Variante RustDeskServer.setup.exe wird laut Doku nicht mehr gepflegt und ist nicht empfohlen.

Prüfung: pm2 log hbbs und pm2 log hbbr, beide Befehle nennt die Doku als Weg zu den Logs.

Lösung: Für Produktivbetrieb Linux verwenden. Wenn Windows sein muss, NSSM statt PM2 nehmen, weil die Dienste dann ohne Benutzeranmeldung starten.

Was Sie aus dieser Liste mitnehmen sollten

Zwei Themen ziehen sich durch diese Liste: die UDP-Seite von Port 21116 und die Frage, wo das Schlüsselpaar tatsächlich liegt. Ich halte diese beiden für die einzigen, die man beim Aufsetzen zwingend nachweisen muss. Der Rest lässt sich später korrigieren, ein verlorenes Schlüsselpaar dagegen sperrt jeden bereits ausgerollten Client aus und zwingt Sie, an jedem Endgerät erneut Hand anzulegen.

Die zugehörigen Prüfbefehle, die passende Reihenfolge beim Aufsetzen und die Begründung für die Schlüsselpflicht stehen im Hauptbeitrag Eigene Fernwartung mit RustDesk und eigenem Schlüssel.

Sie wollen Fernwartung, bei der die Verbindung nicht über fremde Server läuft? Ich richte einen eigenen Fernwartungs-Server mit eigenem Schlüssel ein, sauber abgeschottet und dokumentiert. Wie ich laufende Betreuung aufsetze, lesen Sie unter IT-Betreuung & Managed IT, das Erstgespräch ist unverbindlich.