TheLanc3/rustdesk
1
0
Fork 0
mirror of https://github.com/rustdesk/rustdesk.git synced 2026-07-02 13:25:01 +03:00
Code Issues Packages Projects Releases Wiki Activity

Updated FAQ (markdown)

RustDesk
2026-04-22 10:25:49 +08:00
parent 6891927e78
commit 2082c9cbb4
1 changed files with 27 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
FAQ.md

@@ -597,6 +597,33 @@ NAT Reflection Mode: https://www.reddit.com/r/PFSENSE/comments/fp9h1f/can_someon
> Also make sure your relay server has correct key, https://github.com/rustdesk/rustdesk/issues/7358
# Setup via NAT
> Thanks for the [access logs](https://github.com/rustdesk/rustdesk/wiki/FAQ#access-logs). The logs are consistent with a hairpin NAT / NAT loopback issue.
> https://github.com/rustdesk/rustdesk/wiki/FAQ#deploy-rustdesk-server-in-intranet
>
> Your public-side client is reaching hbbr successfully, but the internal/VPN-side client is timing out when it tries to connect to the relay using the public hostname [rustdesk.freedomfordwi.com:21117](http://rustdesk.freedomfordwi.com:21117/). Because that side never reaches hbbr, the relay session cannot pair.
>
> What the logs show:
> - Relay works when internal/routed addresses are used. hbbr shows successful pairing for internal addresses such as 1.4.x.5 and 1.201.x.2.
>
> - For the failed session 02e684ed-42f7-4646-92a5-89e54a2246f8, hbbr logged only one side of the relay request, from 207.x.x.76.
>
> - On the internal/VPN-side client, RustDesk logged:
> Failed to create relay connection for [1.4.x.5:49597](http://1.4.x.5:49597/) with uuid 02e684ed-42f7-4646-92a5-89e54a2246f8: deadline has elapsed
>
> - That means the internal/VPN-side client could not reach the relay through the public hostname, so the session never paired.
>
> Recommended fixes:
> - Split DNS (recommended): resolve [rustdesk.abc.com](http://rustdesk.abc.com/) to the server’s internal IP for LAN/VPN clients, while external clients continue using the public IP.
>
> - Enable hairpin NAT / NAT reflection on the firewall, if supported.
>
> Since your clients can already reach the server over routed VPN tunnels, prefer the internal route instead of sending LAN/VPN clients out to the public IP and back in again.
>
> If needed, use a separate public relay server, though this is usually unnecessary if split DNS or proper internal routing is configured.
```
# How to insert CTRL-ALT-DEL
<img width="432" height="336" alt="49853fdf-571a-4a5e-ac63-899a7a77c78c" src="https://github.com/user-attachments/assets/36f44ca3-c6b3-4bd1-ac06-8edd9b25d0ce" />