rustdesk docker：容器化 RustDesk 服务器指南

你想在不折腾手动构建、依赖地狱或脆弱虚拟机镜像的情况下自托管 RustDesk。本指南展示如何使用 Docker 和 Docker Compose 运行生产就绪的 RustDesk 服务器堆栈，便于像运维一样管理更新、备份和扩容。

为何为 RustDesk 使用 docker

容器为自托管远程访问堆栈带来两个直接好处：可复现的部署与隔离。你无需在本地编译 hbbs/hbbr 或运行平台特定的软件包，只需拉取 Docker 镜像、挂载持久卷并启动。这简化了升级、CI/CD 和主机迁移。如果你已经在容器中运行其他服务（NGINX、certbot、监控），以这种方式添加 RustDesk 可以保持堆栈一致性。

不适合容器化的情况：如果你需要定制打补丁的二进制文件或为了极高性能的中继进行深度内核集成，本地原生安装可能更合适。此外，如果你需要厂商提供的官方企业 SLA，请确认该厂商是否支持容器部署。

RustDesk 服务器组件 — 简要概述

RustDesk 将服务器角色至少拆分为两部分：

hbbs — ID/信令服务器。负责客户端的注册和协调。
hbbr — 中继服务器（当 NAT 穿透失败时）。它在对端之间中继流量。

在生产环境中通常同时运行两者。单台轻量主机可以同时运行两项服务；较大部署会将它们分离，将 hbbr 实例放在负载均衡器后面，并为中继容量添加自动扩缩。

快速入门：示例 Docker Compose 部署

前提：Ubuntu 22.04 LTS（或任何带有 Docker Engine 20.10+ 的 Linux）、Docker Compose v2.x、一个域名（示例：rustdesk.example.com）。小型测试服务器至少分配 512 MB RAM；若中继将处理多个活动会话，建议 1 GB+。

下面是一个实用的 Docker Compose 示例，分别以独立服务运行 hbbs 与 hbbr，挂载持久数据并发布 RustDesk 的标准端口。运行前检查官方 rustdesk/rustdesk-server 镜像标签以获取最新稳定标签，若需固定版本请替换 rustdesk/rustdesk-server:latest。

version: '3.8'

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbs
    command: ["hbbs", "--listen", "0.0.0.0:21115"]
    ports:
      - "21115:21115/tcp"
      - "21115:21115/udp"
    volumes:
      - ./data/hbbs:/data
    restart: unless-stopped

  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbr
    command: ["hbbr", "--listen", "0.0.0.0:21116", "--relay", "0.0.0.0:21116"]
    ports:
      - "21116:21116/tcp"
      - "21116:21116/udp"
    volumes:
      - ./data/hbbr:/data
    restart: unless-stopped

networks:
  default:
    external: false

说明：

我们将 hbbs 运行在 TCP/UDP 21115 端口，hbbr 在 21116——这些是 RustDesk 服务器构建的常用默认端口。请确认你所用镜像的端口映射（部分社区构建可能使用不同默认值）。
持久卷 ./data/hbbs 和 ./data/hbbr 在重启间保留你的注册和中继数据。
使用 restart: unless-stopped 提供基础的抗故障；在生产环境中，请与你的编排平台的重启策略集成。

安全暴露：TLS、反向代理与防火墙

RustDesk 的信令与中继流量可以通过 TLS 和常规防火墙规则进行保护。常见做法有两种：

在 hbbs 前放置代理并直接终止 TLS（推荐用于证书管理的 Web 层）。
将 hbbr 保持为原始 TCP/UDP 中继并加固主机网络（使用 ufw/nftables），同时对 hbbs 使用 TLS。

大多数部署使用 NGINX 或 Traefik 来终止 TLS 并将流量转发到 hbbs。下面是用于为 rustdesk.example.com 终止 TLS 的示例 NGINX server 块：

