TeamViewer 一偵測到「商業使用」就斷線：RustDesk 用兩支 Rust binary 把遠端桌面搬回自家機房

「Commercial use detected」這行紅字大概是過去十年裡最讓 IT 工程師厭世的字串之一。在家幫長輩修電腦也好、跨辦公室連一台閒置主機也好，TeamViewer 的啟發式偵測一旦判定為「商業使用」，session 五分鐘斷一次，後面接的就是業務報價單。AnyDesk 走訂閱制以後路徑變了但價錢沒變便宜，至於 Chrome Remote Desktop——資料全部過 Google 機房，這件事本身就是答案。

RustDesk 在這個前提下成為 2026 年自架遠端桌面的事實標準。整套協定由兩支 Rust 寫的 binary 構成，分別處理會合與中繼；用戶端跨 Windows、macOS、Linux、Android、iOS 與瀏覽器，AGPL-3.0 授權，伺服器丟在自家 VPS 上跑五分鐘就能起來，連線經過 NaCl 端對端加密後在中繼節點上也是亂碼。GitHub 上已經累積到 11 萬星，是這個分類裡最活躍的一個專案。

RustDesk 的兩個 daemon：hbbs 與 hbbr

自架的 RustDesk 伺服器只有兩個元件，名字短得有點刻意：hbbs 是 ID 與 Rendezvous Server，hbbr 是 Relay Server。

hbbs 的工作是註冊與會合。每台 RustDesk 用戶端啟動時會向 hbbs 報到，用 9 位數字的 ID 註冊自己的網路位置與 NAT 型態。當 A 機要連 B 機時，A 對 hbbs 問「B 在哪裡」，hbbs 回傳 B 的連線資訊並協助雙方做 UDP hole punching。理想情況下這時候就能建立 P2P 直連，整套流量根本不需要經過自家機房。

但有些 NAT 環境（symmetric NAT、雙重 NAT、企業防火牆）打洞會失敗。這時候 hbbr 就出場接管：它純粹是個流量中繼，把 A 與 B 的加密封包對接起來，自己看不到內容。連線速度直接受限於這台 VPS 的頻寬與延遲，這也是為什麼會建議把 RustDesk 伺服器放在跟使用者地理位置接近的機房。

預設 port 配置如下：

21115/tcp：NAT 型態測試
21116/tcp + 21116/udp：ID 註冊與會合
21117/tcp：中繼流量
21118/tcp、21119/tcp：Web 用戶端

注意 21116 走 TCP 跟 UDP 兩個協定，UDP 是 hole punching 的關鍵，少開一個就退化到必中繼模式，VPS 流量會吃得很兇。

加密模型：Ed25519 加 XSalsa20-Poly1305

很多人對自架遠端桌面的疑慮是「那台中繼伺服器會不會看到我的螢幕內容」。RustDesk 的答案是不會，原理值得拆開看一次。

第一次啟動 hbbs 時，會在 data 目錄產生一組 Ed25519 金鑰對：id_ed25519 與 id_ed25519.pub。公鑰會被分發給所有用戶端（透過 RustDesk 設定介面的 Key 欄位），用來驗證伺服器身分，順便鎖定「只有持有這把 key 的用戶端能連這台 hbbs」。沒設 key 的話伺服器是開放的，誰知道網址就能用，這在公網部署上要避免。

連線建立時，A 與 B 兩個用戶端透過 sodiumoxide::crypto::box_（也就是 NaCl 的 box 結構，背後是 Curve25519 + XSalsa20 + Poly1305）做非對稱金鑰交換，協商出一把對稱金鑰。後續所有畫面、鍵盤、剪貼簿、檔案傳輸的串流都用 secretbox（XSalsa20-Poly1305）這把對稱金鑰加密。

關鍵在於：協商出的對稱金鑰不會經過 hbbs 或 hbbr。即使流量必須走中繼，伺服器看到的也只是密文。這跟 Atuin、Headscale 那類自架服務的端對端加密設計是同一個套路——伺服器只做路由，不解內容。

Docker Compose 部署：五分鐘起一台

官方提供的 docker-compose 範本足夠跑線上服務：

networks:
  rustdesk-net:
    external: false

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

  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    ports:
      - 21117:21117
      - 21119:21119
    volumes:
      - ./data:/root
    networks:
      - rustdesk-net
    restart: unless-stopped

幾個容易忽略的細節。hbbs 啟動參數的 -r rustdesk.example.com:21117 必須換成自己的 domain 或 IP，這是告訴 hbbs「中繼伺服器在哪裡」，用戶端會從這個位址連到 hbbr。寫錯或忘記寫，P2P 失敗時就沒中繼可用。

兩個 service 共用同一個 ./data 目錄是刻意的——id_ed25519 金鑰要在兩支 daemon 之間共享。如果分開掛 volume 會生出兩組金鑰，部分功能會錯亂。

