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

1. 为什么我要放弃公共中继自己搭一套 RustDesk 服务用 RustDesk 的人大概都经历过这样的场景白天在公司连家里电脑还挺流畅一到晚上高峰期画面卡成 PPT鼠标拖拽延迟肉眼可见文件传输速度掉到几百 KB。这不是你的网络出了问题而是你正在使用的公共中继服务器被太多人共享了。RustDesk 官方提供的免费中继rs-ny.rustdesk.com 这类节点本质上是一个“公共食堂”谁都能来吃高峰期排队是必然的。RustDesk 的架构其实很清晰客户端之间建立连接时如果双方都在 NAT 后面无法直连就需要一个中继节点Relay帮忙转发流量同时还需要一个信令服务器ID Server来协调双方的握手和身份识别。官方把这套东西打包成了两个核心组件——hbbsID/信令服务器和hbbr中继服务器。自建的本质就是把这两个组件部署在你自己的服务器上让所有流量走你自己的带宽不再和别人挤。自建之后能带来什么实际改变我实测下来同一台云服务器2 核 4G5Mbps 带宽上自建中继晚高峰时段远程桌面延迟从公共节点的 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 需要用到 21114TCPWeb 客户端、21115TCPNAT 类型测试、21116TCP/UDPID 注册与心跳、21117TCP中继、21118/21119TCPWebSocket这几个端口。Docker 的端口映射把这些一次性写清楚比在系统里到处配防火墙直观。提示如果你的服务器是 CentOS 7注意它的内核版本较老建议升级到 CentOS Stream 或者直接换 Ubuntu 22.04/Debian 12Docker 在新内核上跑得更稳。2.2 服务器配置与带宽估算很多人纠结“自建中继要多大带宽”。这里给一个我实际测算的参考RustDesk 远程桌面在 1080P 分辨率、普通办公场景下码率大约在 1~3 Mbps 之间波动如果开高清或者传文件峰值能到 8~10 Mbps。所以使用场景建议带宽建议配置1~2 人偶尔远程3~5 Mbps1 核 1G3~5 人日常办公10 Mbps2 核 2G团队使用 文件传输20 Mbps 以上2 核 4GCPU 和内存反而不是瓶颈hbbs/hbbr本身很轻量2 核 2G 跑几十个并发连接毫无压力。真正吃资源的是带宽和流量。如果你的云服务器是按流量计费的比如某些海外 VPS一定要算清楚远程桌面一小时大约消耗 500MB~1.5GB 流量长期挂着会烧钱。建议选固定带宽包月的机型。另外服务器最好有公网 IPv4。虽然 RustDesk 支持 IPv6但很多客户端网络环境对 IPv6 支持不完整用 IPv4 最省心。如果服务器在海外国内客户端连接会有额外延迟建议中继节点尽量选离你常用设备近的区域。2.3 域名与端口规划自建中继不强制要域名直接用 IP 也能跑。但如果你想让客户端配置更干净或者后续要加 TLS建议准备一个域名解析到服务器 IP。端口方面我建议保持默认端口不变因为客户端默认就按这几个端口去连改端口反而要每个客户端单独配。真正需要做的是在云服务器安全组里放行这些端口。需要放行的端口清单21115 TCPNAT 类型测试21116 TCP UDPID 注册、心跳、打洞协调UDP 很关键别只放 TCP21117 TCP中继转发21118、21119 TCPWeb 客户端支持不用 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 ar /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.ymlversion: 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 客户端打开 RustDesk点击 ID 右侧的菜单进入“网络”设置在ID/中继服务器栏填入你的服务器 IP 或域名在Key栏粘贴刚才拿到的公钥保存后客户端状态栏会显示“就绪”说明已连上你自己的服务器提示如果你有域名ID 服务器填your-domain.com中继服务器可以留空客户端会自动用 ID 服务器返回的中继地址。如果只有 IPID 和中继都填同一个 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 startuppm2 startup会输出一条命令复制执行即可把 PM2 注册为系统服务。4.3 日志、监控与自动更新无论用 Docker 还是 PM2日志都是排错的第一手资料。Docker 下用docker compose logs -f --tail100看最近 100 行PM2 下用pm2 logs --lines 100。重点关注几类信息客户端注册New connection from ...、中继建立relay connection、以及任何error或panic字样。监控方面我习惯用docker stats看容器资源占用或者pm2 monit看进程 CPU/内存。正常情况下 hbbs 内存占用在 20~50MBhbbr 在 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\configLinux 在~/.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 放行这件事刻在脑子里然后备份好密钥文件。这两件事做到位后面基本不会有大问题。至于带宽宁可买大一点远程桌面这东西卡起来是真的影响心情。