自架 RustDesk relay server：hbbs 與 hbbr 設定

自架 RustDesk relay server 是什麼

自架 RustDesk relay server 是在一台 VPS 上執行的兩個 daemon。hbbs 是 ID 與 rendezvous server：它會註冊每個 client ID，並協助兩個 client 彼此建立連線。hbbr 是 relay server：它會傳送工作階段資料，但只處理無法直接互通的工作階段。多數指南會安裝這兩個 daemon，協助完成配對，然後就此停止。以下說明其餘工作：作為存取控制的 key、埠號、升級方式及頻寬。

兩個 daemon 都隨同映像檔 rustdesk/rustdesk-server 提供，並從同一個目錄讀取相同的 Ed25519 key pair。Ed25519 是公開金鑰簽章機制。這組 key pair 會決定哪些 client 能與您的 server 通訊，且其後沒有 user database。

hbbs 與 hbbr：哪個 daemon 會消耗頻寬

hbbs 的流量少且固定：包括 ID 註冊、心跳，以及介紹兩個 peer 的短暫交換。它會全天執行，但幾乎不會產生流量成本。

hbbr 的流量就是工作階段本身。螢幕畫面往一個方向傳送，鍵盤與滑鼠操作往另一個方向傳送；每個經過 relay 的 byte 都會先抵達你的 VPS，再從 VPS 傳出。如果供應商只計算 egress，relay 工作階段產生的成本約等於工作階段速率。如果供應商計算總傳輸量，成本約為兩倍。

relay 是備援路徑，不是正常路徑。hbbs 會先嘗試直接連線兩個 client，並透過兩端前方的 NAT（network address translation）進行 hole punching。成功時，工作階段完全不會經過 hbbr，也不會消耗你的傳輸額度。如果其中一端位於會為每個目的地指派新 port 的 NAT 後方，或位於會丟棄 punched path 的防火牆後方，工作階段就會退回 hbbr，所有畫面 frame 都會經過你的 VPS。

有一個環境變數會移除這項選擇。ALWAYS_USE_RELAY=Y 設定在 hbbs 上時，會強制所有工作階段經過 hbbr。RustDesk 文件在其中一個 Compose 範例中使用了這個設定，因此經常被直接複製。它能讓連線更可預測，也會讓 egress 真正產生流量成本。只有在你確實決定要這樣設定時才加入它，不要只是因為複製了範例就使用。

自架 RustDesk 伺服器需要哪些連接埠

以下連接埠編號已於 17 August 2026，對照 RustDesk 伺服器文件與 rustdesk-server repository 進行確認。

• TCP 21115，在 hbbs 上：NAT 類型測試。
• UDP 21116，在 hbbs 上：ID 註冊與 heartbeat。未開放此連接埠時，無論其他連接埠是否開放，client 都不會上線。
• TCP 21116，在 hbbs 上：TCP hole punching 與連線服務。
• TCP 21117，在 hbbr 上：relay。此連接埠傳輸工作階段資料，因此會產生網路流量成本。
• TCP 21118，在 hbbs 上，以及 TCP 21119，在 hbbr 上：WebSocket，供瀏覽器 client 使用。不使用此功能時，請將這兩個連接埠維持關閉。
• TCP 21114 是 RustDesk Server Pro 的 web console。open source build 不會在此連接埠監聽。

安裝 hbbs 與 hbbr，並固定映像標籤

services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:1.1.16
    command: hbbs
    volumes:
      - ./data:/root
    network_mode: "host"
    depends_on:
      - hbbr
    restart: unless-stopped

  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:1.1.16
    command: hbbr -k _
    volumes:
      - ./data:/root
    network_mode: "host"
    restart: unless-stopped

mkdir -p ~/rustdesk
cd ~/rustdesk
# save the block above as ~/rustdesk/compose.yml before this line
sudo docker compose up -d
sudo docker compose ps

兩項服務都應讀取 running。修改防火牆前，先確認這些監聽器已存在。

sudo ss -tlnp | grep -E ':2111[5-7]'
sudo ss -ulnp | grep ':21116'

您應看到 TCP 監聽器位於 21115、21116 與 21117，並看到 UDP 監聽器位於 21116。若缺少 UDP 項目，表示 hbbs 未執行，因為用戶端會向該監聽器註冊。

