Docker部署RustDesk自建服务器：实现安全可控的远程桌面方案-三亩地-编程学习日记

1. 项目概述：为什么选择自建RustDesk服务器？

远程办公这个概念，现在几乎成了我们这行人的日常。但每次提到远程控制，很多人第一反应还是TeamViewer、AnyDesk这些老牌工具，或者向日葵、ToDesk这些国产新秀。用过的朋友都知道，免费版要么限速、要么画质感人，时不时还弹个窗提醒你“商业用途”；付费版呢，对于个人或者小团队来说，又是一笔不大不小的开销。更别提数据安全这个心头大患了，你的桌面画面、操作指令，全都经过别人的服务器中转，心里总有点不踏实。

所以，当RustDesk出现时，它就像一股清流。开源、免费、主打自建中继服务器，口号是“你的数据，你做主”。它的核心思路非常清晰：官方提供了基础的开源客户端和中继服务器程序，你可以完全免费使用官方的公共服务器，但延迟和画质可能不稳定。而它的精髓在于，允许你一键部署自己的中继服务器（Relay Server）和信令服务器（ID Server），所有远程连接的数据流都走你自己的服务器，彻底摆脱第三方限制，实现真正意义上的“远程办公自由”。

我折腾过不少远程方案，从早期的VNC到各种商业软件，最后落到自建RustDesk上，就是看中了它“鱼和熊掌可以兼得”的潜力：既有媲美商业软件的流畅高清体验，又拥有开源自建的安全可控和零成本。网上很多教程把自建说得特别复杂，动不动就要改编译参数、配置防火墙规则，让不少新手望而却步。其实，借助Docker这个神器，整个过程可以简化到一分钟以内。这篇内容，我就结合自己多次部署的经验，带你走一遍最清晰、最省事的路径，无论你是Linux新手还是有一定基础的运维，都能轻松搞定，让你手头的任何云服务器、甚至家里的NAS，瞬间变成专属的高性能远程办公网关。

2. 核心架构与方案选型：理解RustDesk自建的“五脏六腑”

在动手之前，我们得先搞清楚RustDesk自建到底建了什么，这决定了我们后续的所有操作。很多人以为自建就是搭一个服务器，其实它包含两个核心部分，理解这个双服务器架构是关键。

2.1 双服务器架构解析

RustDesk的架构设计得很巧妙，它将连接过程分成了“找人”和“传数据”两步，分别由两个不同的服务处理：

信令服务器 (hbbs - RustDesk ID Server)：
- 作用：相当于“电话总机”或“联系人目录”。它的核心工作是管理所有在线的RustDesk客户端（包括控制端和被控端）的ID（一个由服务器生成的唯一数字）和网络地址信息。当你想连接另一台电脑时，客户端会先询问这个服务器：“ID是123456的机器在哪？” 服务器会回复你它的当前IP和端口。
- 核心数据：它使用一个本地的SQLite数据库（或可选的MySQL）来存储用户、密钥对等信息，数据量很小。
- 通信特点：信令交互的数据量极小，主要是文本消息，对带宽和延迟要求不高。
中继服务器 (hbbr - RustDesk Relay Server)：
- 作用：相当于“数据快递中心”。当两台客户端因为网络限制（比如双方都在不同的局域网内，即NAT后面）无法直接建立P2P连接时，所有远程桌面的画面、鼠标键盘指令、文件传输等数据，都会通过这个服务器进行中转。
- 核心任务：转发大量的音视频流和数据流。这是影响远程体验（流畅度、清晰度）最关键的部件，对服务器的带宽、流量和CPU（视频编解码）有直接要求。
- 通信特点：传输的是实时的、压缩后的视频帧和音频数据，流量消耗大，对带宽和质量敏感。

简单来说，hbbs负责“牵线搭桥”，告诉客户端彼此的位置；hbbr负责“扛货运输”，在直连不通时搬运数据。在理想情况下（双方网络友好），客户端会尝试P2P直连，数据不经过中继，延迟最低。自建服务器的最大意义，就是让你完全掌控这个“牵线”和“运输”的枢纽，避免拥堵在公共节点上。

