Relay server not used despite ALWAYS_USE_RELAY=Y, and clients cannot connect when UDP port 21116 is blocked

[layer6org]

Environment

• RustDesk client version: 1.4.9 or 1.4.8 tested
• RustDesk server: OSS
• hbbs version: 1.1.15
• hbbr version: 1.1.15
• Server OS: Debian Linux
• Public server hostname: rd.example.com
• Public IPv4 address: any
• IPv6: disabled
• hbbs and hbbr are running on the same server.

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:

• TCP port 21116 remains open.
• TCP port 21117 for hbbr remains open.
• ALWAYS_USE_RELAY=Y is configured.
• hbbs correctly advertises the relay server.
• Direct TCP connectivity to port 21117 has been verified.

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:

1. The client registers with hbbs.
2. hbbs instructs the client to use hbbr.
3. The actual remote desktop session is established through TCP port 21117.
4. External client traffic becomes visible on port 21117.
5. If UDP 21116 is unavailable, the client should still be able to communicate using TCP and establish the remote session through the relay server.

Actual behavior

The actual behavior is:

1. Clients communicate with hbbs on port 21116.
2. UDP 21116 appears to be mandatory for successful client connectivity.
3. Blocking UDP 21116 causes the client to become disconnected.
4. No external client traffic reaches hbbr on TCP 21117.
5. The relay server does not appear to handle any remote desktop sessions despite ALWAYS_USE_RELAY=Y.

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.