ガイド

著者 Matt Connor 2026-08-17 ・更新日 2026-08-23

RustDeskのリレーサーバーをVPSで自分で構築する方法

Q: RustDesk サーバーキーはどこに保存されますか？紛失した場合はどうなりますか？

hbbs は初回起動時に、作業ディレクトリ内へ id_ed25519 と id_ed25519.pub を生成します。公式イメージ内では、そのディレクトリは /root です。そのため、前述のボリュームマウントを使用すると、ファイルはホスト上の ./data に現れます。両方のファイルをサーバー外へバックアップしてください。紛失すると、次回起動時に hbbs が新しいキーペアを生成します。古い公開キーを保持しているすべてのクライアントは拒否されます。復旧するには、各クライアントの Key フィールドを手動で編集するしかありません。

VPSでRustDeskのhbbsとhbbrを運用する方法です。Ed25519鍵、固定したイメージタグ、制限すべきポート、契約プランが負担するリレー帯域を確認できます。

自己ホスト型 RustDesk リレーサーバーとは

自己ホスト型 RustDesk リレーサーバーは、1 台の VPS 上で動作する 2 つのデーモンです。hbbs は ID サーバー兼ランデブーサーバーです。すべてのクライアント ID を登録し、2 台のクライアントを相互に接続します。hbbr はリレーサーバーです。直接通信できなかったセッションに限り、セッションのデータを中継します。多くのガイドは両方をインストールして接続できる状態にしたところで終わります。実際には、その後にアクセス制御として機能する鍵、ポート、アップグレード、帯域幅の管理が必要です。

両方のデーモンは同じイメージ（rustdesk/rustdesk-server）に含まれており、同じディレクトリから同じ Ed25519 鍵ペアを読み込みます。Ed25519 は公開鍵署名方式です。この鍵ペアによって、サーバーが通信するクライアントが決まります。これとは別にユーザーデータベースはありません。

hbbs と hbbr: 帯域幅を消費するデーモン

hbbs のトラフィックは少なく、一定です。ID の登録とハートビートに加え、2 つのピアを紹介する短い通信が発生します。終日動作しますが、コストはほとんどかかりません。

hbbr のトラフィックはセッションそのものです。画面フレームが一方向に送られ、キーボードとマウスの入力が反対方向に送られます。中継されるすべてのバイトが VPS に到着し、その後 VPS から再び送信されます。プロバイダーが送信トラフィックだけを計測する場合、中継セッションのコストはセッションの通信量とほぼ同じです。総転送量を計測する場合は、ほぼ 2 倍になります。

リレーは通常の経路ではなく、フォールバックです。hbbs はまず、各クライアントの前段にある NAT (network address translation) を通過するホールパンチングを使い、2 つのクライアントを直接接続しようとします。これが成功すれば、セッションは hbbr を経由せず、転送量の上限も消費しません。一方が接続先ごとに新しいポートを割り当てる NAT の背後にある場合や、ホールパンチングで確立した経路を破棄するファイアウォールがある場合、セッションは hbbr にフォールバックします。その場合、すべてのフレームが VPS を通過します。

1 つの環境変数でこの選択をなくせます。ALWAYS_USE_RELAY=Y を hbbs に設定すると、すべてのセッションが hbbr を経由します。RustDesk のドキュメントには Compose の例の 1 つとして記載されているため、よくコピーされています。接続は予測しやすくなりますが、送信トラフィックも実際に発生します。自分で選択した場合に設定し、貼り付けたからという理由だけで設定しないでください。

セルフホストの RustDesk サーバーに必要なポート

以下のポート番号は、2026 年 8 月 17 日に RustDesk サーバーのドキュメントと rustdesk-server リポジトリを照合したものです。

