自建 RustDesk 专属远程桌面服务：从 Docker/二进制双路部署到多端免配打包实战

前言：为什么我们需要自建 RustDesk？

在远程办公与技术支持的日常工作中，远程桌面软件几乎是每个技术团队的刚需。然而，传统的商业远程桌面软件（如 TeamViewer、ToDesk、向日葵等）正面临着越来越多的痛点：

• 限速与高额收费：免费版经常遭遇无情的连接中断与严重的限速，想要流畅画质必须支付昂贵的年费。
• 隐私与安全隐患：所有数据中继均通过商业软件的公共云服务器，对于金融、政企等敏感数据行业而言，存在极大的数据泄露和安全合规审计风险。
• 设备数量限制：严格限制主控端与受控端的数量，多台设备频繁登录极易被判定为“商业用途”而封禁。

作为目前全球最火的开源远程桌面解决方案，RustDesk 应运而生。它不仅完全开源免费，更支持端到端加密，并允许用户极其简单地自建专属的 ID 与中继服务器。

只要你拥有一台国内的轻量应用服务器（哪怕是最低规格的 1核1G 内存，只要带宽有 5Mbps~10Mbps 以上），自建 RustDesk 就能为你提供画质高清、低延迟、无限设备数且绝对安全的专属远程控制体验。

1.1 RustDesk 核心架构解析

RustDesk 的后台服务主要由两个极度轻量（基于 Rust 编写，资源占用几乎可以忽略不计）的守护进程组成：

1. hbbs (ID 与注册服务器)：负责接收客户端的连接注册、ID 分配以及协助两端客户端进行 NAT 穿透打洞。如果打洞成功，主控与被控之间会建立直接的点对点（P2P）连接，此时不消耗服务器带宽。
2. hbbr (中继服务器)：当主控端与被控端处于对称型 NAT 等严苛网络环境下，无法成功打洞时，所有的远程桌面音视频流量均会强制通过 hbbr 进行加密中继转发，此时会消耗服务器带宽。

---

一、 部署前的网络与安全组规划

在正式安装前，网络规划是整个部署的核心。由于 RustDesk 的连接涉及打洞、心跳、中继等多个链路，我们需要确保云服务器的安全组（或者操作系统的防火墙）精确放行以下端口：

1.1 端口与协议矩阵

端口号	协议类型	关联组件	功能描述	生产环境暴露级别
21115	TCP	hbbs	穿透服务工作端口，用于主控端的连接测试	必须公开
21116	TCP	hbbs	ID / 注册服务器的主工作端口，处理注册与连接请求	必须公开
21116	UDP	hbbs	打洞与心跳包监听端口，协助客户端进行 NAT 穿透	必须公开（最核心，常被遗漏）
21117	TCP	hbbr	中继服务器工作端口，处理中继流量转发	必须公开
21118	TCP	hbbs	网页端（Web Client）连接服务端口	选填（如果不用网页端控制，建议关闭）
21119	TCP	hbbr	网页端中继服务端口	选填（如果不用网页端控制，建议关闭）

[!IMPORTANT]
黄金避坑提示：21116 端口必须同时放行 TCP 和 UDP 协议！
90% 的新手部署完 RustDesk 后，客户端右下角始终提示 Not ready 或连接超时，原因都是云服务器安全组中只放行了 21116 的 TCP 协议，而忽略了负责心跳与打洞的 UDP 协议。

---

二、 方案一：基于 Docker Compose 极速部署（推荐）

在现代容器化运维中，使用 Docker Compose 是最优雅、最高效的部署方式。它能实现服务的秒级拉起、平滑升级与环境隔离。

2.1 环境准备

确保你的云服务器已经安装了 Docker 以及 Docker Compose 插件。如果尚未安装，可执行以下通用脚本进行一键安装：

# 适用于 Ubuntu/Debian 系统的 Docker 极速安装
curl -fsSL https://get.docker.com | bash -s docker
sudo systemctl enable --now docker

# 验证 Docker Compose 插件是否就绪
docker compose version

2.2 编写黄金生产级 docker-compose.yml

在宿主机上创建专属工作目录，并编写容器编排配置文件：

sudo mkdir -p /opt/rustdesk-server
cd /opt/rustdesk-server
sudo vi docker-compose.yml

写入以下严格经过生产环境检验的配置。此处我们采用 Host 网络模式（可以直接复用宿主机网卡，避免容器桥接 NAT 层对 UDP 打洞造成的性能耗损与延迟，且免去映射一大堆端口的麻烦）：

version: '3.8'

services:
  hbbs:
    container_name: rustdesk-hbbs
    image: rustdesk/rustdesk-server:latest
    command: hbbs -r 1.2.3.4:21117 -k _
    volumes:
      - ./data:/root
    network_mode: host
    restart: always
    depends_on:
      - hbbr

  hbbr:
    container_name: rustdesk-hbbr
    image: rustdesk/rustdesk-server:latest
    command: hbbr -k _
    volumes:
      - ./data:/root
    network_mode: host
    restart: always

