From 5e61faf10acf110765732a088fca057fb531ac40 Mon Sep 17 00:00:00 2001 From: RustDesk <71636191+rustdesk@users.noreply.github.com> Date: Sat, 23 Aug 2025 22:33:51 +0800 Subject: [PATCH] Updated FAQ (markdown) --- FAQ.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/FAQ.md b/FAQ.md index ac5759b..4fb5e82 100644 --- a/FAQ.md +++ b/FAQ.md @@ -429,13 +429,13 @@ Case study: - Case 1 -> A: What happened lately? +> RustDesk: What happened lately? -> B: Nothing, our rustdesk works since 8 months. But this morning it’s doesn’t work, even after restarting the docker. +> User: Nothing, our rustdesk works since 8 months. But this morning it’s doesn’t work, even after restarting the docker. -> A: I believe there is some unawared router/network or firewall change on your side causing the problem. You can check access log (controlled device) to see if there is something different. https://github.com/rustdesk/rustdesk/wiki/FAQ#access-logs +> RustDesk: I believe there is some unawared router/network or firewall change on your side causing the problem. You can check access log (controlled device) to see if there is something different. https://github.com/rustdesk/rustdesk/wiki/FAQ#access-logs -> B: Thanks, you have the true answer. The issue come from our Fortinet Client. +> User: Thanks, you have the true answer. The issue come from our Fortinet Client. - Case 2 @@ -445,11 +445,11 @@ The controlled side works fine with UDP `21116` port, but it can not connect to - Case 3 -> A: I'm having this error when one of my employees tries to connect to a Samsung s20 (pic attached). All devices work fine for me, including the s20 He can connect to the google pixels fine, just no the s20 I have also had this issue as well, but it just goes away. He has always had the issue. +> User: I'm having this error when one of my employees tries to connect to a Samsung s20 (pic attached). All devices work fine for me, including the s20 He can connect to the google pixels fine, just no the s20 I have also had this issue as well, but it just goes away. He has always had the issue. -> B: A possible reason is that UDP is blocked on your devices. Could you try out this advanced option, https://rustdesk.com/docs/en/self-host/client-configuration/advanced-settings/#disable-udp ? with this option on custom client, it will not use UDP any more (only use TCP) +> RustDesk: A possible reason is that UDP is blocked on your devices. Could you try out this advanced option, https://rustdesk.com/docs/en/self-host/client-configuration/advanced-settings/#disable-udp ? with this option on custom client, it will not use UDP any more (only use TCP) -> A: Thank you this worked! Much appreciated. +> User: Thank you this worked! Much appreciated. # Deploy RustDesk server in intranet. @@ -1452,9 +1452,9 @@ The executable (`hbbs`/`hbbr`) is still maintained. We marked it as deprecated o # The RustDesk iOS app has no issue with Cert when connecting outside of local network. The issue is only when connecting on local network. > User: Found the issue, it was due to having only deployed the cert and not the full chain. -> + > RustDesk: Intersting, why does "not the full chain" cause "outside of local network" works, but local network not? -> + > User: My best guess is that the reason this worked is because we have an IIS reverse proxy in between the Internet and our Internal Linux server running Rust Desk. The reverse proxy was able verify the cert to create a secure connection between reverse proxy and the Linux server but when the iOS app was connecting directly to the Linux server on the local network if could not verify the cert. The odd part is the Desktop App, Self Hosted Web preview, and the iOS web browser all had no issue without the full chain and worked fine with just the cert. image @@ -1470,7 +1470,7 @@ Please right click on the tab, you will see it as below > RustDesk: I noticed in the previous logs that when the connection failed, the relay server was “REDACTED.WEBSITE.TO.RUSTDESK.SERVER2.com:21114.” Usually, the relay port is 21117. When I set my client's relay server to host:21114, > I replicated the "bytes remaining on stream" error. > Therefore, the cause of the error was the incorrect setting of the relay port to 21114. -> + > User: I don’t remember where I ever saw the relay being 21114, but that might have been something I set for testing and forgot to remove at any stage beyond that. > Hopefully my mishap will help others with similar issues in the future, in case it happens again.