How to use RustDesk over your local network with Direct IP access

RustDesk is a remote-control tool: the person connecting sees the desktop session that is already open and can share its mouse and keyboard. That differs from Windows Remote Desktop Protocol (RDP), which normally starts another Windows session and can lock the console session on a client edition of Windows.

That distinction mattered when replacing a remote-access workflow that behaved like AnyDesk. RDP was technically fast, but it interrupted the local user. RustDesk preserved the right interaction model, then raised a different question: why did a connection using the numeric ID feel slow while both computers were on the same network?

The useful answer is not to assume that every RustDesk ID connection travels through a relay. RustDesk can establish a direct peer-to-peer path, but network address translation, firewall rules, or Wi-Fi policy can prevent that. For devices on the same trusted LAN, RustDesk also exposes an explicit Direct IP access listener. Connecting to that listener avoids the ID lookup path for that session.

This guide configures that local path, verifies it, and separates the network problem from display-quality tuning. In the tested setup, connecting by LAN address and port was noticeably faster than connecting through RustDesk’s numeric ID. That result is evidence for this network, not a universal performance guarantee: an ID connection can already be direct, and another LAN can have different bottlenecks.

Start with the connection model you need

Choose the remote-access protocol according to the session behavior, before optimizing latency.

RDP is appropriate when a separate session is acceptable or desirable, such as an administrative host. It is the wrong default when someone needs to stay logged in at the physical computer, see what the remote person is doing, or resume exactly where they left off.

RustDesk, like other screen-sharing tools, captures and controls the current desktop. That preserves the local session. Its numeric ID is the normal way to find another device, including devices outside the home network. The ID does not by itself prove that video frames are using a public relay; the client may establish a direct connection after negotiation. Still, if the session is not direct, a relay adds another network hop and can become the bottleneck.

Direct IP access has a narrower job: it accepts a RustDesk connection at a LAN address and port. It is useful only when the devices can already route to each other locally. It is not an Internet-access configuration and should not be exposed with router port forwarding.

Enable Direct IP access on the computer being controlled

Configure the listener on every computer that should receive local RustDesk connections. In the RustDesk desktop app, open Settings > Security > Security, unlock the settings if the client asks for it, and enable Direct IP access.

The official RustDesk advanced settings reference documents this option as direct-server. It also documents 21118 as the default Direct IP access port. Keep the default unless another local service is already using it; if you change the port, use the same port in the connection address.

For a home LAN, enable an IP allowlist as well. RustDesk accepts CIDR notation, so a network such as 192.168.1.0/24 can be allowed without listing every device. An allowlist limits who may reach this local listener, but it is not authentication. Keep a strong permanent password or require manual approval according to how the machine is used.

Do not confuse LAN discovery with Direct IP access. Discovery makes peers visible on a LAN. Direct IP access opens a listener that can be reached by an address and port. Discovery can be useful, but the explicit address is the reliable test when diagnosing a slow connection.

Find the remote computer’s LAN address

The address must belong to the network interface the two devices actually share. Do not use a public IP address, and do not copy an address from a VPN adapter unless the connection is intentionally meant to traverse that VPN.

On Windows, run this in PowerShell or Command Prompt and read the IPv4 address under the active Wi-Fi or Ethernet adapter:

ipconfig

On macOS, open System Settings > Network, select the active Wi-Fi or Ethernet service, then open Details > TCP/IP. A typical home address looks like 192.168.1.50, 192.168.0.50, or 10.0.0.50.

An address in the same range is only a hint. 192.168.1.20 and 192.168.1.50 often share a LAN, but guest Wi-Fi, VLANs, and wireless client isolation can deliberately block traffic between them. The Direct IP test will expose that difference.

Connect by address and port instead of the RustDesk ID

On the computer doing the controlling, enter the remote computer’s address in the normal RustDesk connection field using this form:

192.168.1.50:21118

Replace both values with the remote device’s actual LAN IP and configured port. Authentication and permissions still apply. The change is only how RustDesk reaches the controlled device.

Use the numeric RustDesk ID again when away from home. A private LAN address is not normally reachable from another network, and publishing port 21118 through a home router would turn a local troubleshooting feature into an Internet-exposed service. If off-site access becomes frequent, use RustDesk’s normal connection flow, a trusted private network, or a deliberately maintained self-hosted RustDesk setup instead of exposing the Direct IP listener.

