RustDesk Not Connecting: Check ID, Relay, and Direct

RustDesk not connecting can reflect different failures; first identify the server deployment and the last successful connection stage. An ID appearing on screen does not establish that the remote computer is available, access is authorized, or a relay can carry the session. Keep those questions separate before changing the network path.

Key Takeaways:

• Confirm whether both clients use the intended public or self-hosted service.
• Separate ID discovery, owner approval, direct connection, and relay transport.
• Preserve server settings and keys while comparing an approved route.
• A successful test needs the correct desktop and an explainable connection mode.

This diagnostic guide follows the cited RustDesk client and self-hosting documentation; it has not undergone a complete end-to-end test. Record both clients’ versions and operating systems. Menu labels and available connection details may differ, so retain an unknown mode when your version does not expose it clearly.

Where does RustDesk not connecting occur?

RustDesk's client documentation describes a readiness message, a local ID, and fields for connecting to another computer. Its network settings can specify server and proxy configuration. These are different observations: a populated ID field is not equivalent to a working connection to the intended remote endpoint.［1］

Last observation	Investigate next	Keep separate
Client not ready or ID unavailable	Intended deployment and ID service access	Remote owner's session permission
ID known but destination unavailable	Remote client and correct service configuration	Whether your own ID exists
Owner receives request but refuses	Identity and allowed task	Network-path repair
Direct connection fails, relay works	Actual mode and direct-path limitations	Relay failure
ID stage works but relay attempt fails	Same configured public relay and its availability	A requirement to replace server keys
Desktop opens but action is restricted	Session or operating system permission	Transport establishment

Use the general device troubleshooting flow when several applications fail. This article concentrates on RustDesk's connection stages and existing deployment; it is not a guide to building or exposing a remote desktop server.

Step 1: Which server deployment should both clients use?

Ask the deployment owner whether the clients should use public infrastructure or an organization-managed server. Verify that answer against the intended configuration on both devices. Two people can exchange a valid-looking ID while their clients are configured for different service environments.

1. Record client versions and operating systems on the access and remote computers.
2. Identify the approved ID and relay service arrangement, without publishing private server addresses.
3. Check whether an organization-supplied configuration or managed build must remain in place.
4. Record the local readiness state before entering the remote ID.

The official client instructions distinguish ID, relay, optional Pro API, and key settings. Do not treat an API login failure as proof that the ID or relay service failed. Likewise, do not paste a new configuration string or replace a key copied from a forum into an existing deployment.［1］

For self-hosted infrastructure, the administrator owns server configuration and the key expected by the clients. If a client reports a configuration or key mismatch, send that evidence to the owner before attempting a network comparison. A different public exit does not establish the trust of a different service.

Keep installation and server migration out of this repair. Save local work before any restart and ensure a trusted person can recover the remote computer if its client is restarted. A host nobody can access locally is a poor candidate for speculative configuration changes.

Step 2: Does the RustDesk ID server connection match the target?

Verify the remote device's ID through a trusted channel with its owner. Do not accept an unsolicited support request, ask for a permanent password, or change the access method to avoid an owner's rejection. The objective is an agreed session with a known computer.

Check the remote client's power, network, running state, and intended deployment separately from your local readiness. A sleeping remote computer can be unavailable even though your own client has an ID. If the owner cannot confirm availability, stop at that uncertainty instead of interpreting every failed request as a relay defect.

RustDesk's self-host documentation distinguishes hbbs, the ID and rendezvous service, from hbbr, the relay service. Clients contact the ID service to locate the destination and attempt to establish a path. Keep a successful discovery observation distinct from successful transport of the desktop session.［2］

Record the exact message after a single approved attempt. Note whether it appears before contacting the destination, after a request reaches the owner, or while starting the desktop. Redact IDs, passwords, configuration strings, and private addresses from screenshots shared publicly.

If both clients are intended to use the same deployment but their approved settings disagree, let the administrator reconcile them. Do not "fix" that mismatch by moving one endpoint to an unrelated public server. That changes the deployment, introduces a new trust relationship, and makes the comparison answer a different question.

Step 3: Is this a direct path or a RustDesk relay connection?

The official architecture describes an attempt to connect peers directly through hole punching, followed by relay use when the direct attempt fails. A failed direct path therefore does not automatically mean the entire session is impossible. Conversely, a successful ID lookup does not prove that the required relay is reachable.［2］

Use the client's available connection information to record the actual mode for a session that opens. If your version does not make the mode clear, record it as unknown and consult the deployment owner or official documentation. Do not infer a direct connection from low latency or a relay from a slow screen update.

A VPN can change routing and the conditions seen by NAT traversal. That is a reason to measure the outcome, not to promise more reliable direct access. If the same authorized session succeeds through a relay after a direct failure, preserve that distinction instead of claiming you repaired hole punching.

For a self-hosted service, send a transport-specific failure to the administrator with its stage and time. The official server documentation lists different roles for the ID and relay services and different deployment options. Those requirements belong to the actual server arrangement, not a blanket instruction for users to open every inbound port on their home routers.［2］

