1. 项目概述1.1 为什么我最终选择了自建RustDesk事情还得从一次出差说起。我在火车站接到同事急电说公司那台跑着生产数据库的Windows Server连不上了远程桌面一直转圈好几分钟都进不去桌面。当时用的恰恰是各家云服务商自带的Web远程终端和Windows自带的RDP结果一个卡死一个被网关拦在外面最后只能干瞪眼。回来后我认真复盘了一下发现所谓“稳定的远程桌面”其实是三件事的组合一是连接必须能穿透两层网络对方路由器NAT加上公司出口防火墙二是交互延迟不能高到让人抓狂三是软件不能被杀毒误报或者频繁提示过期。市面上几款主流的商业远程软件在我看来都各有各的别扭。而RustDesk这个开源项目我关注了很久它主打的就是可以在自己的服务器上部署完整的远程控制方案服务端、客户端、中继转发全部自持数据不经过第三方。最打动我的一点是它的带宽开销比其他同类工具低不少据官方说明和网友实测在相同分辨率下RustDesk比TightVNC这类老牌工具省流量而且延迟表现更接近原生RDP。一句话概括就是RustDesk可以让我用自己的机器搭一套“类向日葵/Todesk”的远程控制平台客户端全部由我们自己人使用服务器上跑的每一行数据都是我自己的。如果你也厌倦了公共服务器排队、连接老是掉线、有时候还要看人脸识别安全验证又不想花高价买企业版授权那么自建RustDesk就是这个场景下的最优解。1.2 这个标题背后隐藏的完整需求很多人看到“自建RustDesk远程桌面服务”这个标题第一反应是不就是装个服务端吗其实这里面的坑深得很。我拆解下来它至少包含了四个层面的需求。第一层也是最直接的自建服务端让远程桌面连接不再依赖官方公共服务器解决连不上、连得慢、高峰期排队的问题。第二层内网穿透。如果你人在外面要连回办公室或家里的电脑光有RustDesk服务端还不行你得想办法让双方都能找到服务器而这个服务器可能是在家里NAS上、在云主机上、甚至在公司内网里这就涉及端口映射、公网IP、IPv6选型、甚至反向代理这些基础网络问题。第三层客户端批量管理。远程桌面不是一个人的事你要是负责给整个团队搭建这套服务就要解决配置怎么传给同事、对方打开软件就能自动连到你的服务器、怎么防止别人乱连的问题。第四层安全策略。远程桌面是把你的屏幕和鼠标键盘交到别人手上服务端本身的权限控制、防火墙策略、密钥校验一个都不能省。所以我这篇文章计划按照“为什么自建——服务端部署——网络打通——客户端配置——安全加固——问题排查”这条主线来讲争取覆盖从零到一的全过程。2. 方案选型与服务端架构2.1 自建远程桌面的几种路线对比先聊一下方案选型。自建远程桌面服务现在市面上主流的路子有这么几条RustDesk、Apache Guacamole、xrdp、VNC系TigerVNC、RealVNC、TurboVNC一大票、还有frp加Windows自带的RDP中转。VNC系是老前辈了跨平台能力强但默认协议是RFB带宽占用大、剪贴板双向同步做得比较糙而且公网裸奔基本属于找打。xrdp则是Linux下常用的RDP服务端但它是把RDP协议翻译给X Window用的偶尔有兼容性问题。Apache Guacamole更牛直接在浏览器里跑远程桌面但它依赖Tomcat和Guacamole服务端架构重、配置复杂普通用户用起来门槛太高。RustDesk之所以能在这些方案里杀出来核心优势我觉得有三点。第一是协议性能好。RustDesk用的加密视频流压缩效率比较高网络差的时候明显比VNC流畅第二是自带完整的“ID服务器中继服务器”架构不需要像“frpRDP”那样自己拼两个服务第三是服务端极其轻量官方提供了Docker镜像一个不到100MB的容器就能跑起来对NAS、小主机这些设备非常友好。我在自己的部署实践中分别试过云主机方案和家里的NAS方案。云主机方案优点是公网IP是固定静态IP不用折腾DDNS缺点是每月要交流量费不过RustDesk流量很小一个月的开销基本可以忽略。NAS方案优点是利用闲置设备零成本缺点是你家的上行带宽上限是硬伤而且运营商一般给的是动态公网IP或者干脆没有公网IPv4需要配合DDNS网络环节的坑会多一点。2.2 服务端两个核心组件hbbs与hbbrRustDesk服务端有两大组件这个必须搞明白不然后面排错无从下手。一个是hbbsID/注册服务器它的官方名叫RustDesk ID Server在官方文档里也叫ID/Relay Server中的ID部分。hbbs负责维护在线设备的ID注册表客户端上线后先跟hbbs报到告诉它“我是某某ID我当前在哪个IP哪个端口”。这样当你想连接那台机器时直接搜索这个IDhbbs就能把目标设备的当前网络地址告诉你。可以这么理解hbbs就相当于一个动态通讯录谁在哪里、端口是多少它门儿清。另一个是hbbr中继服务器。中继服务器负责数据转发。如果两台设备无法建立点对点直连比如双方都在复杂的对称NAT后面流量就会从hbbr这里走把画面和输入指令转发给双方。hbbr的带宽决定了你在低连通性条件下的体验上限。在Docker部署中这两个角色是放在同一个容器里的分别监听各自的端口对外暴露方式略有不同。我在部署时还会加一个可选的key参数用于生成加密公钥。这个公钥要记住后面客户端配置时会用到配了公钥之后服务端只接受持有对应私钥的RustDesk客户端连接没有这个公钥的客户端根本连不上你的服务端这算是一道很关键的访问控制门禁。2.3 我选择的部署形态与原因当前RustDesk服务端的部署形态主要有三种Docker容器、Linux系统原生安装、Windows服务器上手动跑进程。我先说结论如果你有条件跑Docker哪怕只是群晖NAS里的Container Manager我都建议优先Docker。原因很简单升级方便、卸载干净、环境隔离不用折腾依赖库。RustDesk官方镜像在Docker Hub上更新很勤后续升级一行命令搞定。至于Windows服务器上跑服务端我不是很推荐因为RustDesk官方并没有Windows服务端的原生安装包只能靠下载hbbs.exe和hbbr.exe这两个二进制文件然后用计划任务或者WinSW之类的工具把它注册成系统服务。我试过一次挂在计划任务下确实能跑但每次重启服务器都要保证计划任务正常触发而且Windows防火墙的入站规则还得自己手工配置排错起来绕来绕去体验确实一般。除非你只有一台Windows Server且实在不想装Docker否则不建议走这条路。所以我下面优先推荐两条路线一条是面向新手和NAS用户的Docker方式一条是面向Linux VPS的原生安装方式。3. 服务端部署实操3.1 基于Docker的快速部署先说我推荐的第一种方式用Docker跑服务端。第一步是准备工作。你需要一台Linux服务器、群晖NAS或者任何能跑Docker的设备需要一个稳定网络环境来拉取镜像然后需要把防火墙放行相关端口。这里的端口分配是RustDesk官方钦定的固定组合我已经整理成了表格方便你在防火墙和路由器端口转发时对照使用。端口协议用途21115TCPNAT类型检测21116TCP UDPID注册、心跳、P2P打洞21117TCP中继服务hbbr21118TCPWeb客户端访问可选21119TCPWeb客户端中继可选如果你是有一台Linux主机最简单的部署方式是用docker run指令一行命令就能把服务跑起来。官方镜像的用法大致是这样的docker run --name rustdesk-server -d --nethost \ --restartunless-stopped \ rustdesk/rustdesk-server:latest这里我用了--nethost意思是让容器直接共享宿主机的网络栈这样就不用手动做端口映射了RustDesk的5个监听端口会直接暴露在宿主机的IP上。用host网络的好处是省心坏处是安全性粒度粗了一点端口全部暴露在外网后面必须靠防火墙策略兜底。如果你用的是群晖NAS更推荐用docker-compose来定义服务和端口映射方便长期管理。我贴一份典型的compose配置你根据自己的实际情况调整路径和版本号version: 3 services: rustdesk-server: image: rustdesk/rustdesk-server:latest container_name: rustdesk-server restart: unless-stopped ports: - 21115:21115/tcp - 21116:21116/tcp - 21116:21116/udp - 21117:21117/tcp - 21118:21118/tcp volumes: - ./data:/data environment: - TZAsia/Shanghai与host网络模式不同这里我把端口显式映射到了宿主机。需要注意的是21116同时用TCP和UDP两个协议跑不同的数据流在Compose里必须分别用两行写出来否则UDP的心跳打洞功能会失效。这是我配置第N次时踩过的坑少写了UDP那一行导致客户端始终报“无法连接服务器”。等你看到容器日志里出现hbbs和hbbr都处于监听状态的输出后服务端就算起来了。接下来只需要给服务端配一个固定公网IP或者域名让客户端能顺利访问到它。3.2 基于Ubuntu的原生安装再说第二种原生安装。这种方式的适用场景是你没有Docker或者嫌弃Docker多包一层性能损耗又或者你所在的云镜像默认禁用了Docker服务。其实原生安装同样很轻量推荐在Ubuntu 22.04 LTS上验证。原生安装的办法有两种一种是直接吃官方预编译好的二进制另外一种是克隆源码自己编译。为了效率推荐用预编译二进制。具体操作是去RustDesk官方GitHub的Releases页面找到最新版本的rustdesk-server-linux-amd64压缩包然后解压把hbbs和hbbr这两个可执行文件放到/usr/local/bin里。接着创建一个服务目录比如/opt/rustdesk-server用systemd来守护这两个进程。我贴一个最简单的systemd服务配置思路。你可以为hbbs创建/etc/systemd/system/rustdesk-hbbs.service内容大致如下[Unit] DescriptionRustDesk ID Server (hbbs) Afternetwork.target [Service] Typesimple ExecStart/usr/local/bin/hbbs -r 你的公网IP或域名 -k _ WorkingDirectory/opt/rustdesk-server Restartalways RestartSec5 [Install] WantedBymulti-user.targethbbr的服务文件类似ExecStart改成/usr/local/bin/hbbr -k _即可因为hbbr是被hbbs调度的角色它自己不需要指定中继地址。-r参数告诉hbbs“当你告诉客户端中继服务在哪里时就报这个地址”这里必须填客户端反向能够访问到的地址通常就是你这台服务器的公网IP或者域名。-k _表示自动生成并保存密钥。如果-k后面跟一个具体字符串那就用这个固定字符串作为加密公钥反而不利于保密。都配置好以后执行以下命令启动sudo systemctl daemon-reload sudo systemctl enable rustdesk-hbbs rustdesk-hbbr sudo systemctl start rustdesk-hbbs rustdesk-hbbr最后千万不要忘记把11个端口映射到宿主机防火墙否则一切白搭。需要注意的是原生安装方式的公钥文件名为id_ed25519.pub位于工作目录下后续客户端配置要用到它。3.3 Windows下服务端不推荐但可行的方案虽然我前面说Windows上跑RustDesk服务端不算顺路但总有人只有一台Windows服务器不愿意装Docker Desktop我就顺手把这条路也讲清楚免得读者卡在这里。Windows方案的本质就是让hbbs.exe和hbbr.exe这两个Windows可执行文件在后台持续运行。你可以直接从官方Release页面下载Windows版本的压缩包解压到比如C:\rustdesk-server目录。然后在命令行里分别执行cd C:\rustdesk-server hbbs.exe -r your-public-ip hbbs.log 21 hbbr.exe hbbr.log 21这里的作用是把日志输出到文件方便排查。但这种方式挂在你当前的命令提示符窗口下窗口一关就停了。如果你想让它在系统后台稳定运行建议用NSSM这个工具把两个exe注册为Windows服务或者直接用Windows计划任务在系统启动时分别执行这两个命令。我自己的建议是如果在Windows上做实验拿来玩玩时可以这样跑但如果是公司正式环境强烈建议还是搞一台Linux小主机或直接用云服务器来跑稳定性完全不在一个量级。4. 客户端配置与网络打通4.1 客户端手动配置服务器地址服务端部署完接下来就是要让每台安装RustDesk客户端软件的机器“认”你的服务器。这一步如果不会服务端就只是个空壳。在Windows、macOS、Linux客户端上操作方式是类似的。打开RustDesk主界面在左边菜单找到“设置”局域网那边有个“ID/中继服务器”的二级选项在里面选择“ID/中继服务器”然后填入你服务器的地址。需要注意的是这里的地址格式要写成IP:21116因为RustDesk客户端默认会尝试连上21116端口做ID注册。如果只填IP不填端口某些老版本客户端会默认走80端口就会出现“网络异常”的假象。中继服务器那个框同样填同一个IP或域名不过不用填端口客户端会自动用默认端口连。填好之后点“确定”过几秒钟客户端下方会显示“就绪”这就说明已经成功注册到你的自建服务器上了。4.2 客户端批量配置实用技巧如果你是给一个部门甚至一个公司的电脑批量部署RustDesk手动一台台填服务器地址太费劲了效率太低。这里分享一个批量下发配置的技巧。RustDesk的客户端在首次配置完服务器以后会把连接配置写进本地配置文件。Windows下这个文件是安装目录下的config\RustDesk2.tomlLinux和macOS则放在用户目录的.config/rustdesk/RustDesk2.toml。这个文件长成什么样呢我可以给你一个简化例子options { custom-rendezvous-server 你的服务器IP:21116, relay-server 你的服务器IP, key }其中key是服务端生成的公钥填上之后会在客户端网络设置界面显示“密钥已配置”说明这一端已经信任了你自建的服务端。你可以把这份写好的配置文件通过域策略、批量脚本或者公司软件管理平台推送下去分发给所有员工。Linux和macOS还有更省事的一招支持用环境变量指定服务器地址比如export RUSTDESK_SERVER你的服务器IP这样客户端启动后会自动读取环境变量就不用每个用户都手动配置一遍。至于多平台配置文件的详细差异RustDesk的GitHub Wiki里有相关介绍建议实际部署前先去翻一遍。4.3 公网访问、端口映射与IPv6的取舍服务端如果跑在云主机上有固定IP那客户端只要地址填对基本就通了。但如果你和我一样把服务端跑在家里的NAS或者公司内网主机上那你还需要解决一个“外面如何访问内网服务器”的问题。先说最理想的情况运营商给你分配了动态公网IP。这时候你需要在路由器上做端口映射把公网侧的21115-21119端口转发到内网NAS的对应端口。同时因为IP是动态的你还需要一个DDNS域名解析服务。现在很多路由器自带花生壳或阿里云DDNS插件填上域名和密钥就能自动更新解析记录然后客户端那边的“ID/中继服务器”地址就填这个域名比记IP一劳永逸。再说没有公网IPv4的情况。如果你家里是光猫拨号、路由器二级NAT甚至干脆是运营商内网IP那想从外面访问可以看看运营商有没有给你下发IPv6地址。现在国内很多宽带都默认开启了IPv6你在路由器上确认一下WAN口有没有240e开头的地址如果有用RustDesk的IPv6地址访问就行不过前提是你的手机4G/5G网络也支持IPv6而且整套网络路径上没有IPv6防火墙拦截。如果IPv4和IPv6双双不可行那就老老实实用frp之类反代内网穿透工具把你的服务器端口映射到一台有公网IP的VPS上。不过这种做法有一个注意点RustDesk的端口连接不只走TCP还涉及UDP打洞frp对UDP的支持比自己搭建TCP隧道要麻烦不少我个人实测的体验是经过frp中转后延迟会略高但在没有公网环境的场景下已经是很好的兜底方案了。网络中还有一个非常隐蔽的问题是UDP端口是否放行。很多云服务商的安全组默认只放行TCP规则UDP 21116这个端口经常被忽略。一旦UDP不通客户端可以正常跟服务器说“我上线了”但两台设备之间的P2P打洞通道建立不起来经常出现“能看到设备列表但连不上”的诡异问题。这一点我安排在后面问题排查里重点说。5. 安全加固与常见问题排查5.1 自建服务端的安全基线讲完了部署和连通安全这块就是重中之中了。远程桌面这种服务一旦被人盯上轻则电脑被插上木马重则整个内网被拖走。自建服务端本身就已经比用公共服务器安全一些因为数据不经过第三方中继也没有第三方云平台在背后扫描流量但该有的安全意识一步也不能少。第一条把服务端公钥分发到位。这一步就是在客户端配置文件里填上服务端生成的id_ed25519.pub内容。配置完成后一个没有公钥的RustDesk客户端连你的服务器时会被拒绝注册。这个机制可以理解成服务器只认“带了护照的人”也就是你的服务端只和“知道密钥”的客户端握手能挡住至少99%的扫描流量。第二条防火墙白名单策略。你完全可以用云防火墙或iptables把21115-21119这组端口限制到“只允许内部IP段访问”比如公司出口IP、家用宽带IP段等。这样即使有人拿到了你的服务器地址因为他的网络环境不符合白名单规则也是白搭。但如果你的客户端设备分布在天南海北固定IP省不了心那白名单这一步就要谨慎使用否则你自己出差到酒店反而连不上了。第三条设置一个复杂且独立的RustDesk连接密码。RustDesk支持为每台被控设备设置“固定密码”就是“安全”选项卡下的那个永久密码这个密码在每次远程连接时都会用到。这个密码不应跟你系统登录密码一样也不应该跟WiFi密码一个套路建议用随机生成的16位以上强密码统一在密码管理器里保存。还有一条很容易被忽略的是如果你用的是Docker部署建议把容器内的存储卷单独分出来比如挂载到./data目录这样万一容器崩溃重建公钥和配置不会丢。5.2 常见问题排查实录我把这几个月来最常遇到的问题做了一份速查表基本覆盖了自建RustDesk过程中99%的坑强烈建议你收藏备用。症状可能原因解决方法客户端显示无法连接服务器服务端没启动或端口被封检查容器状态、netstat监听列表、云安全组规则能弹出设备列表但连接超时UDP 21116没放行云安全组和路由器同时放行21116/UDP同一局域网能连公网连不上服务器没有公网地址或端口映射没做对确认WAN IP类型、路由器转发规则改用IPV6或frp两台设备都在复杂NAT后连不上点对点打洞失败确认hbbr中继服务正常观察是否通过中继转发速度很卡延迟高走了中继而非P2P直连查看连接详情是否显示“中继”想办法优化网络或直连手机客户端连不上电脑手机和电脑不在同一网络且服务端不可达临时用电脑开热点测试确认手机网络能访问服务器挑几个重点展开说。第一个是“能出现设备列表但连不上”。这个问题十有八九是UDP打洞没通。RustDesk的ID服务器与客户端的通信同时用TCP和UDP两个协议TCP负责注册和交互管理UDP负责穿梭两端的NAT打洞。如果你在云服务器安全组里只放行了TCPUDP的包进不来那么客户端虽然能看到设备但真正建立点对点数据流时打洞的UDP包根本到不了对方连接就会卡在“正在连接”状态。放下心去安全组把21116/UDP打开就行。第二个是“手机4G流量访问延迟高卡到怀疑人生”。这种情况首先看一下RustDesk界面下方的“连接信息”标签如果显示连接类型为“中继”说明没有走P2P直连而是数据全部从你的服务器中转了一遍速度自然快不了。正常的P2P连接速度取决于两端网络出口带宽而中继则受限于你服务器的上行带宽。如果服务器在云端看下云服务器带宽规格要不升带宽要不就尽量设法让两端在同一个局域网内访问。第三个是“局域网内一切正常换到公网就连接失败”。这种基本可以断定是NAT和端口转发的问题。本地IP和服务器都正确但公网入口的端口没有全部放行或者路由器没有正确的DNAT规则。你可以先在外网用telnet测一下服务器的TCP端口通不通如果某个端口不通再逐个排查往往能快速锁定是云安全组、路由器、还是防火墙的问题。5.3 从踩坑到稳定运行的心得最后再分享几个我个人的心得。第一点是自建RustDesk不要一上来就追求“全功能”。网上有大量花里胡哨的配置教程教你开Web客户端、做定制UI、接数据库这些对于绝大多数个人和中小企业来说都是伪需求。你把ID服务器和中继服务器这两大核心跑稳保证日常远程连接顺畅就已经达到了90%的目标。第二点是如果你是用NAS跑服务端一定要注意USB硬盘的休眠策略。我家的群晖NAS默认会在10分钟无访问后把硬盘休眠但RustDesk服务端每隔几秒就要写一次心跳日志导致硬盘反反复复唤醒。后来我在服务端设置里把日志级别调低同时给NAS硬盘设置了永不休眠才算消停。第三点是公网IP的DDNS解析更新有延迟。有一次我出门在外连接怎么都建立不起来一查才发现家里的宽带IP在两小时前更换过DDNS还没来得及把新IP同步到客户端。后来我在路由器上设置了每5分钟强制检查一次IP变化这个坑就很少再踩到了。结尾我在实际使用中最大的体会是自建RustDesk这件事初期部署的成本其实不高只要照着一份可靠的教程走两台设备对连成功率就很高了。难点恰恰在后面那几个容易忽略的细节UDP端口有没有放行、客户端公钥是否正确配置、中继带宽是否够用。这些细节决定这套系统是“偶尔能用”还是“长期稳定能用”。如果你正准备给家里或者公司搭远程桌面我的建议是先把服务端跑在云主机上花点小钱租一台1核2G的轻量服务器毕竟公网速度还是比家宽上行快得多再把客户端配好体验几天稳定之后再考虑迁移到NAS或者局域网内。团队使用的话把公钥和固定密码管理起来别省这一步。这篇文章写到这里服务端、客户端、网络、安全、排错这几个环节算是都聊透了。自建RustDesk这件事本质上就是用一台轻量服务器换一个随时能连的安心感。你把这套流程跑通之后会发现以后不管出差到哪个城市只要有网络家里的电脑和办公室的主机就跟揣在兜里一样方便。