Verify that the local path is actually working

A connection that opens is not enough evidence that the intended path was used. Open RustDesk’s connection information or quality monitor during the session and look for a direct connection rather than a relay. The official settings reference exposes Show quality monitor under Settings > Display > Other default options; enable it before testing if it is hidden.

Test the same task twice while both computers are on the LAN: once with the numeric ID and once with IP:port. Compare the reported connection type, latency, frame rate, and input responsiveness. This is more useful than comparing by memory, especially because a numeric-ID connection may already be direct.

In this test, Direct IP access made the session noticeably faster. That makes the route a stronger suspect than screen capture alone in this setup. If the same comparison does not improve a different session, keep the direct connection and inspect capture, encoding, Wi-Fi, or CPU next.

Fix firewall and Wi-Fi barriers before changing codecs

When a direct connection fails, the common mistake is to immediately reduce image quality. That can hide the symptom but cannot make two devices communicate through a blocked local network.

First, make sure the target computer’s operating-system firewall allows RustDesk on a private network. On Windows, verify the RustDesk rule in Windows Defender Firewall and confirm that the network profile is Private, not Public. On macOS, allow incoming RustDesk connections in System Settings > Network > Firewall when macOS prompts for it.

Then inspect the network topology. Guest SSIDs often isolate clients by design. Many routers call the same feature AP isolation, client isolation, or wireless isolation. Separate VLANs can also block east-west traffic even when each device reaches the Internet. A wired desktop and a Wi-Fi laptop can be affected too, depending on the access-point configuration.

Run a simple reachability check from the controlling computer before retesting RustDesk:

Test-NetConnection 192.168.1.50 -Port 21118

On macOS or Linux, use:

nc -vz 192.168.1.50 21118

A successful TCP test does not prove that RustDesk will be smooth, but a failed test narrows the problem to the listener, firewall, IP address, or network policy. Correct that first.

Tune the session only after the route is direct

Once the session is local and direct, video settings can address a separate problem: how much image data the remote device captures, encodes, transfers, decodes, and draws.

Start with RustDesk’s adaptive bitrate and hardware codec enabled. RustDesk documents both options in its client settings: adaptive bitrate adjusts the stream to connection conditions, and hardware encoding can make the picture smoother when the graphics hardware and driver support it. If enabling hardware codec causes artifacts or a blank image, turn it off and test again; a hardware path is not automatically better on every driver.

For ordinary administration, choose balanced image quality rather than maximum quality. Reduce resolution or select one display if a machine drives several high-resolution monitors. Temporarily remove the remote wallpaper when visual effects consume bandwidth or encoding time. These changes trade image detail for lower encode and transfer cost; they do not repair a relay, an isolated Wi-Fi network, or a blocked port.

Ethernet remains the simplest way to reduce variability on a desktop host. If Wi-Fi is required, use the non-guest network and test close enough to the access point to rule out poor signal before blaming RustDesk.

The complete local-access flow

Use this sequence for every machine that should accept direct LAN access:

1. Install RustDesk and configure its incoming access policy.
2. In Settings > Security > Security, enable Direct IP access.
3. Keep port 21118 or record a chosen replacement port.
4. Restrict the listener to the trusted LAN with an IP allowlist when appropriate.
5. Find the remote device's active LAN IPv4 address.
6. Confirm the firewall permits RustDesk on a private network.
7. From the controlling device, test IP:21118 reachability.
8. Connect in RustDesk with IP:port, not the numeric ID.
9. Use the quality monitor to confirm a direct path before changing display settings.
10. Keep the listener private: do not forward its port from the router.

Checklist

• The remote computer is running RustDesk and Direct IP access is enabled.
• The address is the remote device’s active LAN IP, not its public address or an unrelated VPN address.
• The connection uses IP:21118, or the chosen replacement port.
• RustDesk is allowed through the target firewall on private networks.
• Guest Wi-Fi, AP isolation, and VLAN rules are not blocking device-to-device traffic.
• The quality monitor reports a direct session before display settings are tuned.
• The Direct IP port is not forwarded through the Internet router.

The practical lesson is to separate remote-control behavior from transport behavior. RustDesk is the right class of tool when the current desktop session must remain visible. Direct IP access is the right test when the same-LAN route needs to be explicit. If it is still slow after that, the remaining work is performance diagnosis, not another VPN or remote-desktop protocol.