TCP 21115、hbbs: NAT タイプのテストに使用します。
UDP 21116、hbbs: ID 登録とハートビートに使用します。これが開いていないと、ほかのポートを開いていてもクライアントはオンラインになりません。
TCP 21116、hbbs: TCP ホールパンチングと接続サービスに使用します。
TCP 21117、hbbr: リレーに使用します。セッションデータを転送するポートであるため、通信料金が発生するポートです。
TCP 21118、hbbs、および TCP 21119、hbbr: ブラウザクライアントが使用する WebSocket です。使用しない場合は、両方とも閉じておきます。
TCP 21114: RustDesk Server Pro の Web コンソールです。オープンソース版はこのポートで待ち受けません。

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 は直近に push されたものが常に使われることを意味し、6 か月後の docker compose pull によって、テストしていないサーバーが配布される可能性があるためです。network_mode: "host" はホストのインターフェイスに直接 bind します。これは RustDesk のドキュメントが推奨する方法であり、ファイアウォールの動作にも影響します。./data:/root はイメージの作業ディレクトリをホストにマッピングするため、鍵ペアをバックアップ可能な場所に保存できます。hbbr -k _ は upstream の例から変更した箇所です。デフォルトの設定では、リレーが誰でも利用できる状態になるためです。Compose に慣れていない場合は、VPS で Docker Compose を実行するで、ファイル形式とライフサイクル用コマンドを説明しています。

hbbr を別のサーバーへ移す場合は、hbbs に移行先を通知する必要があります。-r relay.example.com:21117 を渡すか、RELAY-SERVERS 環境変数を設定してください。1 台のサーバーで運用する場合は不要です。

Ed25519 鍵ペアがアクセス制御を担います

初回起動時に hbbs は作業ディレクトリに id_ed25519 と id_ed25519.pub を生成します。上記のマウント設定により、両方のファイルがホスト側に表示されます。

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

id_ed25519.pub には 1 つの 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 フィールドと比較してください。2 つの文字列は一致しなくなり、その不一致が障害の原因です。修正するには、RustDesk で接続する予定だったマシンも含め、すべてのマシンで設定を手作業で編集する必要があります。

この鍵はセッションパスワードではありません。両者を混同すると、どちらか一方を省略してしまいます。鍵は、サーバーが通信するクライアントを決定します。管理対象マシンに設定する永続パスワードまたはワンタイムコードは、そのマシンでセッションを開けるユーザーを決定します。両方が必要です。一方があっても、もう一方が弱いことの補いにはなりません。

認証なしリレーが問題になる理由

デフォルトでは、hbbr は何も検証しません。RustDesk の設定ドキュメントにも明記されているとおり、空の key を指定すると、一致する key を持たないクライアントでもリレーを利用できます。空のデフォルト値は、初回起動時に新規ユーザーが key の不一致エラーに遭遇しないようにするためのものです。その代わり、TCP 21117 上のアドレスを見つけた誰でも、VPS の転送量を消費し、VPS の IP アドレスから送信する形で、セッションのトラフィックを VPS 経由で転送できてしまいます。

command: hbbr -k _ でこれを防げます。_ 引数により、hbbr は作業ディレクトリから key ペアを読み込みます。両方のコンテナが同じ ./data をマウントしているため、読み込まれるのは hbbs がすでに生成した key ペアです。手動でコピーする必要がないため、内容がずれることもありません。

共有ボリュームの設定を誤るケースが多くあります。hbbr に専用ディレクトリを割り当てると、hbbr は別の key ペアを生成します。その結果、hbbs と hbbr の key が一致せず、すべてのリレーセッションが失敗します。一方、直接接続は引き続き動作します。NAT ホールパンチングが成功したかどうかによって、RustDesk が一部のピアには接続でき、別のピアには接続できないため、症状が分かりにくくなります。単一の id_ed25519 ペアだけを示す ls -l ~/rustdesk/data/ が 1 つあれば、この可能性を排除できます。

クライアントをサーバーに向ける

各マシンで RustDesk を開き、Settings、Network、ID/Relay Server の順に選択します。

ID Server: サーバーのホスト名を指定します。例: rustdesk.example.com。クライアントは、別のポートを指定しない限り 21116 を使用します。
Relay Server: hbbr が hbbs と同じホストで動作している場合は空欄のままにします。
API Server: 空欄のままにします。オープンソース版のサーバーには API Server がありません。
Key: id_ed25519.pub の base64 文字列を、末尾に空白を付けず、そのまま貼り付けます。

その後、メインウィンドウにクライアントの準備が完了したことが表示されます。表示されない場合は、UDP 21116 が hbbs に到達していません。登録とハートビートは UDP で実行されるため、他の処理によって ID Server がオンラインになることはありません。

