1. 为什么我要把远程桌面换成 rustDesk 自建方案先说结论如果你手里同时管理着三五台以上跨系统的设备或者经常需要在不同网络环境下远程办公、给家人朋友维护电脑那么一套自建的 rustDesk 私有远程桌面服务是性价比极高的选择。rustDesk 是开源跨平台的远程桌面工具主打一个可自托管。它由两个核心服务组成一个是 hbbs主控服务器负责注册和信令另一个是 hbbr中继服务器负责音视频数据转发和流量中转。这两个组件搭起来之后客户端就能通过你自己的服务器完成设备发现、连接握手和数据通路全程不需要经过任何第三方公共中继节点。最初让我动心的是这几个点数据完全由自己掌控。连接记录、登录凭据的验证、传输通道全部走自建的服务器没有第三方插手的空间。没有商业软件那样的设备数量和时长限制。TeamViewer 商用版本动不动就弹检测到商业用途限制AnyDesk 也有类似的授权问题自建以后这些都不存在。跨平台确实够全。桌面端的 Windows、macOS、Linux移动端的 Android、iOS 都有客户端而且体验基本一致。部署流程比想象中简单二进制文件解压就能跑也支持 Docker不存在复杂的编译过程。需要说明我这里的方案是基于 rustDesk 官方开源项目的常见实践整理而来。rustDesk 自身迭代挺快我写这篇文章时的版本是 1.2.x 和 1.3.x 系列如果你的版本更新界面细节可能略有差异但整体逻辑基本不会变。这篇文章不是单纯把官方文档翻译一遍而是把我从踩坑到稳定运行的完整过程、选型考量、证书配置、防火墙细节、多用户权限折腾的记录都梳理出来给想真正自己掌控远程桌面的朋友一份可以照着做的参考。2. rustDesk 的核心原理与自建方案的整体设计2.1 hbbs、hbbr 各管什么为什么需要两个刚开始接触 rustDesk 自建的时候我一直有个疑问既然是开源免费的工具直接用官方公共服务器不就行了后来深入看了一下它的架构才明白公共服务器和自建服务器之间的差别到底在哪里。rustDesk 之所以拆成两个服务是有明确分工的hbbsID/注册服务器负责客户端的身份注册、设备 ID 分配、在线状态维护、点对点P2P连接的建立协商。可以把它理解成一个通讯录信使就是让两台设备先互相找到对方。hbbr中继服务器负责在两端无法直连时做数据传输的中继也就是把画面、操作指令、文件数据包转发到对端。当网络环境复杂比如两边都是运营商 NAT打洞失败时hbbr 就是那个保证连接不会断的兜底通道。设计上hbbs 和 hbbr 可以放在同一台服务器上也可以分开部署在不同机器上。如果设备量不大个人使用场景完全没必要拆开。这里有一个关键技术细节值得多说一句P2P 打洞之后数据不一定走中继服务器。rustDesk 内部会优先尝试 UDP 打洞直连如果双方 NAT 类型允许比如全锥型 NAT数据就直接设备到设备地传输此时自建的中继服务器只承担初次握手的工作压力小得可以忽略。只有在 Cube NAT/对称 NAT 等打洞失败的情况下流量才会全部经过 hbbr 中转。所以自建服务器的带宽压力取决于你的网络环境和设备 NAT 类型而不是简单的所有流量都经过服务器。2.2 自建私有远程桌面与商业远程软件的核心差异既然市面上已经有 TeamViewer、AnyDesk、向日葵这些成熟产品为什么还要折腾自建我实际用下来最直观的感受有三个维度。对比维度商业远程软件TeamViewer / AnyDesk / 向日葵rustDesk 自建部署成本免费版受限商用授权费用高服务器成本低基础配置即可运行数据路径经官方中继节点数据合规性需评估完全自控的服务器数据不出内网身份验证依赖厂商账号体系账号异常会中断工作本地密码、公钥双重校验凭据留存在自有服务器连接质量高峰期受公共节点调度影响带宽和链路由自己掌控可针对场景优化扩展性设备数、功能授权固定无设备数限制可自由接入 Web 终端、Linux 客户端等功能层面功能更多、更成熟基础远程桌面体验常规场景已经非常够用这里说的数据不出内网是指如果你在同一个局域网里用自建服务器两端的通信流量完全不会跑到外网这对隐私要求高、又需要在不同内网环境频繁操作的场景非常友好。即便是跨外网使用数据流经的也是你控制的服务器安全边界比公共服务器清晰得多。我自己的使用场景比较典型白天在公司连实验室的 Linux 工作站晚上可能又要连家里那台存着素材的台式机偶尔还要帮家里长辈远程处理电脑问题。商业软件要么限制设备数量要么各种弹窗提示商业使用时间一长真的会烦所以自建方案是我实际观察和对比后的选择。2.3 项目适用的场景和读者定位先别急着动手搞清楚这套方案到底适不适合你可以少走很多弯路。这套方案比较适合的人手里有多台电脑/服务器需要跨网络维护的开发者或运维人员公司内部有内网远程运维需求想避免员工使用公共远程软件把内部机器暴露到第三方平台希望数据通路完全自控的个人用户隐私意识较强的对 TeamViewer 等商业软件授权策略不满想要一劳永逸解决问题的中小团队如果你的需求只是偶尔远程看一下办公室电脑的桌面、不频繁、也不涉及敏感数据那用公共服务器版就能满足自建确实有点杀鸡用牛刀。但一旦你的使用频率上来了或者开始涉及多人维护同一台设备需要稳定连接不中断这类需求时自建的价值就会迅速体现出来。3. 环境准备与部署方案选型3.1 服务器配置选型和操作系统要求很多朋友第一反应是自建服务是不是要一台很贵的服务器我的实测经验是——远不用。rustDesk 的 hbbs 和 hbbr 都是轻量级进程一个连接的握手信息只有几 KB就算几十个设备同时在线内存占用也就几十 MB 级别。我最初在一台 1 核 1G 的云主机上跑了三个月稳定得很CPU 利用率平时不到 5%。当然如果你要长时间中转高分辨率画面比如远程进行 4K 视频剪辑预览、远程设计那就得考虑带宽和中继 CPU 了但这属于极端场景常规办公和运维完全不需要担心。操作系统的选择上Linux 是最省心的因为 rustDesk 官方对 Linux 的支持最完善包括 systemd 集成和 Docker 镜像都在持续更新。Windows 也可以跑但需要自己在任务计划程序里配置开机启动没有 Linux 下 systemd 那么顺滑。我的建议是服务器选 Ubuntu 20.04 / 22.04 LTS 或 Debian 11/12买一台 1 核 1G 或 1 核 2G 的 VPS 即可。如果你的服务器在国内要注意带宽和线路质量。中继服务器最怕的就是高延迟 丢包这会导致远程桌面画面卡顿和操作延迟。国内云厂商的轻量应用服务器通常的带宽就够用但别买那种流量费极高的按量计费机器——远程桌面中转时每天消耗几个 GB 流量是很正常的事。3.2 端口规划防火墙放行哪些端口部署之前先把端口规划做好这是后续连接稳定性的基础。rustDesk 的通信端口如下21115hbbs 的 TCP 端口用于 NAT 类型探测和各端的连接信令21116hbbs 的 UDP 端口用于客户端注册和心跳服务如果网络环境允许这个端口能打通 P2P 打洞的关键通道21117hbbr 的 TCP 端口用于中继服务的 TLS 封装数据传输21118/21119这两个端口是 Web 客户端和 Web 服务器端rustdesk-web使用的如果你需要浏览器远程访问就需要一并放行我个人的习惯是在云服务器的安全组中只开放最小必要端口。默认情况下我只会放行 21115TCP、21116TCP/UDP、21117TCPWeb 端口根据实际需要再加。不要在安全组里开放 SSH 之外的额外管理端口不要为了方便把 1-65535 全暴露出去。3.3 部署方式Docker 与二进制文件二选一rustDesk 服务器端的部署方式主要有两种官方二进制包和 Docker Compose。两者我分别测过各有优劣。二进制方式直接从官方仓库下载 hbbs 和 hbbr 两个文件放到服务器上执行即可。优点是直观、没有容器层依赖、对新手更友好缺点是更新要自己手动下载替换且需要一个进程守护工具如 systemd来保证开机启动和异常重启。Docker 方式用官方维护的 rustdesk-server 镜像通过 docker-compose 一条命令启动。优点是环境隔离、升级方便重新拉镜像再 restart 就行、不容易搞乱系统依赖缺点是需要你至少熟练使用 Docker能够自己排查容器日志。考虑到步骤的优雅程度我推荐 Docker 方式官方仓库里有完整的docker-compose.yml示例配置起来并不复杂。下面给一个可以直接用的 docker-compose 配置version: 3 networks: rustdesk-net: driver: bridge services: hbbs: container_name: hbbs image: rustdesk/rustdesk-server:latest command: hbbs -r 中继服务器地址:21117 ports: - 21115:21115 - 21116:21116 - 21116:21116/udp - 21118:21118 volumes: - ./data:/data networks: - rustdesk-net restart: unless-stopped hbbr: container_name: hbbr image: rustdesk/rustdesk-server:latest command: hbbr ports: - 21117:21117 - 21119:21119 volumes: - ./data:/data networks: - rustdesk-net restart: unless-stopped这里有一个容易踩坑的细节hbbs -r参数后面填的地址一定是你客户端能够真正访问到的中继服务器地址不要填内网 IP。如果你的服务器有公网 IP就填公网 IP如果用域名就填域名。这个地址会写进客户端配置里填错的话连接时就会尝试去访问一个不可达的中继导致握手失败。3.4 网络环境检查域名、公网 IP、NAT 类型判断服务器就绪之后先别着急部署客户端花十分钟做一次网络环境检查可以避免后面一堆莫名其妙的问题。第一步确认服务器有公网 IP或者至少有一个可以正常映射到外网的端口。如果你自己家里放了一台 NAS 作为服务器那就要在路由器上配置端口转发。常见的家庭宽带没有固定公网 IP可以用 DDNS 动态域名方案但要注意如果你的宽带处于运营商级 NAT 之后内网 IP那自建服务器的对外访问就会受限这种情况下建议直接用云服务器别在自家网络环境里折腾。第二步确认目标设备的 NAT 类型。在 rustDesk 客户端中输入对方的 ID 发起一次连接如果成功建立了 P2P 直连客户端会显示连接方式为 Direct说明两端的 NAT 环境比较友好如果一直显示 Relay中继说明打洞失败数据会走你的中继服务器。这部分可以在后面的实测阶段去验证。第三步建议提前准备好一个域名并解析到服务器 IP。不是必须但强烈建议。证书配置和后续的 Web 访问都依赖域名直接用 IP 意味着只能放弃 TLS 证书连接安全性和稳定性都会打折扣。如果实在没有域名也可以先用 IP 跑通流程后面证书部分再单独处理。4. 服务器端部署从零开始把 rustDesk 服务跑起来4.1 Docker 部署实操从下载镜像到容器启动有了上面那份 docker-compose 文件部署其实就三步# 1. 创建项目目录并进入 mkdir -p rustdesk cd rustdesk # 2. 新建 docker-compose.yml粘贴上面的内容 # 3. 启动服务 docker compose up -d启动之后用下面的命令看一下容器状态docker ps正常情况下你应该能看到两个容器都处于Up状态。然后看一下日志docker logs -f hbbs docker logs -f hbbr如果日志里出现了Listening on的字样说明服务已经在监听端口了。此时再验证端口是否真正对外可访问在服务器本地执行ss -lntup | grep -E 2111[5-9]确认端口都在监听后再用另一台机器测试目标端口连通性。注意不要只测本机回环地址要用外部客户端或telnet从另一台网络位置的机器去测。telnet 你的服务器IP 21116如果连接成功说明防火墙规则生效了。如果超时优先检查云厂商安全组是否放行了对应端口其次是本机防火墙Ubuntu 默认没有启用 ufw但 CentOS 默认有 firewalld 需要处理。4.2 使用 systemd 管理二进制版本非 Docker 用户参考如果你不想用 Docker二进制部署其实也很简单。从 rustDesk 的 GitHub Releases 页面下载服务器端压缩包文件名类似rustdesk-server-linux-amd64.zip解压到/opt/rustdesk目录直接运行两个二进制。为了让服务在后台稳定运行我建议在/etc/systemd/system/下建两个 service 文件。下面是 hbbs 的示例[Unit] Descriptionrustdesk hbbs service Afternetwork.target [Service] Typesimple WorkingDirectory/opt/rustdesk ExecStart/opt/rustdesk/hbbs -r 中继服务器地址:21117 Restartalways RestartSec5 [Install] WantedBymulti-user.targethbbr 的服务文件类似只是把 ExecStart 改成/opt/rustdesk/hbbr不需要带参数。配置好之后执行systemctl daemon-reload systemctl enable --now hbbs hbbr systemctl status hbbs hbbr这里有个经验一定要设置 Restartalways。rustDesk 服务器进程虽然稳定但如果服务器的带宽或内存出现短时异常进程可能会被系统杀掉。没有守护进程的话你往往要等用户反馈连不上的时候才会发现服务挂了远程运维的时效性就没了。4.3 第一次连接测试配置客户端连接自建服务器服务器跑起来之后先不急着批量配置所有设备用一台桌面端做一个完整的流程验证。先看客户端界面。打开 rustDesk 客户端后主界面上会显示一个 9 位数字 ID 和一个临时密码。这个 ID 就是在局域网或公网上远程连接时的门牌号。默认情况下客户端连接的是官方公共服务器我们自建的服务器还没有生效所以首先要做的是把客户端指向自建服务器。rustDesk 客户端工单页签中有一个网络设置区域点开后在ID/中继服务器一栏填上你的服务器地址格式是你的IP或域名:21116或直接填 IP/域名客户端会自动拼接默认端口然后在Key一栏填上服务器端生成的公钥。这个公钥是在服务器首次启动时自动生成的就存放在你挂载的 data 目录下。如果你用 Docker 部署可以这样获取公钥# 在 docker-compose.yml 所在目录下执行 cat ./data/id_ed25519.pub把输出的内容整串复制到客户端的 Key 输入框保存配置。此时客户端应该会显示已就绪或状态条的提示改变表示已经连接上你的自建服务器。提示公钥信息很重要作用类似于一个准入凭证。如果客户端填入了错误的 Key服务端在握手阶段就会拒绝连接如果不填写 Key客户端会采用无加密验证的兼容模式实际使用时可能会暴露安全风险建议务必备份并正确配置。4.4 配置 TCP 打洞与中继模式连接建立机制的深度说明客户端配置好服务器后我们来看连接建立的基础模式。理解这一步后面排查问题会轻松很多。当你发起远程连接时rustDesk 的大致流程如下客户端 A 用目标设备的 ID9 位数字和密码向 hbbs 发起连接请求。hbbs 根据目标设备的在线状态和网络信息返回可用的连接方式包括对方当前在哪个网络出口、采用了什么 NAT 类型。两端尝试 UDP 打洞也就是直接向对方的公网 IP 和端口发送 UDP 数据包试图建立一条不经过服务器的直连通路。如果打洞成功耗时通常在几十毫秒到几百毫秒之后的画面和操作数据就不再多路转发了直接走 P2P 通路延迟最低。如果打洞失败例如网络层级复杂、运营商屏蔽 UDP 等hbbs 会指令 hbbr 开始中继数据此时画面会经过你的服务器进行转发延迟会稍高但功能不受影响。在客户端界面中你可以在连接后查看当前连接状态。当显示Direct时说明是 P2P 直连显示Relay说明走了中继。两种方式各有各的作用场景都算正常但如果你发现所有连接都是 Relay且服务器带宽很紧张那就需要进一步排查 NAT 打洞失败的原因了。5. 安全加固与多设备管理实践5.1 密码策略与权限隔离为设备设置独立访问凭据远程桌面最怕的是裸奔——设备在线密码却是默认的临时密码一旦被扫描到等于大门敞开。rustDesk 客户端在首次运行时会为每台设备生成一个随机临时密码但这个密码在每次客户端重启后都会变化而且很多人往往懒得把它改成固定密码这就给管理带来了麻烦。我的做法是给每台设备设置独立的高强度访问密码仅在必要情况下才提供临时密码给别人使用。在 rustDesk 客户端的安全设置中可以把密码从临时密码改成长效密码也可以设置多个固定密码并分配给不同的使用场景。给家人朋友维护电脑时我在他们机器上设置一个临时密码有效期一天用完随即失效这样即使密码在传输过程中被截获影响也是可控的。对于团队多人维护的场景rustDesk 还支持在服务器层面配置账号权限。hbbs 所在的服务器上可以通过配置文件对客户端的 ID 进行分组和限制但需要注意rustDesk 的开源版本没有像商业软件那样完整的组织用户控制面板权限管理更多是靠登录凭据的分配来实现的。如果团队规模不大五个人以内、每人对自己的设备都拥有密码管理权这个模型完全够用如果组织架构复杂、权限要求严格那可能要搭配其他开源身份管理方案来增强。5.2 公钥证书与 TLS 传输给你的远程访问加上完整加密前文提到的 Key 字段不仅是准入凭证其实还承担着加密认证的功能。rustDesk 客户端和服务端之间使用基于 ed25519 的非对称密钥体系来验证身份。服务器端生成私钥公钥写入客户端配置连接建立时双方用这个密钥进行握手校验确认对面确实是自己的服务器而不是一个中间人伪造的节点。这种方式在服务器只跑内网或者小范围信任设备的情况下已经足够安全。但如果你的目标是公网环境里更严苛的传输安全我建议再叠加一层 TLS 加密。官方文档中给出的方案是使用Lets Encrypt申请域名证书然后将证书配置到 hbbr 的中继端口上。Docker 部署时可以在 docker-compose 中把证书挂载进容器并设置环境变量让 hbbr 启用 TLS 模式。实际操作中还需要在客户端的网络设置中将安全模式调整为TLS 加密。我实测下来TLS 模式会对 CPU 有一点额外占用但对于远程办公这种交互型流量来说几乎无感知。值得提醒的是如果你同时使用了IP 直连 TLS 证书验证证书必须与域名匹配否则客户端会报证书校验失败而拒绝连接。这也是为什么我一直强调优先准备一个域名的原因。5.3 多设备批量配置技巧服务器信息一键下发管理几十台设备的时候一台台去手填服务器地址和 Key 真的很烦。rustDesk 支持通过配置文件统一下发参数这个功能在团队场景中很实用。在客户端安装目录下Windows 版通常在C:\Program Files\RustDeskLinux 版通常在/usr/share/rustdesk有一个config文件或rustdesk.json。官方文档里提到了客户端配置文件的自定义字段用来预设服务器地址、Key、启用自动启动等参数。一个比较常见的做法是在一台参考机器上配置好自建服务器信息和 Key然后把配置文件中与服务器相关的字段提取出来生成一组参数模板用于其他设备安装后的自动导入。实际操作中由于平台差异配置路径可能不同你也可以在客户端界面上选择导入配置文件完成批量配置。这样做的优势在于团队的新成员拿到电脑后只要导入了这份配置机器就能立即使用私有的远程服务不需要修改任何代码或脚本。这也让自建服务器的一次配置、全组生效体验变得更加顺畅。6. 常见问题排查与踩坑实录6.1 客户端无法连接自建服务器怎么办问题表现客户端配置好服务器地址和 Key 后点连接直接报错或者显示无法连接到服务器。排查思路按顺序走确认服务器进程活着。执行docker ps或systemctl status hbbs hbbr如果挂了先看日志。确认服务器端口对外可达。从另一台电脑执行telnet测试 21116 端口。确认客户端填写的服务器地址没有内部外部的混淆。注意区分服务器自身的内网 IP 和公网 IP。确认 Key 没有填错。复制公钥内容时注意不要带空格或换行最好用文本编辑器打开文件后全选复制。检查服务器防火墙和安全组。如果用的是云服务商安全组规则比云主机内部的 iptables 更容易被忽略。这里有个小技巧在客户端日志Windows 版可以通过命令行启动并带调试参数或者查看日志目录里搜索hbbs或Relay关键字可以看到连接尝试的详细过程和失败原因比自己瞎猜快得多。6.2 连接成功后画面卡顿掉帧怎么优化如果是 P2P 直连还卡那问题大概率出在客户端主控端的解码能力或对被控端电脑的性能要求上。检查被控端的网络上传带宽远程桌面对带宽的要求比视频会议低但也不至于完全无感。一次 1080p 的远程会话大约需要 2-4 Mbps 的上传带宽如果被控端本身在跑大文件上传任务自然会影响画质。如果是中继模式掉帧登录服务器看iftop或nload等工具的实时流量确认是否达到带宽上限。同时检查延迟ping 客户端所在网络的出口IP延迟超过 100ms 时远程操作会有明显的输入延迟感。这个情况下可以尝试降低被控端的画面分辨率和色彩深度减少中继的带宽压力。rustDesk 也提供了帧率和压缩率设置适当降低后体验提升明显。另外还有一个经常被忽略的问题被控端的电源管理最好关闭屏幕休眠。有些笔记本默认在合盖后进入睡眠状态远程根本没法唤醒需要先在系统设置里改成合盖不操作或者接上电源保持唤醒。6.3 被控端 ID 为什么会一直在变rustDesk 的 ID 在客户端初次启动时会根据设备的硬件信息和配置生成一个随机 ID。如果你重装了系统、换了系统盘或者删除了客户端目录下的配置文件ID 就会变化。这就会导致你之前在地址簿里保存的 ID 失效。解决办法有两个在客户端界面中重置 ID会基于当前设备重新生成一个后续用新 ID 连接。尽量保持客户端配置目录的完整备份尤其是 Windows 版安装时选择设置密码并自动安装客户端的密钥和 ID 会在各台设备上形成持久化的身份标记。对于经常帮别人远程修电脑的场景建议在被控端设置一个设备备注名或别名方便在地址簿里识别避免 ID 一换就不记得哪台是哪台了。6.4 常见问题速查表下面的表格是这一年来我在自己设备和朋友那边的机器上遇到问题的经验整理供你参考。现象可能原因解决方案客户端填了 IP 和 Key 但连接报错防火墙未放行 21116 端口检查安全组和本机防火墙规则连接建立后画面为灰色/空白被控端显卡驱动或会话锁定问题更新显卡驱动尝试切换到系统桌面会话输入延迟严重建议检查网络链路中继带宽不足或延迟过高换用 P2P 直连场景或降低画质参数客户端无法打开摄像头/麦克风被控端设备权限未授权给 rustDesk在系统隐私设置中允许 rustDesk 访问公网环境下无法连接NAT 类型制约打洞中继未正确配置确认 hbbr 命令中的地址与客户端配置一致服务运行很久后突然无法登录自签证书过期或失效查看证书有效期手动更新后重启进程内网环境延迟正常、公网环境延迟异常链路经过多次网络转发考虑使用专线或更优机房线路的中继7. 从单机自建到轻度架构演进的一些经验和建议跑通自建服务器之后你可能会慢慢发现这套系统的潜力远不止于个人远程桌面。身边有朋友问我能不能用它来替代部分运维工具也有人想把远程支持能力开放给团队成员。如果你的设备规模已经超过十几台或者开始涉及异地办公室间的远程维护我建议关注这几个方向首先为 hbbs 和 hbbr 加上资源监控。即便 rustDesk 的进程很轻但中继服务器长期满载时也会因为 TCP 连接数过多导致文件描述符耗尽。可以在服务器上设置一个简单的定时任务检测Memory / CPU / TCP 连接数三个指标达到阈值时通过邮件或群机器人推送告警。其次为关键设备添加备份 ID 规则。如果你管理的设备中有一些永久在线的角色比如办公室共享机、家庭 NAS建议在客户端设置里勾选保持固定 ID把 ID 写入资产台账这样不会被误改或丢失。最后如果你的中继服务器暴露到公网后经常被扫描可以将 hbbs/hbbr 的监听端口从默认值改成高位端口比如 41115/41116/41117然后在客户端配置中同步填写新的端口。这种做法不能从根本上提升安全性但因为外部扫描器默认只扫热门端口见过的 rustDesk 服务换了高位端口后扫描发现的概率会成倍下降。经过这段时间的折腾和使用我个人最深的体会是自建远程桌面方案不会像商业软件那样开箱即用、全自动最优它需要你在网络、端口、证书、安全策略上投入一点学习成本但换来的是完全可控的主权。那种所有设备都指向自己服务器的踏实感是任何公共云方案都给不了的。希望这篇内容能帮你把这条自建之路走得更顺一点。