2.2 为什么强烈推荐Docker部署？

网上有直接下载二进制程序运行、有从源码编译的，但我坚持推荐Docker部署，尤其对于新手和希望长期稳定运行的用户，理由如下：

环境隔离，天下太平：RustDesk服务器运行需要特定的端口（后面会详述）。用Docker部署，所有依赖（库文件、运行环境）都打包在镜像里，与你宿主机系统的其他服务完全隔离。不会因为你系统升级了某个库，导致RustDesk崩溃。这种“装完即走，不管闲事”的特性，是维护系统整洁稳定的利器。
部署极简，一分钟真不是吹牛：省去了配置系统服务、管理运行用户的繁琐步骤。一条docker run命令，配合几个参数，服务就起来了。更新也简单，拉取新镜像，重启容器即可。
配置持久化，数据安全：通过Docker的“卷映射”功能，我们可以把容器内重要的数据（比如上面提到的SQLite数据库、密钥文件）映射到宿主机的目录。这样即使你删除了容器，数据依然在。重装、迁移服务器变得非常容易。
社区镜像成熟可靠：我们直接使用官方推荐的或社区维护的Docker镜像，如rustdesk/rustdesk-server，这些镜像经过了优化和测试，开箱即用，比自己编译更省心。

注意：有些教程会教你在Docker里同时运行hbbs和hbbr，虽然可行，但从架构清晰度和资源隔离角度，我建议分别为两个服务创建独立的容器。这样管理、监控、重启都互不影响。

2.3 服务器与网络准备要点

工欲善其事，必先利其器。自建服务器的体验好坏，90%取决于你准备的这台“器”。

服务器选择：
- 核心诉求：公网IP、足够的带宽。这是硬性条件，没有公网IP，外网无法访问你的服务器。
- 配置建议：对于个人或3-5人的小团队，一台最低配置的云服务器（如1核1G）跑信令服务器(hbbs)绰绰有余。但中继服务器(hbbr)的配置需要根据实际使用情况来定。
  - CPU：影响视频编解码性能。如果经常需要传输高分辨率（如4K）画面或进行大量屏幕内容变化（如玩游戏、看视频），建议选择2核以上。普通办公、代码编辑，1核足够。
  - 内存：1GB是底线，2GB更从容。
  - 带宽：这是最关键的指标，直接决定画面流畅度和清晰度。建议选择按流量计费的服务器，并购买足够的带宽峰值（如5Mbps以上）。RustDesk的流量消耗与屏幕变化率、分辨率、色彩深度强相关。静态桌面可能只需几十Kbps，而滚动网页或播放视频可能瞬间需要2-5Mbps。务必确保你的服务器带宽上限大于你的预期并发流量总和。
- 地域：选择离你和你的被控设备网络位置都相对较近的机房，可以降低延迟。
网络与防火墙： RustDesk服务器需要开放特定端口供客户端通信。这是部署中最容易踩坑的地方。
- hbbs(信令服务器)：
  - 21115(TCP): 用于客户端注册和ID解析。
  - 21116(TCP/UDP): 用于客户端之间的信令交换和NAT打洞尝试。
  - 21118(TCP): 用于Web API（如获取服务器状态）。
- hbbr(中继服务器)：
  - 21117(TCP): 用于中继数据（音视频流、文件传输）。
  - 21119(TCP): 用于密钥中继（用于P2P加密协商）。
- 操作：你需要在云服务器的安全组（阿里云、腾讯云等叫法）以及服务器内部的防火墙（如ufw或firewalld）中，同时放行上述端口。很多人只配置了一处，导致始终无法连接。

3. 实战部署：一分钟Docker部署详解

理论说完，我们进入实战。假设你已经拥有一台安装了Linux系统（如Ubuntu 22.04, CentOS 7/8, Debian等）并配置好Docker环境的云服务器。下面我们分步操作。

3.1 部署信令服务器 (hbbs)

首先，我们拉取并运行信令服务器。这里我们使用官方推荐的镜像。

