Recommended Free Tools
Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
For a self-hosted RustDesk Server used with desktop clients, allow TCP 21115–21117 and UDP 21116 on the RustDesk server. Add TCP 21114 for the RustDesk Server Pro web console/API, and TCP 21118–21119 for WebSocket and web-client support.
These are primarily server-side listening ports. You do not normally forward ports 21114–21119 to every remote computer. RustDesk uses hbbs for ID registration and connection coordination, then attempts a direct peer-to-peer connection before falling back to the hbbr relay.
RustDesk ports at a glance
| Port | Protocol | Service | Purpose | When needed |
|---|---|---|---|---|
| 21114 | TCP | hbbs / Pro web service |
HTTP/API and web-console access | RustDesk Server Pro when not using an HTTPS reverse proxy |
| 21115 | TCP | hbbs |
Core signaling and NAT-related communication | Required for the normal self-hosted desktop-client setup |
| 21116 | TCP | hbbs |
TCP connection establishment and NAT traversal | Required |
| 21116 | UDP | hbbs |
ID registration, heartbeat, and UDP NAT traversal | Required in the documented minimum configuration |
| 21117 | TCP | hbbr |
Relay traffic when direct connectivity fails | Required for reliable fallback and relay connections |
| 21118 | TCP | hbbs |
WebSocket ID-server endpoint | RustDesk Web Client or WebSocket clients |
| 21119 | TCP | hbbr |
WebSocket relay endpoint | RustDesk Web Client or WebSocket relay connections |
RustDesk’s self-hosting documentation identifies TCP 21115–21117 plus UDP 21116 as the minimum server-side set. Its broader standard range is TCP 21114–21119 plus UDP 21116.
Minimum ports for RustDesk Server OSS
For an OSS server used only by standard desktop clients, open:
TCP 21115
TCP 21116
TCP 21117
UDP 21116The narrow UFW equivalent is:
sudo ufw allow 21115:21117/tcp
sudo ufw allow 21116/udp
sudo ufw enableThis is a practical minimum derived from RustDesk’s documented port requirements. RustDesk’s broader installation example opens the complete range:
sudo ufw allow 21114:21119/tcp
sudo ufw allow 21116/udp
sudo ufw enableThe broader rule is convenient when you expect to add Pro, WebSocket, or web-client features. It is not proof that every one of those ports is required for every deployment.
What hbbs and hbbr do
RustDesk Server has two principal components:
hbbs: the ID, rendezvous, or signaling server. It helps clients register, find one another, and coordinate connection establishment.hbbr: the relay server. It carries session traffic when a direct client-to-client connection cannot be established.
The normal connection flow is:
- Each client registers or sends heartbeat traffic to
hbbs. hbbshelps the clients discover one another and attempts NAT traversal.- RustDesk tries to establish a direct peer-to-peer connection.
- If that fails, both clients use
hbbras a relay.
RustDesk does not always relay traffic. A direct connection may work even when the relay configuration is broken, so one successful test does not prove that TCP 21117 is reachable. Conversely, a relay-heavy deployment consumes server bandwidth. RustDesk’s installation documentation gives indicative relay traffic of roughly 30 KB/s to 3 MB/s depending on screen resolution and update settings; office work is described as around 100 KB/s. These figures are guidance, not a guaranteed measurement.
Optional ports: 21114, 21118, and 21119
TCP 21114: Pro web console and API
Port 21114/TCP is generally associated with the RustDesk Server Pro HTTP/API and web-console service. It is not normally part of the minimum OSS desktop-client setup.
Use it when you run Pro and expose that service directly without an HTTPS reverse proxy. When an SSL reverse proxy handles the public entry point, RustDesk documents using TCP 443 for the HTTPS service instead. Avoid exposing an administrative console directly to the public internet when access can be restricted through HTTPS, a VPN, source-IP controls, or a separate management network.
TCP 21118 and 21119: WebSocket services
Ports 21118/TCP and 21119/TCP are WebSocket ports associated with the RustDesk Web Client:
Rank #2
- 21118: WebSocket endpoint on
hbbs. - 21119: WebSocket relay endpoint on
hbbr.
They are not required for a basic desktop-client-only OSS deployment. RustDesk says a reverse proxy is needed to provide HTTPS for these services. In that design, the public firewall may expose only TCP 443, while the proxy forwards traffic internally to the appropriate RustDesk services.
WebSocket mode is version-sensitive. RustDesk’s current advanced-settings documentation says it is available in client 1.4.0 and later and requires RustDesk Server Pro 1.5.7 or later. It supports relay connections only, so it should not be treated as identical to the normal desktop-client transport.
Which ports should you open for each deployment?
| Deployment | Recommended public ports |
|---|---|
| OSS with desktop clients only | TCP 21115–21117 and UDP 21116 |
| OSS using the full documented range | TCP 21114–21119 and UDP 21116 |
| Pro with desktop clients and direct web console | TCP 21114–21117 and UDP 21116 |
| Pro with the Web Client | TCP 21114–21119 and UDP 21116, or an appropriately configured HTTPS reverse proxy |
| HTTPS/WSS reverse-proxy deployment | Public TCP 443; proxy internally routes to the required RustDesk services |
| Separate relay server | TCP 21117; add TCP 21119 when the relay serves WebSocket clients |
The correct list depends on the features you actually use. Opening every documented port does not compensate for incorrect DNS, client settings, NAT, or service configuration.
Do RustDesk clients need inbound ports?
Usually, no fixed inbound forwarding rule is required on every endpoint for an ordinary ID-based deployment. The ports listed above are the listening ports of the self-hosted RustDesk server. Client computers may use dynamically assigned local ports, and RustDesk attempts direct peer-to-peer connectivity using the network paths available to the endpoints.
This does not mean endpoint firewalls are irrelevant. A strict corporate firewall, direct-IP connection, VPN policy, or operating-system firewall can still block a session. However, there is no universal RustDesk rule saying that every client must accept inbound TCP 21115–21117 or UDP 21116.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →If you use RustDesk’s public infrastructure rather than a self-hosted server, do not assume its network behavior is identical to the port-forwarding model described here. Public-server users normally configure the client to use RustDesk’s public services instead of exposing a RustDesk server at home.
Client settings for a self-hosted server
After deploying a self-hosted server, clients generally need the server’s:
- ID Server hostname or public IP address;
- public key generated by the server;
- Relay Server address when it is not automatically inferred or is hosted separately;
- API Server address when using RustDesk Server Pro features.
In current RustDesk client documentation, open:
Settings → Network → Unlock Network Settings
Enter the relevant ID server, relay server, API server, and key values. A private address such as 192.168.x.x works only for clients that can route to that private network. Internet clients need a publicly reachable hostname or address.
Router port forwarding
For a RustDesk server behind a home router, forward the public ports to the server’s private address:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsPublic TCP 21115 → RustDesk server TCP 21115
Public TCP 21116 → RustDesk server TCP 21116
Public TCP 21117 → RustDesk server TCP 21117
Public UDP 21116 → RustDesk server UDP 21116Add TCP 21114, 21118, or 21119 only when your Pro, web-console, or WebSocket design needs them. If using a reverse proxy, the public rule may instead be TCP 443, with internal proxy rules for the backend services.
Router forwarding and the host firewall are separate controls. Opening a port in UFW does not forward it through the router. Use a DHCP reservation or static private address so a server reboot does not silently invalidate the forwarding rule. Also check whether your router supports NAT loopback; internal clients may fail to reach the public hostname even while external clients work.
Cloud firewalls, Docker, and host firewalls
A RustDesk port is usable only when all relevant layers agree:
Rank #4
- Used Book in Good Condition
- The
hbbsorhbbrprocess is listening. - Docker publishes the port if the service is containerized.
- The Linux or Windows host firewall permits it.
- The cloud security group or VPS firewall permits it.
- The router or upstream NAT forwards it to the correct machine, if applicable.
- DNS points clients to the reachable public address.
For Docker deployments, inspect the containers and published ports:
Free tools Windows power users keep installed
One-click scans. No signup required.
docker ps
docker port hbbs
docker port hbbrFor a Linux host, inspect listening sockets:
sudo ss -lntup | grep -E '21114|21115|21116|21117|21118|21119'For UFW:
sudo ufw status numberedExpected listeners vary by OSS, Pro, WebSocket, Docker, and reverse-proxy configuration. A firewall rule alone does not show that the application is bound to the port.
Web client and HTTPS through a reverse proxy
A reverse proxy such as Nginx or Caddy can terminate HTTPS on TCP 443 and forward requests internally to the RustDesk web and WebSocket services. This is useful when you need browser access, WSS, or a single public HTTPS endpoint.
Use a valid certificate and hostname, and ensure the proxy supports WebSocket upgrade requests. A proxy that forwards ordinary HTTP but drops WebSocket upgrades can produce a web client that loads successfully but cannot connect or relay sessions.
RustDesk’s FAQ describes specialized WebSocket-only designs in which only TCP 443 is exposed externally. That is not the default port recommendation for standard desktop clients; it applies only when the client versions, Pro server version, reverse proxy, and relay-only behavior are configured correctly.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Troubleshooting: RustDesk shows “Ready” but cannot connect
Work through the network path in this order:
- Verify the address. Confirm that the client uses the intended ID server, relay server, API server, and public key.
- Check DNS and public addressing. Ensure the hostname resolves to the correct public address. A private LAN address cannot serve internet clients.
- Confirm both services exist. A deployment with only
hbbsmay register clients but cannot provide relay fallback throughhbbr. - Check listeners. Use
ssor Docker port inspection to confirm the expected processes are bound. - Check the host firewall. Confirm both TCP 21116 and UDP 21116; allowing only one protocol can create partial connectivity.
- Check the router or cloud firewall. Verify forwarding, security-group rules, and the destination private IP.
- Test externally. A test from inside the same LAN can be misleading because of NAT loopback or split-DNS behavior.
- Test relay behavior. A direct session can succeed while TCP 21117 is blocked. Test from networks where direct peer-to-peer connectivity is unlikely.
- Review logs. Look for incorrect addresses, key mismatches, failed registrations, relay errors, and WebSocket upgrade failures.
Common explanations for a “Ready” status followed by a failed session include blocked TCP 21117, blocked TCP or UDP 21116, incorrect router forwarding, a cloud security-group rule, an inaccessible advertised address, split DNS, NAT loopback limitations, or a wrong client key.
CGNAT and residential internet connections
Carrier-grade NAT can prevent ordinary inbound forwarding even when the local router is configured correctly. Changing RustDesk’s port numbers does not bypass CGNAT.
If your ISP places the router behind CGNAT, consider a VPS with a public address, a suitable VPN or private-network architecture, or asking the ISP for a public IPv4 address. IPv6 may work where all participating networks support it correctly, but it requires an appropriate IPv6 firewall and addressing design.
Security recommendations
- Expose only the ports required by your selected RustDesk features.
- Do not expose the Pro management console unnecessarily.
- Prefer HTTPS through a properly configured reverse proxy for web-console and WebSocket access.
- Restrict administration by VPN, source IP, identity-aware proxy, or a separate management network.
- Keep the RustDesk server and containers updated.
- Protect and back up the RustDesk server’s private key.
- Monitor relay bandwidth, especially when many sessions cannot connect directly.
- Review both IPv4 and IPv6 firewall policies if both protocols are enabled.
OSS, Pro, VPS, or reverse proxy?
RustDesk Server OSS is suitable when you need basic self-hosted ID and relay services and can manage updates, keys, firewall rules, backups, and troubleshooting yourself.
RustDesk Server Pro is more appropriate when you need centralized administration, identity integration, device management, access controls, or distributed relay features. RustDesk’s pricing page listed the Individual self-hosting plan at $9.90 per month when billed annually as checked on August 18, 2026; verify the live pricing page because plans and prices can change.
A VPS is useful when the main obstacle is CGNAT or unreliable residential inbound connectivity. A reverse proxy is useful for HTTPS, the web console, and WSS, but it adds certificate, routing, and maintenance responsibilities. Neither Pro nor a reverse proxy removes the need for correct DNS, firewall, NAT, and service configuration.
Quick Recap
Safe port-opening checklist
- Desktop-only OSS: TCP 21115, 21116, and 21117; UDP 21116.
- Pro web console without a proxy: add TCP 21114.
- Web Client or WebSockets: add TCP 21118 and 21119, or use a correctly configured HTTPS reverse proxy.
- HTTPS reverse proxy: expose TCP 443 publicly and keep backend ports private where practical.
- Home router: forward each required TCP/UDP protocol separately to a reserved server IP.
- VPS: update both the provider security group and the operating-system firewall.
- Validation: confirm listeners, published Docker ports, DNS, client settings, and external reachability.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