Inspect an existing approved proxy configuration if it is relevant; the Windows proxy scope explanation helps distinguish system settings from application behavior. Do not clear a managed proxy, disable TLS validation, or alter server keys to make a path comparison look successful.

When the person at the other end uses an Android phone and needs help, the attended Android support guide covers separate viewing and input permissions and ending the session.

Step 4: Compare access to the same approved public relay

Use this branch only when the deployment and authorization are established, the remote client is available, and evidence points to access to an already approved public relay. A relay reachable only through an organization's private network requires that organization's existing access method. A consumer VPN is not an entrance to it.

On a supported Windows access computer, AethoVPN provides an alternate outbound route for the existing relay attempt. Install the official Windows package, use Pro or Premium for desktop access, choose one nearby available position, and enable global mode. Leave the ID service, relay address, server key, destination ID, and remote endpoint unchanged; record whether the eventual session is direct or relayed.

1. On the original permitted route, make one attempt and record the last successful stage.
2. Connect the chosen position and follow the VPN route verification steps.
3. If comparing public addresses, use the exit-IP lookup, then repeat the original RustDesk attempt.
4. Ask the owner whether the request arrives and whether the agreed desktop task works.
5. Record the connection mode when available; disconnect and restore the original approved route if the test adds no useful evidence.

This method does not supply remote consent, guarantee NAT hole punching, fix a server-key mismatch, or change the organization's deployment. If your unresolved task is this permitted public-relay comparison, use an email account to start the 3-day free Pro trial, available once per user and starting at registration.

If using macOS for the access-side comparison, obtain configuration from the official setup guide and use a VPN client with Pro or Premium. Linux product support is limited to the Debian/Ubuntu x64 .deb package.

A working alternate route supports a limited conclusion: this session behaved differently with the access computer's outbound path. If the mode also changed, include that in the result. You cannot attribute improvement solely to relay reachability when the successful attempt actually used a different transport mode.

Step 5: Verify the authorized session and explain its mode

Confirm the expected remote desktop with the owner and perform only the agreed low-impact action. If the session opens but a task is restricted, inspect the appropriate client or operating system permission. Do not change credentials or grant persistent unattended access merely to complete the experiment.

Write the result as a short sequence: local readiness, verified destination, owner response, desktop visibility, permitted action, actual connection mode.

The AnyDesk connection-stage guide illustrates why consent is separate from service access. Its port and local discovery requirements are not RustDesk requirements, so use the comparison for reasoning only, not as a configuration recipe.

When finished, close the session normally and ask the owner to confirm that work can continue. Restore any temporary, approved local network change. Leave the established server configuration in place and retain the private diagnostic record in case the same stage fails later.

If both approved routes fail at the same stage, escalate with versions, time zone, deployment type, error excerpt, and observed mode or its uncertainty. Do not post keys, passwords, full configuration files, private relay addresses, or remote desktop captures to a public issue.

Summary

• Establish the intended deployment before changing access settings.
• Verify the ID and remote owner's availability through a trusted channel.
• Separate discovery, direct connection, relay transport, and permissions.
• Compare only an already approved public service path.
• Confirm the agreed desktop task and record the actual connection mode.

FAQ

Does having a RustDesk ID prove that my remote computer is reachable?

No. The local ID is only one observation. Verify the destination, its owner-confirmed availability, and the intended deployment before using a failed request to diagnose a relay or remote host problem.

Can clients on different server deployments use the same ID normally?

Do not assume that they can locate the intended device. Confirm the approved configuration on both endpoints with the deployment owner. Moving one client to another server is a migration, not a controlled network test.

Does a direct connection failure always prevent remote access?

No. The documented architecture can use a relay when the direct attempt fails. Record what actually happened and distinguish a working relay session from successful NAT hole punching.［2］

Should I replace the server key when the connection times out?

Not as a speculative repair. A timeout and a key mismatch are different observations. The server owner should confirm the trusted configuration; changing it during a route comparison invalidates the test and can introduce a trust problem.

Why can a VPN comparison change the connection mode?

Routing and NAT conditions can differ after a path change. Record direct or relay mode when available, and do not claim the VPN improved hole punching or relay access without observations supporting that specific conclusion.

What proves that the RustDesk problem has recovered?

The known owner approves access, the intended desktop appears, and the permitted task works. Also record the actual mode or explain why it is unknown; a populated ID field alone does not establish recovery.

When should a deployment administrator take over?

Escalate a key or server mismatch, private-network requirement, policy restriction, unavailable remote endpoint, or repeat failure across controlled approved routes. Provide a redacted stage record rather than changing shared infrastructure yourself.

Sources:

1. RustDesk Client — https://rustdesk.com/docs/en/client/
2. Self-host — https://rustdesk.com/docs/en/self-host/

Sources checked 7 October 2026.

---

Related Articles:

• Map RustDesk stages against AnyDesk
• Confirm the tunnel before checking the relay
• Check the Windows proxy on both RustDesk peers