小镇青年的文档中心

Appearance

自建 RustDesk 服务器（基本步骤） ​

一、环境和目标效果 ​

  • 设备列表
    • Android平板（控制端）
    • Windows电脑（被控制端）
    • Ubuntu云服务器（中转服务器）
  • 目标效果：使用自己的云服务器搭建一个私有远程控制枢纽，Android通过它找到Windows并实现远程控制（当然只要知道了目标客户端的ID，就可以进行控制，下面的搭建过程则是以Android控制Windows场景为例），数据协调和中继都走自己的云服务器，而不再依赖官方服务器

二、搭建过程 ​

  1. 第一步：云服务器（中转服务器）上安装RustDesk服务端

    • 说明：RustDesk服务端包含两个核心组件

      组件作用默认端口
      hbbsID注册服务器，负责设备注册和连接协商TCP：21115、21116、21118
      UDP：21116
      hbbr中继转发服务器，当P2P直连失败时负责转发流量TCP：21117

    • 安装方式一：通过 Docker 安装（推荐）

      1. 检查/安装 Docker

        ubuntu安装docker

      2. 下载 RustDesk 服务端编排文件并启动

        shell
        # 创建并进入专用目录，便于后续管理
sudo mkdir -p /opt/rustdesk && cd /opt/rustdesk
# 下载官方提供的 OSS（开源版）Docker Compose 配置文件
sudo wget rustdesk.com/oss.yml -O compose.yml
# 以后台模式启动 hbbs 和 hbbr 两个容器
sudo docker compose up -d

        image-20260930154826300

    • 安装方式二：原生安装

      shell
      # 该脚本会自动下载 hbbs 和 hbbr，并创建 systemd 服务实现开机自启
sudo wget https://raw.githubusercontent.com/techahold/rustdeskinstall/master/install.sh
sudo chmod +x install.sh
./install.sh

  2. 第二步：获取hbbs首次运行时自动生成的公钥（这个公钥是客户端之间建立加密连接所必需的）

    • 如果是通过 Docker 安装

      shell
      cat /opt/rustdesk/data/id_ed25519.pub

    • 如果是通过 原生 安装

      shell
      cat /var/lib/rustdesk-server/id_ed25519.pub
# 或
cat /opt/rustdesk/id_ed25519.pub

    • 上述命令效果：终端会输出一串 Base64 编码的字符串，如下，下面内容中的 vN3xKq8mZ2pL9wR5tY7uI1oP4aS6dF8gH0jK2lM= 就是生成的公钥，找个地方保存一下（注意：公钥文件在 hbbs 首次启动后才会生成，可能需要等待，如果文件不存在，稍等片刻后再重试）

      tex
      zhanghl@VM-24-16-ubuntu:/opt/rustdesk$ cat /opt/rustdesk/data/id_ed25519.pub
vN3xKq8mZ2pL9wR5tY7uI1oP4aS6dF8gH0jK2lM=zhanghl@VM-24-16-ubuntu:/opt/rustdesk$

  3. 第三步：配置云服务器安全组放行端口

    • 目标：允许外部流量通过 RustDesk 所需端口访问服务器

    • 添加的安全组规则

      协议授权对象端口说明
      TCP全部IPv4地址（0.0.0.0/0）21115NAT类型测试
      TCP全部IPv4地址（0.0.0.0/0）21116信令/连接服务
      UDP全部IPv4地址（0.0.0.0/0）21116必须同时放行 UDP
      TCP全部IPv4地址（0.0.0.0/0）21117中继转发服务

  4. 第四步：配置客户端（Android 和 Windows）

    • 目标：让 Android手机 和 Windows电脑 通过云服务器进行连接

    • 操作步骤（两端操作完全一致）

      1. 在 Android 和 Windows 上分别下载 RustDesk 客户端（官网下载地址 或 Github release 地址），下载最新版即可

      2. 这里要单独说一下，Windows 上下载.exe文件并双击打开后，并不意味着可以使用所有的功能了，需要点击左下角的安装按钮进行实际的安装，否则后续解锁网络设置等等功能都无法使用！！！

        image-20260930160952693

      3. 解锁网络设置：点击主界面 ID 旁边的菜单按钮 ⋮ → 选择 网络

        image-20260930161218242

        image-20260930161228550

      4. 解锁网络设置后，点击 ID/中继服务器 选项，填入下面两项内容（中继服务器 和 API服务器 两个字段可以留空，RustDesk 会自动推导），确认后，在首页底部状态栏会显示 “就绪” 或类似绿点标识。如果显示 “未就绪”，请检查公钥是否正确、安全组端口是否放行

        image-20260930161500923

        image-20260930161739273

        image-20260930162519683

      5. Windows电脑设置一个固定的连接密码：点击主界面 ID 旁边的菜单按钮 ⋮ → 选择 安全 → 解锁安全设置 → 切换使用固定密码并设置

        image-20260930162247061

      6. 测试连接：Android端输入远程Windows端的ID，并输入密码，就可以连接上了

        image-20260930162640745