创建数据目录：为了持久化保存密钥和数据库，我们先在宿主机上创建一个目录。
```
sudo mkdir -p /opt/rustdesk/hbbs
```
这个/opt/rustdesk/hbbs目录将用来存放容器内生成的重要文件。
运行hbbs容器：执行以下一条命令。
```
sudo docker run -d \ --name hbbs \ --restart unless-stopped \ -p 21115:21115 \ -p 21116:21116 \ -p 21116:21116/udp \ -p 21118:21118 \ -v /opt/rustdesk/hbbs:/root \ rustdesk/rustdesk-server:latest \ hbbs -r <你的服务器公网IP或域名>:21117
```
- 参数拆解：
  - -d: 后台运行。
  - --name hbbs: 给容器起个名字，方便管理。
  - --restart unless-stopped: 设置自动重启策略，除非手动停止，否则容器退出后会自动重启，保证服务高可用。
  - -p 主机端口:容器端口: 端口映射，将容器内的端口暴露到宿主机。我们映射了hbbs所需的全部TCP端口，以及21116的UDP端口（用于打洞）。
  - -v /opt/rustdesk/hbbs:/root: 卷映射，将宿主机的/opt/rustdesk/hbbs目录挂载到容器内的/root目录。这样容器内生成的文件都会保存在宿主机上。
  - rustdesk/rustdesk-server:latest: 使用的Docker镜像。
  - hbbs -r ...: 容器启动后执行的命令。-r参数是关键，它指定了中继服务器(hbbr)的地址。格式为-r <中继服务器地址>:21117。这里你需要替换<你的服务器公网IP或域名>为你的实际公网IP，或者一个指向该IP的域名（推荐用域名，方便以后IP变更）。注意端口是21117。
实操心得：-r参数一定要填对，这是客户端能找到中继服务器的依据。如果你把hbbs和hbbr部署在同一台服务器，这里就填这台服务器的地址。如果分开放置，则填hbbr所在服务器的地址。
验证与获取密钥：容器运行后，查看日志并获取关键文件。
```
# 查看容器运行状态 sudo docker ps | grep hbbs # 查看容器日志，确认无报错 sudo docker logs hbbs
```
接下来，进入我们映射的目录，获取id_ed25519.pub文件的内容，这是后续配置客户端必需的公钥。
```
sudo cat /opt/rustdesk/hbbs/id_ed25519.pub
```
你会看到一串类似BVP+8GZqLvSX6zgh....的字符串，复制它，保存好。

3.2 部署中继服务器 (hbbr)

中继服务器的部署更为简单，因为它不需要-r参数。

创建数据目录（可选，但建议）：
```
sudo mkdir -p /opt/rustdesk/hbbr
```

运行hbbr容器：

sudo docker run -d \ --name hbbr \ --restart unless-stopped \ -p 21117:21117 \ -p 21119:21119 \ -v /opt/rustdesk/hbbr:/root \ rustdesk/rustdesk-server:latest \ hbbr

参数含义与hbbs类似。注意端口映射的是21117和21119。
启动命令直接就是hbbr，没有额外参数。

验证运行：

sudo docker ps | grep hbbr sudo docker logs hbbr

至此，服务器端的部署在命令执行完的瞬间（一分钟内）就完成了。你可以用sudo docker ps看到两个容器都在运行。

3.3 客户端配置：连接你的私有服务器

服务器搭好了，现在需要在被控端和控制端的RustDesk客户端上进行配置，让它们不再连接官方服务器，而是连接你刚搭建的私有服务器。