該檔案中有 4 項設定是刻意安排的。標籤為 1.1.16，這是截至 2026 年 8 月的目前版本，於 2026 年 7 月 20 日發布，而不是 latest，因為 latest 代表最近推送的任何版本；6 個月後的 docker compose pull 可能會提供一台您從未測試過的伺服器。network_mode: "host" 會直接繫結主機介面，這是 RustDesk 文件建議的方式，也會決定防火牆的行為。./data:/root 會將映像的工作目錄對應到主機，因此金鑰組會儲存在可備份的位置。hbbr -k _ 則是相較於上游範例唯一的變更，因為預設設定會讓任何人都能使用您的 relay。如果您不熟悉 Compose，在 VPS 上執行 Docker Compose 會說明檔案格式與生命週期指令。

如果 hbbr 之後移至第二台伺服器，必須告知 hbbs 新位置：傳入 -r relay.example.com:21117，或設定 RELAY-SERVERS 環境變數。若使用單一主機，則不需要此設定。

Ed25519 金鑰組是存取控制

首次啟動時，hbbs 會在其工作目錄中產生 id_ed25519 和 id_ed25519.pub。使用上述掛載設定後，這兩個檔案都會出現在主機上。

ls -l ~/rustdesk/data/
sudo cat ~/rustdesk/data/id_ed25519.pub

id_ed25519.pub 包含一個 base64 字串。將此字串填入每個用戶端的 Key 欄位。id_ed25519 是私密金鑰部分，絕不會離開伺服器。公開金鑰不是秘密，因為它本來就會複製到每個用戶端設定中。私密金鑰則是秘密：持有私密金鑰的人可以架設一台用戶端會信任的伺服器。

現在就備份這兩個檔案，不要等到設定好 20 個用戶端後才備份。

sudo tar czf ~/rustdesk-keys.tgz -C ~/rustdesk/data id_ed25519 id_ed25519.pub
sudo chmod 600 ~/rustdesk-keys.tgz

將該封存檔複製到這台主機以外的位置。這一步的重要性高於其他步驟，原因如下。刪除 ~/rustdesk/data，或在新的 VPS 上重建服務時未複製該檔案，hbbs 就會在下次啟動時產生新的金鑰組。每個用戶端仍保留舊的公開金鑰，因此 hbbs 會拒絕該用戶端，導致用戶端離線。執行 sudo cat ~/rustdesk/data/id_ed25519.pub，並將結果與任一用戶端的 Key 欄位比較：兩個字串不再相同，而這個不一致就是整個故障的原因。修復方式是手動編輯每台機器的設定，包括原本仰賴 RustDesk 連線的機器。

金鑰不是工作階段密碼，將兩者混淆會導致其中一項未設定。金鑰決定伺服器會與哪些用戶端通訊。受控機器上的永久密碼或一次性代碼，則決定誰可以在該機器上開啟工作階段。兩者都需要，擁有其中一項並不能彌補另一項設定薄弱。

為何未經驗證的中繼服務會造成問題

hbbr 預設不會進行任何檢查。RustDesk 設定文件直接說明：空白金鑰會允許沒有相符金鑰的用戶端使用中繼服務。保留空白預設值，是為了避免新使用者在第一次執行時遇到金鑰不相符的錯誤。代價是，任何找到你在 TCP 21117 上的位址的人，都能透過你的 VPS 傳送其工作階段流量，消耗你的傳輸額度，並使用你的 IP 位址。

command: hbbr -k _ 可解決這個問題。_ 引數會指示 hbbr 從其工作目錄載入金鑰組。由於兩個容器掛載相同的 ./data，因此載入的就是 hbbs 已產生的金鑰組。無須手動複製，因此不會發生金鑰不同步的問題。

共用磁碟區是最容易設定錯誤的部分。若為 hbbr 指定自己的目錄，它會產生另一組不同的金鑰組。此時 hbbs 與 hbbr 的金鑰不相符，所有透過中繼的工作階段都會失敗，但直接連線仍可運作。這種症狀很容易造成混淆：RustDesk 能連線到部分對等端，但無法連線到其他對等端，取決於 NAT 穿透是否恰好成功。使用一個 ls -l ~/rustdesk/data/ 顯示單一 id_ed25519 金鑰組，即可排除這個問題。

將用戶端指向您的伺服器

在每台機器上開啟 RustDesk，依序進入 Settings、Network、ID/Relay Server。

• ID Server：輸入您的主機名稱，例如 rustdesk.example.com。除非另行指定連接埠，否則用戶端會使用 21116。
• Relay Server：當 hbbr 與 hbbs 在同一台主機上執行時，留白。
• API Server：留白。開放原始碼伺服器不提供此項目。
• Key：貼上 id_ed25519.pub 中的 base64 字串。內容必須完全一致，結尾不得有空格。

接著，主視窗應顯示用戶端已就緒。若未顯示，表示 UDP 21116 的流量未到達 hbbs，因為註冊與 heartbeat 都透過 UDP 執行，沒有其他機制能讓 ID 上線。

