RustDesk自建中继服务器实战：Docker部署与PM2守护解决卡顿

1. 为什么我要放弃公共中继，自己搭一套 RustDesk 服务

用 RustDesk 的人大概都经历过这样的场景：白天在公司连家里电脑还挺流畅，一到晚上高峰期，画面卡成 PPT，鼠标拖拽延迟肉眼可见，文件传输速度掉到几百 KB。这不是你的网络出了问题，而是你正在使用的公共中继服务器被太多人共享了。RustDesk 官方提供的免费中继（rs-ny.rustdesk.com 这类节点）本质上是一个“公共食堂”，谁都能来吃，高峰期排队是必然的。

RustDesk 的架构其实很清晰：客户端之间建立连接时，如果双方都在 NAT 后面无法直连，就需要一个中继节点（Relay）帮忙转发流量；同时还需要一个信令服务器（ID Server）来协调双方的握手和身份识别。官方把这套东西打包成了两个核心组件——hbbs（ID/信令服务器）和hbbr（中继服务器）。自建的本质，就是把这两个组件部署在你自己的服务器上，让所有流量走你自己的带宽，不再和别人挤。

自建之后能带来什么实际改变？我实测下来，同一台云服务器（2 核 4G，5Mbps 带宽）上自建中继，晚高峰时段远程桌面延迟从公共节点的 180ms 降到 40ms 左右，文件传输稳定跑满带宽上限。更重要的是数据主权——所有连接握手和中继流量都经过你自己的机器，不依赖第三方。对于需要远程运维、跨设备办公、给家人远程协助的场合，这套方案的价值非常直接。

这篇文章适合谁看？如果你手里有一台带公网 IP 的云服务器（阿里云、腾讯云、华为云或者海外 VPS 都行），会基本的 Linux 命令，想彻底解决 RustDesk 卡顿和数据隐私问题，那接下来的内容可以直接抄作业。我会从服务器选型、Docker 部署、PM2 守护、客户端配置到排错，一步步拆开讲，把踩过的坑都标出来。

2. 部署前的整体设计与关键选型思路

2.1 为什么优先选 Docker 而不是裸机编译

RustDesk 官方提供了多种部署方式：直接下载二进制、Docker 镜像、以及各种一键脚本。我前后试过三种，最后稳定在 Docker 方案上，原因有三个。

第一是依赖隔离。hbbs和hbbr是 Rust 编译的静态二进制，理论上裸机跑也没问题，但它依赖系统的 glibc 版本和端口环境。不同发行版（Ubuntu 22.04、Debian 12、CentOS 7）的库版本差异会导致一些莫名其妙的启动失败。Docker 把这些差异全部抹平，镜像里该有的都有。

第二是升级和回滚方便。RustDesk 更新频率不低，用 Docker 只需要docker pull新镜像再重启容器，出问题一条命令回滚到旧 tag。裸机部署要手动替换二进制、处理权限，麻烦得多。

第三是端口和网络配置清晰。RustDesk 需要用到 21114（TCP，Web 客户端）、21115（TCP，NAT 类型测试）、21116（TCP/UDP，ID 注册与心跳）、21117（TCP，中继）、21118/21119（TCP，WebSocket）这几个端口。Docker 的端口映射把这些一次性写清楚，比在系统里到处配防火墙直观。

提示：如果你的服务器是 CentOS 7，注意它的内核版本较老，建议升级到 CentOS Stream 或者直接换 Ubuntu 22.04/Debian 12，Docker 在新内核上跑得更稳。

2.2 服务器配置与带宽估算

很多人纠结“自建中继要多大带宽”。这里给一个我实际测算的参考：RustDesk 远程桌面在 1080P 分辨率、普通办公场景下，码率大约在 1~3 Mbps 之间波动；如果开高清或者传文件，峰值能到 8~10 Mbps。所以：