获取服务器地址和密钥：
- ID/中继服务器：填写你的服务器公网IP或域名。例如：your-domain.com或123.123.123.123。不需要加端口。客户端会根据内置规则去连接21116端口。
- 密钥：填写之前从/opt/rustdesk/hbbs/id_ed25519.pub文件中复制的那一串公钥。
配置步骤（以Windows客户端为例，其他平台类似）：
- 打开RustDesk客户端。
- 点击左上角的三条横线菜单，进入“设置”。
- 在“网络”选项卡中，找到“ID服务器”输入框，填入你的服务器地址。
- 在“密钥”输入框，填入你复制的公钥。
- 点击“确定”或“应用”。客户端会提示需要重启以使配置生效，重启客户端。
验证连接：
- 重启后，观察客户端主界面。如果配置成功，通常在右下角会显示“就绪”或“在线”，并且不会显示“通过中继连接”之类的提示（除非你正在中继）。
- 更直接的验证方法是，查看hbbs容器的日志，当你客户端上线时，会有新的连接日志出现：
```
sudo docker logs -f hbbs
```
- 你可以尝试用另一台配置了相同服务器和密钥的客户端，输入本机的RustDesk ID进行连接测试。

4. 高级配置与优化调优

基础部署完成后，为了获得更稳定、安全、高效的体验，我们还需要进行一些优化。这部分是区分“能用”和“好用”的关键。

4.1 使用域名与SSL加密（强烈推荐）

直接使用IP地址存在两个问题：IP可能变化；通信是明文的。使用域名并配置SSL可以完美解决。

申请域名与解析：购买一个便宜的域名（或使用免费二级域名），在域名服务商处添加一条A记录，将你的域名（例如rd.yourdomain.com）解析到服务器公网IP。
获取SSL证书：最方便免费的方式是使用Let‘s Encrypt的certbot工具。这里以Nginx反向代理为例（也是更推荐的生产环境方式）：
- 安装Nginx和Certbot。
- 为你的域名申请证书：sudo certbot certonly --nginx -d rd.yourdomain.com。
- 证书会保存在/etc/letsencrypt/live/rd.yourdomain.com/目录下，包含fullchain.pem(证书链) 和privkey.pem(私钥)。

配置Nginx反向代理：我们不直接让客户端连接Docker容器的原始端口，而是通过Nginx转发，并在此处加载SSL证书。

编辑Nginx配置文件（如/etc/nginx/conf.d/rustdesk.conf）：

