我自建 RustDesk 远程桌面服务跑了快两年从最初只在局域网里用到后来家里 NAS 做中继、公司服务器做转发中间踩了不少坑也把配置从“能用”折腾到了“好用”。这篇文章不聊大道理直接把整套方案的选型思路、部署细节、客户端配置和常见故障排查全放出来照着抄就能把服务搭起来。先说这玩意儿能解决什么问题RustDesk 是一款开源远程桌面软件自建服务器之后你可以拥有完全自主可控的 ID 服务器和中继服务器不再依赖公共服务器。对个人用户来说最大的收益是连接更快、隐私更安全、任何设备都能随时连回家对运维或团队场景来说自建服务器意味着所有会话流量都在自己可控的范围内不经过第三方既省钱又能做统一管理。适合家里有 NAS 或云服务器的玩家、中小企业IT管理员、经常跨设备远程办公的折腾党。整体结构上RustDesk 自建服务其实就三个角色一个是客户端程序装在需要被控和发起控制的设备上一个是 ID 服务器负责设备ID注册和点对点互通还有一个是中继服务器负责转发流量。理解了这三者的分工后面配置起来就会非常顺畅。下面我从方案选型开始一步步展开。1. 为什么自建RustDesk方案对比与整体思路1.1 商业远程软件与自建的核心矛盾早期我用 TeamViewer 和 AnyDesk免费版限制多连接时间长了掉线、个人用途判定模糊、跨网段速度不稳定都是老问题。向日葵则是在某些网络环境下有明显的卡顿感设备多了还得付费。商业远程软件的免费档位本质是给你个“试用体验”真拿来做日常主力效率会大打折扣。自建 RustDesk 的意义在于把“连接权”从别人的服务器拿回自己手里。ID 服务器和中继服务器部署在你有权限的机器上客户端连接时先去自己的 ID 服务器做认证和配对再根据网络情况选择直连或者走自己的中继。流量都在自己设备之间流动既不经过公共服务器也没有免费额度的限制想连多久连多久想开多少设备就开多少设备。当然自建也不是没有成本。你得有一台 24 小时在线的服务器或 NAS需要分配公网端口可能要买域名和证书还得花点时间维护。但这些成本折算下来比商业远程软件的订阅费低得多而且是一劳永逸的基础设施后面加设备、加人都不用再花钱。1.2 自建RustDesk的适用场景与边界自建方案适合哪些场景我总结下来主要是三类第一类是个人跨设备远程比如人在公司要连家里电脑取文件、做演示、跑批处理任务自建后不需要任何中转账号启动 RustDesk 输密码就连第二类是家庭媒体中心和 NAS 管理经常在外面要访问家里 NAS 的管理界面、看下载进度、调整 Docker 容器用 RustDesk 进内网再操作比直接暴露 NAS 端口安全得多第三类是团队内部的远程协助给一两台Windows机器做无人值守控制或者给同事远程协助处理问题自建服务器能让整个会话控制在内部网络环境中合规性也更好。边界也很清楚如果你的需求是随时随地连到一台完全没做端口映射、且两边网络都非常复杂的 Windows 电脑自建方案虽然能通过中继兜底但还是建议在网络出口设备上配置好端口转发把 UDP 和 TCP 的常用中继端口都打通体验才会有保障。另外自建服务不负责“内网穿透”本身的自动化如果你的服务器本身没有公网 IP那就需要配合 frp 之类的隧道工具但这不是 RustDesk 本身的问题。1.3 整体架构ID服务器、中继服务器与客户端的关系RustDesk 的架构非常像早期的 TeamViewer每台客户端启动后会生成一个固定 ID一串数字这个 ID 注册到你自建的 ID 服务器上。另一台设备要连接这个 ID 时客户端先去 ID 服务器查询目标设备当前地址在哪边能直连就直连不能直连就自动切换到中继服务器转发流量。可以这样类比ID 服务器等于一本电话簿记录着每台设备的“当前住址”中继服务器相当于一个高效快递站当两台设备因为 NAT 类型限制直接联系不上时快递站负责把数据包从一个口转进另一个口。客户端则是你手里的电话拨号靠电话簿ID服务器通话内容如果直接不通就走快递站中转。自建时最关键的一点是RustDesk 客户端默认使用官方公共服务器你必须把客户端配置里的 ID 服务器和中继服务器地址改成自己的。这个配置可以在客户端 GUI 里填也可以用命令行参数预先设置后面部署客户端部分我会给出具体方法。只要这一步没做好你搭建的服务器就是白搭客户端依然会连到公共服务器上去。2. 服务器端部署Docker、NAS与Windows全流程2.1 Docker快速部署公网VPS最简单的部署方式是用 Docker。RustDesk 官方提供了 rustdesk/rustdesk-server 镜像里面包含 hbbsID服务器和 hbbr中继服务器两个核心组件。我是在一台 2核4G 的云主机上跑的连接几台设备完全没问题带宽才是瓶颈。部署命令很简单但有几个参数要提前想清楚。官方镜像默认暴露的端口包括21115-21119TCP以及 21116 的 UDP。这些端口各有用途21115用于 NAT 类型探测TCP21116hbbs 主端口TCP/UDP 都要开UDP 用于 ID 注册和打洞TCP 用于保底连接21117hbbr 中继端口TCP21118网页客户端的 WebSocket 端口如果不需要网页端可以不映射我用 docker-compose 来管理配置如下version: 3 services: hbbs: container_name: hbbs image: rustdesk/rustdesk-server:latest command: hbbs -r 中继服务器域名或IP:21117 -k 公共KEY ports: - 21115:21115 - 21116:21116 - 21116:21116/udp volumes: - ./data:/root restart: unless-stopped hbbr: container_name: hbbr image: rustdesk/rustdesk-server:latest command: hbbr -k 公共KEY ports: - 21117:21117 volumes: - ./data:/root restart: unless-stopped启动之前先生成一个公共 Key这个 Key 会用于客户端和服务端通信加密相当于所有终端预先共享的密码。生成方式很简单在服务器上运行docker run --rm rustdesk/rustdesk-server-hbbs:latest hbbs -r example.com:21117第一次启动后会在数据目录下生成一个 id_ed25519.pub 文件那个文件里的内容就是 Key后面配客户端要用。所以更稳妥的操作是先把容器跑起来等它生成密钥文件再把这个文件的内容复制到客户端配置里。部署完记得在云服务商控制台和安全组里放开上面那五个端口不然外部客户端端口探测不通ID 服务器注册成功但中继连不上就会出现“能发现设备但连不上”的诡异现象这个问题我后面会在排查章节详细讲。2.2 NAS部署群晖/威联通/极空间NAS 用户其实是最适合自建 RustDesk 的群体因为设备本来就要 7x24 小时开着再跑两个轻量容器毫无压力。我在群晖上用的是 Container Manager旧版套件叫 Docker直接项目文件导入 docker-compose 配置就能跑。威联通和极空间的 Docker 界面也大同小异都是支持 compose 或 stack 方式。需要注意的一个点是如果你的 NAS 放在家庭内网且外网访问是通过路由器端口映射那除了映射 21115-21119 这几个 TCP 端口之外还要特别把 21116 的 UDP 映射出去。UDP 打洞是 RustDesk 能不能直连的关键很多 NAS 用户只映射了 TCP结果设备都能发现但一直走中继延迟高、画面卡还以为是服务器性能不够。实际上就是缺了 UDP 转发。另外NAS 上部署时最好把数据目录挂在独立卷里里面保存的密钥文件和数据库是关键数据。我见过有人在 Docker 升级时把容器删了重建结果密钥变了所有客户端的 Key 都得重新填写非常痛苦。挂载独立目录以后升级容器不会影响数据。2.3 Windows Server部署如果手头只有 Windows Server 或者一台长期开机的 Windows 老机器也不一定要装 Docker。RustDesk 官方仓库里有 Windows 可执行文件直接下载 hbbs.exe 和 hbbr.exe 放到一个目录里用命令行启动就行。我建议用命令行参数加上中继地址启动 hbbs不然默认配置下中继地址是空的客户端需要在界面上手动填写。hbbs.exe -r 中继服务器域名或IP:21117 hbbr.exe为了稳定运行最好注册成 Windows 服务或者用计划任务开机自启。注册成服务可以用 NSSMNon-Sucking Service Manager这个小工具把两个 exe 分别注册为 hbbs 和 hbbr 服务设置重启策略为“失败后自动重启”。家庭环境用 Windows 设备做服务器最大的坑是 Windows 更新自动重启建议把自动重启时间设定在凌晨没人用的时候同时把服务登录账号设为一个有自动登录权限的本地账号避免更新后卡在登录界面导致服务起不来。2.4 部署后的基础验证无论用哪种方式部署最后都要做一次基础验证。在服务器本机用 telnet 或 nc 测试端口是否在监听nc -vz localhost 21116 nc -vz localhost 21117再用手机流量不连家庭WiFi启动一个 RustDesk 客户端把客户端配置指向你的服务器然后查看日志中注册是否成功。最简单的方式是直接用本机客户端连一次手机客户端如果能通过 ID 找到设备并建立连接说明 ID 服务器和中继服务器都通了。如果发现端口监听正常但客户端注册失败优先检查安全组和防火墙。3. 客户端接入与关键配置3.1 Windows客户端安装与配置客户端安装很简单从 RustDesk 官网下载对应平台版本直接装。但配置这一步很多新手会忽略——默认配置连的是官方公共服务器肯定不会走你自建的节点。打开 RustDesk 主界面在左侧的“ID/中继服务器”一栏里把 ID 服务器地址填成你服务器的 IP 或域名Key 填成前面生成的 id_ed25519.pub 内容然后点“OK”。填写后客户端会重新启动服务进程几秒后就能看到“就绪”状态此时 ID 注册到的就是你自己的服务器了。我发现一个很方便的批量做法把要分发的客户端目录下的 rustdesk2.toml或者旧版本的 RustDesk.toml预先写好服务器地址和 Key然后连同安装程序一起打包分发。这样同事或者家人的电脑装完就是默认使用你的服务器不需要手动配置对不熟悉电脑的人特别友好。配置文件内容大概是这样[options] custom-rendezvous-server 你的服务器域名或IP custom-relay-server 你的服务器域名或IP key 这里填pub文件里的内容 api-server https://你的服务器地址注意不同版本的配置字段名可能略有差异建议先在测试机上填一次然后看生成的配置文件内容照着改格式即可。RustDesk 的配置文件放在用户目录下的 AppData/Roaming/RustDesk 目录里。3.2 Ubuntu/Linux客户端接入Linux 客户端的安装有两种方式一种是直接下载官方 .deb 或 .rpm 包安装另一种是下载源码编译但没必要官方发布页针对主流发行版都提供了现成包。Ubuntu 安装命令wget https://github.com/rustdesk/rustdesk/releases/download/版本号/rustdesk-版本号-x86_64.deb sudo dpkg -i rustdesk-版本号-x86_64.deb sudo apt-get install -f # 处理依赖装完以后Linux 客户端同样需要在图形界面里填写服务器配置。如果在无桌面环境或者批量部署的场景可以用命令行直接写入配置。RustDesk 支持通过参数启动并预置配置但最简单的方式是直接用文本编辑器修改配置文件路径在 ~/.config/rustdesk/RustDesk.toml。填好服务器和 Key 后重启客户端即可。在 Linux 上做被控端时有一个坑如果不开桌面登录RustDesk 进程可能在用户未登录状态下无法启动导致远程连接时看到黑屏或登录界面。解决方法是把 RustDesk 加到系统服务里并设置自动登录或者开机后手动启动一次 RustDesk。Ubuntu 桌面版一般会自动启动但如果你配置了自动登录或者使用轻量桌面管理器需要额外确认进程是否存在。3.3 Android/iOS客户端与多设备场景手机端客户端的配置方式和桌面端类似在“设置”里找到“ID/中继服务器”填入服务器信息即可。Android 端要注意的是后台运行的权限设置否则锁屏一段时间后连接会断开。国产手机上尤其要注意需要在电池优化白名单里加入 RustDesk并在“自启动管理”里允许它在后台运行不然系统一杀进程远程控制就断了。iOS 端稍微省心一点系统对后台保活管理比较严格但也别指望锁屏后还能长时间保持被控。iOS 端更多是作为发起端去连接电脑用来看文件、做演示、紧急处理问题。我自己的使用习惯是iPad 上装好客户端配合键盘在外面处理公司电脑的事务比背电脑轻多了。多设备场景下我建议给每台设备设置一个容易识别的别名。RustDesk 默认显示 ID 和主机名跨设备多了以后界面上一串数字根本分不清是哪台。在客户端设置里把设备名改成类似“公司工作站”“家里NAS主机”“客厅HTPC”这样的名称登录到同一服务器后设备列表一目了然。3.4 如何判断流量是否走自己的服务器很多朋友配置完以后不确定流量是不是真的走自己的服务器这里教大家两个简单验证方法。第一观察连接建立后的延迟在客户端连接窗口的标题栏或不明显位置RustDesk 会显示当前的连接模式和延迟如果你看到延迟只有几毫秒到十几毫秒且走的是直连说明打洞成功如果一直是几十毫秒以上且提示中继可能在走服务器转发。第二看服务器端日志hbbs 和 hbbr 的日志里会有对应 IP 的连接记录如果看到大量来自客户端 IP 的接入说明确实在用你的服务器。最直接的方法是先断开服务器外网再尝试连接。如果自建服务器断开后客户端完全连不上说明配置生效、流量依赖你的服务器如果还能连上那说明客户端仍在使用公共服务器兜底配置没生效重新检查一下 Key 和地址是否填反了。4. 常见问题排查与性能调优4.1 连接超时、卡顿与白屏处理搭建服务后最常见的故障是“能注册但连不上”和“连上以后画面卡顿”。前者的根本原因九成是端口没有完全放通特别是 21116 的 UDP 被防火墙拦截导致 NAT 穿透无法建立。排查方法是用客户端连接时同时观察服务器日志如果 hbbr 日志里能看到连接请求但应答慢多半是中继端口不通如果 hbbs 日志里根本没有注册请求那就是客户端地址填错了。卡顿问题则要分清是网络瓶颈还是图像编码瓶颈。如果卡顿只出现在跨运营商网络下优先检查是否走了中继而不是直连中继模式对带宽消耗大服务器的上行带宽决定了流畅度上限。如果画面是间歇性模糊然后突然清晰多半是图像编码参数设置不合理可以在连接窗口的显示设置里调整画质和帧率。对于普通办公操作建议设置为“清晰”模式加 30 帧不需要用“最佳质量”模式那个模式会占用大量带宽实际体验反而容易卡。白屏通常是 GPU 加速问题。远程连接时目标电脑的显卡驱动如果不太兼容RustDesk 的硬件编码会出现白屏或画面撕裂。遇到这种情况在连接设置里把“硬件编码”开关关掉改用软件编码问题一般就解决了。虽然 CPU 占用会高一点但稳定性好很多。4.2 WSL2与RDP ActiveX控件报错的区分网上有一个很常见的报错“无法加载远程桌面服务 ActiveX 控件”有朋友会误以为是 RustDesk 的问题其实这完全是两个东西。这个报错来自 Windows 自带的远程桌面连接mstsc报错信息提示“请确保 rdclientax.dll 在路径中”本质是 Windows 远程桌面组件损坏或程序不完整和 RustDesk 没有关系。我遇到过用 WSL2 开发时偶尔要打开 Windows 自带远程桌面访问其他机器结果出现这个 ActiveX 报错。排查步骤是先检查系统文件完整性用命令提示符管理员运行sfc /scannow如果没修复再重新注册 rdclientax.dll命令是regsvr32 rdclientax.dll。这不是 RustDesk 的故障不用去重启 hbbs 服务。但这里有一个容易混淆的点如果你在 Windows 上同时启用了系统远程桌面服务RDP又装了 RustDesk端口监听可能会让人疑惑。RDP 监听的是 3389 端口RustDesk 是 21115-21119两者互不干扰。有些运维同事喜欢 RDP 加 RustDesk 双通道兜底一旦 RDP 因为系统更新或安全策略被禁用RustDesk 还能作为备用入口接进去处理这也是我推荐的组合方式。4.3 组策略与Windows远程桌面服务配置既然提到 Windows 远程桌面就多说一句很多公司环境为了安全会通过组策略限制远程桌面会话。路径是“计算机配置 - 管理模板 - Windows 组件 - 远程桌面服务 - 远程桌面会话主机”里面有连接数限制、会话超时、加密级别等策略。如果你把 RustDesk 作为远程入口同时想保留 RDP 作为备用建议检查这些策略是否限制了并发会话数。有一种很常见的坑服务器本身设置了“限制连接数量为1”当你已经用 RDP 登录了再远程协助进系统时会被踢出或者提示已满你会误以为是 RustDesk 连不上。实际上这是 Windows 会话机制的问题不是自建服务器的问题。解决办法是在组策略里调高最大连接数或者规划好主用和备用通道的登录顺序。另外如果要用网页版控制台管理 RustDesk 服务器需要额外配置 21118/21119 端口的 WebSocket 支持。我搭建初期没开这俩端口本地测试网页端一直白屏排查了半天才发现是安全组没放行。网页端不是主力功能但偶尔用手机浏览器应急管理一下也挺方便建议顺手开掉。4.4 性能调优带宽、CPU与帧率设置RustDesk 的性能瓶颈通常不在 CPU而在网络带宽和延迟。中继服务器部署在云主机时购买的带宽直接决定了多路远程的质量。我自己测试过1Mbps 上行带宽只能勉强应付 720p 静态画面5Mbps 上行1080p 用“均衡”模式基本流畅如果是 10Mbps 及以上才能比较舒服地跑“清晰”模式加 60 帧。如果服务器带宽有限可以在客户端默认设置里把画质和帧率调低。远程办公场景30 帧加 720p 足够鼠标移动和文字输入都不会有迟滞感。远程看视频或演示动画的场景再临时手动调高画质。不要一上来就开 4K 高帧率那会直接把中继带宽打满其他设备全都跟着卡。CPU 方面需要注意的是硬件编码和软件编码的选择。被控端如果 CPU 较老开硬件编码反而可能出问题而现代 CPU 都有 Quick Sync 或 NVENC 之类的硬件编码器开启后能大幅降低 CPU 占用。具体取舍可以在连接设置里切换对比一下以“任务管理器占CPU不超过30%且画面不撕裂”为准。5. 安全加固与长期运维要点5.1 端口与防火墙策略自建服务最怕的是把端口裸奔在公网。RustDesk 的端口不像 Web 服务可以套 HTTPS 证书自动加密如果你直接开放全部端口等于让别人可以随意扫描到你的 hbbs 和 hbbr 服务。我的做法是在云服务器安全组层面只对常用来源 IP 段开放管理端口对 RustDesk 的端口也尽量限制来源 IP比如只允许公司出口 IP 和自己家庭宽带的动态 IP 规则虽然动态 IP 不便限制但至少能把大范围扫描挡掉定期查看服务器日志观察是否有来自陌生 IP 的探测连接。如果你的服务器还跑了 Web 管理界面务必把管理服务绑定在内网地址或加认证不要暴露到公网。RustDesk 本身的管理功能有限但服务器上如果同时运行着其他服务整体安全配置要统一考虑。5.2 密钥管理与访问控制RustDesk 的 Key就是 id_ed25519.pub 里的字符串相当于所有客户端共享的密码。一旦这个 Key 泄露任何知道 Key 和服务器地址的人都能注册到你的服务器上如果你的端口又开着匿名注册对方甚至能直接发起连接请求。我有一次就是 Key 在团队聊天里发过后来发现有陌生设备出现在设备列表里赶紧换了 Key。换 Key 的流程是先在服务器端停止 hbbs 和 hbbr删除或备份旧的 id_ed25519 和 id_ed25519.pub 文件然后重启服务生成新 Key再同步修改所有客户端的 Key。这个过程会中断所有远程连接所以尽量选择深夜或者维护窗口操作。最好的做法是提前规划好哪些设备需要接入把 Key 通过加密渠道分发不要明文转发。另一个建议是给无人值守的电脑设置强密码。RustDesk 支持设置“永久密码”和 Windows 账号无关是 RustDesk 自有的访问密码。这个密码不要和其他账号密码相同长度至少 12 位以上。在客户端设置里开启“允许直接连接”每次远程连接时输入密码即可这样即使有陌生 ID 知道你的设备 ID也过不了密码这一关。5.3 证书与加密配置RustDesk 自建服务默认情况下传输是不走 TLS 的但官方版本在客户端配置里支持填写服务器地址时用hbbs://或直接填写 IP底层通信有基于 Key 的加密安全性足够应对个人和中小团队场景。如果你有更高的安全要求可以给 RustDesk 服务器套一层 TLS 反向代理但整体配置复杂度会提升个人使用没必要。更实际的加密建议是不管用不用 TLS一定要保证 Key 的私密性和中继端口的干净。hbbr 中继服务会转发所有经过它的流量哪怕数据内容是加密的流量特征依然能暴露通信模式。如果对隐私敏感建议把中继服务器放在自己的私有网络环境比如家里或公司机房而不是公共云主机上。5.4 备份与版本更新Docker 部署的更新非常方便docker compose pull加docker compose up -d就能升级。但升级前一定记得备份数据目录尤其是 hbbs 的密钥文件。RustDesk 服务端的设备注册信息都集中在数据目录里备份好这个目录换服务器迁移时直接拷过去就行客户端的 ID 和 Key 都不用变。我在实际运维中遇到过一个问题某次镜像升级后新版本 hbbs 的配置项格式有变化导致旧的启动参数按原样启动时报错。解决方案是升级前先去官方 GitHub Releases 页面看一眼版本说明确认没有破坏性变更再动手。如果是 NAS 部署的容器建议用镜像标签锁版本比如rustdesk-server:1.1.14不要用 latest这样方便回滚。6. 一些实操中的体会最后说点个人经验。RustDesk 自建服务最大的价值不是“免费替代商业软件”而是“所有东西都能自己掌控”。我家里 NAS 上跑着 hbbs/hbbr公司一台云主机也跑着一套两边配置几乎一样。云主机那套用来在公司内网访问客户设备NAS 那套专门服务家庭设备。两套之间用不同 Key 隔离互不干扰又都能在手机端一键接入。踩过几次坑之后我现在每次部署都会按这个清单自查端口是否全开含 UDP、Key 是否分发到位、客户端配置文件是否预置好、设备列表里能否看到新注册的 ID。四步都没问题基本不会翻车。RustDesk 还在持续更新客户端和服务端的功能越来越完善但目前这套自建架构已经很稳定了。如果看完文章还有不确定的地方建议先在自己的局域网环境搭一套测试环境再慢慢扩展到公网试错成本会低很多。 
长河君 · 2026/9/19 10:21:48 · 阅读 1.2k RustDesk自建远程桌面服务器：部署、配置与安全加固完整指南
我自建 RustDesk 远程桌面服务跑了快两年从最初只在局域网里用到后来家里 NAS 做中继、公司服务器做转发中间踩了不少坑也把配置从“能用”折腾到了“好用”。这篇文章不聊大道理直接把整套方案的选型思路、部署细节、客户端配置和常见故障排查全放出来照着抄就能把服务搭起来。先说这玩意儿能解决什么问题RustDesk 是一款开源远程桌面软件自建服务器之后你可以拥有完全自主可控的 ID 服务器和中继服务器不再依赖公共服务器。对个人用户来说最大的收益是连接更快、隐私更安全、任何设备都能随时连回家对运维或团队场景来说自建服务器意味着所有会话流量都在自己可控的范围内不经过第三方既省钱又能做统一管理。适合家里有 NAS 或云服务器的玩家、中小企业IT管理员、经常跨设备远程办公的折腾党。整体结构上RustDesk 自建服务其实就三个角色一个是客户端程序装在需要被控和发起控制的设备上一个是 ID 服务器负责设备ID注册和点对点互通还有一个是中继服务器负责转发流量。理解了这三者的分工后面配置起来就会非常顺畅。下面我从方案选型开始一步步展开。1. 为什么自建RustDesk方案对比与整体思路1.1 商业远程软件与自建的核心矛盾早期我用 TeamViewer 和 AnyDesk免费版限制多连接时间长了掉线、个人用途判定模糊、跨网段速度不稳定都是老问题。向日葵则是在某些网络环境下有明显的卡顿感设备多了还得付费。商业远程软件的免费档位本质是给你个“试用体验”真拿来做日常主力效率会大打折扣。自建 RustDesk 的意义在于把“连接权”从别人的服务器拿回自己手里。ID 服务器和中继服务器部署在你有权限的机器上客户端连接时先去自己的 ID 服务器做认证和配对再根据网络情况选择直连或者走自己的中继。流量都在自己设备之间流动既不经过公共服务器也没有免费额度的限制想连多久连多久想开多少设备就开多少设备。当然自建也不是没有成本。你得有一台 24 小时在线的服务器或 NAS需要分配公网端口可能要买域名和证书还得花点时间维护。但这些成本折算下来比商业远程软件的订阅费低得多而且是一劳永逸的基础设施后面加设备、加人都不用再花钱。1.2 自建RustDesk的适用场景与边界自建方案适合哪些场景我总结下来主要是三类第一类是个人跨设备远程比如人在公司要连家里电脑取文件、做演示、跑批处理任务自建后不需要任何中转账号启动 RustDesk 输密码就连第二类是家庭媒体中心和 NAS 管理经常在外面要访问家里 NAS 的管理界面、看下载进度、调整 Docker 容器用 RustDesk 进内网再操作比直接暴露 NAS 端口安全得多第三类是团队内部的远程协助给一两台Windows机器做无人值守控制或者给同事远程协助处理问题自建服务器能让整个会话控制在内部网络环境中合规性也更好。边界也很清楚如果你的需求是随时随地连到一台完全没做端口映射、且两边网络都非常复杂的 Windows 电脑自建方案虽然能通过中继兜底但还是建议在网络出口设备上配置好端口转发把 UDP 和 TCP 的常用中继端口都打通体验才会有保障。另外自建服务不负责“内网穿透”本身的自动化如果你的服务器本身没有公网 IP那就需要配合 frp 之类的隧道工具但这不是 RustDesk 本身的问题。1.3 整体架构ID服务器、中继服务器与客户端的关系RustDesk 的架构非常像早期的 TeamViewer每台客户端启动后会生成一个固定 ID一串数字这个 ID 注册到你自建的 ID 服务器上。另一台设备要连接这个 ID 时客户端先去 ID 服务器查询目标设备当前地址在哪边能直连就直连不能直连就自动切换到中继服务器转发流量。可以这样类比ID 服务器等于一本电话簿记录着每台设备的“当前住址”中继服务器相当于一个高效快递站当两台设备因为 NAT 类型限制直接联系不上时快递站负责把数据包从一个口转进另一个口。客户端则是你手里的电话拨号靠电话簿ID服务器通话内容如果直接不通就走快递站中转。自建时最关键的一点是RustDesk 客户端默认使用官方公共服务器你必须把客户端配置里的 ID 服务器和中继服务器地址改成自己的。这个配置可以在客户端 GUI 里填也可以用命令行参数预先设置后面部署客户端部分我会给出具体方法。只要这一步没做好你搭建的服务器就是白搭客户端依然会连到公共服务器上去。2. 服务器端部署Docker、NAS与Windows全流程2.1 Docker快速部署公网VPS最简单的部署方式是用 Docker。RustDesk 官方提供了 rustdesk/rustdesk-server 镜像里面包含 hbbsID服务器和 hbbr中继服务器两个核心组件。我是在一台 2核4G 的云主机上跑的连接几台设备完全没问题带宽才是瓶颈。部署命令很简单但有几个参数要提前想清楚。官方镜像默认暴露的端口包括21115-21119TCP以及 21116 的 UDP。这些端口各有用途21115用于 NAT 类型探测TCP21116hbbs 主端口TCP/UDP 都要开UDP 用于 ID 注册和打洞TCP 用于保底连接21117hbbr 中继端口TCP21118网页客户端的 WebSocket 端口如果不需要网页端可以不映射我用 docker-compose 来管理配置如下version: 3 services: hbbs: container_name: hbbs image: rustdesk/rustdesk-server:latest command: hbbs -r 中继服务器域名或IP:21117 -k 公共KEY ports: - 21115:21115 - 21116:21116 - 21116:21116/udp volumes: - ./data:/root restart: unless-stopped hbbr: container_name: hbbr image: rustdesk/rustdesk-server:latest command: hbbr -k 公共KEY ports: - 21117:21117 volumes: - ./data:/root restart: unless-stopped启动之前先生成一个公共 Key这个 Key 会用于客户端和服务端通信加密相当于所有终端预先共享的密码。生成方式很简单在服务器上运行docker run --rm rustdesk/rustdesk-server-hbbs:latest hbbs -r example.com:21117第一次启动后会在数据目录下生成一个 id_ed25519.pub 文件那个文件里的内容就是 Key后面配客户端要用。所以更稳妥的操作是先把容器跑起来等它生成密钥文件再把这个文件的内容复制到客户端配置里。部署完记得在云服务商控制台和安全组里放开上面那五个端口不然外部客户端端口探测不通ID 服务器注册成功但中继连不上就会出现“能发现设备但连不上”的诡异现象这个问题我后面会在排查章节详细讲。2.2 NAS部署群晖/威联通/极空间NAS 用户其实是最适合自建 RustDesk 的群体因为设备本来就要 7x24 小时开着再跑两个轻量容器毫无压力。我在群晖上用的是 Container Manager旧版套件叫 Docker直接项目文件导入 docker-compose 配置就能跑。威联通和极空间的 Docker 界面也大同小异都是支持 compose 或 stack 方式。需要注意的一个点是如果你的 NAS 放在家庭内网且外网访问是通过路由器端口映射那除了映射 21115-21119 这几个 TCP 端口之外还要特别把 21116 的 UDP 映射出去。UDP 打洞是 RustDesk 能不能直连的关键很多 NAS 用户只映射了 TCP结果设备都能发现但一直走中继延迟高、画面卡还以为是服务器性能不够。实际上就是缺了 UDP 转发。另外NAS 上部署时最好把数据目录挂在独立卷里里面保存的密钥文件和数据库是关键数据。我见过有人在 Docker 升级时把容器删了重建结果密钥变了所有客户端的 Key 都得重新填写非常痛苦。挂载独立目录以后升级容器不会影响数据。2.3 Windows Server部署如果手头只有 Windows Server 或者一台长期开机的 Windows 老机器也不一定要装 Docker。RustDesk 官方仓库里有 Windows 可执行文件直接下载 hbbs.exe 和 hbbr.exe 放到一个目录里用命令行启动就行。我建议用命令行参数加上中继地址启动 hbbs不然默认配置下中继地址是空的客户端需要在界面上手动填写。hbbs.exe -r 中继服务器域名或IP:21117 hbbr.exe为了稳定运行最好注册成 Windows 服务或者用计划任务开机自启。注册成服务可以用 NSSMNon-Sucking Service Manager这个小工具把两个 exe 分别注册为 hbbs 和 hbbr 服务设置重启策略为“失败后自动重启”。家庭环境用 Windows 设备做服务器最大的坑是 Windows 更新自动重启建议把自动重启时间设定在凌晨没人用的时候同时把服务登录账号设为一个有自动登录权限的本地账号避免更新后卡在登录界面导致服务起不来。2.4 部署后的基础验证无论用哪种方式部署最后都要做一次基础验证。在服务器本机用 telnet 或 nc 测试端口是否在监听nc -vz localhost 21116 nc -vz localhost 21117再用手机流量不连家庭WiFi启动一个 RustDesk 客户端把客户端配置指向你的服务器然后查看日志中注册是否成功。最简单的方式是直接用本机客户端连一次手机客户端如果能通过 ID 找到设备并建立连接说明 ID 服务器和中继服务器都通了。如果发现端口监听正常但客户端注册失败优先检查安全组和防火墙。3. 客户端接入与关键配置3.1 Windows客户端安装与配置客户端安装很简单从 RustDesk 官网下载对应平台版本直接装。但配置这一步很多新手会忽略——默认配置连的是官方公共服务器肯定不会走你自建的节点。打开 RustDesk 主界面在左侧的“ID/中继服务器”一栏里把 ID 服务器地址填成你服务器的 IP 或域名Key 填成前面生成的 id_ed25519.pub 内容然后点“OK”。填写后客户端会重新启动服务进程几秒后就能看到“就绪”状态此时 ID 注册到的就是你自己的服务器了。我发现一个很方便的批量做法把要分发的客户端目录下的 rustdesk2.toml或者旧版本的 RustDesk.toml预先写好服务器地址和 Key然后连同安装程序一起打包分发。这样同事或者家人的电脑装完就是默认使用你的服务器不需要手动配置对不熟悉电脑的人特别友好。配置文件内容大概是这样[options] custom-rendezvous-server 你的服务器域名或IP custom-relay-server 你的服务器域名或IP key 这里填pub文件里的内容 api-server https://你的服务器地址注意不同版本的配置字段名可能略有差异建议先在测试机上填一次然后看生成的配置文件内容照着改格式即可。RustDesk 的配置文件放在用户目录下的 AppData/Roaming/RustDesk 目录里。3.2 Ubuntu/Linux客户端接入Linux 客户端的安装有两种方式一种是直接下载官方 .deb 或 .rpm 包安装另一种是下载源码编译但没必要官方发布页针对主流发行版都提供了现成包。Ubuntu 安装命令wget https://github.com/rustdesk/rustdesk/releases/download/版本号/rustdesk-版本号-x86_64.deb sudo dpkg -i rustdesk-版本号-x86_64.deb sudo apt-get install -f # 处理依赖装完以后Linux 客户端同样需要在图形界面里填写服务器配置。如果在无桌面环境或者批量部署的场景可以用命令行直接写入配置。RustDesk 支持通过参数启动并预置配置但最简单的方式是直接用文本编辑器修改配置文件路径在 ~/.config/rustdesk/RustDesk.toml。填好服务器和 Key 后重启客户端即可。在 Linux 上做被控端时有一个坑如果不开桌面登录RustDesk 进程可能在用户未登录状态下无法启动导致远程连接时看到黑屏或登录界面。解决方法是把 RustDesk 加到系统服务里并设置自动登录或者开机后手动启动一次 RustDesk。Ubuntu 桌面版一般会自动启动但如果你配置了自动登录或者使用轻量桌面管理器需要额外确认进程是否存在。3.3 Android/iOS客户端与多设备场景手机端客户端的配置方式和桌面端类似在“设置”里找到“ID/中继服务器”填入服务器信息即可。Android 端要注意的是后台运行的权限设置否则锁屏一段时间后连接会断开。国产手机上尤其要注意需要在电池优化白名单里加入 RustDesk并在“自启动管理”里允许它在后台运行不然系统一杀进程远程控制就断了。iOS 端稍微省心一点系统对后台保活管理比较严格但也别指望锁屏后还能长时间保持被控。iOS 端更多是作为发起端去连接电脑用来看文件、做演示、紧急处理问题。我自己的使用习惯是iPad 上装好客户端配合键盘在外面处理公司电脑的事务比背电脑轻多了。多设备场景下我建议给每台设备设置一个容易识别的别名。RustDesk 默认显示 ID 和主机名跨设备多了以后界面上一串数字根本分不清是哪台。在客户端设置里把设备名改成类似“公司工作站”“家里NAS主机”“客厅HTPC”这样的名称登录到同一服务器后设备列表一目了然。3.4 如何判断流量是否走自己的服务器很多朋友配置完以后不确定流量是不是真的走自己的服务器这里教大家两个简单验证方法。第一观察连接建立后的延迟在客户端连接窗口的标题栏或不明显位置RustDesk 会显示当前的连接模式和延迟如果你看到延迟只有几毫秒到十几毫秒且走的是直连说明打洞成功如果一直是几十毫秒以上且提示中继可能在走服务器转发。第二看服务器端日志hbbs 和 hbbr 的日志里会有对应 IP 的连接记录如果看到大量来自客户端 IP 的接入说明确实在用你的服务器。最直接的方法是先断开服务器外网再尝试连接。如果自建服务器断开后客户端完全连不上说明配置生效、流量依赖你的服务器如果还能连上那说明客户端仍在使用公共服务器兜底配置没生效重新检查一下 Key 和地址是否填反了。4. 常见问题排查与性能调优4.1 连接超时、卡顿与白屏处理搭建服务后最常见的故障是“能注册但连不上”和“连上以后画面卡顿”。前者的根本原因九成是端口没有完全放通特别是 21116 的 UDP 被防火墙拦截导致 NAT 穿透无法建立。排查方法是用客户端连接时同时观察服务器日志如果 hbbr 日志里能看到连接请求但应答慢多半是中继端口不通如果 hbbs 日志里根本没有注册请求那就是客户端地址填错了。卡顿问题则要分清是网络瓶颈还是图像编码瓶颈。如果卡顿只出现在跨运营商网络下优先检查是否走了中继而不是直连中继模式对带宽消耗大服务器的上行带宽决定了流畅度上限。如果画面是间歇性模糊然后突然清晰多半是图像编码参数设置不合理可以在连接窗口的显示设置里调整画质和帧率。对于普通办公操作建议设置为“清晰”模式加 30 帧不需要用“最佳质量”模式那个模式会占用大量带宽实际体验反而容易卡。白屏通常是 GPU 加速问题。远程连接时目标电脑的显卡驱动如果不太兼容RustDesk 的硬件编码会出现白屏或画面撕裂。遇到这种情况在连接设置里把“硬件编码”开关关掉改用软件编码问题一般就解决了。虽然 CPU 占用会高一点但稳定性好很多。4.2 WSL2与RDP ActiveX控件报错的区分网上有一个很常见的报错“无法加载远程桌面服务 ActiveX 控件”有朋友会误以为是 RustDesk 的问题其实这完全是两个东西。这个报错来自 Windows 自带的远程桌面连接mstsc报错信息提示“请确保 rdclientax.dll 在路径中”本质是 Windows 远程桌面组件损坏或程序不完整和 RustDesk 没有关系。我遇到过用 WSL2 开发时偶尔要打开 Windows 自带远程桌面访问其他机器结果出现这个 ActiveX 报错。排查步骤是先检查系统文件完整性用命令提示符管理员运行sfc /scannow如果没修复再重新注册 rdclientax.dll命令是regsvr32 rdclientax.dll。这不是 RustDesk 的故障不用去重启 hbbs 服务。但这里有一个容易混淆的点如果你在 Windows 上同时启用了系统远程桌面服务RDP又装了 RustDesk端口监听可能会让人疑惑。RDP 监听的是 3389 端口RustDesk 是 21115-21119两者互不干扰。有些运维同事喜欢 RDP 加 RustDesk 双通道兜底一旦 RDP 因为系统更新或安全策略被禁用RustDesk 还能作为备用入口接进去处理这也是我推荐的组合方式。4.3 组策略与Windows远程桌面服务配置既然提到 Windows 远程桌面就多说一句很多公司环境为了安全会通过组策略限制远程桌面会话。路径是“计算机配置 - 管理模板 - Windows 组件 - 远程桌面服务 - 远程桌面会话主机”里面有连接数限制、会话超时、加密级别等策略。如果你把 RustDesk 作为远程入口同时想保留 RDP 作为备用建议检查这些策略是否限制了并发会话数。有一种很常见的坑服务器本身设置了“限制连接数量为1”当你已经用 RDP 登录了再远程协助进系统时会被踢出或者提示已满你会误以为是 RustDesk 连不上。实际上这是 Windows 会话机制的问题不是自建服务器的问题。解决办法是在组策略里调高最大连接数或者规划好主用和备用通道的登录顺序。另外如果要用网页版控制台管理 RustDesk 服务器需要额外配置 21118/21119 端口的 WebSocket 支持。我搭建初期没开这俩端口本地测试网页端一直白屏排查了半天才发现是安全组没放行。网页端不是主力功能但偶尔用手机浏览器应急管理一下也挺方便建议顺手开掉。4.4 性能调优带宽、CPU与帧率设置RustDesk 的性能瓶颈通常不在 CPU而在网络带宽和延迟。中继服务器部署在云主机时购买的带宽直接决定了多路远程的质量。我自己测试过1Mbps 上行带宽只能勉强应付 720p 静态画面5Mbps 上行1080p 用“均衡”模式基本流畅如果是 10Mbps 及以上才能比较舒服地跑“清晰”模式加 60 帧。如果服务器带宽有限可以在客户端默认设置里把画质和帧率调低。远程办公场景30 帧加 720p 足够鼠标移动和文字输入都不会有迟滞感。远程看视频或演示动画的场景再临时手动调高画质。不要一上来就开 4K 高帧率那会直接把中继带宽打满其他设备全都跟着卡。CPU 方面需要注意的是硬件编码和软件编码的选择。被控端如果 CPU 较老开硬件编码反而可能出问题而现代 CPU 都有 Quick Sync 或 NVENC 之类的硬件编码器开启后能大幅降低 CPU 占用。具体取舍可以在连接设置里切换对比一下以“任务管理器占CPU不超过30%且画面不撕裂”为准。5. 安全加固与长期运维要点5.1 端口与防火墙策略自建服务最怕的是把端口裸奔在公网。RustDesk 的端口不像 Web 服务可以套 HTTPS 证书自动加密如果你直接开放全部端口等于让别人可以随意扫描到你的 hbbs 和 hbbr 服务。我的做法是在云服务器安全组层面只对常用来源 IP 段开放管理端口对 RustDesk 的端口也尽量限制来源 IP比如只允许公司出口 IP 和自己家庭宽带的动态 IP 规则虽然动态 IP 不便限制但至少能把大范围扫描挡掉定期查看服务器日志观察是否有来自陌生 IP 的探测连接。如果你的服务器还跑了 Web 管理界面务必把管理服务绑定在内网地址或加认证不要暴露到公网。RustDesk 本身的管理功能有限但服务器上如果同时运行着其他服务整体安全配置要统一考虑。5.2 密钥管理与访问控制RustDesk 的 Key就是 id_ed25519.pub 里的字符串相当于所有客户端共享的密码。一旦这个 Key 泄露任何知道 Key 和服务器地址的人都能注册到你的服务器上如果你的端口又开着匿名注册对方甚至能直接发起连接请求。我有一次就是 Key 在团队聊天里发过后来发现有陌生设备出现在设备列表里赶紧换了 Key。换 Key 的流程是先在服务器端停止 hbbs 和 hbbr删除或备份旧的 id_ed25519 和 id_ed25519.pub 文件然后重启服务生成新 Key再同步修改所有客户端的 Key。这个过程会中断所有远程连接所以尽量选择深夜或者维护窗口操作。最好的做法是提前规划好哪些设备需要接入把 Key 通过加密渠道分发不要明文转发。另一个建议是给无人值守的电脑设置强密码。RustDesk 支持设置“永久密码”和 Windows 账号无关是 RustDesk 自有的访问密码。这个密码不要和其他账号密码相同长度至少 12 位以上。在客户端设置里开启“允许直接连接”每次远程连接时输入密码即可这样即使有陌生 ID 知道你的设备 ID也过不了密码这一关。5.3 证书与加密配置RustDesk 自建服务默认情况下传输是不走 TLS 的但官方版本在客户端配置里支持填写服务器地址时用hbbs://或直接填写 IP底层通信有基于 Key 的加密安全性足够应对个人和中小团队场景。如果你有更高的安全要求可以给 RustDesk 服务器套一层 TLS 反向代理但整体配置复杂度会提升个人使用没必要。更实际的加密建议是不管用不用 TLS一定要保证 Key 的私密性和中继端口的干净。hbbr 中继服务会转发所有经过它的流量哪怕数据内容是加密的流量特征依然能暴露通信模式。如果对隐私敏感建议把中继服务器放在自己的私有网络环境比如家里或公司机房而不是公共云主机上。5.4 备份与版本更新Docker 部署的更新非常方便docker compose pull加docker compose up -d就能升级。但升级前一定记得备份数据目录尤其是 hbbs 的密钥文件。RustDesk 服务端的设备注册信息都集中在数据目录里备份好这个目录换服务器迁移时直接拷过去就行客户端的 ID 和 Key 都不用变。我在实际运维中遇到过一个问题某次镜像升级后新版本 hbbs 的配置项格式有变化导致旧的启动参数按原样启动时报错。解决方案是升级前先去官方 GitHub Releases 页面看一眼版本说明确认没有破坏性变更再动手。如果是 NAS 部署的容器建议用镜像标签锁版本比如rustdesk-server:1.1.14不要用 latest这样方便回滚。6. 一些实操中的体会最后说点个人经验。RustDesk 自建服务最大的价值不是“免费替代商业软件”而是“所有东西都能自己掌控”。我家里 NAS 上跑着 hbbs/hbbr公司一台云主机也跑着一套两边配置几乎一样。云主机那套用来在公司内网访问客户设备NAS 那套专门服务家庭设备。两套之间用不同 Key 隔离互不干扰又都能在手机端一键接入。踩过几次坑之后我现在每次部署都会按这个清单自查端口是否全开含 UDP、Key 是否分发到位、客户端配置文件是否预置好、设备列表里能否看到新注册的 ID。四步都没问题基本不会翻车。RustDesk 还在持续更新客户端和服务端的功能越来越完善但目前这套自建架构已经很稳定了。如果看完文章还有不确定的地方建议先在自己的局域网环境搭一套测试环境再慢慢扩展到公网试错成本会低很多。