使用场景	建议带宽	建议配置
1~2 人偶尔远程	3~5 Mbps	1 核 1G
3~5 人日常办公	10 Mbps	2 核 2G
团队使用 + 文件传输	20 Mbps 以上	2 核 4G

CPU 和内存反而不是瓶颈，hbbs/hbbr本身很轻量，2 核 2G 跑几十个并发连接毫无压力。真正吃资源的是带宽和流量。如果你的云服务器是按流量计费的（比如某些海外 VPS），一定要算清楚：远程桌面一小时大约消耗 500MB~1.5GB 流量，长期挂着会烧钱。建议选固定带宽包月的机型。

另外，服务器最好有公网 IPv4。虽然 RustDesk 支持 IPv6，但很多客户端网络环境对 IPv6 支持不完整，用 IPv4 最省心。如果服务器在海外，国内客户端连接会有额外延迟，建议中继节点尽量选离你常用设备近的区域。

2.3 域名与端口规划

自建中继不强制要域名，直接用 IP 也能跑。但如果你想让客户端配置更干净，或者后续要加 TLS，建议准备一个域名，解析到服务器 IP。端口方面，我建议保持默认端口不变，因为客户端默认就按这几个端口去连，改端口反而要每个客户端单独配。真正需要做的是在云服务器安全组里放行这些端口。

需要放行的端口清单：

• 21115 TCP：NAT 类型测试
• 21116 TCP + UDP：ID 注册、心跳、打洞协调（UDP 很关键，别只放 TCP）
• 21117 TCP：中继转发
• 21118、21119 TCP：Web 客户端支持（不用 Web 端可以不开放）

注意：21116 的 UDP 是最容易被漏掉的。很多人只放行了 TCP，结果客户端能上线但打洞失败，所有流量都走中继，速度反而更慢。这一点后面排错章节还会细说。

3. Docker 部署 RustDesk 服务端的完整实操

3.1 安装 Docker 与 Docker Compose

先确认系统环境。我用的是 Ubuntu 22.04，命令在 Debian 12 上同样适用。第一步装 Docker：

# 更新包索引 sudo apt update sudo apt install -y ca-certificates curl gnupg # 添加 Docker 官方 GPG key sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod a+r /etc/apt/keyrings/docker.gpg # 添加软件源 echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 安装 Docker Engine 和 Compose 插件 sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

装完后验证：

sudo docker version sudo docker compose version

如果docker compose version报错，说明 compose 插件没装上，可以单独装docker-compose-plugin。国内服务器如果拉镜像慢，可以配置镜像加速，编辑/etc/docker/daemon.json：

{ "registry-mirrors": ["https://docker.mirrors.ustc.edu.cn"] }

然后sudo systemctl restart docker。这一步不是必须的，但能明显加快后续拉取镜像的速度。

3.2 用 Docker Compose 编排 hbbs 和 hbbr

我推荐用docker-compose.yml来管理，比手敲docker run清晰得多，也方便后续改配置。新建一个目录，比如/opt/rustdesk，在里面创建docker-compose.yml：

version: '3' services: hbbs: container_name: hbbs image: rustdesk/rustdesk-server:latest command: hbbs -r your-server-ip:21117 volumes: - ./data:/root network_mode: "host" restart: unless-stopped hbbr: container_name: hbbr image: rustdesk/rustdesk-server:latest command: hbbr volumes: - ./data:/root network_mode: "host" restart: unless-stopped

这里有几个关键点要解释清楚。

command: hbbs -r your-server-ip:21117里的-r参数指定中继地址，必须填你服务器的公网 IP 或域名，端口是 21117。这个参数告诉 hbbs：“当客户端需要中继时，让它们去连这个地址”。如果填错，客户端会连不上中继。

network_mode: "host"让容器直接使用宿主机网络，省去端口映射的麻烦。因为 RustDesk 需要用到 UDP 21116，用 host 模式最省事，避免 bridge 模式下 UDP 转发的问题。代价是容器和宿主机共享网络栈，但对这个场景完全够用。

