自建 RustDesk 服务端的三个容器，到底各干什么？一篇大白话讲清楚

自己搭过 RustDesk 服务端的人,大概都被那一长串 docker run 劝退过:hbbs、hbbr、还有一个第三方的 rustdesk-api,三个容器一堆端口,看着头大。

这篇就用大白话把它们讲明白。先打个比方建立整体印象:

RustDesk 干的事,本质就是 让两台电脑隔着互联网"牵手"。
三个容器分别扮演:红娘、搬运工、前台管理员。

记住这三个角色,后面就全通了。

一、rustdesk-hbbs —— 红娘(信令服务器)

hbbs -r 你的域名:21117

它负责 牵线搭桥。

所有客户端开机后,都会先到红娘这里 报到登记:"我是 ID 12345,我现在在线,我的网络地址是 xxx"。

当你想远程某台电脑时,你先找红娘说一句"我要连 67890",红娘就把 双方的网络地址互相告知,撮合两台电脑尝试 直接牵手(P2P 打洞)。

它用到三个端口——而且你只需要指定主端口,另外两个是 hbbs 自动派生出来的:

端口	协议	用途	怎么来的
21116	TCP+UDP	主信令:登记报到、发起连接请求	你指定的主端口
21115	TCP	NAT 类型测试(判断你的网络好不好打洞)	主端口减 1
21118	TCP	WebSocket,给网页客户端用	主端口加 2

小记:hbbs 可以理解成 Handbook bridge server——牵线的那个。

二、rustdesk-hbbr —— 搬运工(中继服务器)

hbbr

红娘撮合之后,如果两台电脑能 直接牵手(P2P 成功),数据就走直连,搬运工不参与,速度最快。

但现实里,双方常常都躲在路由器后面(NAT),握不上手。 这时候就轮到搬运工出场:两台电脑各自把数据交给它,由它在中间 转发画面、键鼠、文件。

走中继时,所有流量都从它身上过,所以 它是最吃带宽的一个。如果你的主控和被控分布在不同地区、还经常打洞失败,那这台搬运工的出口带宽就是体验好坏的关键。

端口	协议	用途
21117	TCP	中继转发数据(屏幕 / 键鼠 / 文件都走这)
21119	TCP	WebSocket 中继,网页客户端用

小记:hbbr = Handbook bridge relay——搬东西的那个。

红娘那条 -r 你的域名:21117 参数,就是让红娘在撮合时顺便告诉客户端:"打洞失败的话,去这个地址找搬运工。"

三、rustdesk-api —— 前台管理员(Web 管理后台)

lejianwen/rustdesk-api:...

注意:这个容器不是 RustDesk 官方的,是社区做的增强后台。

前面两个(红娘、搬运工)才是干活的核心,光有它俩,RustDesk 就已经能正常用了。这个 api 属于 锦上添花,它给你提供:

网页管理后台(/_admin/):查看哪些设备在线、管理用户、地址簿、权限
网页客户端(/webclient/):不装软件,浏览器里直接发起远程
API 接口:给客户端下发配置、登录鉴权等

端口	用途
21114	api 服务的 HTTP 端口

它靠几个环境变量,知道红娘和搬运工分别在哪:

ID_SERVER     = 127.0.0.1:21116   # 红娘在本机 21116
RELAY_SERVER  = 127.0.0.1:21117   # 搬运工在本机 21117
SIGNAL_SERVER = 127.0.0.1:21115   # NAT 测试端口

如果你改了 hbbs 的主端口,这几个值要 跟着一起改,否则后台和真正干活的容器就对不上号了。

把它们串起来看

你(主控)                                       对方(被控)
   │                                               │
   │ ①「我要连对方」                     ① 早就登记过 │
   └──────────►   红娘 hbbs (21116)   ◄─────────────┘
                       │
                 ② 撮合,互告地址
                       │
         ┌─────────────┴─────────────┐
         ▼                           ▼
    能直连?──是──►  P2P 直连,搬运工不参与(最快)
         │
         否
         ▼
    搬运工 hbbr (21117) 在中间转发画面 / 键鼠 / 文件

一句话总结

容器	角色	干什么	核心端口	缺了会怎样
`rustdesk-hbbs`	红娘	登记、撮合、打洞	21116	不可缺,没它谁都连不上
`rustdesk-hbbr`	搬运工	打洞失败时中继转发	21117	不可缺,没它打洞失败就彻底连不上
`rustdesk-api`	前台管理员	网页后台 / 网页客户端 / API	21114	可缺,只是没有后台,裸用照样行

hbbs 牵线、hbbr 搬货、api 管后台。 前两个是骨架,第三个是装修。

附录:一键部署脚本(可直接套用)