三、使用建议：网络波动时，控制端勾选 ”强制走中继连接“ ​

  • 背景知识

    • 自建中继服务器的作用：“兜底” 和 “替代官方中继服务器”

    • RustDesk 默认的连接策略： P2P直连优先，中继服务器兜底

      维度P2P 直连中继
      理想条件下网络延迟最低（双方直连 RTT）稍高（控制端和被控制双方到中继 RTT 之和）
      网络波动时的连接稳定性差，容易卡顿/断连好，TCP 保障
      带宽消耗零服务器带宽全部画面数据经过服务器
      对服务器依赖无中继服务器不可用时完全无法连接
      画质上限取决于两端宽带取决于中继服务器上行带宽

    • 控制端与被控制端连接过程解释：RustDesk控制端默认是不勾选 强制走中继 这个选项的，所以控制端和被控制端在建立连接的时候默认是 P2P（因为 P2P 在理想条件下确实是更优的，服务器带宽消耗为0、服务器负载为0、双方直连延迟更低），但是架不住有时候网络波动不稳定，导致 P2P 连接不稳定，会陷入 “卡顿 → 连接中断 → 自动重连” 的循环（我在雨天尝试远控的时候就出现了这种情况，在勾选了 强制走中继连接 选项后，问题得到了解决）

      deepseek_mermaid_20261019_e763a2

      image-20261019162901006

    • 基于上面的背景知识，对 P2P 和 中继服务器 的选择场景参考如下：

      场景P2P 表现中继表现谁更好
      双方网络稳定、延迟低极佳稍差（多一跳）P2P
      一方或双方网络波动大、丢包严重卡顿、花屏、频繁重连稳定，TCP 自动重传中继
      对称 NAT / 防火墙封 UDP打洞失败，无法连接正常连接中继（唯一选择）
      移动网络（4G/5G）下使用基站切换导致断连相对稳定中继
      追求最低延迟（如游戏、高频操作）更低稍高P2P
      隐私要求高，不希望数据经过第三方不经过服务器经过自建服务器（可控）看需求

自建 RustDesk 服务器（更安全的做法） ​

一、适用前提与加固目标 ​

本节接续前面的“基本步骤”：Ubuntu 云服务器已经运行 OSS（开源版）的 hbbs、hbbr，Android 与 Windows 已能连接。下面继续使用这套服务，在现有配置上补充密钥校验、端口限制和客户端访问控制。

以下命令以 Docker 安装方式为例，沿用 /opt/rustdesk/compose.yml、./data:/root 数据挂载和 network_mode: "host"。若前文选择了原生安装，应使用原服务的数据目录和启动配置，不能直接照抄 Compose 命令。

先明确三个不同的安全环节：

项目作用
服务端公钥 id_ed25519.pub供客户端校验服务端签名、建立可信的加密连接；也用于下文的 Key 匹配校验
被控制端的连接密码或人工确认决定是否允许访问这台 Windows 电脑；知道设备 ID 并不等于获得控制权限
安全组、防火墙或私有网络限制哪些网络来源能够访问 hbbs、hbbr

**公钥不是保密的访问口令，-k _ 也不是设备白名单。**持有正确公钥的其他人仍可能使用服务端，因此不能把“自建 + 填写 Key”理解成“只有自己的设备才能使用”。

二、备份现有配置和密钥 ​

在没有远程会话的维护时间执行以下命令。备份时短暂停止两个服务，避免直接复制正在写入的数据库：

bash
cd /opt/rustdesk
sudo install -d -m 700 /opt/rustdesk-backups
sudo docker compose stop hbbs hbbr &&
sudo tar -czf "/opt/rustdesk-backups/rustdesk-$(date +%Y%m%d-%H%M%S).tar.gz" -C /opt rustdesk
sudo docker compose start hbbs hbbr