volumes: ./data:/root把数据目录挂载出来。hbbs首次启动会生成一对密钥（id_ed25519和id_ed25519.pub），这对密钥是客户端认证的核心，必须持久化，否则容器重建后所有客户端都要重新配置。

启动服务：

cd /opt/rustdesk sudo docker compose up -d

查看日志确认启动成功：

sudo docker compose logs -f

正常的话你会看到hbbs输出类似Listening on 0.0.0.0:21116的日志，hbbr输出Listening on 0.0.0.0:21117。如果看到报错，多半是端口被占用或者权限问题。

3.3 获取密钥并配置客户端

服务起来后，去数据目录拿公钥：

cat /opt/rustdesk/data/id_ed25519.pub

这串字符就是客户端要填的Key。接下来在每台需要远程的设备上配置 RustDesk 客户端：

1. 打开 RustDesk，点击 ID 右侧的菜单，进入“网络”设置
2. 在ID/中继服务器栏填入你的服务器 IP 或域名
3. 在Key栏粘贴刚才拿到的公钥
4. 保存后，客户端状态栏会显示“就绪”，说明已连上你自己的服务器

提示：如果你有域名，ID 服务器填your-domain.com，中继服务器可以留空（客户端会自动用 ID 服务器返回的中继地址）。如果只有 IP，ID 和中继都填同一个 IP 即可。

配置完成后，用另一台设备测试连接。第一次连接时，双方会通过你的 hbbs 交换信息，然后尝试 P2P 打洞；打洞失败才走 hbbr 中继。你可以在 hbbs 日志里看到连接记录，确认流量确实走了自己的服务器。

4. 用 PM2 守护与进阶运维技巧

4.1 为什么还要提 PM2

看到这里你可能疑惑：Docker 已经有restart: unless-stopped了，为什么还要 PM2？答案是——不是所有人都用 Docker。有些人的服务器环境受限（比如公司内网机器、老旧系统装不了新版 Docker），或者你就是想用二进制裸跑。这种情况下，PM2 是一个非常好用的进程守护工具，它能自动重启崩溃的进程、管理日志、开机自启。

PM2 本质是 Node.js 的进程管理器，但完全可以用来守护任何可执行文件。它的优势在于：日志集中管理、pm2 monit实时监控、pm2 save保存进程列表后配合pm2 startup实现开机自启。

4.2 裸机二进制 + PM2 部署方案

先从 RustDesk 官方发布页下载对应架构的二进制包（rustdesk-server-linux-amd64.zip或arm64），解压后得到hbbs和hbbr两个文件。放到/opt/rustdesk目录，赋予执行权限：

chmod +x hbbs hbbr

安装 PM2：

# 需要先有 Node.js 环境 curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs sudo npm install -g pm2

用 PM2 启动两个进程：

cd /opt/rustdesk pm2 start ./hbbs --name rustdesk-hbbs -- -r your-server-ip:21117 pm2 start ./hbbr --name rustdesk-hbbr

注意--后面的参数是传给hbbs本身的，这个语法别写错。启动后查看状态：

pm2 list pm2 logs rustdesk-hbbs

设置开机自启：

pm2 save pm2 startup

pm2 startup会输出一条命令，复制执行即可把 PM2 注册为系统服务。

4.3 日志、监控与自动更新

无论用 Docker 还是 PM2，日志都是排错的第一手资料。Docker 下用docker compose logs -f --tail=100看最近 100 行；PM2 下用pm2 logs --lines 100。重点关注几类信息：客户端注册（New connection from ...）、中继建立（relay connection）、以及任何error或panic字样。

监控方面，我习惯用docker stats看容器资源占用，或者pm2 monit看进程 CPU/内存。正常情况下 hbbs 内存占用在 20~50MB，hbbr 在 10~30MB，如果持续增长到几百 MB，可能是连接泄漏，重启一下容器即可。