下面这套脚本把三个容器一次性拉起来。用之前只需要改一处——把 RD_DOMAIN 换成你自己的域名:

#!/usr/bin/env bash
# RustDesk 服务端一键部署脚本(hbbs + hbbr + api)
# 用法:改好 RD_DOMAIN,保存为 deploy.sh,然后 bash deploy.sh

RD_DOMAIN="rustdesk.example.com"            # ← 改成你自己的域名
RD_DIR="/home/$USER/dockerfile/rustdesk"    # 数据存放目录,可自定义

# 清理旧容器(首次部署没有也不会报错)
docker rm -f rustdesk-hbbs rustdesk-hbbr rustdesk-api 2>/dev/null

# 准备数据目录
mkdir -p "$RD_DIR"/{data,api}

# ① 红娘:hbbs 信令服务器
docker run -d \
  --name rustdesk-hbbs \
  --restart always \
  --network host \
  -v "$RD_DIR/data":/root \
  rustdesk/rustdesk-server:1.1.15 \
  hbbs -r ${RD_DOMAIN}:21117

# ② 搬运工:hbbr 中继服务器
docker run -d \
  --name rustdesk-hbbr \
  --restart always \
  --network host \
  -v "$RD_DIR/data":/root \
  rustdesk/rustdesk-server:1.1.15 \
  hbbr

# ③ 前台管理员:rustdesk-api 网页后台(第三方,可选)
docker run -d \
  --name rustdesk-api \
  --restart always \
  --network host \
  -e TZ=Asia/Shanghai \
  -e RUSTDESK_API_LANG=zh-CN \
  -e RUSTDESK_API_APP_WEB_CLIENT=1 \
  -e RUSTDESK_API_RUSTDESK_ID_SERVER=127.0.0.1:21116 \
  -e RUSTDESK_API_RUSTDESK_RELAY_SERVER=127.0.0.1:21117 \
  -e RUSTDESK_API_RUSTDESK_API_SERVER=https://${RD_DOMAIN} \
  -e RUSTDESK_API_RUSTDESK_SIGNAL_SERVER=127.0.0.1:21115 \
  -e RUSTDESK_API_APP_REGISTER=false \
  -v "$RD_DIR/api":/app/data \
  -v "$RD_DIR/data":/app/conf/data \
  lejianwen/rustdesk-api:v2.7

# 等待启动,打印关键信息
sleep 5
echo "=== 部署完成 ==="
docker ps | grep rustdesk
echo ""
echo "管理后台:   https://${RD_DOMAIN}/_admin/"
echo "网页客户端: https://${RD_DOMAIN}/webclient"
echo "ID 服务器:  ${RD_DOMAIN}:21116"
echo "中继服务器: ${RD_DOMAIN}:21117"
echo "公钥(Key): $(cat "$RD_DIR/data/id_ed25519.pub" 2>/dev/null || echo '稍等几秒再查看')"
echo "管理员密码: $(docker logs rustdesk-api 2>/dev/null | grep -i 'Admin Password Is:' | tail -1 | sed 's/.*Admin Password Is: //')"

部署完别忘了 放行端口(云厂商安全组 + 服务器本地防火墙,两层都要开):

协议	端口	说明
TCP	21114-21119	api / hbbs / hbbr 全套
UDP	21116	hbbs 信令(必须,容易漏)

客户端配置时填三样:ID 服务器 = 你的域名:21116、中继服务器 = 你的域名:21117、Key = 上面打印出来的公钥内容。

脚本里用的是默认端口 21116。如果你的网络环境需要换端口(见下一节),把 hbbs 那行加上 -p 新端口,同时改 api 的 ID_SERVER / SIGNAL_SERVER,并放行新端口对应的三个口。

一点实战补充:为什么有人把 21116 改成别的端口

21116 是 RustDesk 的默认信令端口,也正因为太出名,成了被重点识别的"特征端口"。

在一些跨境(比如大陆访问香港节点)的场景里,会遇到一个很迷惑的现象:

服务器、防火墙、Key、配置全都正确
telnet 端口看着也通
但只要真正发起远程,主控端就连不上

这种情况往往不是服务器的锅,而是 链路上对"特定 IP + 21116 端口"做了 RST 干扰。一个常见的应急办法,就是把 hbbs 的主端口从 21116 挪到一个冷门高位端口(比如 31116),配置同步下发,很多时候就能立刻恢复。

记得改端口要三处一起改:hbbs 的 -p 参数、api 的环境变量、防火墙放行新端口(派生的三个端口都要放)——而且云厂商安全组和服务器本地防火墙是两层,都得开。

不过换端口属于"续命"而非"根治",更稳的长期方案是把信令和中继套进 443 的 TLS/WSS 流量里,让链路层抓不到特征。这就是另一篇的故事了。