适合这些情况：

• 你经常用 RustDesk 远程自己的电脑。
• 你不想依赖默认公共服务器。
• 你有多台设备要长期远程维护。
• 你希望中继节点离自己更近，比如香港、日本、新加坡、美国西海岸。
• 你能接受开放几个 RustDesk 专用端口。

不适合这些情况：

• 你只是偶尔帮朋友远程一次。
• 你没有公网 VPS，只想在家里 NAS 上跑。
• 你不能开放 UDP 端口。
• 你希望像商业远控那样有完整账号、权限、审计和团队管理。

如果只是临时远控，直接用 RustDesk 默认服务器更省事。自建的价值在于：稳定、可控、延迟更可预期。

RustDesk Server 最容易出错的地方就是端口。

官方文档里 OSS 自建服务主要涉及这些端口：

如果你不用 Web Client，核心端口就是：

TCP: 21115, 21116, 21117
UDP: 21116

21118 和 21119 不是桌面客户端必须端口，主要和 Web Client 相关。刚开始排查时可以先按完整端口放行，跑通以后再按实际需求收紧。

RustDesk Server 不太吃 CPU 和内存，但吃网络质量。

最低配置：

真正要看的是：

• VPS 到你所在地的延迟。
• 晚高峰是否稳定。
• 上下行带宽够不够。
• UDP 是否正常。
• 流量包是否够用。

如果你主要在国内远程家里电脑，香港、日本、新加坡、美国西海岸通常比欧洲更合适。欧洲 VPS 很便宜，但远控延迟高了以后，鼠标移动会很难受。

本文默认：

• Ubuntu 22.04 / 24.04 或 Debian 12。
• 已安装 Docker 和 Docker Compose。
• 有一个对外可访问的域名，例如 rustdesk.example.com，也可以直接用 VPS 公网 IP。
• 防火墙和云厂商安全组可配置。

确认 Docker：

docker version
docker compose version

创建目录：

sudo mkdir -p /opt/rustdesk-server
sudo chown -R "$USER":"$USER" /opt/rustdesk-server
cd /opt/rustdesk-server
mkdir -p data

data 目录很重要，里面会保存 RustDesk Server 生成的密钥。这个目录丢了，客户端里配置的 Key 就对不上，后面要重新配置所有设备。

创建 docker-compose.yml：

nano docker-compose.yml

写入下面内容，把 rustdesk.example.com 换成你的公网域名或 VPS 公网 IP。不要写容器名、内网主机名或只在服务器本机能解析的地址，客户端必须能从外网访问它。

services:
  hbbs:
    image: rustdesk/rustdesk-server:1.1.15
    container_name: hbbs
    command: hbbs -r rustdesk.example.com:21117
    volumes:
      - ./data:/root
    ports:
      - "21115:21115"
      - "21116:21116"
      - "21116:21116/udp"
      - "21118:21118"
    depends_on:
      - hbbr
    restart: unless-stopped

  hbbr:
    image: rustdesk/rustdesk-server:1.1.15
    container_name: hbbr
    command: hbbr
    volumes:
      - ./data:/root
    ports:
      - "21117:21117"
      - "21119:21119"
    restart: unless-stopped

这里有几个重点：

• hbbs -r rustdesk.example.com:21117 告诉客户端 relay 服务器地址。
• ./data:/root 用来持久化密钥。
• 21116 同时需要 TCP 和 UDP。
• hbbs 和 hbbr 共用同一个 data 目录。
• 示例固定使用 rustdesk/rustdesk-server:1.1.15，后续升级时可以先查 Docker Hub / GitHub Release，再手动改版本号。

如果你用的是纯 IP，也可以写：

command: hbbs -r 1.2.3.4:21117

域名的好处是以后换 VPS，只要改 DNS，不用每个客户端都重新填 IP。

执行：

docker compose up -d

查看容器：

docker compose ps

看日志：

docker compose logs -f --tail=100

正常情况下，hbbs 会生成一组密钥。你可以直接看文件：

ls -l data
cat data/id_ed25519.pub

也可以从日志里找 Key：

docker logs hbbs 2>&1 | grep -i key

后面客户端要填的 Key，通常就是 id_ed25519.pub 里的内容。

如果 VPS 开了 UFW：

sudo ufw allow 21115/tcp
sudo ufw allow 21116/tcp
sudo ufw allow 21116/udp
sudo ufw allow 21117/tcp
sudo ufw allow 21118/tcp
sudo ufw allow 21119/tcp
sudo ufw reload

如果你确认不用 Web Client，可以不开放 21118、21119。但新手排查阶段按完整端口放行更省事，确认能连以后再收紧。

别忘了云厂商后台的安全组。有些人 VPS 里 ufw allow 写对了，但云后台还挡着，最后一直连不上。

检查监听端口：

ss -lntup | grep 211

你应该能看到 21115、21116、21117 等端口。

打开 RustDesk 客户端：

Settings -> Network -> ID/Relay Server

常见填写方式：

ID Server: rustdesk.example.com
Relay Server: rustdesk.example.com
API Server: 留空
Key: 粘贴 data/id_ed25519.pub 的内容