リレーをオープンサービスにしないためにポートを制限する

コンテナはホストネットワークを使用するため、コンテナの前段に 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 は効果がなくなり、ufw status がそうでないと示していても、リレーはインターネットに公開された状態になります。Docker の公開ポートは ufw を迂回するでは、チェーンの適用順序について説明しています。ホストネットワークを使用すれば、この問題を完全に回避できます。ポートを公開する場合は、リバースプロキシの背後にある "127.0.0.1:21118:21118" のように、1 つのアドレスにバインドしてください。

送信元アドレスによる制限が機能するのは、クライアントのアドレスが安定している場合だけです。

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

ホテルのネットワークに接続するノート PC には安定したアドレスが割り当てられません。そのため、ここではファイアウォールよりも hbbr の key のほうが実際の保護に大きく貢献します。

鍵を保持するスタックのアップグレード

鍵はコンテナ内ではなく bind mount に保存されます。そのため、./data に手を加えない限り、アップグレードは安全です。

最初にデータディレクトリをバックアップします: sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data。
rustdesk-server の releases ページで、新しいタグのリリースノートを確認します。
compose.yml を編集し、2 つの image: 行を新しいタグに変更します。
sudo docker compose pull を実行し、続いて sudo docker compose up -d を実行します。
sudo cat ~/rustdesk/data/id_ed25519.pub を実行し、クライアントがすでに保持している文字列と同じであることを確認します。

重要なのはステップ 5 の確認です。鍵が変更されてもサーバー側では警告なく処理され、すべてのクライアントが同時に接続できなくなるためです。ロールバックするには、古いタグに戻して up -d を再度実行します。タグを固定していたため、この方法が使えます。latest を使用した場合、docker compose pull は名前を新しいイメージに移動するため、古いイメージを指すタグが残りません。

鍵を失う一般的な原因は、bind mount をそのまま保持する docker compose down ではありません。新しい VPS へ移行する際に、compose.yml だけをコピーすることです。./data も一緒にコピーしてください。

転送量上限のあるプランで送信トラフィックを監視する

この構成で転送量上限を消費する可能性があるのは hbbr だけです。RustDesk の FAQ では、1920x1080 の画面で 1 つのリレー接続が 30 KB/s から 3 MB/s の範囲になると説明されています。また、通常のオフィス作業は約 100 KB/s とされています。これらは 1 セッションについて公開されている値であり、実際の構成を測定した値ではありません。1 日 2 時間、1 か月に 60 時間利用すると、次のようになります。

ChartVPS egress from one relayed RustDesk session, 60 hours per month

label

gb_per_month

Low end, 30 KB/s

6.5

Office work, 100 KB/s

21.6

High end, 3 MB/s

648

The data behind this chart

[
  {
    "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
  }
]

オフィス作業の速度では、1 セッションの月間使用量は約 21.6 GB です。どのプランでも問題にならない量です。公開値の上限では、同じ 60 時間で 648 GB になります。この速度で 2 セッションを同時に使用すると、1 か月以内に 1 TB の上限を超えます。下限では 6.5 GB です。ここでの Gigabytes は 1000 MB として計算しています。これは通常、転送量上限で使われる計算方法です。

docker stats では、この内訳を確認できません。ホストネットワークを使用するコンテナはホストのネットワーク名前空間を共有するため、コンテナのカウンターがホストのカウンターになるからです。使用できるツールは 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 がないため、許可内容を変更せずにパケット数とバイト数だけを数えます。また、独自のテーブルに配置しているため、ufw に影響しません。これは永続化されません。再起動後も有効にしたい場合は、同じ行を /etc/nftables.conf に記述してください。カウンターは、実際にセッションがリレーされている間だけ増加します。自分のマシンがどれも接続していないのにカウンターが増え続ける場合は、他者がリレーを見つけて使用しています。これを防ぐために hbbr -k _ が存在します。

hbbr には引き下げ可能なレート制限もあります。SINGLE_BANDWIDTH のデフォルト値はリレー接続ごとに 128 Mb/s、TOTAL_BANDWIDTH のデフォルト値は全接続合計で 1024 Mb/s です。SINGLE_BANDWIDTH=8 を設定すると、1 セッションの速度を約 1 MB/s に制限できます。これは速度を制限するものであり、月間合計を制限するものではありません。そのため、1 セッションが回線を占有するのを防ぐ手段として使用し、転送量の予算管理には使わないでください。

