Top 5 Common Mistakes When Setting Up Your First RustDesk Server
Avoid the headaches. We list the most frequent pitfalls new users face when deploying their own remote desktop relay.
Top 5 Common Mistakes When Setting Up Your First RustDesk Server
You’ve decided to take the plunge and self-host. Great! But before you hit “Go,” let’s look at the mistakes that cause 90% of the support tickets in the RustDesk community.
1. The NAT Loopback Issue
Many admins set up their server in the office and try to connect to it using the public IP while still on the office Wi-Fi. Many routers block this. The Fix: Always test your connection from a different network (like your phone’s hot-spot) to make sure it’s reaching the internet.
2. Neglecting UDP on Port 21116
People remember to open TCP ports, but RustDesk loves UDP for performance. 21116 TCP/UDP is the heartbeat of your system. The Fix: Ensure your firewall rules specifically allow UDP traffic on port 21116.
3. Leaving your Key wide open
If you don’t configure your server to require a key, anyone who guesses your server IP can use your bandwidth as their own relay.
The Fix: Run your HBBS with the -k _ parameter to ensure only clients with your public key can connect.
4. Underestimating Latency
“I’ll host my server in Australia because it’s cheaper!” said the technician in Mexico. Bad idea. The Fix: Host your server as close as possible to your clients. 10ms of extra latency feels like 1 second of lag in a remote desktop session.
5. Manual Management of Services
Setting up a server is easy; keeping it running after a reboot is where people fail.
The Fix: Use systemd or docker-compose with restart: always. If you don’t, your server will go down the first time it updates and reboots.
Setting up a server should be a “set it and forget it” experience. By avoiding these five pitfalls, you’ll be well on your way to a professional deployment.