[!IMPORTANT]
核心参数硬核解析：

1. -r 1.2.3.4:21117：必须将 1.2.3.4 替换为您服务器的真实公网 IP 或域名。该参数用于强制告诉 hbbs，当需要强制中继时，引导客户端前往哪个公网 IP 和端口（hbbr 端口）进行中继握手。如果填错，中继功能会彻底失效。
2. -k _：强密钥校验安全机制。在后台命令末尾加此参数，服务启动时会在挂载目录（./data）中自动生成一对 Ed25519 公私钥。客户端接入时必须提供配对的公钥（Key），否则服务器会单向拦截连接请求。这能铁腕防御你的中继服务器被全网黑客扫描到后，盗用你的高昂服务器带宽进行不法传输。

2.3 启动与状态检查

一键拉起容器：

# 后台静默启动服务
docker compose up -d

# 查看容器运行状态
docker compose ps

确保 rustdesk-hbbs 和 rustdesk-hbbr 均处于 Up 运行状态。

运行以下命令，实时追踪容器日志输出，确认服务无报错：

docker compose logs -f hbbs

---

三、 方案二：基于 Linux 二进制包免容器化原生部署

如果您处于某些政企局域网物理隔离环境，或者不希望引入 Docker 容器层的资源消耗，可以直接使用原生二进制部署，并配合 Systemd 守护进程来实现企业级稳定性。

3.1 规划生产安全用户与目录

出于操作系统层面的最高安全审计准则，绝对禁止使用 root 用户直接启动任何暴露在公网的网络守护进程。我们为其规划专用的非登录系统用户：

# 1. 创建专门的无登录权限系统用户组与用户
sudo groupadd rustdesk
sudo useradd -r -g rustdesk -s /bin/false rustdesk

# 2. 创建规范的安装目录结构
sudo mkdir -p /opt/rustdesk-server

3.2 下载与部署官方二进制文件

访问 RustDesk Server 的 GitHub Release 官方仓库，下载对应系统架构（本文以主流 x86_64 为例，若是鲲鹏/飞腾信创服务器，请选择 aarch64 包）的最新稳定版二进制包：

cd /opt/rustdesk-server

# 下载官方 Linux 二进制包
sudo wget https://github.com/rustdesk/rustdesk-server/releases/download/1.1.10-3/rustdesk-server-linux-amd64.zip

# 安装解压工具并解压
sudo apt install unzip -y
sudo unzip rustdesk-server-linux-amd64.zip -d .