限制連接埠，避免 relay 成為開放服務

由於容器使用 host networking，前方沒有 Docker NAT 規則，因此 ufw 規則會依預期套用。

sudo ufw allow 22/tcp
sudo ufw allow 21115:21117/tcp
sudo ufw allow 21116/udp
sudo ufw enable
sudo ufw status numbered

只有在執行瀏覽器用戶端時才加入 21118:21119/tcp。啟用 ufw 時，請保持第二個 SSH 工作階段開啟，避免 SSH 規則設定錯誤而將自己鎖在伺服器之外。VPS 的 ufw 防火牆基本概念涵蓋預設政策與規則順序。

現在要注意一個陷阱。如果改用 ports: 區塊發布連接埠，而替代的 RustDesk supervisor 映像範例正是採用此方式，Docker 會自行寫入 DNAT 規則，封包不必經過 ufw 規則所在的鏈。此時，對 21117 設定 ufw deny 不會生效；relay 會直接對網際網路開放，即使 ufw status 聲稱情況相反。Docker 發布的連接埠會繞過 ufw說明鏈的順序。使用 host networking 可完全避免此問題。如果確實要發布連接埠，請將它繫結至單一位址，例如反向代理後方的 "127.0.0.1:21118:21118"。

依來源位址限制僅適用於用戶端位址穩定的情況。

sudo ufw allow from 203.0.113.0/24 to any port 21115:21117 proto tcp
sudo ufw allow from 203.0.113.0/24 to any port 21116 proto udp

在旅館網路上的筆記型電腦通常沒有穩定位址，這正是 hbbr 上的金鑰在此處比防火牆發揮更實際作用的原因。

升級存放金鑰的堆疊

金鑰位於 bind mount 中，而不是容器內。因此，只要不動 ./data，升級就是安全的。

1. 先備份資料目錄：sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data。
2. 在 rustdesk-server releases 頁面閱讀新 tag 的版本資訊。
3. 編輯 compose.yml，將兩個 image: 行都改為新 tag。
4. 執行 sudo docker compose pull，再執行 sudo docker compose up -d。
5. 執行 sudo cat ~/rustdesk/data/id_ed25519.pub，確認輸出的字串與用戶端目前持有的字串一樣。

第 5 步是關鍵檢查。伺服器上的金鑰變更時不會顯示明顯錯誤，卻會同時使所有用戶端失效。回復版本的方法是填回舊 tag，然後再次執行 up -d。這只有在固定 tag 的情況下才有效：使用 latest 時，docker compose pull 會將名稱移至新映像，因此已沒有任何 tag 可指向舊映像。

通常導致金鑰遺失的原因不是 docker compose down，因為該操作不會變更 bind mount，而是遷移至新的 VPS 時只複製了 compose.yml。請一併複製 ./data。

監控具有流量額度方案的對外流量

hbbr 是此堆疊中唯一可能消耗流量額度的元件。RustDesk 的 FAQ 指出，1920x1080 畫面上的單一轉送連線流量介於 30 KB/s 和 3 MB/s 之間，一般辦公作業約為 100 KB/s。這些是單一工作階段的公開數據，不是您環境的實測值。以每月 60 小時、每天 2 小時計算，結果如下。

[
  {
    "label": "Low end, 30 KB/s",
    "gb_per_month": 6.5
  },
  {
    "label": "Office work, 100 KB/s",
    "gb_per_month": 21.6
  },
  {
    "label": "High end, 3 MB/s",
    "gb_per_month": 648
  }
]

以辦公作業的流量計算，單一工作階段每月約使用 21.6 GB，任何方案都不會注意到這個用量。以公開範圍的上限計算，同樣的 60 小時會使用 648 GB；若有 2 個工作階段同時以此速率運作，單月就會超過 1 TB 的流量額度。下限則是 6.5 GB。此處的 GB 以 1000 MB 計算，這也是流量額度通常採用的計算方式。

docker stats 不會替您細分這些流量，因為使用 host networking 的容器會共用主機的 network namespace，因此容器的計數器就是主機的計數器。以下 2 個工具可以使用。vnstat 會測量整台主機：

sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

整台主機就是整台主機：如果這台 VPS 也執行其他會傳輸實際資料的服務，例如每晚將手機相片庫上傳的 自架相片伺服器，其上傳流量會與轉送流量計入同一條每月流量額度。

nftables 計數器可以只測量轉送流量：

sudo nft add table inet relaymeter
sudo nft add chain inet relaymeter out '{ type filter hook output priority 0 ; }'
sudo nft add rule inet relaymeter out tcp sport 21117 counter
sudo nft list table inet relaymeter