如果你没有域名，就填 VPS 公网 IP。这里一定要填客户端能访问到的公网地址，不要填 hbbs、localhost、127.0.0.1 或 Docker 内部网络地址。

两台设备都要填同样的服务器和 Key。填完后重启 RustDesk 客户端，或者断开重连。

如果配置成功，客户端底部通常会显示服务器连接状态变正常。然后你再用一台设备连接另一台设备测试。

RustDesk 能直连就直连，直连不行才走 relay。自建服务器的 hbbs 会先协调打洞，失败后再通过 hbbr 转发。

你可以用几种方式判断：

• 看客户端连接信息。
• 看 hbbr 日志是否有连接记录。
• 远程时观察 VPS 流量是否明显上升。
• 用 iftop 或 nload 看 21117 端口流量。

安装 nload：

sudo apt update
sudo apt install -y nload
nload

如果远控时 VPS 出站流量明显增加，大概率正在走中继。

这也提醒一点：如果你经常中继传输大文件，VPS 流量会消耗得很快。远程桌面本身还好，文件传输和高分辨率画面才是真正吃流量的地方。

RustDesk 核心端口不是普通 HTTP 服务，不能像网站那样随便 reverse_proxy 127.0.0.1:21117 就完事。

如果你只是部署 OSS RustDesk Server，核心连接建议直接开放 21115-21117 这些端口，不要强行套普通 HTTP 反代。

可选的 21118、21119 和 Web Client 场景才会涉及 WebSocket / HTTPS 代理。大多数个人用户先不用碰它，先把桌面客户端跑通更重要。

如果你所在网络只允许 443 出站，RustDesk 还有更复杂的 443 方案，但那已经不是入门部署了。本文先讲最稳、最容易排查的标准端口方式。

这点非常重要。

备份 data 目录：

cd /opt/rustdesk-server
mkdir -p /opt/backups/rustdesk-server

tar czf /opt/backups/rustdesk-server/rustdesk-server-$(date +%F-%H%M).tar.gz data docker-compose.yml

最稳妥的做法是备份整个 data 目录。最少也要保住私钥文件：

data/id_ed25519

data/id_ed25519.pub 是给客户端填写的公钥，很重要，但真正决定服务端身份的是 id_ed25519 私钥。私钥丢了，服务端重新生成一套密钥，客户端原来填的 Key 就失效了，你得重新给每台设备配置。设备少还好，十几台设备就很烦。

建议把备份同步到第二个地方，比如另一台 VPS、NAS、对象存储或加密云盘。

升级前先备份：

cd /opt/rustdesk-server
tar czf /opt/backups/rustdesk-server/before-upgrade-$(date +%F-%H%M).tar.gz data docker-compose.yml

然后查一下新版本，再修改 docker-compose.yml 里的镜像标签，例如从 1.1.15 改到新的稳定版。

拉新镜像：

docker compose pull
docker compose up -d

看日志：

docker compose logs -f --tail=100

升级后用两台设备实际连一次，不要只看容器是 Up 就以为没问题。

我不建议在教程里长期使用 latest。个人测试可以图省事，正式使用还是固定版本更稳，出了问题也更容易回滚。

RustDesk Server 本身就是为了让客户端找到彼此，不是传统后台系统，但也别完全不管安全。

建议：

• 不要把 VPS root 密码登录暴露着。
• 防火墙只开放需要的端口。
• 不用 Web Client 时，不开放 21118/21119。
• 及时更新 Docker 镜像和系统补丁。
• 备份 data 密钥目录，尤其是 id_ed25519 私钥。
• 不要把服务端私钥发给别人。
• 客户端开启强密码和确认连接。
• 不给陌生人长期无人值守访问权限。

如果你给家人或团队用，最好先约定好：哪些设备允许无人值守，哪些设备必须手动确认。远程桌面工具方便是真的方便，但权限给错也是真的危险。

正式使用前检查一遍：

• hbbs 和 hbbr 容器都在运行。
• 21115/tcp、21116/tcp、21116/udp、21117/tcp 已放行。
• 如使用 Web Client，21118/tcp、21119/tcp 已处理；不用则保持关闭。
• hbbs -r 填的是客户端可访问的公网域名或 VPS 公网 IP。
• 客户端 ID Server、Relay Server、Key 都已填写。
• 整个 data 目录已备份，尤其是 data/id_ed25519 私钥。
• 两台设备实际连接测试通过。
• 文件传输和无人值守访问按需测试。
• VPS 流量和带宽够用。

如果你只是偶尔远程一次，用 RustDesk 默认公共服务器就够了。

如果你经常远程自己的电脑、NAS、家人电脑，或者你不想把连接质量交给公共服务器，自建 RustDesk Server 很值得。它对 VPS 配置要求不高，真正关键的是网络线路、端口放行和密钥备份。

我的建议是：先用一台便宜但线路稳定的 VPS 跑起来，测试 3-5 天。如果晚高峰远控也顺滑，再把家里和办公设备慢慢切过去。别一上来就把所有设备都改掉，先验证，再迁移。