ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

RustDesk自建中继节点完整指南:从部署到优化

RustDesk自建中继节点完整指南:从部署到优化 1. 为什么我要放弃公共节点自己搭一套 RustDesk 中继用 RustDesk 的人大概都经历过这么几个阶段一开始觉得哇开源、免费、跨平台比某些商业远控香多了用了一阵子发现直连还行一旦跨运营商、跨地区画面就开始糊、延迟就开始飘再往后你开始琢磨它那个中继服务器到底是怎么回事为什么官方公共节点有时候快有时候慢。我自己是大概两年前开始把 RustDesk 当成主力远控工具的。家里一台常开的迷你主机、公司一台办公机、老家还有一台给父母用的旧笔记本三台机器互相连。刚开始用官方公共中继白天还行晚上高峰期经常卡到怀疑人生鼠标移动有明显的拖影传个几十兆的文件要等半天。后来我下定决心自己搭一套中继节点前后折腾了差不多一周踩了不少坑也总结出一套相对稳定的部署方案。这篇内容就是把这套方案完整地摊开讲。RustDesk 自建中继节点这件事说难不难说简单也不简单——难的不是敲几条 Docker 命令而是搞清楚 hbbs、hbbr 这两个服务各自干什么、端口怎么放、密钥怎么配、客户端怎么指过去、以及出问题的时候从哪儿开始查。我会按我实际的部署顺序来讲中间穿插那些文档里不会写、但实际部署时一定会遇到的细节。适合谁看如果你已经用过 RustDesk觉得公共节点不够用想自己掌控一条稳定的中继链路那这篇就是给你写的。如果你连 RustDesk 都还没装过建议先去官网下个客户端连一次感受一下基本流程再回来。另外这篇会涉及 Docker、Docker Compose、防火墙、端口映射这些基础操作我会尽量把每一步的理由讲清楚但完全不熟悉 Linux 命令行的朋友可能需要边看边查。先说结论一套能用的自建中继核心就是两个服务加一个密钥hbbsID 注册服务器负责给每台客户端分配和登记 ID相当于通讯录。hbbr中继服务器当两端无法直连时数据从它这里转发相当于中转站。Key客户端和中继之间的身份凭证配错了就连不上这是新手最容易翻车的地方。下面我从服务器选型开始一步步往下走。2. 服务器选型与网络环境别一上来就买最便宜的2.1 中继节点对服务器的真实要求很多人一听说自建服务器就紧张觉得要买很贵的机器。实际上 RustDesk 中继对硬件的要求低得离谱。我实测下来一台 1 核 1G 内存的入门级云主机同时承载十几路中继连接毫无压力CPU 占用长期在 5% 以下内存也就吃个一两百兆。真正决定体验的不是 CPU 和内存而是带宽和线路质量。这里有个关键点要理解中继服务器转发的是实时画面数据它对延迟和上行带宽极其敏感对下行带宽反而没那么在意。因为数据流是双向的服务器既要收又要发所以上行带宽才是瓶颈。我第一台机器买的是某厂商的1M 带宽套餐结果一开中继画面直接卡成 PPT——1M 上行大概只能撑一路 720p 的低码率画面多开几路就爆了。我的建议是使用场景推荐配置带宽要求说明个人自用1-2 台设备1 核 1G3-5M 上行入门云主机足够小团队5-10 台设备2 核 2G10M 上行建议选按流量计费或大带宽套餐多设备高频使用2 核 4G20M 以上优先考虑线路质量而非配置提示带宽这个参数一定要看清楚是上行还是下行。很多云厂商宣传的100M 带宽其实是下行上行可能只有几兆。买之前务必确认上行带宽这是中继体验的命门。2.2 线路选择为什么我最后选了离自己近的机房线路这件事比配置重要得多。我一开始图便宜买了台海外机器延迟 200ms 起步中继转发之后画面延迟直接翻倍操作起来像在玩幻灯片。后来换成国内同城机房延迟降到 20ms 以内体验立刻不一样了。选线路的逻辑很简单中继服务器要尽量靠近你的主要使用设备。如果你主要在家里和公司之间远控那就选一个离这两地都近的机房。如果你经常跨地区使用那就选一个网络枢纽城市比如华东、华南的核心节点。还有一个容易被忽略的点云厂商的线路质量差异巨大。同样是华东节点有的走的是优质骨干网晚高峰依然稳定有的走的是廉价线路一到晚上就丢包。这个没法从参数上看出来只能靠实测。我的做法是先买一个月付的机器用ping和mtr测一下到各个目标地的延迟和丢包满意了再续费长期。# 测试到中继服务器的延迟和丢包 ping -c 100 your-server-ip # 查看路由每一跳的情况定位丢包发生在哪一段 mtr --report --report-cycles 100 your-server-ipmtr这个工具特别有用它能告诉你丢包是发生在你的本地网络、运营商骨干、还是机房入口。如果丢包集中在最后几跳那基本就是机房的问题换机器如果分散在中间可能是运营商互联的问题换线路。2.3 系统选择与基础环境准备操作系统我推荐 Ubuntu 22.04 LTS 或者 Debian 12这两个是我实测最省心的。CentOS 7 虽然还能用但已经停止维护新机器不建议再上。系统装好之后第一件事是更新软件源并装好基础工具# 更新系统 apt update apt upgrade -y # 安装常用工具 apt install -y curl wget vim ufw net-tools然后是时间同步这个很多人会忽略但时间不同步会导致 TLS 握手失败、日志时间错乱排查问题时非常痛苦# 确认时间同步服务正常运行 timedatectl status # 如果没开手动开启 timedatectl set-ntp true接着处理防火墙。RustDesk 中继需要放行这几个端口我先把它们列清楚后面配置的时候会反复用到21114/tcpWeb 控制台如果部署了 API 服务21115/tcphbbs 的 NAT 类型测试21116/tcp udphbbs 的 ID 注册与心跳UDP 尤其重要21117/tcphbbr 的中继转发21118/tcphbbs 的 WebSocket用于网页客户端21119/tcphbbr 的 WebSocket用 ufw 放行的命令ufw allow 21114/tcp ufw allow 21115/tcp ufw allow 21116/tcp ufw allow 21116/udp ufw allow 21117/tcp ufw allow 21118/tcp ufw allow 21119/tcp ufw enable注意21116 的 UDP 端口是重灾区。很多人只放行了 TCP结果客户端能注册 ID 但连不上排查半天才发现是 UDP 被挡了。如果你用的是云厂商的安全组记得在安全组里也要放行一遍两层防火墙都要过。3. 用 Docker Compose 把 hbbs 和 hbbr 一次拉起来3.1 为什么我坚持用 Docker 而不是直接装二进制RustDesk 官方提供了两种部署方式直接下载二进制运行或者用 Docker。我两种都试过最后长期用 Docker原因有三个。第一是依赖隔离。hbbs 和 hbbr 是静态编译的 Go 程序理论上直接跑也没问题但一旦系统库版本有差异就可能出现莫名其妙的报错。Docker 把这些不确定性都封在容器里换台机器照样跑。第二是升级方便。RustDesk 更新挺频繁的用 Docker 升级就是改一下镜像 tag 然后docker compose up -d几秒钟的事。直接装二进制的话得先停服务、备份数据、替换文件、再启动步骤多还容易出错。第三是配置清晰。用docker-compose.yml把端口、卷、环境变量都写在一起换机器的时候整个文件拷过去就行不用回忆当初敲了哪些命令。当然 Docker 也有代价就是多了一层网络抽象出问题的时候排查链路会长一点。但总体来说对自建中继这种部署一次、长期运行的场景Docker 的收益远大于成本。3.2 安装 Docker 与 Docker Compose如果你机器上还没装 Docker用官方脚本装最省事# 安装 Docker curl -fsSL https://get.docker.com | sh # 启动并设置开机自启 systemctl enable docker systemctl start docker # 验证安装 docker versionDocker Compose 现在一般是 Docker 的插件形式装完 Docker 之后确认一下docker compose version如果提示找不到命令单独装一下 Compose 插件apt install -y docker-compose-plugin提示国内机器拉取 Docker 镜像可能会很慢甚至超时。如果你遇到docker pull卡住的情况可以配置镜像加速器。具体方法是在/etc/docker/daemon.json里加上 registry-mirrors 配置然后重启 Docker。这个配置因网络环境而异建议根据自己的实际情况选择合适的加速源。3.3 编写 docker-compose.yml每个参数都要知道为什么这是整套部署的核心文件。我先把完整的配置贴出来然后逐段解释。version: 3 networks: rustdesk-net: driver: bridge services: hbbs: container_name: hbbs image: rustdesk/rustdesk-server:latest command: hbbs -r your-server-ip:21117 -k _ volumes: - ./data:/root network_mode: host depends_on: - hbbr restart: unless-stopped hbbr: container_name: hbbr image: rustdesk/rustdesk-server:latest command: hbbr -k _ volumes: - ./data:/root network_mode: host restart: unless-stopped几个关键点必须讲清楚command: hbbs -r your-server-ip:21117 -k _这一行是灵魂。-r参数告诉 hbbs中继服务器的地址是什么客户端注册之后会拿到这个地址去连 hbbr。这里的 IP 必须填你服务器的公网 IP不能填内网 IP 或者 127.0.0.1否则客户端拿到地址之后根本连不上。-k _表示启用密钥认证密钥会自动生成。network_mode: host这个设置很关键。RustDesk 的中继服务对 UDP 端口依赖很重如果用 Docker 默认的 bridge 网络UDP 端口映射经常出问题导致客户端能注册但连不上。用 host 模式让容器直接使用宿主机网络省去端口映射的麻烦稳定性最好。volumes: - ./data:/root把数据目录挂载出来密钥文件、数据库都存在这里。这样容器删了重建密钥还在客户端不用重新配置。这个目录一定要备份丢了的话所有客户端都得重新配。-k _这个参数我单独说一下。它表示使用自动生成的密钥。第一次启动时hbbs 会在 data 目录下生成一对密钥文件id_ed25519和id_ed25519.pub。客户端配置时需要填公钥的内容。如果你不想用自动生成的也可以自己指定一个固定的 key但自动生成更省事也更安全。3.4 启动服务并验证运行状态配置写好之后在同一个目录下执行docker compose up -d然后看日志确认服务正常docker compose logs -f hbbs docker compose logs -f hbbr正常的日志里应该能看到类似Listening on 0.0.0.0:21116这样的信息。如果看到报错多半是端口被占用或者权限问题。验证端口是否真的在监听ss -tulnp | grep -E 21115|21116|21117你应该能看到 hbbs 监听 21115、21116hbbr 监听 21117。如果某个端口没出现回去检查防火墙和容器日志。最后把生成的公钥读出来客户端配置要用cat ./data/id_ed25519.pub这串字符就是你的 Key复制下来后面客户端配置会用到。注意如果你在docker-compose.yml里用了-k _但发现 data 目录下没有生成密钥文件检查一下目录权限。容器里的进程可能没有写权限导致密钥生成失败。可以手动chmod 755 ./data再重启容器。4. 客户端配置Key 填错是 90% 连不上的原因4.1 客户端到底要填哪几个字段服务端跑起来只是第一步客户端配置才是真正决定能不能用的环节。RustDesk 客户端的配置入口在设置 - 网络里需要填三个东西ID 服务器填your-server-ip:21116注意这里不带协议头直接 IP 加端口。中继服务器填your-server-ip:21117如果留空客户端会默认用 ID 服务器同 IP 的 21117 端口。Key填刚才cat出来的那串公钥内容。我见过太多人卡在这一步问题基本集中在两个地方一是 IP 填成了内网地址二是 Key 复制的时候多了空格或者换行。Key 是一串 Base64 编码的字符复制的时候一定要确保首尾没有多余空白。4.2 一个容易被忽略的细节客户端版本要匹配RustDesk 的服务端和客户端版本如果差太多可能会出现协议不兼容的情况。我遇到过服务端是最新版、客户端是半年前的老版本结果客户端能注册 ID 但一直连不上中继。后来把客户端升级到和服务端相近的版本问题立刻消失。所以部署完服务端之后建议把所有客户端也更新到较新的版本。RustDesk 的更新频率挺高新版本通常会修复一些连接稳定性问题值得跟进。4.3 验证连接是否真的走了自建中继配置完之后怎么确认流量真的走了自己的服务器而不是还在用公共节点有几个办法第一看服务端日志。客户端连接时hbbs 和 hbbr 的日志里会有对应的连接记录。如果日志里能看到你客户端的 ID 和连接信息说明走的是自建节点。第二看客户端的连接状态。在 RustDesk 主界面连接成功后鼠标悬停在连接信息上会显示当前是直连还是中继。如果显示中继并且你配置了自建服务器那基本就是走自己的了。第三最直接的办法把服务端停掉看客户端还能不能连。如果停了服务端就连不上说明确实依赖自建节点。提示RustDesk 会优先尝试 P2P 直连直连成功的话是不走中继的。所以有时候你看到延迟很低可能不是中继的功劳而是直连成功了。想强制测试中继可以在客户端设置里关闭允许直连选项。5. 部署后必做的几件事安全、备份与监控5.1 密钥管理丢了它等于重来自建中继最核心的资产就是那对密钥。id_ed25519是私钥id_ed25519.pub是公钥。私钥绝对不能泄露公钥要分发给所有客户端。我的做法是把./data目录定期备份到另一个地方至少保留两份。备份的时候注意私钥文件权限应该是 600只有属主可读。如果权限太开放某些系统会拒绝加载。# 检查密钥文件权限 ls -l ./data/id_ed25519* # 如果权限不对修正 chmod 600 ./data/id_ed25519 chmod 644 ./data/id_ed25519.pub5.2 用 systemd 或 Docker 的重启策略保证服务常驻Docker Compose 里我已经写了restart: unless-stopped这能保证容器异常退出后自动重启。但还有一种情况宿主机重启后Docker 服务本身如果没设置开机自启容器也不会起来。所以前面装 Docker 时那步systemctl enable docker很重要别漏了。如果你想要更细粒度的控制可以写一个 systemd unit 来管理 compose 的启停但对大多数场景来说Docker 自带的重启策略已经够用。5.3 简单的可用性监控中继服务平时很安静出问题的时候往往是你急着用的时候才发现。我建议加一个最简单的监控定时检查端口是否在监听不在就发个通知。#!/bin/bash # check_rustdesk.sh if ! ss -tuln | grep -q :21116; then echo RustDesk hbbs 端口异常 | mail -s 告警 your-emailexample.com fi配合 crontab 每五分钟跑一次*/5 * * * * /path/to/check_rustdesk.sh这个脚本很粗糙但能覆盖大部分服务挂了的场景。如果你有更完善的监控体系把端口检测接进去就行。6. 踩过的坑从连不上到连上但卡我遇到的四类问题6.1 客户端一直显示正在连接却连不上这是最典型的问题原因通常有三个。第一是 Key 填错第二是 21116 的 UDP 没放行第三是-r参数里的 IP 填成了内网地址。排查顺序我建议这样先确认 Key 有没有多余空格再ss -tulnp看 UDP 端口在不在最后检查docker-compose.yml里的-r参数。这三个都对了基本就能连上。6.2 能连上但画面卡顿严重如果连接建立成功但画面很卡八成是带宽问题。先用mtr看延迟和丢包如果延迟正常但带宽跑满那就是上行不够。这时候要么升级带宽要么降低客户端的画质设置。RustDesk 客户端里可以调画质和帧率把画质从高质量降到平衡帧率从 60 降到 30带宽占用能降一半以上。对于文字办公场景这个画质完全够用。6.3 服务运行一段时间后自动停止我遇到过 hbbs 跑几天就挂掉的情况查日志发现是内存溢出。后来发现是某个旧版本的 bug升级到最新镜像之后就再没出现过。所以保持镜像更新很重要RustDesk 的迭代速度不慢很多稳定性问题都是在新版本里修的。升级方法很简单docker compose pull docker compose up -d数据在挂载的 volume 里升级不会丢。6.4 多台客户端之间互相连不上这种情况通常是 ID 注册出了问题。检查 hbbs 日志看客户端有没有成功注册 ID。如果注册失败可能是 21116 端口不通或者客户端配置的 ID 服务器地址不对。还有一个隐蔽的原因如果两台客户端在同一个局域网里它们可能尝试用内网地址直连而内网地址在跨网段时是不通的。这时候需要在客户端设置里关闭允许直连强制走中继。7. 关于性能调优和长期维护的几点个人经验部署完成只是开始长期稳定运行还需要一些维护习惯。我自己的做法是每个月花十分钟做几件事检查镜像有没有更新、看一眼服务日志有没有异常报错、确认备份的密钥文件还在。性能调优方面RustDesk 本身可调的参数不多主要优化空间在服务端和网络层。如果你的服务器带宽充足但延迟偏高可以考虑开启系统的 TCP BBR 拥塞控制算法对实时数据传输有一定帮助# 开启 BBR echo net.core.default_qdiscfq /etc/sysctl.conf echo net.ipv4.tcp_congestion_controlbbr /etc/sysctl.conf sysctl -p # 验证是否生效 sysctl net.ipv4.tcp_congestion_control另外如果你的使用场景是固定的几台设备可以考虑在客户端之间建立更直接的连接方式减少对中继的依赖。RustDesk 的直连能力其实不错很多时候中继只是兜底。最后说一个心态上的经验自建中继这件事第一次部署可能会花几个小时甚至一两天但一旦跑通后面就是设置好就不用管的状态。我现在的这套节点已经稳定运行了大半年中间只升级过两次镜像其他时间完全不用操心。相比公共节点时不时抽风这点前期投入非常值得。如果你在部署过程中遇到这篇没覆盖到的问题建议先去翻服务端日志RustDesk 的日志信息其实挺详细的大部分错误都能从日志里找到线索。实在搞不定把日志里的关键报错拿去搜基本都能找到答案。
返回列表