リレーがまったく必要ない場合

個人利用では、これらの仕組みがまったく必要ないこともあります。2 台のマシンをメッシュ VPN に接続し、トンネルのアドレスへ直接接続します。hbbs も hbbr も不要で、リレーによる外向き通信もなく、VPS 上のコンテナを更新する必要もありません。

操作対象のマシンで、RustDesk のセキュリティ設定から直接 IP アクセスを有効にします。ポート欄の初期値は 21118 です。接続する前に、待ち受け状態を確認してください。

ss -tlnp | grep 21118

そのピアの VPN アドレスへ、ID ではなく接続します。RustDesk の FAQ では、このモードの接続は暗号化されないと説明されています。そのため、トンネル内でのみ使用し、オープンインターネット経由では決して使用しないでください。暗号化を提供するのはトンネルです。

マシンの所有者に基づいて選択してください。自分が所有していないマシンを管理する場合や、VPN クライアントを決してインストールしない利用者を支援する場合は、自己ホスト型の hbbs と hbbr が適しています。相手側では ID とパスワードだけを使えばよいためです。すべてのマシンを自分が所有し、各マシンで鍵を利用できる場合は、メッシュ VPN と直接 IP アクセスが適しています。WireGuard と Tailscale の比較では、このメッシュを構築する一般的な 2 つの方法を説明しています。Linux VPS 上でリモートデスクトップを実行するでは、画面を表示したいマシン自体がサーバーである別のケースを説明しています。

FAQ

すべての RustDesk セッションは自分のリレーを経由しますか？

いいえ。hbbs はまず、各クライアントの前段にある NAT を通過するホールパンチングを使用し、2 台のクライアント間の直接接続を試みます。直接接続に失敗したセッションだけが hbbr にフォールバックするため、帯域幅を消費するのもそのセッションだけです。例外は hbbs の ALWAYS_USE_RELAY=Y です。これを設定すると、直接接続できる場合でも、すべてのセッションが hbbr を経由します。この変数を Compose ファイルで設定すると、すべてのセッションのすべてのバイトが転送量の請求対象になります。

RustDesk サーバーキーはどこに保存されますか？紛失した場合はどうなりますか？

hbbs は初回起動時に、作業ディレクトリ内へ id_ed25519 と id_ed25519.pub を生成します。公式イメージ内では、そのディレクトリは /root です。そのため、前述のボリュームマウントを使用すると、ファイルはホスト上の ./data に現れます。両方のファイルをサーバー外へバックアップしてください。紛失すると、次回起動時に hbbs が新しいキーペアを生成します。古い公開キーを保持しているすべてのクライアントは拒否されます。復旧するには、各クライアントの Key フィールドを手動で編集するしかありません。

自ホストの RustDesk サーバーで開放する必要があるポートはどれですか？

TCP 21115、21116、21117 と UDP 21116 です。hbbs は NAT タイプのテストに 21115 を使用します。また、UDP による ID 登録と heartbeat、および TCP によるホールパンチングに 21116 を使用します。hbbr はリレーに 21117 を使用します。TCP 21118 と 21119 はブラウザクライアント用の WebSocket ポートです。使用しない場合は閉じたままにしてください。TCP 21114 は Pro の Web コンソール用であり、オープンソース版では必要ありません。

見知らぬユーザーが自ホストの RustDesk リレーを使用できますか？

はい。デフォルト設定で hbbr を実行している場合は使用できます。RustDesk のドキュメントによると、空のキーを設定すると、一致するキーを持たないクライアントもリレーを使用できます。そのため、ホスト名とポート 21117 を知っているユーザーは誰でも、サーバー経由でトラフィックを送信できます。hbbr を -k _ 付きで実行し、共有 ./data ボリューム内で hbbs が生成した同じキーペアを読み込ませてください。その後は、自分の公開キーを設定したクライアントだけが、サーバー経由でリレーできます。

#rustdesk #remote-desktop #docker #self-hosting #firewall