server {
  listen 443 ssl;
  server_name rustdesk.example.com;

  ssl_certificate /etc/letsencrypt/live/rustdesk.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/rustdesk.example.com/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:21115;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

# Optional: redirect http to https
server {
  listen 80;
  server_name rustdesk.example.com;
  return 301 https://$host$request_uri;
}

使用 certbot（Let's Encrypt）或你的 CA 获取证书。如果你的中继（hbbr）在公网开启 UDP/TCP，请直接暴露这些端口并将防火墙限制到预期的 IP 范围，或将中继节点放入私有子网并置于负载均衡器之后。

DNS、客户端与 NAT 穿透

将一个 DNS A 记录（例如 rustdesk.example.com）指向服务器的公网 IP。在 RustDesk 客户端中将服务器地址设置为该域名（用于 ID 与中继查找）。客户端使用 ID 服务器进行协调；如果双方客户端都处于严格 NAT 后，hbbr 将通过你的中继服务器中继会话。

如果你能控制局域网内的客户端，可运行内部 DNS 或分发指向 hbbs 内部 IP 的配置文件，以便实现更快的本地连接。

扩展与资源建议

中继需要多少 CPU/RAM？取决于并发会话数和会话类型：

小型测试服务器：1 vCPU、512 MB RAM — 少量空闲连接。
生产中继（轻度使用）：2 vCPU、1–2 GB RAM — 数十个并发会话。
高吞吐中继：4+ vCPU、4+ GB RAM，并配备与预期带宽相匹配的网络能力（例如 100+ Mbps）。

如果预期存在流量峰值（媒体密集的远程控制、屏幕共享），建议在负载均衡器后自动扩缩 hbbr 实例。可使用容器编排（Kubernetes、Docker Swarm）或通过保留客户端 IP 的 TCP/UDP 负载均衡器（haproxy、云 LB）做简单水平扩展。

备份、更新与版本固定

务必为数据挂载持久卷并定期备份。一个最小备份脚本：

# daily-backup.sh
TIMESTAMP=$(date +%F)
mkdir -p /backups/rustdesk/$TIMESTAMP
rsync -a ./data /backups/rustdesk/$TIMESTAMP/
# rotate: keep 14 days
find /backups/rustdesk -maxdepth 1 -type d -mtime +14 -exec rm -rf {} \;

更新时应使用带标签的镜像而不是 :latest。提升服务器镜像前请在预演环境中测试。示例工作流：

拉取新镜像：docker pull rustdesk/rustdesk-server:1.3.0（示例）。
使用相同卷启动测试容器并运行冒烟测试。
安排维护窗口并在生产主机上替换容器。

故障排查与常见陷阱

先看日志：docker logs rustdesk-hbbs 和 docker logs rustdesk-hbbr。常见问题：

客户端无法注册：检查域名能否访问 hbbs 并确保证书有效。
会话回落到中继但性能差：检查中继主机的 CPU/内存与网络。中继数据包通常为 UDP；确保防火墙与云安全组允许 UDP。
客户端显示版本不匹配：使用相配或兼容的 RustDesk 客户端/服务器版本。若你固定了服务器镜像，请确保客户端没有使用已弃用的协议特性。

如果大量客户端持续无法穿透 NAT，通常是对称 NAT 或企业防火墙所致。在这些情况下，依赖 hbbr 中继并监控延迟/吞吐以确保可接受的用户体验。

安全注意事项

自托管将责任转移给你。关键步骤：

在反向代理处终止 TLS 并使用强加密套件。从 Let's Encrypt 或受信任的 CA 获取证书。
加固主机：仅开放必要端口，启用操作系统的自动安全更新，并使用防火墙（ufw/nftables）。
限制对管理界面的访问并监控日志以发现暴力破解尝试。考虑网络分段；如可能，将中继节点放在独立子网中。

若想对锁定远程访问做更广泛的讨论，可参阅我们的 remote desktop security 一文以及关于 self‑hosted remote desktop 的实用权衡说明。

何时选择托管厂商更合适

使用 docker 自托管可获得控制与隐私，但若你需要完全托管的 SLA、官方企业功能（用户管理、集中计费）或开箱即用的 Windows AD 集成，商业厂商如 TeamViewer 或 AnyDesk 可能更合适。公开权衡：自托管可节省按座位计费并提供数据本地化，但需投入运维时间去维护、监控和加固。

下一步与参考

从实验室到生产的清单：

选择一台运行 Docker Engine 20.10+ 与 Docker Compose v2.x 的主机。
创建持久卷并设置每日备份任务。
固定服务器镜像并在预演环境验证更新。
使用 NGINX/Traefik 终止 TLS，并从 Let's Encrypt 获取证书。
监控中继主机并在 CPU 或带宽达到健康阈值时扩展 hbbr。

想要一个干净的下载以便与容器方法并排比较？从 /download 获取 Tenvo 的二进制或安装程序，并查看我们的 /pricing 页面了解部署选项。如果你更想跟随更全面的远程访问设置，我们的 remote access setup guide 覆盖了跨工具的网络、认证与可用性话题。

在 Docker 下运行 RustDesk 对大多数自托管者来说是稳健且易于维护的方法：它简化了升级并能很好地融入现有容器基础设施。如果你需要 compose 文件的副本或帮助将此适配到 Kubernetes，请返回，我会提供 K8s 清单和 Helm chart 示例。