自动更新我建议手动控制，不要用 watchtower 之类的工具自动拉新镜像。RustDesk 偶尔会有不兼容的版本更新，自动升级可能导致客户端连不上。我的做法是：每月检查一次官方 release，确认稳定后再手动docker compose pull && docker compose up -d。

5. 常见问题排查与避坑实录

5.1 客户端连不上服务器的排查顺序

这是最高频的问题。按下面顺序排查，基本能定位 90% 的故障：

现象	可能原因	排查方法
客户端一直“正在连接”	21116 端口未放行	telnet ip 21116测试
能上线但无法远程	21117 中继端口未放行	检查安全组和防火墙
连接后卡顿严重	UDP 21116 未放行，走了中继	放行 UDP 后重试
提示 Key 错误	公钥填错或未持久化	重新cat id_ed25519.pub
服务启动即退出	端口被占用	`ss -tulnp

我踩过最坑的一次是：安全组放行了 TCP 21116，但忘了 UDP。结果客户端能注册上线，但 P2P 打洞全部失败，所有流量走中继，延迟反而比公共节点还高。放行 UDP 后立刻恢复正常。所以UDP 21116 一定要放行，这是打洞的关键。

5.2 密钥丢失与客户端批量重配

如果你不小心删了data目录，或者换了服务器，密钥会重新生成，所有客户端都要重新填 Key。避免这个问题的办法就是备份id_ed25519和id_ed25519.pub。我习惯把这两个文件单独存一份到本地。

如果已经丢了，也不用慌。重新生成后，在每台客户端上更新 Key 即可。设备多的话，可以用 RustDesk 的“导入配置”功能，或者直接改客户端的配置文件（Windows 在%APPDATA%\RustDesk\config，Linux 在~/.config/rustdesk/），把新的服务器地址和 Key 写进去。

5.3 带宽跑满与限速思路

自建中继最大的风险是带宽被跑满，导致服务器上其他服务受影响。RustDesk 本身没有内置限速，但可以在系统层面用tc（流量控制）做限制。比如限制 21117 端口的出站带宽：

# 限制 eth0 出站到 10Mbps（示例，需根据实际网卡调整） sudo tc qdisc add dev eth0 root tbf rate 10mbit burst 32kbit latency 400ms

这条命令比较粗暴，会限制整块网卡。更精细的做法是用iptables配合hashlimit对特定端口限速，但配置复杂。我的建议是：如果只是个人或小团队用，直接买够带宽的服务器，别折腾限速；如果是多人共享，考虑在中继前面加一层流量监控，超阈值告警。

5.4 客户端编译的坑（进阶）

有些朋友想自己编译 RustDesk 客户端做定制（比如改默认服务器地址、去掉某些功能）。这条路我走过，坑不少。首先需要 Rust 工具链和一堆系统依赖（libgtk-3-dev、libxdo-dev、libssl-dev等），在 Ubuntu 上编译 Windows 版本还要装mingw-w64。编译一次动辄半小时，而且不同版本的依赖经常变。

如果你只是想改默认服务器地址，其实不用编译。RustDesk 支持通过配置文件或环境变量指定服务器，改配置比编译省事得多。真要编译，建议用官方提供的 Docker 编译镜像，能省掉大量环境配置的麻烦。

6. 我实际用下来的一些体会

这套自建方案我跑了大概半年，中间经历过一次服务器迁移、两次 RustDesk 版本升级，整体稳定性很好。最大的感受是：自建中继的门槛比想象中低，但细节决定体验。Docker 部署十分钟能搞定，真正花时间的是端口放行、UDP 打洞验证、以及客户端批量配置这些琐碎环节。

如果让我给刚上手的朋友一句建议：先把 UDP 21116 放行这件事刻在脑子里，然后备份好密钥文件。这两件事做到位，后面基本不会有大问题。至于带宽，宁可买大一点，远程桌面这东西，卡起来是真的影响心情。