防火牆規則上，TCP 的 21115-21119 跟 UDP 的 21116 都得對外開。21116/udp 特別容易在 cloud provider 的 security group 漏掉，因為大多數人預設只想到 TCP。

第一次跑起來後，到 ./data/id_ed25519.pub 把公鑰內容複製出來，這就是分發給用戶端用的 Key。

用戶端設定：把 ID 跟 Relay 指向自家伺服器

裝好 RustDesk 用戶端後，進入「網路」設定，三個欄位要填：

ID 伺服器：rustdesk.example.com:21116（或預設 port 直接寫 domain）
中繼伺服器：可以留空，會用 hbbs 啟動參數 -r 指定的值
金鑰：貼上 id_ed25519.pub 的內容

設定完後重啟用戶端，主畫面會顯示「Ready」綠燈，表示已經跟自架 hbbs 註冊成功。從這刻起，這台機器再也不會跟官方雲端服務通訊。

對需要批量部署的場景（例如要在公司內部 50 台 Windows 主機上裝），用戶端支援透過環境變數或設定檔自動帶入伺服器資訊。打包安裝程式時帶上預設配置，比叫每個使用者手動填三個欄位實際得多。

中繼頻寬規劃：別把小 VPS 當救火隊

hbbr 的角色是流量中繼，這意味著當 P2P 失敗時，連線雙方的全部流量都會從這台 VPS 過。1080p 桌面連線在中等品質設定下大約吃 2-5 Mbps，4K 或要傳檔可以飆到 20 Mbps 以上。同時十條連線打進來、又剛好全部都退化到中繼模式，一張 100 Mbps 的網卡很容易被吃滿。

兩條經驗法則。第一，盡量讓 P2P 直連能成功——這代表 hbbs 的 UDP 21116 一定要通，雙方的 NAT 型態能容許 hole punching，這時候 hbbr 的流量幾乎是零。第二，VPS 規格選擇上頻寬比 CPU、記憶體都關鍵，RustDesk server 本身吃資源極少（兩個 daemon 加起來 50MB 不到記憶體），但中繼吃的是頻寬。

地理位置也要納入考量。如果使用者主要在臺灣，伺服器擺在臺灣機房延遲最低；中繼模式的延遲直接影響操作體感，超過 80ms 滑鼠就會有明顯拖滯。跨國團隊則可能要考慮多開幾台 hbbr，用戶端設定中繼伺服器清單來分流。

RustDesk Pro 的取捨：OSS 對絕大多數場景已經夠

RustDesk 還有一個 Pro 版本，授權上是商業授權，不是開源。Pro 加上去的東西包括：Web 主控台、LDAP/OIDC 整合、地址簿管理、權限策略、稽核日誌、自動更新派送等。對需要管理上百台終端的 IT 部門，這些功能省下的人力遠超授權費。

個人或小團隊用 OSS 版完全沒問題。AGPL 授權對自架使用者沒有實際限制——只要你沒有把修改過的版本當成 SaaS 對外提供，就不需要釋出原始碼。本地端跑、自家機房跑、公司內部用，全部都在 AGPL 容許範圍。

唯一要小心的是：如果想把 RustDesk 整合進對外販售的產品（例如做成「遠端支援工具」賣給客戶），AGPL 會把整個產品的程式碼都拖下水。這種商用整合場景就是 Pro 授權存在的理由。

適合與不適合的場景

最甜蜜的使用情境：個人/小團隊跨地點操作機器、給家裡長輩做技術支援、跨辦公室連測試機、臨時遠端 demo。這些場景共通點是流量散、單次時間短，自架一台小 VPS 就綽綽有餘。

不適合的場景：需要 24 小時無人值守的 server 管理。這種需求 SSH 加 mosh 加 tmux 才是對的工具，遠端桌面只是把問題弄複雜。另一個不適合的是高延遲環境下的設計工作，遠端桌面協定再怎麼優化都比不上 native 操作的反饋速度。

跟商業方案比較，RustDesk OSS 沒有的東西是雲端代管的便利性與商業客服。但對技術讀者來說，這兩件事的價值都被「資料留在自家機房」與「沒有商業使用偵測誤判」抵消有餘。

遠端桌面這類工具本來就有強烈的「資料主權」屬性——畫面、鍵盤輸入、剪貼簿內容，任何一段被截走都會出大事。把控制平面跟中繼節點都拉回自家機房，是這類工具該有的部署形態，而 RustDesk 是目前少數把這條路走得乾淨利落的開源方案。

NCSE Network 的 VPS 採 Intel Gold CPU 與 NVMe SSD，位於臺灣是方電訊機房，跑 RustDesk hbbs 加 hbbr 的資源需求極低，最小規格方案就夠用，臺灣本地的低延遲對遠端桌面的操作手感特別重要。詳情可到 ncse.tw 查看方案。