确认备份成功、服务恢复后再继续。备份中包含 compose.yml 和 data，应限制备份文件的访问权限。

  • data/id_ed25519 是私钥，保留在服务端，不发送给客户端、不上传公开仓库；文件权限应只授予实际运行服务的用户及必要的管理员。
  • data/id_ed25519.pub 是公钥，客户端填写的是它的完整内容。
  • 沿用现有数据挂载和密钥，避免误用空目录导致生成新的密钥。更换密钥后，客户端原来的 Key 将不再匹配。

三、让 hbbs 和 hbbr 都校验 Key ​

先查看实际运行的版本：

bash
cd /opt/rustdesk
sudo docker compose exec hbbs hbbs --version
sudo docker compose exec hbbr hbbr --version

以 OSS 1.1.16 源码为例，hbbs 的 Key 参数默认使用已有密钥；hbbr 在没有指定 -k 或 KEY 环境变量时，默认不进行同样的 Key 匹配校验。因此不能因为客户端已经填写公钥，就认为两个服务都限制了未携带正确 Key 的连接请求。参见 hbbs 启动参数、hbbr 启动参数。

编辑现有的 /opt/rustdesk/compose.yml，为两个服务的启动命令明确添加 -k _：

yaml
# 仅展示需要修改的 command 字段，不是完整的 compose.yml
services:
  hbbs:
    command: hbbs -k _
  hbbr:
    command: hbbr -k _

**只修改对应的启动参数，保留原有 image、volumes、network_mode 等配置。**如果 hbbs 原来已经带有 -r 等参数，应保留它们再补充 -k _；如果已有 -k，应调整原参数，避免重复添加。

这里的 _ 是程序约定的特殊值：从工作目录中的现有私钥取得对应公钥，用于检查客户端请求。前文的两个容器都挂载 ./data:/root，应继续共享同一套密钥。不能把 _ 填进客户端的“密钥”字段。具体行为参见 hbbr Key 校验与密钥读取源码。

检查配置，只有检查成功才应用：

bash
cd /opt/rustdesk
sudo docker compose config -q && sudo docker compose up -d hbbs hbbr
sudo docker compose ps
sudo docker compose logs --tail=50 hbbs hbbr

修改 Compose 的启动参数后应执行 up -d，仅执行 restart 不会应用新的容器配置。确认两个服务正常运行，且使用原来的公钥。原生安装则需要在已有 systemd 服务的启动命令中做相同调整，保留原工作目录；修改服务配置后执行 daemon-reload 并重启对应服务。

四、收紧云服务器的公网访问 ​

对于本文的 Android、Windows 原生客户端，继续保留前文已经使用的端口：

协议端口用途
TCP21115NAT 类型测试
TCP21116连接协商与 TCP 打洞
UDP21116ID 注册与心跳
TCP21117hbbr 中继转发

**不能为了“只开放 443”而关闭这些原生端口，尤其不能关闭 UDP 21116。**本场景无需开放 Pro Web 控制台使用的 TCP 21114，也无需开放 Web 客户端使用的 TCP 21118、21119；若之前额外放行过，应移除这些不需要的公网规则。端口用途见官方 OSS Docker 文档。

按实际网络条件调整前文的 0.0.0.0/0 规则：

  • 两端都有固定公网出口 IP：将上述四项规则的来源限制为 Android 和 Windows 所在网络的出口 IP（单个 IPv4 地址使用 /32）。不能只放行控制端，被控制端同样需要注册和连接中继。
  • Android 经常切换 Wi-Fi、移动网络，或家庭公网 IP 会变化：不要把当前临时 IP 当成长期白名单，否则换网后会无法连接。需要随时从这些网络接入时，可以保留必要端口的公网访问，并依靠 Key 校验和被控端认证；这仍属于公网服务。
  • 要求只有自己的设备能够访问服务端：需另行建立有设备认证的 VPN / 私有网络，确认两端通过该网络完成注册和中继后，再关闭原生端口的公网入口。单靠域名或公钥不能实现这一要求。

新增窄范围规则后，还应检查所有关联安全组中是否仍存在 0.0.0.0/0 的同端口或全端口放行规则；这些宽范围规则会使来源限制失效。服务器启用公网 IPv6 时，也要检查 ::/0 等 IPv6 规则。SSH 和其他业务端口按原用途单独保留。