# 规整目录：将二进制文件移动到安装根目录下
sudo mv amd64/* .
sudo rm -rf amd64 rustdesk-server-linux-amd64.zip

# 3. 将整个目录的所有权移交给 rustdesk 安全用户
sudo chown -R rustdesk:rustdesk /opt/rustdesk-server

解压完成后，确认 /opt/rustdesk-server 目录下存在 hbbs 和 hbbr 两个可执行程序，且它们具有执行权限。

3.3 编写 Systemd 守护进程配置文件

为了保证服务器重启后服务能自动拉起，以及宕机后能秒级自我修复，我们需要分别为 hbbs 和 hbbr 编写 Systemd 服务配置文件。

1. 创建并编写 rustdesk-hbbs.service：

sudo vi /etc/systemd/system/rustdesk-hbbs.service

写入以下内容（注意：请将指令中的 1.2.3.4 替换为您自己服务器的真实公网 IP 或域名）：

[Unit]
Description=RustDesk ID and Rendezvous Server (hbbs)
After=network.target

[Service]
Type=simple
User=rustdesk
Group=rustdesk
WorkingDirectory=/opt/rustdesk-server
ExecStart=/opt/rustdesk-server/hbbs -r 1.2.3.4:21117 -k _
Restart=on-failure
RestartSec=10s

# 资源限制优化：极大提升该进程的最大文件打开数，防范高并发控制时由于描述符耗尽而崩溃
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

2. 创建并编写 rustdesk-hbbr.service：

sudo vi /etc/systemd/system/rustdesk-hbbr.service

写入以下内容：

[Unit]
Description=RustDesk Relay Server (hbbr)
After=network.target

[Service]
Type=simple
User=rustdesk
Group=rustdesk
WorkingDirectory=/opt/rustdesk-server
ExecStart=/opt/rustdesk-server/hbbr -k _
Restart=on-failure
RestartSec=10s
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

3. 重新加载并激活服务进程

# 刷新 Systemd 守护进程列表
sudo systemctl daemon-reload

# 开启服务开机自启，并即刻拉起服务
sudo systemctl enable --now rustdesk-hbbs rustdesk-hbbr

# 实时查看两个服务的运行健康状态
sudo systemctl status rustdesk-hbbs rustdesk-hbbr

如果看到输出状态中均高亮显示绿色的 active (running)，且无任何错误日志，则表明原生二进制服务化部署宣告成功！

---

四、 核心安全防御：密钥校验与提取

由于我们在启动命令中均附加了 -k _ 强校验参数，服务端会在首次启动时自动在当前工作目录下生成非对称加密的公私钥对。我们需要把这串公钥（Key）提取出来，配置到客户端中。

4.1 提取公钥文件内容

• Docker 部署方案下：
  由于我们挂载了工作目录，公钥文件自动生成在宿主机的 ./data 下：

  cat /opt/rustdesk-server/data/id_ed25519.pub

• 二进制原生部署方案下：
  密钥生成在服务的工作目录（WorkingDirectory）下：

  cat /opt/rustdesk-server/id_ed25519.pub

运行以上命令后，控制台会输出一串看似杂乱无章的 Base64 字符串（例如：o1R8vX7HhNnE9aW1+y...=）。请完整复制这串字符，它是未来所有客户端接入你的私有服务器的唯一凭证，切勿丢失！

---

五、 多端客户端配置与“重命名免配运行”黑科技

服务端搭建完毕后，我们将进行受控端与主控端的客户端配置与完美互联。

5.1 常规手动配置（Windows / macOS / Linux / 移动端通用）

1. 前往 RustDesk 官网或 GitHub 下载对应系统的官方客户端。

2. 打开 RustDesk 客户端，在主界面中找到自己的“ID”，点击旁边的三点菜单栏按钮 -> 选择 “ID/中继服务器” (ID/Relay Server)：

   (示意图：客户端内网参数设置位置)

3. 在弹出的配置输入框中，精准填写以下核心参数：

   • ID 服务器 (ID Server)：输入您自建服务器的公网 IP 或域名（例如：1.2.3.4）。
   • 中继服务器 (Relay Server)：输入您自建服务器的公网 IP 或域名（与上面相同，例如：1.2.3.4）。
   • API 服务器：留空（除非您自建了第三方的地址簿 API 服务）。
   • Key：粘贴您在第四章中提取出来的 id_ed25519.pub 文件中的完整公钥串。

   (示意图：填入公网 IP 和密钥)

4. 填写完成后，点击“确定”保存。回到主界面，观察客户端底部状态栏。

5. 在短短数秒内，红色的连接提示会瞬间变为绿色的 Ready (就绪)。这表明当前客户端已完美与你的私有服务器握手成功，您可以立刻进行安全的远程桌面控制了。

---

5.2 大厂运维级黑科技：Windows 免配置双击直接运行

当我们需要给身处异地的客户、非技术同事提供远程协助时，如果要求他们手动去客户端里寻找三点菜单、折腾 IP 地址并粘贴长达数十位的 Key，简直是一场灾难。

RustDesk 官方其实隐藏了一个极其强悍的特性——“文件名参数自解析黑科技”。针对 Windows 绿色版客户端，你只需要通过修改客户端可执行文件的文件名，就能达到“双击即配好”的完美效果！

具体实操步骤：

1. 下载 Windows 通用便携版可执行文件，官方原名为：rustdesk-1.x.x-x86_64.exe。
2. 根据你的服务器公网 IP 和第四章提取的 Key，将此 exe 文件进行重命名，命名格式严格如下：

   rustdesk-host=<Server-IP-or-Domain>,key=<Your-Public-Key>.exe

   真实范例：如果您的服务器 IP 为 118.25.10.20，提取的公钥为 o1R8vX7HhN=，则重命名为：

   rustdesk-host=118.25.10.20,key=o1R8vX7HhN=.exe

3. 分发体验：你只需要将重命名后的这个 .exe 文件，通过微信、邮件等直接打包发给你的客户。客户收到后直接双击运行，客户端在启动时会自动读取并解析自身的文件名参数，瞬间把 ID 服务器、中继服务器和密钥全部自动写入系统配置中！
4. 客户无需进行任何额外学习和操作，右下角秒绿，你只需让他们报出主界面显示的“ID”与“随机密码”，即可实现高速、安全的远程控制。

---

六、 线上典型故障“救火”与排错实战

在长周期的运营过程中，你可能会遇到一些突发报错，我们整理了生产一线的经典故障，助你快速诊断。

6.1 故障一：客户端右下角始终显示“未就绪，请检查网络连接 (Connecting / Not ready)”

• 现象还原：
  两端客户端的配置项、密钥填写的均准确无误，但底部状态栏始终转圈并提示 Not ready。
• 第一现场排查逻辑：
  由于打洞和心跳是依靠 UDP 协议的，很多新手在云服务器的安全组中仅开启了 TCP 协议的端口。
• 诊断工具（使用网络排错利器 nc 的 UDP 探测指令）：
  在客户端（Linux 或 macOS）中打开终端，强制探测服务端的 UDP 端口连通性：

  # -u 参数代表探测 UDP，-z 代表仅建立握手而不发送内容
  nc -uvz 1.2.3.4 21116

  • 失败响应：如果没有任何显示，或提示 Connection refused，说明数据包在网络层被完全拦截了。
  • 成功修复：前往腾讯云、阿里云等云控制台，进入安全组规则，新增一条专门针对 UDP 协议的放行规则，端口填入 21116。保存后，在客户端重新点击“ID/中继服务器”保存刷新，几秒内即刻变绿。

---

6.2 故障二：主控端连接被控端时，屏幕红字报错“安全密钥不匹配 (Key mismatch)”

• 现象还原：
  输入受控端 ID 准备连接，却立刻弹窗拦截，显示 Key mismatch。
• 第一现场排查逻辑：
  1. 最常见原因：客户端里面粘贴的 Key 公钥串复制不完整（例如末尾的 = 号漏掉了，或者粘贴时不小心带入了多余的空格或换行符）。
  2. 硬核 Systemd 二进制部署暗坑：
     如果你是使用二进制部署且用 Systemd 托管，但在 /etc/systemd/system/rustdesk-hbbs.service 配置文件中，遗漏了 WorkingDirectory=/opt/rustdesk-server 配置项。
     因为没有指定工作目录，当 Systemd 启动 hbbs 时，可能会默认把宿主机的根目录 / 或默认家目录作为工作目录，并在该目录下生成了一对新的公私钥。这导致你从 /opt/rustdesk-server/id_ed25519.pub 里复制出来的公钥，与内存中实际运行的私钥根本不配对，发生验证失败。
• 成功修复：
  确保 Systemd 的 .service 配置文件中存在规范的 WorkingDirectory 参数，且密钥复制 100% 完整无空格。

---

6.3 故障三：远程控制画面帧率极低，拖拽鼠标有极强滞后感

• 现象还原：
  远程桌面连接建立成功，但卡顿严重，画面像幻灯片，甚至出现严重丢包马赛克。
• 第一现场排查逻辑：
  我们需要理清该连接走的是“直连打洞（P2P）”还是“服务器中继（Relay）”。
  1. 在 RustDesk 远程窗口的正上方，点击网络信号柱状图图标，查看当前的连接方式：
     • Direct (直连)：说明打洞成功，两台客户端直接通信。此时卡顿，纯粹是主控端或被控端各自的本地宽带网络上传/下载差导致，与服务器无关。
     • Relay (中继)：说明打洞失败，流量强行通过你的云服务器进行中继转发。
  2. 如果是 Relay 且卡顿，原因一般是云服务器的物理公网带宽饱和了。比如你买的是 1Mbps 带宽的入门级服务器，最大下载速度仅 128KB/s，承载 1080P 远程画面的传输必定会发生严重的延迟与丢包。
• 成功修复调优策略：
  1. 升级云服务器带宽：自建私有中继，建议云服务器带宽至少在 5Mbps 以上（可以流畅承载 1080P/30帧 画面），若需多人同时进行远程控制，建议配置到 10Mbps 及以上。
  2. 客户端画质调优：在主控端的 RustDesk 控制面板 -> 远程控制设置中，将画面质量从“平衡”或“高质量”修改为**“优化反应速度”或“低画质”**。这能瞬间把传输码率拉低 60% 以上，极大缓解小带宽云服务器的阻塞压力。

---

结语：RustDesk 私有化适配一页纸 Checklist

构建一个高速、坚固的远程桌面基座，同样在于对细节的精准把握。部署完毕后，请使用下表对自建服务进行最终审计校验：

• 安全组双放行：确认 21116 端口同时放行了 TCP 和 UDP 协议。
• 强密钥安全锁：确认 hbbs 与 hbbr 启动命令中均附加了 -k _，且挂载/工作目录中已安全生成公钥。
• 中继地址指定：确认 hbbs 的 -r 参数中填写的 IP 地址是您服务器的公网 IP，且端口为 21117。
• Systemd 用户限制：如果采用二进制部署，确认该进程是以新建的 rustdesk 非特权系统用户运行，并指定了 WorkingDirectory。
• 重命名分发测试：尝试将客户端包重命名为 rustdesk-host=你的IP,key=你的Key.exe，发送至另一台干净的 Windows 电脑双击，测试能否秒级上线并进入 Ready 状态。

通过这一整套精密的私有化部署实践，你已彻底摆脱了商业软件的限速、封号与隐私泄露阴影。这台隐匿在云端、由你完全掌控的专属中继服务器，将成为技术团队日常高效、无阻交付业务的坚实后盾！