此規則不指定 verdict，因此只會計算封包與位元組，不會改變允許的流量；規則也位於獨立的 table 中，不會干擾 ufw。此設定不具持久性：如果希望重新開機後恢復，請將相同的行加入 /etc/nftables.conf。只有在實際轉送工作階段期間，計數器才會增加。若沒有任何自有機器連線，計數器卻持續增加，表示有人找到了您的 relay；這正是 hbbr -k _ 用來防止的情況。

hbbr 也提供可以調低的速率限制。SINGLE_BANDWIDTH 預設將每個 relay connection 限制為 128 Mb/s，TOTAL_BANDWIDTH 則將所有連線合計限制為 1024 Mb/s。設定 SINGLE_BANDWIDTH=8 可將單一工作階段限制在約 1 MB/s。這只會限制速度，不會限制每月總流量，因此應將它視為防止單一工作階段占滿連線的方式，而不是流量預算控制。

完全不需要 relay 時

對於個人環境，實際上可能完全不需要這些元件。將兩台機器加入 mesh VPN，直接連線到 tunnel 位址即可。不需要 hbbs、hbbr 或 relay 對外流量，也不需要在 VPS 上執行容器並進行升級。

在要控制的機器上，於 RustDesk 的安全性設定中啟用直接 IP 存取。連接埠欄位預設為 21118。嘗試連線前，先確認該連接埠正在監聽：

ss -tlnp | grep 21118

接著改用該對等端的 VPN 位址，而不是 ID 進行連線。RustDesk 的 FAQ 指出，此模式的連線未加密，因此應在 tunnel 內使用，絕不可跨越公開網際網路連線。加密由 tunnel 提供。

請依機器的管理歸屬選擇方案。當你需要支援不屬於自己的機器，或對方永遠不會安裝 VPN client 時，自架 hbbs 和 hbbr 是適合的選擇，因為對方只需使用 ID 和密碼。當每台機器都屬於你，且能配置 cryptographic key 時，搭配直接 IP 存取的 mesh VPN 便是適合的選擇。WireGuard 與 Tailscale 的比較說明建立此 mesh 的兩種常見方式；在 Linux VPS 上執行 remote desktop則說明另一種情況：需要顯示畫面的機器本身就是伺服器。

FAQ

每個 RustDesk 工作階段都會經過我的 relay 嗎？

不會。hbbs 會先嘗試讓兩個用戶端直接連線，方法是穿透各自前方 NAT 的 hole punching。只有直接連線失敗的工作階段才會改用 hbbr，且只有這些工作階段會耗用你的頻寬。例外是 hbbs 的 ALWAYS_USE_RELAY=Y，這會強制所有工作階段經過 hbbr，不論是否存在可用的直接路徑。如果 Compose 檔案設定了這個變數，每個工作階段的每個位元組都會計入你的傳輸費用。

RustDesk 伺服器金鑰儲存在哪裡？遺失後該怎麼辦？

hbbs 第一次啟動時，會在工作目錄中產生 id_ed25519 和 id_ed25519.pub。官方映像中的該目錄是 /root，因此使用上方所示的 volume mount 後，檔案會出現在主機的 ./data。請將這兩個檔案備份到伺服器以外的位置。如果檔案遺失，hbbs 會在下次啟動時產生一組新的金鑰，而仍持有舊公開金鑰的所有用戶端都會遭到拒絕。除了手動編輯每個用戶端的 Key 欄位之外，沒有其他復原方式。

自架 RustDesk 伺服器需要開放哪些埠？

需要開放 TCP 21115、21116 和 21117，以及 UDP 21116。hbbs 使用 21115 進行 NAT 類型測試，使用 21116 透過 UDP 進行 ID 註冊與 heartbeat，也使用 21116 透過 TCP 進行 hole punching。hbbr 使用 21117 提供 relay。TCP 21118 和 21119 是瀏覽器用戶端使用的 WebSocket 埠；如果不使用瀏覽器用戶端，請保持關閉。TCP 21114 屬於 Pro web console，開放原始碼版本不需要此埠。

陌生人可以使用我自架的 RustDesk relay 嗎？

可以，前提是你以預設設定執行 hbbr。RustDesk 文件指出，空白金鑰允許沒有相符金鑰的用戶端使用 relay，因此任何得知你的主機名稱與埠 21117 的人，都能讓網路流量經過你的伺服器。請以 -k _ 執行 hbbr，讓它載入 hbbs 在共用 ./data volume 中產生的同一組金鑰。完成後，只有設定你公開金鑰的用戶端才能透過你的伺服器進行 relay。