前文官方 Compose 使用主机网络，服务直接在宿主机监听，应同时检查云安全组及现有主机防火墙。若自行改成 Docker 桥接网络并发布端口，不能仅凭 ufw status 判断访问已受限，Docker 发布的流量可能绕过 UFW 的常规规则。参见 Docker 防火墙说明。

五、复核客户端与被控端权限 ​

Android 和 Windows 的“ID/中继服务器”继续采用 OSS 原生连接配置：

字段 / 选项设置
ID 服务器原来的云服务器公网 IP，或直接解析到该 IP 的域名；默认端口不需要另填
中继服务器同机、默认端口部署可继续留空；需要显式指定时，填写同一服务器的地址及 :21117
API 服务器留空，OSS 不提供 Pro 的账户 / 管理 API
密钥（Key）现有 id_ed25519.pub 的完整内容
使用 WebSocket关闭
禁用 UDP保持关闭（如果客户端提供此选项）

其中 API 留空的原因是 OSS 不使用这项 API，不是客户端会自动推导出一个可用的 OSS API 地址。客户端基本字段说明见官方客户端配置文档。

如需把 IP 换成域名，可以将 rustdesk.qnmdmyy.top 的 DNS A 记录指向原服务器公网 IP，再在客户端填写域名；这只是地址管理方式的变化。原生连接无需添加 https://、申请网站证书或配置 Nginx HTTP 反向代理。

在 Windows 被控制端进一步调整安全设置：

  • 无人值守时，设置独立、足够长的随机固定密码，并选择只使用固定密码，避免仍允许较短的临时密码连接。
  • 有人在电脑旁时，可按需要采用人工确认连接；不要把“密码或点击确认”误认为必须同时满足密码和人工确认。
  • 在权限中关闭不需要的文件传输、剪贴板同步、TCP 隧道等功能，只保留实际需要的控制权限。

密码验证方式与权限选项见官方安全设置说明。

六、验证加固后的连接 ​

  1. 两端核对 ID 服务器和公钥，确认状态就绪，再从 Android 输入 Windows 的 ID 和连接密码，实际检查画面及输入是否正常。“就绪”只表示注册 / 心跳等基本状态，不能单独证明 Key 校验和远程访问认证全部通过。
  2. 单独测试一次中继：在目标 ID 后临时添加 /r 发起连接，例如 123456789/r（替换为实际 ID），并确认会话显示为中继连接。这样可以发现 hbbr 端口或 Key 配置问题；只测到 P2P 直连不足以验证 hbbr。测试后去掉 /r 恢复正常连接方式。参见官方强制中继说明。
  3. 收紧安全组后，用两端实际会使用的网络重新连接；设置了固定来源限制时，还应从未获准的外部网络确认这些入口不可访问。服务器本机的监听状态不能证明公网访问规则有效。
  4. 后续更新客户端或服务端时，先备份配置和数据，再查阅对应版本说明并重复上述连接测试。本文关于默认 Key 行为的核对基于 OSS 1.1.16，不能仅凭镜像名中的 latest 判断正在运行的版本。

本节采用 OSS 的原生协议完成加固。官方“所有平台通过 WebSocket 接入”的方案要求客户端 ≥ 1.4.0、Pro 服务端 ≥ 1.5.7，属于另一种部署方案，不能直接套到前文 OSS 服务上再关闭原生端口。参见官方 WebSocket 适用条件。

RustDesk 画质模糊及优化点 ​