server { listen 443 ssl http2; server_name rd.yourdomain.com; ssl_certificate /etc/letsencrypt/live/rd.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/rd.yourdomain.com/privkey.pem; # 可在此添加其他SSL优化参数，如ssl_protocols, ssl_ciphers等 location / { proxy_pass http://127.0.0.1:21118; # 转发到hbbs的Web API端口 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 注意：Nginx反向代理TCP/UDP流比较麻烦。对于21115-21117,21119这些端口， # RustDesk客户端目前更推荐直接连接。或者使用Nginx的stream模块进行TCP代理。 # 更简单的做法是，仅对Web API(21118)和未来可能的Web客户端做反向代理和HTTPS。 # 主连接端口（21116, 21117）依然直接暴露，但通信内容已被RustDesk端到端加密。 }

修改hbbs启动命令中的-r参数，将IP改为域名：hbbs -r rd.yourdomain.com:21117。
客户端配置中的“ID服务器”也改为rd.yourdomain.com。

重要提示：RustDesk的客户端-服务器通信本身是加密的（使用你配置的公钥对应的私钥）。这里的SSL（HTTPS）主要保护的是Web API接口（21118）和未来可能通过浏览器访问的Web客户端。对于核心的桌面流协议，即使不走HTTPS，其安全性也已由内置的加密机制保障。因此，是否一定要为所有端口配置SSL反向代理，需权衡复杂性和收益。对于绝大多数个人用户，配置好密钥并直接使用端口连接已足够安全。

4.2 性能与画质参数调优

RustDesk客户端提供了丰富的画质和性能选项，合理设置能极大提升体验。

编码器：优先选择H.264或H.265。H.265压缩效率更高，在同等画质下占用带宽更少，但对CPU编解码能力要求也稍高。如果被控端或控制端CPU较弱，遇到卡顿可以尝试切换到H.264。
画面质量：这是一个在清晰度和流畅度之间权衡的滑块。
- “最好”：几乎无损，带宽消耗最大，适合局域网或极高带宽场景。
- “平衡”：默认选项，在大多数办公场景下（文本、代码）表现良好。
- “低画质”：优先保证流畅度，画面会有明显压缩感，适合网络状况很差时（如手机流量）应急使用。
- 个人建议：在控制端设置里，将“默认质量”设为“平衡”。在具体连接时，可以通过工具栏的“画质”按钮实时调整。如果感觉鼠标移动有延迟，首要任务是检查网络延迟和服务器带宽，其次才是降低画质。
帧率 (FPS)：办公场景下，30 FPS足够流畅。如果需要进行动态演示或轻度设计，可以尝试调到60 FPS，但这会显著增加CPU和带宽负担。
硬件加速：确保客户端设置中“使用硬件编码”和“使用硬件解码”选项是开启的（如果硬件支持）。这能大幅降低CPU占用，提升流畅度。
网络缓冲：如果网络波动较大，可以适当增加缓冲（如从“自动”调到“中”或“大”），这能减少因网络抖动导致的卡顿，但会略微增加操作延迟。

4.3 安全加固措施

自建服务器意味着安全责任也到了自己肩上。

防火墙最小化开放：严格按照第2.3节只开放必要的5个端口（21115-21119），并定期检查服务器是否有异常连接。
使用强密码保护密钥文件：虽然私钥(id_ed25519)默认保存在服务器上，但确保/opt/rustdesk/目录的权限仅限于必要用户（如root）。

定期更新：关注RustDesk项目的GitHub发布页，定期更新Docker镜像到最新版本，以获取安全补丁和功能改进。

sudo docker pull rustdesk/rustdesk-server:latest sudo docker stop hbbs hbbr && sudo docker rm hbbs hbbr # 然后重新运行第3节中的docker run命令（注意保留原有的-v卷映射和参数）

监控与日志：定期查看Docker容器日志(docker logs)，关注是否有大量异常连接或错误信息。可以使用docker stats查看容器的实时资源占用（CPU、内存、网络）。
访问控制（高级）：RustDesk服务器本身不支持用户认证。如果你需要限制特定ID才能连接你的服务器，一个变通方法是：定期轮换密钥对。生成新密钥后，只分发给授权的客户端。未经授权的客户端即使知道服务器地址，也会因为密钥不匹配而无法注册和连接。但这需要你手动管理密钥分发。

5. 常见问题与故障排查实录

即使按照步骤操作，也可能会遇到问题。这里把我踩过的坑和解决方案汇总一下，你可以像查字典一样快速定位。

5.1 部署阶段问题

问题1：Docker命令执行后，容器状态为Exited。

排查：立即使用sudo docker logs hbbs（或hbbr）查看退出日志。
常见原因与解决：
- 端口冲突：Error: listen tcp :21115: bind: address already in use。说明宿主机21115端口已被其他程序占用。用sudo netstat -tlnp | grep :21115查找占用进程，停止它或修改Docker映射端口（如-p 22115:21115，但需同步修改客户端和-r参数）。
- 镜像拉取失败：网络问题。尝试sudo docker pull rustdesk/rustdesk-server:latest手动拉取，或配置Docker国内镜像加速器。
- 权限问题：确保/opt/rustdesk/目录存在且Docker有权限写入。

问题2：客户端配置服务器地址和密钥后，显示“无法连接到服务器”或一直“离线”。

排查步骤（逐步缩小范围）：
1. 检查服务器地址：在控制端电脑上，用ping your-domain.com或telnet your-domain.com 21116（Windows需开启Telnet客户端功能）测试是否能通。如果不通，检查域名解析、服务器防火墙、云服务商安全组。
2. 检查容器状态：在服务器上执行sudo docker ps，确认hbbs和hbbr两个容器都在运行（STATUS为Up）。
3. 检查容器内部监听：进入容器内部检查端口是否正常监听。
```
sudo docker exec hbbs netstat -ant | grep LISTEN
```
  应该能看到0.0.0.0:21115,0.0.0.0:21116,0.0.0.0:21118在监听。
4. 检查服务器防火墙：这是高频坑点！确保云服务器控制台的安全组和服务器内部防火墙（如ufw）都放行了相关端口。对于ufw，可以执行：
```
sudo ufw allow 21115/tcp sudo ufw allow 21116/tcp sudo ufw allow 21116/udp sudo ufw allow 21117/tcp sudo ufw allow 21118/tcp sudo ufw allow 21119/tcp sudo ufw reload
```
5. 检查密钥：确保客户端填写的密钥与服务器上/opt/rustdesk/hbbs/id_ed25519.pub的内容完全一致，没有多余空格或换行。最好直接复制粘贴。
6. 查看服务器日志：在客户端尝试连接时，实时查看hbbs日志sudo docker logs -f hbbs，看是否有来自你客户端IP的连接记录或错误信息。

5.2 连接与使用阶段问题

问题3：连接成功，但画面非常卡顿、延迟高。

排查方向：
1. 服务器带宽瓶颈：这是最常见原因。登录服务器，用iftop、nload或vnstat等工具查看实时带宽使用情况。如果远程操作时带宽持续跑满，说明服务器带宽不足，需要升级。
2. 客户端画质设置过高：在连接状态下，尝试调低画质（如从“最好”调到“平衡”），看是否有立竿见影的改善。
3. P2P直连失败，走了中继：检查连接界面下方的提示。如果显示“中继”或“Relay”，说明双方无法直接P2P，所有数据都经过你的服务器中转，这会增加延迟并消耗服务器带宽。确保双方网络（尤其是被控端）的UDP端口（21116）可访问，有助于成功打洞。
4. 服务器CPU/内存不足：使用htop或docker stats命令查看容器资源占用。如果hbbr进程CPU持续高负荷，可能是同时在处理多路高画质流转码，考虑升级服务器配置。

问题4：能控制，但无法传输文件或剪贴板同步失效。

可能原因：
- 防火墙阻断：文件传输使用21117端口。确保该端口在服务器防火墙和客户端本地防火墙（如Windows Defender防火墙）上未被阻止。
- RustDesk客户端权限：在某些系统（如Linux）上，剪贴板同步可能需要额外的权限或依赖（如wayland与x11的区别）。确保客户端有访问剪贴板的权限。
- 功能未开启：检查客户端设置->安全选项卡中，“启用文件传输”和“同步剪贴板”选项是否勾选。

问题5：如何让服务开机自启？

解答：我们在docker run命令中已经添加了--restart unless-stopped参数，Docker守护进程启动时就会自动启动这些容器。只要服务器本身的Docker服务是开机自启的（通常默认就是），我们的RustDesk服务也就会随之启动。无需额外配置systemd服务单元。

5.6 维护与备份策略

任何自建服务，稳定的运维离不开日常维护。

日志管理：Docker容器的日志默认会占用磁盘空间。可以配置Docker的日志驱动和轮转策略，或者定期清理旧日志。一个简单的方法是使用logrotate工具。
数据备份：核心需要备份的就是/opt/rustdesk/hbbs/目录下的文件，尤其是id_ed25519和id_ed25519.pub这对密钥文件，以及db_v2.sqlite3数据库文件（存储了注册的ID信息）。丢失密钥意味着所有客户端需要重新配置；丢失数据库意味着所有已注册的ID映射关系丢失。建议定期将此目录打包备份到其他位置。
更新流程：如前所述，更新就是拉取新镜像，停止并删除旧容器，然后用新镜像和原有参数（特别是卷映射-v和端口映射-p）重新创建容器。务必在操作前备份数据目录。

走到这里，你应该已经拥有一个完全受自己掌控、流畅且高清的远程办公环境了。从被商业软件的各种限制裹挟，到亲手搭建起一条专属的远程通道，这种自由感和掌控感，是付费订阅也无法完全给予的。自建RustDesk服务器的过程，更像是一次对“工具”本质的回归——它应该安静、可靠地服务于你，而不是反过来用条款和弹窗打扰你。当然，自由也意味着责任，你需要承担起维护服务器的角色，但相比它带来的便利和安全感，这点投入绝对是值得的。如果在实践中遇到上面没覆盖到的新问题，多看看日志，善用搜索引擎，社区里有很多同路人的经验可以借鉴。

日记详情

Docker部署RustDesk自建服务器：实现安全可控的远程桌面方案