远程桌面这个需求过去我一直是 TeamViewer 的老用户免费版用了几年后来它动不动就提示“疑似商用用途”连接时间直接掐断换到 AnyDesk 也一样个人免费版偶尔弹窗跨省访问的画质和延迟也越来越拉垮。后来我发现了 RustDesk 这个开源项目支持自己搭建一套私有远程桌面控制端和被控端的数据全部走自己的服务器完全不依赖第三方中转节点日常用起来心里踏实得多。这篇就把我完整的自建过程记录下来从架构原理、服务器部署、客户端接入到安全加固和故障排查全过程可以直接参考复现。这套方案适合谁远程办公的上班族、要帮家里老人处理电脑问题的朋友、跨地区管理服务器和 NAS 的运维党还有不想把设备控制权交给第三方服务的人。整个方案不复杂一台带公网 IP 的云服务器加两个客户端就能跑起来但部署过程中涉及的端口、Key、中继关系网上教程往往语焉不详所以我把实际搭完的过程和踩过的坑完整梳理了一遍希望能帮有同样需求的人少走弯路。1. 为什么选 RustDesk 自建而不是继续依赖商业软件1.1 商业远程桌面软件的三个痛先说说我为什么放弃商业远程桌面。TeamViewer 免费版的使用限制越来越严免费个人版用在非商业用途还好但只要连接频率高一点、设备数量多一点就会被算法标记为“疑似商业用途”然后直接掐断会话解决办法只有付费或者等一段时间。AnyDesk 的免费版也有类似策略弹窗提示是不可控的跨区域连接时明显能感觉到画面卡顿。还有国内常用的向日葵个人免费版在 macOS 和 Linux 下的权限控制经常出问题全屏控制远程 Linux 机器时键盘映射偶尔失灵。更关键的是隐私问题。商业远程桌面软件的控制端、被控端、指令传输都会经过服务商的中转服务器虽然传输层有加密但从原理上来讲服务商在技术上具备看到会话内容和设备信息的可能不外传和能不能看是两码事。对于远程办公场景公司内部文件和数据对第三方可见这是很多人没法接受的。1.2 RustDesk 打开的新路径RustDesk 的核心卖点可以总结成三句话开源可自建、数据走自己的节点、跨平台覆盖广。它基于 Rust 语言编写代码仓库完整开放客户端支持 Windows、macOS、Linux、Android、iOS服务端也提供了 Linux 预编译包和 Docker 镜像。所谓“自建”就是把远程桌面里的信令服务和中继服务部署到自己的服务器上客户端连接时不再访问官方公共服务器而是访问你自己的服务器。这里要澄清一个容易误解的点自建 RustDesk 并不需要高性能服务器因为它只是负责“牵线搭桥”。两台设备能直连时服务器只在握手阶段起个作用后续画面和输入数据走 P2P 直连只有双方网络环境无法直连时数据才会经过我们的中继服务器转发而中继转发只是数据包搬运不做视频编解码所以 1 核 1G 内存的轻量云服务器完全够用。这也是我推荐这套方案的原因——成本很低换来的却是数据路径的自主可控。1.3 什么场景不适合自建诚实说自建 RustDesk 也有短板。如果你只是偶尔远程控制一下家人的电脑不想折腾服务器直接用官方公共服务器版本就够了自建反而多余。另外如果你的使用场景需要多人同时接入大量设备、需要集中的设备管理和审计报表RustDesk 默认没有管理后台需要自己维护配置文件这类需求更适合商业版或专业远程运维工具。总之选择自建的前提是你有“可控服务器”并且愿意花半小时完成部署和维护。2. 自建远程桌面的架构先把原理讲明白2.1 三个组件各干各的活RustDesk 的私有部署里有三个角色被控端目标机器、控制端发起连接的机器、服务器端信令加中继。服务器端又拆成两个进程hbbs 和 hbbr。hbbs 是 ID 注册和信令服务负责处理客户端上线、ID 登记、双方握手、NAT 类型探测hbbr 是中继服务负责在双方无法建立 P2P 直连时转发加密后的画面和输入数据。客户端装上之后会生成一个设备 ID这个 ID 其实是一对密钥的标识。被控端启动后主动向 hbbs 注册自己告诉服务器“我在线我的 ID 是 xx”控制端发起连接时也是先找到 hbbs由 hbbs 告诉控制端“目标设备当前地址是 xx”然后双方尝试直连。这个过程非常像现实中的“交换名片”hbbs 相当于帮你查电话号码的黄页而 hbbr 是在你俩的网络互相不通时充当中间人帮你们传话。2.2 P2P 打洞和中继兜底机制很多人在局域网里用 RustDesk 很流畅跨公网就连不上原因就在这里。RustDesk 客户端接入 hbbs 后会尝试建立 P2P 连接也就是走“打洞”流程通过 UDP 包双方互相探测对方的公网地址和端口如果双方都处于普通 NAT 环境下大概率能打通一条 UDP 通道之后画面数据直接点对点传输服务器只在握手阶段参与速度取决于两端的上行下行带宽延迟最低。但现实里的网络环境很复杂比如办公网只允许 TCP 出站、UDP 被封禁或者企业防火墙做了严格的 NAT 限制打洞就失败。此时连接会自动切换到 hbbr 中继通道。中继模式下控制端和被控端的加密数据都汇入 hbbr 再转发出去服务器带宽就成了瓶颈这也是自建方案里唯一需要重点关注的性能指标。所以选服务器时流量和带宽比 CPU 重要得多。2.3 自建到底解决了什么自建之后所有客户端的 ID 注册请求都会指向我们自己的 hbbs不再依赖官方服务器这意味着即便官网公共服务拥挤、出现临时故障也不影响我们私有通道的正常连接。数据链路上只有我们自己的中继服务器参与了转发端到端数据默认经过加密第三方无法还原内容。再加上服务器是我们可以访问的 VPS日志、监控、防火墙权限都在自己手里从合规和信任角度来说这套私有远程桌面的价值就在这里。3. 服务器端的完整部署过程部署环境我以 Debian 12 为例Ubuntu 20.04 以上版本操作完全一致。整个流程按照“服务器准备 → 端口放行 → 服务端启动 → 客户端接入”的顺序来不走歧路。3.1 服务器选型与系统准备我用的是一台 1 核 1G 内存、带宽 1Mbps 的轻量云服务器系统 Debian 12。选 1G 内存是因为 hbbs 和 hbbr 两个进程加起来占用约 80MB 内存非常轻量带宽方面如果你经常跨网远程办公建议选至少 5Mbps 以上峰值带宽因为中继模式下的流畅度和带宽直接相关。如果你只用于极其偶尔的应急维护1Mbps 也能用只是画面会比较糊。先更新系统基础软件并确认服务器时间正确避免后续证书和握手出现偏差apt update apt upgrade -y apt install -y unzip wget curl nano ufw timedatectl set-timezone Asia/Shanghai服务器时间不准会导致 TLS 握手和 ID 验证异常这是我踩过的一个很隐蔽的坑后面排查部分会细说。3.2 域名、解析与端口规划建议提前准备一个域名解析到服务器 IP。有域名的话中继地址不用写一串 IP后续迁移服务器时客户端配置不用改动而且可以为 hbbs 和 hbbr 做正式证书证书信任问题会少很多。如果没有域名直接用 IP 也可以正常工作只是客户端首次连接会提示证书不受信任。RustDesk 服务端默认占用以下端口端口协议用途说明21115TCPhbbs 信令服务NAT 类型探测21116TCP UDPhbbs 主信令服务UDP 用于打洞TCP 用于兜底21117TCPhbbr 中继服务中继转发入口21118TCPhbbs WebSocket网页端可能用到可开21119TCPhbbr WebSocket网页端可能用到可开配置防火墙前先把 SSH 端口确认好我是直接把 22 端口替换成了随机高位端口并只允许自己的 IP 段访问。下面用 UFW 配置放行这些端口ufw allow 22/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 reload注意 21116 是一个特殊端口TCP 和 UDP 都要放行漏掉 UDP 会导致打洞失败表现为“能连上但画面走中继延迟很高”。这是部署过程中最常见的配置错误。3.3 下载服务端并启动两种方式皆可RustDesk 官方发布的服务端包在项目 Releases 页面可以找到有x86_64和arm64两种架构根据自己的服务器 CPU 选择。以 x86_64 为例mkdir -p /opt/rustdesk-server cd /opt/rustdesk-server wget https://github.com/rustdesk/rustdesk-server/releases/download/1.1.9/rustdesk-server-linux-amd64.zip unzip rustdesk-server-linux-amd64.zip chmod x hbbs hbbr启动时要用到两个参数。-r指定中继服务器地址也就是 hbbr 的地址和端口一般写成你的域名:21117-k指定公钥的生成方式传_表示让服务端自动生成并保存密钥文件。启动命令cd /opt/rustdesk-server ./hbbs -r your-domain.com:21117 -k _ /dev/null 21 ./hbbr /dev/null 21 第一次启动后在当前目录下会生成id_ed25519.pub和id_ed25519两个文件其中id_ed25519.pub的内容就是客户端要填入的“Key”。如果你希望用固定的密钥对也可以用-k 任意字符串手动指定后续换服务器时保持一致即可。强烈建议此时就执行cat id_ed25519.pub把公钥内容复制出来妥善保存后面客户端配置要用到丢了就得重置。使用 Docker 的方式更省事适合已经装了 Docker 的环境docker run -d --name rustdesk-hbbs \ --network host \ -v /opt/rustdesk-server:/data \ rustdesk/rustdesk-server hbbs -r your-domain.com:21117 -k _ docker run -d --name rustdesk-hbbr \ --network host \ -v /opt/rustdesk-server:/data \ rustdesk/rustdesk-server hbbrDocker 方案建议各位尽量用--network host因为 hbbs 需要直接绑定 21116 的 UDP 端口桥接网络下端口映射容易出问题host 模式最省心。3.4 注册为 systemd 服务配置开机自启上面用方式启动的后台进程SSH 断开后虽然还活着但服务器一重启就全部丢了所以推荐注册成 systemd 服务。先创建一个启动脚本cat /opt/rustdesk-server/rustdesk-server.sh EOF #!/bin/bash /opt/rustdesk-server/hbbs -r your-domain.com:21117 -k _ /dev/null 21 /opt/rustdesk-server/hbbr /dev/null 21 EOF chmod x /opt/rustdesk-server/rustdesk-server.sh再创建 service 文件cat /etc/systemd/system/rustdesk-server.service EOF [Unit] DescriptionRustDesk Server Afternetwork-online.target Wantsnetwork-online.target [Service] Typeforking ExecStart/opt/rustdesk-server/rustdesk-server.sh PIDFile/opt/rustdesk-server/rustdesk-server.pid Restartalways RestartSec5 [Install] WantedBymulti-user.target EOF systemctl daemon-reload systemctl enable --now rustdesk-server由于脚本里同时启动了两个进程Type 用了forking配合Restartalways进程异常退出会自动拉起。检查服务状态时用systemctl status rustdesk-server再配合ss -lntup | grep 211确认端口都在监听。3.5 客户端配置服务器地址和 Key在需要被控制的电脑上安装 RustDesk 客户端打开主界面后不用先连接直接进入 设置 → 网络。在“ID/中继服务器”一栏填三个东西ID 服务器填your-domain.com或者服务器 IPKey 填上一步id_ed25519.pub文件里的完整内容中继服务器留空即可客户端会默认使用ID服务器:21117作为中继入口。填好后点击“应用”RustDesk 会自动校验配置。如果配置正确客户端会自动生成一个新的 ID之前那种数字形式的 ID 会变成admin主机名或者类似格式。注意这个变化是正常的因为切换服务器后 ID 的生成规则会基于新服务器的密钥对重新派生。配置完成后在另一台设备安装客户端同样填入服务器和 Key然后输入被控端的 ID 连接连接成功后可以在连接信息里看到通道类型是“直连”还是“中继”这就说明私有通道已完全打通。4. 客户端接入后的安全加固与日常维护服务器部署完很多人以为就结束了其实安全加固才是自建方案里必须补的一课。RustDesk 默认状态下所有配置是开放的如果不做访问控制任何知道服务器地址和 ID 的人都有机会探测你的设备。4.1 密码策略与会话权限RustDesk 客户端可以设置两种密码一种是“永久密码”存在被控端本地适合固定办公设备另一种是“临时密码”每次开机后随机生成失效时间可设置适合临时授权场景。强烈建议所有设备开启密码保护并且使用高强度密码至少 12 位以上的字母加数字加特殊符号组合。在控制端发起连接后被控端会弹出请求确认窗口里面可以直接授予或拒绝权限。不要把“自动接受连接”打开否则任何知悉 ID 的人都能无感接入。权限设置里建议取消“允许控制端修改被控端设置”默认不勾选“自动使用 Easy 登录”。4.2 防火墙与公网暴露面收敛服务器上只保留前面放行的端口就够了。UUID 里能看到 hbbs 和 hbbr 的端口不要为了省事把它们改成标准 Web 端口因为客户端已经内置了默认端口。有一个值得注意的细节是如果你只在少数几个固定地点办公可以在服务器 UFW 里加一条规则只允许办公室出口 IP 访问 21117 中继端口其他 IP 一律拒绝这样即使被控端密码泄露外部连中继的机会也被封死了。SSH 层面建议直接禁用 root 密码登录改用公钥认证nano /etc/ssh/sshd_config # 修改 PermitRootLogin prohibit-password # 开启 PubkeyAuthentication systemctl restart sshd如果有能力再加一个 fail2ban 防暴力破解虽然这一步对远程桌面本身没有直接影响但服务器被入侵后所有配置都会暴露基础安全还是要做扎实。4.3 日志查看与日常状态验证服务端的日志默认打到了/dev/null配置里为了排查问题可以改成输出到文件。修改启动脚本把 /dev/null 21换成 /opt/rustdesk-server/hbbs.log 21然后重启服务这样后续排查问题会方便很多。客户端日志在 Windows 上位于%APPDATA%\RustDesk\logmacOS 位于~/Library/Logs/RustDesk排查连接问题时这两个日志是最直接的线索。4.4 证书信任与 HTTPS 配置如果直接用 IP 连接RustDesk 客户端在第一次连接时可能会提示“远程服务器证书无效”或类似警告这是因为服务端默认使用自签名证书。这个提示可以接受但每次重连都弹窗很烦。更好的做法是给服务器配置好正式证书把 hbbs 和 hbbr 的 WebSocket 端口跑在 TLS 上。具体做法是用 Nginx 反代 21118 和 21119 端口配置你域名对应的 SSL 证书然后在客户端设置里把“安全”选项关闭这样证书校验由 Nginx 层完成客户端不会再报错。5. 高频故障排查与性能调优5.1 连不上、一直转圈的排查步骤连接卡在“连接中”是最常见的故障。绝大多数情况下原因是端口没放行或 Key 没配对。第一步在控制端看客户端的日志目录搜hbbs或hbbr如果在日志里看到“Connection refused”基本可以断定服务器端口不通。在服务器上执行ss -lntup | grep 211确认监听状态再在被控端执行telnet your-domain.com 21117确认中继端口能连通。第二步检查 ID 服务器填的是不是域名。如果填了 IP中继地址会自动推导为“IP:21117”这在大多数场景没问题但如果你把域名解析改了旧配置就会失效务必保证 ID 服务器地址和证书域名一致。第三步核对 Key。RustDesk 客户端连接时如果提示“密钥不匹配”是 Key 填错或服务端重新生成过密钥文件导致的。把客户端配置里的 Key 清空重新填一次即可这个操作不需要改服务器端。5.2 速度慢、画面卡顿怎么判断走了中继画面卡顿首先要判断当前连接是“直连”还是“中继”。连接成功后点击连接状态的图标如果看到“Relay”中继说明 P2P 打洞没有成功所有数据都在过服务器。此时先确认服务器 UFW 里 21116 的 UDP 放行了吗这是最常见的原因。UDP 被容器网络或云防火墙拦截也会导致打洞失败云厂商的安全组和系统防火墙是两套独立机制两边都要放行。如果确认 UDP 放行后仍走中继大多是被控端所处的网络环境限制。办公网常常禁止 UDP 出站这种情况下只能依赖中继此时画质的流畅度上限取决于服务器带宽。解决方向是在客户端设置里调整画质和传输模式——选择“速度优先”会明显降低码率可以减少卡顿。另外控制端和被控端如果同在一个局域网可以直接使用 IP 直连功能绕过服务器这样最稳定。5.3 常用故障排查速查表问题现象可能原因排查方法连接一直转圈21116 UDP 未放行检查云安全组和系统防火墙提示密钥不匹配Key 旧或填错重新粘贴 public key连接成功但画面黑屏权限或显卡驱动问题被控端检查显示输出和 RustDesk 版本卡帧、延迟高走了中继链路看连接状态确认是否 Relay无法连接被控端ID 服务器填错看客户端日志中的报错信息服务端重启后连接失败进程未拉起来检查 systemd 状态和日志客户端 ID 变了切换了服务器地址这是正常现象重新配置连接即可5.4 性能调优的实际建议服务器带宽有限的情况下优先保证工作流而不是画质。在控制端设置里把“画质”从“高”改成“均衡”把帧率从 60 降到 30视觉差别其实不大但中继带宽占用能下降一半以上。同时在“网络”设置里勾选“压缩视频”CPU 占用会高一些但带宽消耗更温和。如果经常通过移动网络远程办公建议把所有设备都升级到较新版本新版本的编解码效率在低带宽下的表现比老版本好很多。这套方案我已经保持运行了大半年最深的体会是“自建远程桌面其实没有技术门槛门槛全在细节里”。端口、公钥、process 管理、防火墙每一环都简单但串起来时少一个环节就会掉链子。如果你也打算搭建私有远程桌面我希望这篇能帮你把每一个细节都提前想清楚省掉我自己当初踩坑的时间。最后再补充一个小经验把id_ed25519.pub内容备份到密码管理工具里服务器重装后直接复用客户端配置完全不用改这是整个维护过程中最省心的一招。