RustDesk Connection Failed: Complete Troubleshooting Guide

Nothing is more frustrating than seeing “Connection Failed” when a client is waiting on the other end. This guide covers every known cause and its fix.

Error 1: “Connection Timeout”

Symptoms: The client spins for 30+ seconds then gives up.

Cause: The ID server (HBBS) is unreachable. This is almost always a firewall or DNS issue.

Fixes:

1. Check your firewall rules. Ensure ports 21115 (TCP), 21116 (TCP+UDP), 21117 (TCP), 21118 (TCP), and 21119 (TCP) are open.
2. Test from outside your network. Use a mobile hotspot to verify the server is accessible from the internet.
3. Verify DNS resolution. If you’re using a domain name, run nslookup your-server.com to ensure it resolves correctly.
4. Check if HBBS is running: sudo systemctl status rustdesk-hbbs or docker ps.

Error 2: “Relay Connection Failed”

Symptoms: You see the remote desktop for a split second, then it drops.

Cause: The relay server (HBBR) is down or unreachable. Direct P2P failed and the fallback relay isn’t responding.

Fixes:

1. Confirm HBBR is running alongside HBBS. They are separate processes.
2. Check port 21117 (TCP). This is the relay port. Many admins forget to open it.
3. Verify the -r flag. When starting HBBS, make sure the -r parameter points to the correct relay IP: hbbs -r your-server-ip:21117.

Error 3: “Wrong Password” on Unattended Access

Symptoms: You enter the permanent password but it’s rejected.

Cause: The password was changed on the remote machine, or the client is connecting to the wrong ID.

Fixes:

1. Re-set the permanent password on the remote machine via RustDesk settings.
2. Verify the ID number. IDs can change if the machine’s hardware identifier changes (e.g., after a motherboard swap).

Error 4: “ID Server Mismatch”

Symptoms: Client connects but shows a different set of machines.

Cause: The client is configured to use a different ID server than expected.

Fixes:

1. Check the client configuration. Go to Settings → Network → ID/Relay Server and verify the IP and key match your server.
2. Re-deploy the configuration using a custom client build with your server details baked in.

Error 5: “NAT Type: Symmetric” (No Direct Connection)

Symptoms: Connections always go through the relay, never P2P. Higher latency and bandwidth usage.

Cause: Your network router uses Symmetric NAT, which blocks UDP hole-punching.

Fixes:

1. Use a VPS with a public IP for your relay. This ensures at least one side of the connection has a direct path.
2. Enable UPnP on the client’s router if possible.
3. Accept the relay route. If both sides are behind Symmetric NAT, relay is the only option—but a well-placed relay makes this transparent.

Prevention: The DeployRD Approach

Most connection issues stem from misconfigured servers. With DeployRD, the firewall rules, relay configuration, and key management are handled automatically during deployment. You focus on supporting your clients—not debugging your infrastructure.

Deploy a Problem-Free Server →