Relay server not used despite ALWAYS_USE_RELAY=Y, and clients cannot connect when UDP port 21116 is blocked #677
Description
Activity
- changed the title
[-]Bug Report: Relay server not used despite ALWAYS_USE_RELAY=Y, and clients cannot connect when UDP port 21116 is blocked[/-][+]Relay server not used despite ALWAYS_USE_RELAY=Y, and clients cannot connect when UDP port 21116 is blocked[/+]on Jul 9, 2026 Same Issue on 1.1.16
Reacted by durzy and QianziTechI can confirm the same issue here. There is a working workaround, described below.
Environment:
RustDesk client macOS: 1.4.9
RustDesk client Windows: 1.4.9
RustDesk Server OSS: 1.1.16
Self-hosted hbbs + hbbr using Docker with network_mode: host
Both clients are on the same LAN behind the same public NATDirect LAN connection to the Windows host works correctly via :21118.
A normal connection using the RustDesk ID fails with:Failed to connect via rendezvous server: Please try laterThe server itself appears to be working correctly:
hbbs is reachable on TCP/UDP 21116
hbbr is reachable and listening on TCP 21117
Setting ALWAYS_USE_RELAY=Y on the server does not help
Explicitly configuring the relay server as :21117 on both clients does not help
Enabling Always connect via relay server on the macOS client does not helpDuring the failed connection, tcpdump shows traffic only to hbbs:21116. hbbs still sends UDP packets to the other client's public NAT mapping, but there is no connection attempt to hbbr:21117.
I also captured traffic for the working /r workaround.
With a normal ID connection, there is no TCP connection to hbbr:21117 at all.
When connecting using [ID]/r, both peers immediately establish TCP connections to the relay server on port 21117, and normal bidirectional traffic starts.Example from the working capture:
client A -> server:21117 SYN server:21117 -> client A SYN/ACK client B -> server:21117 SYN server:21117 -> client B SYN/ACK ...bidirectional TCP payload through 21117...This confirms that the relay server itself is working correctly.
The issue appears to be that RustDesk 1.4.9 does not actually force the relay path when using ALWAYS_USE_RELAY=Y or the client-side Always connect via relay server option.
Workaround:
Connecting using: [ID]/r
works immediately and correctly uses the relay server.So /r successfully forces the relay connection, while ALWAYS_USE_RELAY=Y and the client-side relay option do not appear to do so with RustDesk 1.4.9.
This looks like the same issue described here and is consistently reproducible in my setup.
I can also provide tcpdump output from both the failing normal-ID connection and the working /r connection if useful.I did some further testing and found something that may help narrow this issue down.
My setup is RustDesk Server OSS with hbbs and hbbr running on the same Debian server.
I have:ALWAYS_USE_RELAY=Y
hbbs confirms this at startup:
relay-servers=[]
ALWAYS_USE_RELAY=Yhbbr is listening on the standard TCP port 21117.
Initially, both RustDesk clients were configured to use the public IP address of my RustDesk server as the ID/relay server.
When both clients were on the same LAN, I could connect successfully between them, but nothing appeared in the hbbr relay log. This made it appear that ALWAYS_USE_RELAY=Y was being ignored and that the clients were establishing a direct LAN connection.
I then changed the ID/relay server configuration on both clients from the public IP to the RustDesk server's local LAN IP address.
After doing this, without changing ALWAYS_USE_RELAY=Y, the LAN-to-LAN connection immediately started going through hbbr and was recorded in relayserver.log.So in my case:
Both clients on LAN + public server IP
→ connection succeeds
→ no hbbr relay eventBoth clients on LAN + local server IP
→ connection succeeds
→ hbbr relay event is recordedInternet client → LAN client + public server IP
→ connection succeeds
→ hbbr relay event is recordedThis makes me wonder whether at least some of the reported ALWAYS_USE_RELAY behaviour is related to NAT loopback/hairpin NAT or how RustDesk handles a public ID/relay server address when both peers are behind the same NAT.
A potentially cleaner workaround than configuring individual LAN clients with the server's local IP would be to use split DNS/internal DNS.
The RustDesk clients could continue using the same hostname for their ID/relay server everywhere, but the internal DNS server would resolve that hostname to the RustDesk server's local IP address for clients on the LAN. Public DNS would continue resolving the same hostname to the server's public IP address for Internet clients.For example:
rustdesk.example.comInternal DNS → 192.168.1.x
Public DNS → public WAN IPThis would mean the RustDesk client configuration wouldn't need to change depending on whether the client is inside or outside the network, while also avoiding reliance on NAT loopback/hairpin NAT for local clients.
It may be useful for others experiencing this issue to test whether using an internal DNS override for the RustDesk server hostname causes LAN-to-LAN sessions to correctly pass through hbbr.
In my case, simply changing both LAN clients from the server's public IP to its local IP caused ALWAYS_USE_RELAY=Y to work as expected. This suggests that the public-vs-local network path is an important factor, rather than ALWAYS_USE_RELAY simply not functioning.
Environment
Server configuration
hbbs is started with a dedicated relay server:
/opt/rustdesk/hbbs -r rd.example.com:21117 -k <PUBLIC_KEY>
The following environment variable is configured:
ALWAYS_USE_RELAY=Y
The hbbs startup log confirms both settings:
relay-servers=["rd.example.com:21117"]
ALWAYS_USE_RELAY=Y
hbbr is running and listening correctly on TCP port 21117:
Listening on tcp :21117
Listening on websocket :21119
Start
TCP connectivity to the relay server has also been verified successfully:
Connection to rd.example.com port 21117 [tcp/*] succeeded!
Problem 1: Relay server is not used
Despite ALWAYS_USE_RELAY=Y being enabled and hbbs correctly advertising rd.example.com:21117 as the relay server, client traffic does not appear on TCP port 21117.
Packet captures show that clients communicate with hbbs on port 21116 using both UDP and TCP, but no external client traffic reaches hbbr on TCP port 21117.
Example:
Client -> Server:21116 UDP
Client -> Server:21116 TCP
However, there is no corresponding external connection:
Client -> Server:21117 TCP
The only traffic observed on port 21117 in some captures is local loopback traffic such as:
::1: -> ::1:21117 UDP
::1:21117 -> ::1: UDP
The relay server log also shows no actual client relay sessions. It only contains startup information.
This suggests that hbbs correctly recognizes the configured relay server but clients are never redirected to or connected through hbbr.
Problem 2: Blocking UDP 21116 makes the client unusable
Another important observation is that the RustDesk client cannot establish a connection when UDP port 21116 is blocked on the server.
This happens even though:
When UDP 21116 is disabled, the client fails to connect entirely instead of falling back to TCP and/or the configured relay server.
When UDP 21116 is enabled again, the client can communicate with the ID server, but the connection still does not use hbbr on TCP 21117.
Expected behavior
With:
ALWAYS_USE_RELAY=Y
and:
relay-servers=["rd.example.com:21117"]
I would expect the following behavior:
Actual behavior
The actual behavior is:
Additional observations
The following ports are listening correctly:
UDP 21116 -> hbbs
TCP 21115 -> hbbs
TCP 21116 -> hbbs
TCP 21117 -> hbbr
TCP 21118 -> hbbs WebSocket
TCP 21119 -> hbbr WebSocket
The public DNS record resolves correctly to the server’s IPv4 address, and there is no AAAA record.
The server has also been completely reinstalled, but the behavior remains unchanged.
This appears reproducible and does not seem to be caused by DNS resolution, basic firewall reachability, or the hbbr process not listening.