一、问题现象与原因 ​

  • 现象：在使用 RustDesk 进行远程桌面连接时，会存在画面模糊、文字不清晰，尤其在高分辨率显示器（如4K）环境下更为明显，问题通常表现为：

    • 文本边缘锯齿严重，难以阅读
    • 图标和界面元素出现模糊或重影
    • 高DPI缩放后内容失真
    • 动态画面有块状压缩痕迹

  • 原因：RustDesk默认采用的视频编码策略偏向于 带宽节省，而非视觉保真度，也就是说，RustDesk 在带宽有限（尤其是走中继服务器时）触发的自适应降质机制，滚动或播放视频时，需要传输的数据量骤增，编码器为了不卡顿，优先急剧降低画质压缩数据量，等画面重新静止，码率需求降下来，画质才慢慢恢复清晰，所以走自建中继服务器这种情况下，上行带宽瓶颈很可能是核心原因

  • 解决方式（控制端方）

    1. 将图像质量改成“自定义”，手动拉高码率和调整帧率

      RustDesk 默认的“平衡”模式码率上限较低。进入 设置 → 显示 → 默认图像质量，改为 自定义，然后将 码率（Bitrate）拉到 100%，帧率调到 60 FPS 或更高

      注意：码率设置可能需要重新连接才能生效。100% 意味着不人为限制编码器输出，让它在你的网络带宽允许范围内尽可能输出高质量画面

    2. 切换编码器：优先尝试 AV1，其次 VP9

      进入 设置 → 显示 → 默认编解码器，优先选择 AV1。如果你的显卡不支持 AV1，次选 VP9。如果 VP9 也出现色块或模糊，可以退回 VP8 试试

      注意：控制端设置的编码器，被控制端显卡或CPU必须支持该编码器，否则选项为灰色或自动回退

      编码器动态画面表现带宽效率硬件要求
      AV1最佳，快速滚动时文字不糊最高较新 GPU，CPU 也可软编
      VP9较好，但部分场景有模糊或色块较高软件编码，CPU 占用高
      H.264/H.265一般，动态场景文字易产生压缩伪影中硬件加速支持最广泛
      VP8较差，带宽消耗大低兼容性最好

    3. 在控制端的显示菜单调整分辨率

      如果被控制端是 2K 或 4K 屏幕，动态画面需要传输的数据量是 1080p 的 2~4 倍，所以在会话中，将分辨率降到 1920×1080，能在不改变画质设置的前提下大幅减少带宽压力（调整的分辨率实际上是被控制端的分辨率）

    4. 关闭音频和剪贴板同步（不建议，看个人需求）

      在控制端的会话菜单里关闭音频、剪贴板同步，当然被控制端也可以关闭，进一步省带宽

  • 解决方式（被控制端方）

    1. 开启硬件编码支持（两端都建议开，但是侧重点不同）

      被控制端开硬件编码，负责把屏幕画面压成视频；

      控制端开硬件编码，负责把视频解出来显示；

    2. 性能检查

      被控制端的 CPU、GPU 和网络带宽不能成为瓶颈

  • 解决方式（中继服务器方）

    1. 检查云服务器的上行带宽并提升

      服务器的上行带宽就是画面传输硬上限，所以如果带宽不够，尝试升级套餐或改成按量付费

    2. 优化中继路径

      把 hbbr 部署到离两端更近、带宽更大的服务器。hbbs 可以继续留在原阿里云，只要密钥一致

RustDesk 设置开机自启动 ​

  1. 按 Win + R，输入：

    tex
    # 为当前用户设置开机自启动
shell:startup

# 为所有用户设置开机自启动（需要管理员权限）
shell:common startup

  2. 把该应用的 快捷方式 复制/拖进去

RustDesk 控制端（Android）切屏后需重连的问题解决方案 ​

一、原因 ​

Android 系统（尤其是国产定制系统）为了省电，会严格限制应用在后台的活动。当你把 RustDesk 切到后台时：

  1. 系统冻结或杀死进程：系统可能很快将 RustDesk 的进程冻结，甚至直接关闭，导致它与被控端的连接中断。
  2. 网络连接被切断：系统可能会切断应用的后台网络连接，以节省电量。
  3. “省电模式”或“电池优化”：这些系统功能会主动限制后台应用的活动，导致连接无法维持。

二、解决方案 ​

  • 关闭电池优化：进入手机 设置 → 应用 → RustDesk → 电池，将电池策略设置为 “无限制” 或 “不受限制”（不同品牌叫法可能略有不同）。
  • 锁定后台：在手机的多任务界面（最近任务），找到 RustDesk，通常可以通过下拉或长按来 “锁定” 该应用，防止被一键清理。
  • 开启自启动：在应用权限设置中，允许 RustDesk “自启动”。
  • 允许后台活动：在应用权限中，确保允许 RustDesk “在后台运行”。
  • 关闭省电模式：在不需要时，关闭手机的 “省电模式”。

三、注意事项 ​

  • 即使完成了上述所有设置，在某些系统（如 MIUI、澎湃 OS、荣耀等）上，RustDesk 的后台存活率依然可能不高，这是系统层面的限制导致的。所以修改的上述设置只是尽可能延长它在后台的存活时间，减少重连的频率。

MIT版权，未经许可禁止任何形式的转载

Copyright © 2016-2026