自托管远程桌面：诚实的 2026 指南

你可以自托管中继——堆栈是开源的，本指南逐步讲解整个安装。教程经常忽略的是持续运行的成本，以及谁应承担这些运维责任。

搜索自托管远程桌面，会看到十来篇教程停在 docker compose up -d。安装是容易的，确实大约 30 分钟。本指南完整覆盖安装——并且覆盖决定你是否应该这样做的部分：教程结束后维持运行的成本。

简短回答

当有要求强制时就自托管。没有时就使用托管中继。听起来简单，这里是实际的判断：

自托管条件：如果书面的合规义务规定会话流量不得经过第三方基础设施；或者你在隔离网段或其他受限网络中，外部中继不可达；或者数据驻留规则明确要求你必须留在特定司法辖区内。
使用托管中继当：你的理由是任何形式的“我更愿意自己运行”。这是一个真实的偏好，但它同时是一项持续的运维工作——在你签约之前请见下面的费用清单。

值得澄清你在两者之间选择什么，因为这并不是两个不同的产品。Tenvo 采用 AGPL-3.0，托管中继运行的是本指南所安装的相同 hbbs/hbbr 架构。区别在于谁运营这台主机，而不是软件本身。

首先：中继实际能看到什么

这点比其他都重要，因为它通常是人们首先选择自托管的原因——但通常被描述错误。

在点对点直接连接时，会话在两台设备之间端到端运行。无法建立直接连接时——对称 NAT、严格的公司防火墙——会话改为通过中继转发，TLS 在中继处终止。因此，运营该中继的人有能力查看被中继的流量。关于我们的情况，我们不会隐瞒这一点。

这是协议的属性，而不是由谁付费决定的。自己运行中继并不会加密供应商中继不会加密的内容；它改变的是占据该位置的主体。如果“谁被允许占据该位置”的答案被写入合规义务，自托管就是正确的选择，本指南的其余部分适合你。如果这没有任何书面说明，你就是在承担一项运维工作来解决一个你并不存在的问题。

你要搭建的内容

两个服务：

hbbs（rendezvous 服务器）：处理初始握手。双方客户端短暂连接到它以发现彼此、交换公钥，并判断是否可以直接 P2P。监听 TCP/UDP 21115-21117。
hbbr（relay 服务器）：在直接 P2P 失败时转发会话。监听 TCP 21117（在某些场景下也使用 UDP）。

只有在 P2P 无法工作时中继才会介入——在消费者 NAT 上常见，在同一局域网内则很少。因此即便自托管，你也只为确实需要中继的会话支付 VPS 带宽。

步骤 1：选择 VPS

带宽是关键资源。CPU 和内存需求很低，因为中继主要是转发字节而不是处理它们。

Hetzner CX22（€4/mo，2 vCPU，4 GB RAM，20 TB 带宽，EU 数据中心）— 最佳性价比的带宽。
DigitalOcean Basic Droplet（$6/mo，1 vCPU，1 GB，1 TB 带宽）— 良好的用户体验，US/EU 区域。
OVH VPS Starter（€3.50/mo，2 vCPU，2 GB，未计量带宽）— 适合高带宽场景。

选择靠近连接客户端的区域。中继流量受往返延迟影响，因此这是对感知延迟影响最大的可控因素——如下面所述，这是单台 VPS 最难做到的一点。

步骤 2：设置服务器

部署一台新的 Ubuntu 22.04 或 Debian 12 VPS。以 root 登录 SSH。

# Update + harden basics
apt update && apt upgrade -y
apt install -y ufw fail2ban docker.io docker-compose-plugin
ufw allow 22/tcp     # SSH
ufw allow 21115:21119/tcp
ufw allow 21115:21119/udp
ufw enable
systemctl enable --now docker

不要跳过防火墙。默认配置只开放必要端口；其他所有端口都应被锁定。

步骤 3：通过 Docker 运行 hbbs + hbbr

创建 /opt/tenvo-relay/docker-compose.yml：

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

将 your-server.example.com 替换为实际主机名，然后启动：

cd /opt/tenvo-relay
mkdir -p data
docker compose up -d
docker compose logs --tail 20

hbbs 在首次启动时会打印公钥。从日志中保存它（数据卷中的 id_ed25519.pub）——客户端用它来校验它们连接的是你的中继而不是冒名顶替者。

步骤 4：配置 DNS

为 relay.yourdomain.com 添加 A 记录指向 VPS IP。直接使用裸 IP 也可，但如果你将来迁移，使用主机名会更便于维护。

步骤 5：在客户端指向你的中继

大多数指南略过的部分。每个客户端需要三个值：

ID 服务器 = relay.yourdomain.com:21116
Relay 服务器 = relay.yourdomain.com:21117
公钥 = 来自 VPS 的 data/id_ed25519.pub 的内容

在 Windows、macOS 和 Linux 上：

打开 Tenvo 或 RustDesk 客户端。
设置 → 网络 → ID/Relay 服务器。
输入上述三项并保存。
重启客户端。

状态指示应在几秒内变为绿色。如果保持红色，检查防火墙规则以及公钥是否完全匹配——通常是尾随换行符导致的问题。

