自建RustDesk中继服务器：部署hbbs/hbbr实现公网远控内网机器

1. 为什么要自建RustDesk中继服务器老实说远程控制工具我几乎没有断过TeamViewer、AnyDesk、向日葵、ToDesk挨个换过。免费版有限制、商用授权贵得离谱最要命的还是连接质量——你根本说不清那一段到底走的是哪条链路。圈内朋友推荐了RustDesk我一开始只当普通远控软件用用着用着就冒出一个念头既然它是开源的能不能把服务端也完全掌握在自己手里把ID注册和中继转发都换成自己的节点于是就有了这篇文章。我接下来的操作完全围绕“RustDesk搭建公网中继服务器远控内网机器”这个目标展开。说白了就是准备一台带公网IP的云服务器在上面部署RustDesk服务端两个核心组件ID注册服务hbbs和中继转发服务hbbr。部署完成后位于家庭宽带、办公局域网等NAT后面的电脑即使没有任何公网IP也能被另一台在任意地点的电脑通过RustDesk远程控制。整个过程不依赖RustDesk官方的公共节点数据流向完全由自己掌控。这篇文章适合谁看一类是刚接触自建服务、想少走弯路的运维新人一类是长期远程办公、对延迟和隐私比较敏感的用户还有一类就是喜欢在NAS和云主机上折腾各种服务的玩家。我会尽量把每一步讲透把参数写全哪怕你对RustDesk一点都不熟照着做也能跑起来。1.1 官方公共节点有哪些让人不放心的点先聊为什么很多人最终会走到自建这条路。RustDesk官方提供的服务器确实开箱即用但你实际用上一段时间会发现两个绕不开的问题。第一是稳定性。官方公共服务器分布在全球各地国内用户访问海外节点时延迟和丢包往往很大。如果家里或公司网络本身不稳定远控画面基本就在幻灯片和延迟之间反复横跳鼠标点一下要隔半秒才有反应。特别是你想通过远控去修复另一台电脑的系统故障时这种不稳定就是灾难。第二是隐私和数据流向。虽然RustDesk本身是开源的但使用官方服务器时设备ID、注册信息、连接元数据包括一部分转发数据终究要经过别人的基础设施。对于处理公司内网数据、或者单纯不想让痕迹留在第三方服务器上的用户来说这个选项本身就让人不舒服。自建中继服务器可以把这些环节统统收回到自己的设备里服务器上跑什么组件、留什么日志都是自己说了算。1.2 自建之后的收益到底值在哪自建RustDesk中继服务器的收益总结起来是四个字可控、可预期。我实测下来的感受是这样的维度使用官方节点自建中继延迟视节点到客户端路由而定波动较大部署在就近机房后明显更低波动可控稳定性受官方服务器负载影响流量只有自己用很少出现排队抖动数据流向经过官方服务器全部走自己的云服务器日志可控成本免费但功能受限商用需付费一台入门云主机即可支撑个人使用限制官方策略调整可能影响体验无官方策略限制连接数自己控制当然自建并不是没有代价。服务器要花钱部署和后续维护也要花时间。但对长期有远程需求的人来说投一台低配云主机换稳定的远控通道这笔账很划算。云主机上还可以顺带跑监控、跑脚本不浪费。1.3 先厘清一个概念中继服务器不只是转发标题里写的是“公网中继服务器”但实际要部署的是两个东西ID服务器和中继服务器。很多人配置时只盯着中继端口21117却漏掉了ID注册、NAT穿透都依赖的hbbs。这个误解非常普遍我刚开始也犯过。所以接下来我会先拆解它们的职责说清楚一套完整的自建方案到底需要哪些组件。2. 理解RustDesk的“中继”到底是怎么工作的RustDesk远控的核心不是“把机器A的屏幕直接搬到机器B”而是先让双方都找到一个共同的“见面地点”然后协商出一条可用的通信路径。这个“见面地点”就是你的公网服务器。服务器能不能正常工作直接决定了内网机器能不能被发现、能不能连上也决定了连接是走P2P直连还是走中继转发。2.1 hbbs和hbbr各自扮演什么角色hbbs全称是RustDesk ID注册服务它负责两件事第一接收所有RustDesk客户端的注册请求记录每个客户端的ID、内网IP、外部IP、NAT类型这些元数据第二当两个客户端想建立连接时hbbs作为“通讯录”和“媒人”帮忙交换双方地址信息促成连接。hbbr才是真正负责数据转发的服务也就是标题里说的“中继服务器”。当双方无法通过P2P直接连通时远程控制的画面、键鼠指令、文件传输数据都会由hbbr作中间人转发。你可以把hbbs理解成前台接待负责登记和引路hbbr理解成专属飞线员专门负责在两端不通时把数据包倒腾过去。那为什么P2P不总是能通因为两台电脑通常都在NAT后面想直连必须“打洞”。打洞是否成功取决于双方NAT设备的类型。家用宽带大多数是锥形NAT打洞成功率很高但办公网、校园网、企业安全边界环境下经常出现对称NAT这种NAT几乎无法打洞。再加上部分地区运营商宽带不给公网IPv4是CGNAT那所有客户端的“外部IP”可能是同一个运营商网关地址打洞基本凉凉。遇到这些情况hbbr的中继转发是唯一兜底方案。2.2 端口用途和通信协议RustDesk服务端默认涉及下面几个端口先记住这张表后面配置防火墙和安全组全靠它端口协议服务用途21115TCPhbbsNAT类型探测21116TCPhbbsID注册、终端间信息交换21116UDPhbbsNAT穿透打洞的核心通道21117TCPhbbr中继转发数据的主通道21118TCPhbbsWeb客户端HTTP访问可选21119TCPhbbrWeb客户端HTTPS访问可选重点关注21116的UDP。很多第一次搭的人只开了TCP端口结果客户端能看到服务器但无论如何都注册不上一查才发现UDP被防火墙拦截了。RustDesk的打洞和注册都依赖UDP 21116这个口子不开ID显现不出来后面的一切都免谈。2.3 一次远程连接的真实流程理解了端口之后我们再串一遍完整流程你就明白为什么公网中继服务器是整套方案的基石被控端内网机器启动RustDesk通过网络向hbbs发起注册上报自己的ID、当前公网IP端口以及NAT类型信息。控制端在任意地点打开RustDesk输入被控端ID同样先找hbbs查询这个ID当前在哪里。hbbs把双方的地址信息互换。如果双方满足打洞条件它们会尝试通过UDP 21116建立直连。一旦P2P建立成功画面就走P2P通道中继服务器基本不参与数据转发速度最快。如果打洞失败RustDesk自动切换到hbbr由hbbr通过TCP 21117接收一方数据、转发给另一方。这套流程里hbbs是“牵线”的hbbr是“兜底”的。哪怕P2P成功hbbs也全程参与了注册和查询所以单跑一个中继转发服务是没用的两个组件必须同时在线。2.4 服务器需要满足的条件硬件要求不高但也不是随便一台机器就行。我的建议配置CPU1核起步2核更稳。转发时涉及编解码压力不大但多路并发会有CPU消耗。内存1GB勉强能跑建议2GB以上避免高峰期内存吃紧。磁盘10GB足够日志和数据库都很小不用大硬盘。带宽上行至少10Mbps有条件上50Mbps或更高。中继模式下服务器要同时下载和上传带宽翻倍消耗所以带宽是最大瓶颈。系统Ubuntu 22.04 LTS或Debian 11/12老版本系统容易遇到依赖问题。公网IP必须有一份公网IPv4地址且不会被运营商NAT二次转换。域名非必须但强烈建议准备一个。用了域名之后以后服务器换IP客户端不用重新配置改一条DNS记录就行。如果被控端有几十台甚至上百台只要不是同时高码率转发4核8G的服务器也能扛住。个人使用场景入门款云主机完全够用。3. 服务器端部署从零开始搭中继服务接下来是重头戏在服务器上把hbbs和hbbr跑起来。我已经在Ubuntu 22.04上验证过下面的步骤Debian系其他版本同样适用。3.1 部署方式怎么选Docker还是二进制RustDesk服务器官方提供两种主流方式Docker镜像和纯二进制文件。Docker方式最省心镜像开箱即用升级时拉新镜像重建容器即可数据目录挂载在宿主机上方便备份。唯一需要注意的是RustDesk服务端包含UDP端口用Docker时最好采用host网络模式否则端口映射容易踩坑。二进制方式适合喜欢完全掌控过程的同学直接把hbbs和hbbr做成systemd服务不依赖Docker环境。我个人推荐新手先用Docker跑通熟悉之后想拆成systemd再折腾也不迟。3.2 Docker方式两条命令跑起来首先登录服务器创建工作目录mkdir -p /opt/rustdesk cd /opt/rustdesk拉取官方镜像docker pull rustdesk/rustdesk-server:latest启动hbbs和hbbr。假设你的服务器IP是123.45.67.89域名是relay.example.com命令如下docker run -d --name hbbs --nethost --restartalways \ -v /opt/rustdesk/data:/data \ rustdesk/rustdesk-server:latest \ hbbs -r relay.example.com -h relay.example.com docker run -d --name hbbr --nethost --restartalways \ -v /opt/rustdesk/data:/data \ rustdesk/rustdesk-server:latest \ hbbr解释一下关键参数--nethost让容器直接使用宿主机网络避免Docker端口映射搞不清UDP通道。使用host模式后容器不再需要-p参数暴露端口。-v /opt/rustdesk/data:/data把容器内的数据目录挂载到宿主机密钥、数据库、日志都保存在这里。-r relay.example.com告诉hbbs中继服务器的地址是哪个。客户端在查询时会收到这个地址后面填写中继服务器也要用它。-h relay.example.com固定hbbs自身对外的主机名。如果不指定部分场景下服务器会拿不到正确的自身地址。--restartalways服务器重启后容器自动拉起省得手动处理。如果暂时没有域名直接用IP也行docker run -d --name hbbs --nethost --restartalways \ -v /opt/rustdesk/data:/data \ rustdesk/rustdesk-server:latest \ hbbs -r 123.45.67.89启动后确认容器状态docker ps看到hbbs和hbbr两个容器都是Up状态就成功了一半。接下来查看生成的公钥这是客户端必填的关键信息。3.3 二进制方式适合喜欢完全控制的同学不喜欢Docker也没关系用二进制文件部署其实也就几步。先下载最新版RustDesk服务器cd /opt wget https://github.com/rustdesk/rustdesk-server/releases/download/1.1.9/rustdesk-server-linux-amd64.zip unzip rustdesk-server-linux-amd64.zip cd rustdesk-server-linux-amd64 chmod x hbbs hbbr前台跑一下确认能正常启动./hbbs -r relay.example.com ./hbbr 正式使用时建议把这两个进程交给systemd管理。新建两个服务文件。先创建/etc/systemd/system/hbbs.service[Unit] DescriptionRustDesk ID Server Afternetwork.target [Service] ExecStart/opt/rustdesk-server-linux-amd64/hbbs -r relay.example.com WorkingDirectory/opt/rustdesk-server-linux-amd64 Restartalways RestartSec3 LimitNOFILE65535 [Install] WantedBymulti-user.target再创建/etc/systemd/system/hbbr.service[Unit] DescriptionRustDesk Relay Server Afternetwork.target [Service] ExecStart/opt/rustdesk-server-linux-amd64/hbbr WorkingDirectory/opt/rustdesk-server-linux-amd64 Restartalways RestartSec3 LimitNOFILE65535 [Install] WantedBymulti-user.target启用并启动systemctl daemon-reload systemctl enable hbbs hbbr systemctl start hbbs hbbr systemctl status hbbs hbbr注意LimitNOFILE65535这一行。默认的文件描述符限制可能只有1024如果同时接入的RustDesk客户端较多很容易出现连接数不足。加上65535可以避免大量连接时报错。3.4 防火墙放行与云安全组配置部署完成只是第一步如果防火墙没放行外面的人根本摸不到你的服务。先确认系统防火墙Ubuntu默认装了ufw执行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 reload如果你用的是云服务器还得去云厂商控制台的安全组/防火墙规则里同步放行。这一步特别容易漏你在服务器里配好ufw结果云控制台的安全组没放行外面照样连不上。安全组规则建议按端口放开端口范围协议来源说明21115-21119TCP0.0.0.0/0RustDesk主通信端口21116UDP0.0.0.0/0NAT穿透注册通道放行的时候别图省事只要TCPUDP 21116必须一起开。3.5 密钥管理要分发给客户端的公钥RustDesk服务端首次启动会自动生成一对加密用的密钥。用Docker方式部署时文件保存在数据目录用二进制方式则生成在运行目录。查看公钥cat /opt/rustdesk/data/id_ed25519.pub或者cat /opt/rustdesk-server-linux-amd64/id_ed25519.pub输出是一串字符类似xxxxxxx。这串内容后面要填到每个RustDesk客户端的“密钥”字段里。这是安全防线也是身份验证。它能防止陌生客户端接入你的ID服务器和中继。如果公钥没填对客户端会提示密钥不匹配连接直接被拒绝。这里有个容易被忽略的细节公钥要保密但更要妥善保存。服务器如果重装系统数据目录没备份原来的密钥就没了所有客户端都得重新配置。我建议把data目录整个打包压缩存一份到对象存储或本机备份。4. 远控内网机器客户端配置全流程服务器端跑起来之后剩下的重点就是让内网机器和控制端都指向你的自建服务器。这里的客户端不仅指Windows也包括Linux、macOS、Android、iOS配置逻辑完全一致只是界面入口略有差别。4.1 RustDesk客户端基本信息录入在Windows上打开RustDesk点击左下角菜单进入“设置”→“网络”你会看到几个关键字段ID服务器填写你的hbbs地址域名或IP都可以。中继服务器填写你的hbbr地址也就是启动hbbs时-r指定的那个地址。密钥粘贴上一节查看的id_ed25519.pub文件内容。三个字段填完点击“应用”或“确定”。注意不要只填ID服务器中继服务器也要填否则部分场景下客户端可能拿不到中继信息。填完之后客户端界面上的ID应该会正常显示底部状态从“连接中”变成“就绪”或“在线”。有一个常见误解是“ID服务器和中继服务器必须填同一个地址”。实际上它们确实通常配置成同一个域名或IP但原理不一样。填同一个域名时hbbs负责注册hbbr负责转发两个服务都在同一台服务器上监听不同端口。用域名是为了客户端配置简单用IP则要注意IP变化时全部重新配置。4.2 内网先用本机地址验证服务端正式远程之前我强烈建议你先在局域网内做一次验证把服务器端问题排除掉。操作很简单在内网的另一台电脑上装好RustDesk同样填入服务器的域名和公钥。然后打开控制端RustDesk输入被控端的ID尝试连接。如果一切正常说明服务端配置、密钥、防火墙都通了。这次验证为什么要做因为如果直接在公网测试失败你很难判断问题出在哪一环。局域网验证若成功剩下的就只是路由器NAT穿透和公网链路问题。若局域网就失败多半是服务器配置或防火墙问题排查范围能缩小很多。4.3 从公网控制内网机器的完整验证局域网验证通过后把控制端拿到公网环境比如手机开热点、公司网络再次尝试连接。连接时输入被控端ID然后输入无人值守连接密码。RustDesk支持为主机设置访问密码这样即使没有人在被控端点同意你也可以通过ID加密码直接远程登录。这一步是远程维护的核心一定要设置。成功后RustDesk窗口顶部会显示连接状态。如果走的是中继你会在hbbr日志里看到连接记录如果走了P2P直连日志里看不到转发流量。用下面命令实时看docker logs -f hbbr如果看到大量数据进出日志说明中继转发正常。整个过程不需要对路由器做任何端口映射因为被控端的出方向连接是由它主动发起的RustDesk只在系统层面处理。4.4 多台机器批量接入的经验如果你要管理多台内网机器没必要每台都手动填三次信息。RustDesk客户端配置可以复制Windows系统下配置文件通常存放在C:\ProgramData\RustDesk\configLinux系统下在/etc/rustdesk或~/.config/rustdesk。最简单的方法在一台机器上配置好把整个配置目录原封不动复制到其他机器。不过机器ID是每台唯一的你只需要保留服务器配置部分ID相关的数据库文件不要乱复制否则会出现两台机器ID冲突的诡异问题。更规范的做法是通过RustDesk提供的命令行参数批量设置。在企业镜像部署时可以通过登录注册表或配置文件统一写入ID服务器、中继服务器和公钥让员工拿到机器就能直接连。这属于进阶用法我后面再单独写一篇细说。5. 公网链路优化与安全加固服务搭好、客户端能连之后接下来考虑的是怎么让链路更稳、更安全。RustDesk默认配置能跑但离“生产可用”还有一段距离。5.1 用域名替代IP一劳永逸我在前面已经反复强调域名的重要性这里再展开讲一次。用IP做服务器地址的问题非常直观云服务器到期重买、机房迁移、临时换IP都会导致所有客户端失效。而用域名的话只需要修改DNS解析记录客户端什么都不用动。配置域名有几个注意点在域名服务商处添加A记录把relay.example.com解析到服务器IP。hbbs启动时-r参数填域名客户端中继服务器也填域名。解析TTL设置短一点比如600秒这样以后换IP时生效更快。用域名还有一个好处可以被后续的Web客户端功能复用。RustDesk Web客户端需要通过域名来生成合法的访问地址纯IP虽然也能用但HTTPS证书的适配会更麻烦。5.2 需要HTTPS和Web客户端时怎么办RustDesk除了原生客户端还支持通过浏览器远控。如果你要用Web客户端需要在服务器数据目录里配置HTTPS证书并保证21118和21119端口对外开放。证书可以用域名服务商提供的免费SSL证书也可以使用Let‘s Encrypt。RustDesk Web客户端的实际体验比原生客户端稍弱但胜在零安装。临时从一台没装软件的电脑上应急控制内网机器会非常有用。在我的使用场景里Web客户端主要是“救急”用的日常操作还是靠原生客户端。5.3 日志目击与版本升级备份服务跑长了日志和密钥文件的维护会变得很重要。Docker部署时日志可以通过容器查看docker logs --tail 50 hbbs docker logs --tail 50 hbbr如果日志疯狂刷屏先确认是不是有陌生客户端在尝试接入。如果发现大量来源IP的连接尝试说明你的服务被公网扫描器盯上了。解决方案是确认公钥配置正确保证没有使用-k _这种禁用加密的测试参数。升级RustDesk服务端时先备份数据目录再拉新镜像重建容器cp -r /opt/rustdesk/data /opt/rustdesk/data.bak docker stop hbbs hbbr docker rm hbbs hbbr docker pull rustdesk/rustdesk-server:latest # 重新执行docker run命令升级完成后重启容器确认密钥文件还在。如果密钥文件因为挂载路径配置错误而丢失客户端全部失联就只能重新分发公钥了。备份这个动作值得养成习惯。5.4 服务器系统级参数优化最后是系统层面的小优化。RustDesk中继转发涉及大量并发连接调整一下文件描述符限制和网络参数很有价值。在/etc/sysctl.conf加一条net.core.somaxconn 1024执行sysctl -p生效。前面systemd配置里的LimitNOFILE65535同样重要特别是机器上同时有几十台设备连接时不然会出现“Too many open files”报错。如果是云服务器带宽和CPU是最核心的瓶颈。中继模式下服务器上传下行各一遍10Mbps小水管带宽下实际远控体验会比较勉强画面质量需要压低。有条件的话把带宽升到50Mbps以上基本就能流畅传输1080P画面了。6. 常见问题与排查技巧实录到最后这一节把我在实际操作中踩过的一些坑拿出来复盘。这些问题在官方文档里不容易找到答案但对第一次搭建的人来说每一个都可能成为劝退坑。6.1 客户端连不上ID服务器ID一直为空这是最普遍的问题。症状是RustDesk界面上ID一直不显示或者显示connecting就断掉。排查顺序按下面来第一确认服务器进程在跑docker ps第二确认21116的UDP端口真的在监听ss -ulpn | grep 21116第三确认云安全组和ufw都放行了UDP 21116。这一步最坑云控制台的安全组规则有时候更新不及时或者你只在ufw放行却漏了云控制台。用下面的命令在客户端侧测试端口是否可达nc -uvz 你的服务器IP 21116如果结果不是Connected那就是UDP通道没开重点查防火墙。还有一个隐藏原因很多云厂商控制台安全组的来源IP默认是0.0.0.0/0但有的会限制成我的IP。改成0.0.0.0/0建议确认清楚。6.2 能注册但打洞失败、画面卡顿连接能建立但画面频繁卡顿、马赛克严重甚至操作有明显的键盘延迟这就要看连接是P2P还是中继。在RustDesk连接窗口打开连接信息面板如果显示Relay说明当前走的是hbbr中继。中继模式下视频流要经过服务器转发延迟肯定比P2P高但也不至于卡得像PPT。如果卡顿明显先看服务器带宽是不是被打满了iftop或者ethtool 网卡名服务器带宽满了最简单的方案是降低被控端RustDesk的编码码率。在客户端“设置”→“显示”里把画质从“高清”调整到“流畅”优先保证操作响应。另外中继模式下延迟还受物理距离影响。如果控制端在华东、服务器在海外链路长、国际出口不稳定那种卡顿几乎是物理决定的。建议服务器位置选在客户端主要分布的区域这就是我说选择机房要看“被控端加上控制端的综合地理位置”的原因。6.3 强制走中继避免P2P反复穿透失败有些网络环境下P2P穿透不仅不成功还反复拖慢连接建立过程。这种情况下可以强制RustDesk关闭P2P直接使用中继。在客户端“设置”→“安全”或“网络”中取消“允许P2P直连”的勾选连接就会始终走hbbr中继。有人可能会问走了中继不是更慢吗严格来说如果P2P能通P2P当然更快。但在一些对称NAT、CGNAT环境里P2P尝试会消耗好几秒失败后还要回退到中继反而把整体体验搞得更糟。强制中继减少了反复协商的过程至少稳定可靠。我的建议是先保留P2P默认开启正常家用网络环境多数能打洞成功如果某台机器频繁出现连接慢或闪断再对它单独配置强制中继。6.4 密钥和版本兼容性相关的坑RustDesk客户端和服务端版本最好保持同步。旧版客户端连接新版服务端时偶尔会出现密钥不匹配、加密协商失败的问题。我遇到过客户端版本太老、服务端已经升级到新算法的情况最终统一更新客户端版本解决。公钥配置问题时先确认你粘贴的内容是不是服务器上真的id_ed25519.pub文件里的内容。有些人为了省事把网络教程里的示例公钥填了进去结果自然是连不上。还有一个细节公钥文件末尾可能带换行符粘贴时最好用十六进制编辑器或无格式编辑器确认别粘贴到结尾多带一个空格。最后提醒一件事如果服务器重装过系统data目录里的密钥没有备份那你必须重新导出公钥并去每一台客户端更新密钥。这件事非常痛苦我经历过一次从那之后每次服务器升级都先备份/opt/rustdesk/data。6.5 一套我自己的长期维护经验经过几次折腾我现在搭好的RustDesk中继服务器基本不用怎么管一个重要原因是把运维习惯固化下来了所有服务器配置都在Docker命令里数据卷单独挂载配置变更都做记录每周看一眼hbbr日志确认没有异常连接每月备份一次数据目录。做了这些之后远控反而成了我存在感最低的工具——这正是我希望它变成的样子。跟我一样受不了官方公共节点又觉得商业远控太贵的完全可以按这套流程把链路搭起来。整体投入就是一台低配云主机和半小时部署时间换来的却是理论上完全属于你自己的远控通道。真正用起来之后你会明白什么是“数据在自己手里的踏实感”。