步骤 6：添加 TLS

在中继端口前放置反向代理。Caddy 是最省力的方式：

relay.yourdomain.com {
    reverse_proxy /ws/* localhost:21118
    reverse_proxy * localhost:21115
}

Caddy 会为你签发并续期 Let's Encrypt 证书。将客户端更新为使用 443 端口并启用 TLS——这也能让你穿过仅允许 443 的出站限制防火墙。

步骤 7：备份密钥

data/ 目录保存 rendezvous 服务器的密钥对。丢失它会导致每台客户端必须手动用新公钥重新配置一次。

# Local backup
rsync -avz vps:/opt/tenvo-relay/data/ ~/tenvo-relay-backup-$(date +%Y%m%d)/
# OR copy the two key files
scp vps:/opt/tenvo-relay/data/id_ed25519* ~/tenvo-keys/

请将其离线保存。如果 VPS 曾被攻破，你会希望在新机器上用相同密钥重建，这样现有客户端可以不受影响地继续工作。

教程忽略的故障模式

客户端无法连接到中继。几乎总是防火墙问题。检查 ufw status，检查云提供商的安全组是否允许相同端口，并从客户端运行 nc -vz relay.yourdomain.com 21116 以确认可达性。

所有流量都回落到中继。对称 NAT 和严格的公司防火墙会强制每个会话走中继。性能通常能保持，但你现在的带宽账单会成为主要问题，而不再是例外。

中继宕机且无法恢复。Docker 的 restart: unless-stopped 可以覆盖常见情况。它无法应对磁盘已满、OOM 杀死或内核崩溃——这些情况需要能通知人的监控，而这个人就是你。

证书过期。使用 Caddy 时自动处理。使用 nginx + certbot 时则是一个你必须记得的定时任务；certbot.eff.org 有官方指南。

教程未显示的账单

€4 的 VPS 是账单中最便宜的一项，将其作为自托管成本等同于把汽车购置价当做行驶成本。这之外还有：

你要对自己的中继承担值班责任。当它在凌晨 2 点宕机时，你将无法通过远程访问去修复它。
操作系统打补丁，永无止境。一台面向公网的机器由你负责持续打补丁。
密钥保管。丢失 data/ 就要手动为每个客户端重新配置。备份现在是需要你真正验证的东西，而不仅仅是安排计划任务。
证书续期。自动进行直到某天不再自动为止。
单一区域、单台机器。单台 VPS 只有一个位置且无故障切换。世界另一端的客户端为此支付往返延迟；如果该机器宕机，所有人都受影响。

带宽是唯一真正容易估算的成本。每次被中继的会话的大致数据：

低质量、以文本为主的工作：约 50 KB/s = 180 MB/小时
中等、一般办公工作：约 200 KB/s = 720 MB/小时
高强度、视频与设计工作：约 1 MB/s = 3.6 GB/小时

一台 Hetzner CX22 的 20 TB/月大致能覆盖约 5,500 小时的高质量中继会话。对于个人或小团队，这个上限通常不是限制——这正是要说明的点。如果你打算自托管是出于带宽考虑，那并不是个充分理由。真正的限制是上面那四条要点。

托管中继的替代做法

架构相同，但运营方不同。中继集群为多区域而非单台 VPS，因此客户端会连接到离他们更近的节点而不是离你更近的节点。它由以此为职责的人监控。密钥材料、打补丁和证书续期不再是你的问题。当它在凌晨 2 点出问题时，被通知的人不是你。

这就是订阅所买到的：Free 层 $0，Lite 层 $2.99/mo，Pro 层 $7.99/mo——查看定价了解各层包含内容，或在团队部署时查看商业计划。与 €4 VPS 加上你自己的值班轮班相比，对于大多数人来说账面计算并不接近。

何时自托管是真正正确的选择

当义务明确要求时这是正确的选择：有监管的工作要求流量不得经过第三方基础设施、隔离网段或受限网络外部中继不可达、或驻留规则将你限定在某个司法辖区。在这些情况下，运维成本不是额外负担，而是必须履行的要求，本指南正是你需要的。

选项本身的存在也很重要。Tenvo 采用 AGPL-3.0，服务器堆栈是开源的，因此托管中继是你购买的一种便利而非被迫接受的锁定。如果我们某天不再值得信赖，退出路径就是上面的指南——这正是发布它的目的。参见托管版本与原始 RustDesk 的比较，或安全模型的工作原理。

回顾

部署在最接近客户端的区域的 VPS。
Docker、UFW，以及 hbbs/hbbr 容器。
指向 VPS 的 DNS A 记录。
每台客户端的三项配置值：ID 服务器、Relay 服务器、公钥。
一个你实际做过一次恢复验证的 data/ 离线备份。
通过 Caddy 提供 TLS，并配置能通知你的监控。

部署需要三十分钟；拥有它则是无限期的责任。如果某项要求把你置于那种情形，上述步骤就是全部工作。如果没有要求，从托管中继开始——下载客户端，当合规表格让它变得相关时再回到本页。