RustDesk на VPS: свой сервер удалённого доступа

Self-hosted сервисы
RustDesk на VPS: свой сервер удалённого доступа

Собственный RustDesk Server нужен, когда вы хотите подключаться к компьютерам через привычный клиент RustDesk, но не зависеть от публичной инфраструктуры проекта для регистрации устройств и ретрансляции трафика. На VPS запускаются две службы: hbbs координирует соединения и выдаёт клиентам сведения о сервере, а hbbr передаёт трафик, если прямое соединение между устройствами установить не удалось. Ниже — практическая схема для Ubuntu и Docker Compose с фиксированной версией RustDesk Server OSS 1.1.16, минимально необходимыми портами, проверкой результата, резервным копированием ключей и безопасным обновлением.

Оглавление

Что именно разворачивается на VPS

RustDesk состоит не только из программы удалённого рабочего стола на Windows, Linux, macOS или мобильном устройстве. Для поиска устройств и соединения клиентов ему нужна серверная часть. В бесплатной редакции RustDesk Server OSS это два отдельных процесса:

  • hbbs — ID-, rendezvous- и signaling-сервер. Он регистрирует клиентские ID, помогает устройствам найти друг друга и участвует в согласовании соединения;
  • hbbr — relay-сервер. Он становится промежуточным узлом, когда прямое peer-to-peer-соединение невозможно из-за NAT, корпоративных файрволов или особенностей сети провайдера.

Важно понимать границу решения. VPS с RustDesk Server не превращается в удалённый рабочий стол сам по себе и не хранит рабочие столы пользователей. На управляемых компьютерах всё равно должен быть установлен клиент RustDesk. Сервер помогает клиентам встретиться, а при необходимости пропускает через себя трафик сеанса.

Если прямое соединение установилось, основная нагрузка relay-сервера может быть небольшой. Если соединение идёт через hbbr, трафик удалённого экрана проходит через VPS. В официальной документации RustDesk приведён широкий ориентир для relay-соединения — примерно от 30 КБ/с до 3 МБ/с для экрана 1920×1080 в зависимости от разрешения и частоты обновления. Это не гарантия и не расчёт ёмкости: реальное потребление меняется от содержимого экрана, настроек качества, активности пользователя и характеристик обеих сетей.

RustDesk Server OSS предоставляет базовые функции самостоятельного размещения. Веб-консоль, централизованное управление устройствами, API, OIDC, LDAP и некоторые административные функции относятся к RustDesk Server Pro. Не открывайте порт веб-консоли и не обещайте пользователям функции Pro, если разворачиваете OSS.

Почему важно использовать актуальную версию

Для серверов удалённого доступа обновления особенно важны: сервис доступен из интернета, принимает сетевые запросы и участвует в установлении соединений. На дату подготовки материала актуальным официальным релизом RustDesk Server OSS является 1.1.16, опубликованный 20 июля 2026 года.

В описании релиза разработчики указали три исправления:

  1. устранено переполнение i32, из-за которого устройства, находившиеся офлайн примерно 24,9–49,7 дня, могли ошибочно отображаться как доступные;
  2. обновлена зависимость mio с 0.8.5 до 0.8.11 для исправления критической проблемы;
  3. исправлена возможность злоупотребления неаутентифицированными UDP-запросами hole punching для reflection/amplification.

Третий пункт непосредственно влияет на публично доступный сервер. Поэтому в примере используется не плавающий тег latest, а конкретный образ rustdesk/rustdesk-server:1.1.16. Фиксация версии делает развёртывание воспроизводимым и не позволяет получить новую сборку неожиданно при очередном docker compose pull.

При этом фиксированный тег не отменяет обновления. Администратор должен следить за официальными релизами, читать список изменений и планово менять версию после проверки. Перед публикацией или выполнением инструкции обязательно проверьте, не вышел ли релиз новее 1.1.16.

Какой VPS выбрать для RustDesk Server

Серверная часть RustDesk не требует мощного процессора для самого факта регистрации нескольких личных устройств. Главный неопределённый ресурс — сеть: при невозможности прямого подключения весь relay-трафик идёт через hbbr. Дополнительно нужны стабильная доступность, публичный адрес и возможность открыть несколько TCP- и UDP-портов.

Для предсказуемой настройки удобнее обычный VPS с выделенным IPv4. Клиенты RustDesk по умолчанию ожидают стандартные серверные порты проекта, а администратору проще проверить доступность сервисов и объяснить конфигурацию пользователям.

NAT VPS использует общий IPv4 и выделенный набор входящих портов. Теоретически приложения могут работать за NAT, если доступные внешние порты корректно сопоставлены внутренним и клиент умеет обращаться к нужным номерам. Но для RustDesk требуется несколько TCP-портов и UDP на 21116, а relay должен быть доступен клиентам без неоднозначности. Поэтому NAT-линейку стоит выбирать только после подтверждения схемы проброса конкретных портов в панели. Для первого публичного RustDesk Server практичнее обычный VPS.

На странице основного каталога Cheap-Host на дату подготовки указан тариф Start: 6 vCPU, 8 ГБ RAM, 96 ГБ NVMe, один выделенный IPv4, сеть 100 Mbit/s и локация в Москве за 450 ₽ в месяц. Эта конфигурация значительно шире минимальных требований, заявленных документацией RustDesk, но выбор нельзя делать только по CPU и RAM: оцените количество одновременных relay-сеансов, географию пользователей и фактическое потребление трафика.

Если вы только выбираете сервер, сначала полезно пройти общий чек-лист выбора VPS. Для связи между компьютерами из разных регионов также учитывайте локацию: задержка до VPS особенно заметна в relay-режиме. Сравнение Москвы и Германии разобрано в материале о выборе локации сервера.

Что подготовить перед установкой

Понадобятся:

  • VPS с Ubuntu 24.04 LTS или другой поддерживаемой 64-битной Ubuntu;
  • пользователь с sudo;
  • рабочий SSH-доступ;
  • выделенный IPv4 или доменное имя, указывающее на VPS;
  • возможность открыть TCP-порты 21115, 21116, 21117 и UDP-порт 21116;
  • локальная копия публичного ключа сервера после установки;
  • резервная копия каталога данных RustDesk, особенно приватного ключа.

Перед изменением SSH и UFW держите открытым второй SSH-сеанс. Ошибка в правилах файрвола может отрезать удалённый доступ к серверу. Сначала выясните фактический SSH-порт:

sudo sshd -T | grep '^port '

Команда должна показать, например, port 22. Если используется другой порт, во всех правилах ниже подставьте его вместо 22.

Обновите индекс пакетов и установите доступные обновления:

sudo apt update
sudo apt upgrade

Не добавляйте -y, если хотите просмотреть список изменений и отдельно подтвердить обновление ядра или критичных пакетов. После обновления проверьте, нужен ли перезапуск:

test -f /var/run/reboot-required && cat /var/run/reboot-required || echo "Перезагрузка не требуется"

Базовую защиту нового сервера — отдельного пользователя, SSH-ключи, UFW и обновления — следует выполнить до публикации RustDesk в интернет. Используйте чек-лист первых шагов после покупки VPS, но не отключайте вход по паролю, пока не проверили авторизацию ключом в отдельном окне.

Установка Docker Engine на Ubuntu

Официальная документация Docker рекомендует для постоянного сервера установку из собственного APT-репозитория. Convenience script с get.docker.com предназначен прежде всего для тестовых и разработческих сред: он требует повышенных прав, автоматически определяет систему и может установить новую основную версию без удобного контроля параметров.

Сначала проверьте версию Ubuntu:

. /etc/os-release
printf '%s %s\n' "$NAME" "$VERSION_ID"
dpkg --print-architecture

Затем добавьте официальный ключ и репозиторий Docker:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources >/dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

Если на сервере уже стояли docker.io, старый docker-compose, containerd или совместимые пакеты, сначала изучите официальный список конфликтов и состояние существующих контейнеров. Не удаляйте пакеты и каталог /var/lib/docker вслепую: там могут находиться рабочие образы, тома и данные других приложений.

Установите Docker Engine и плагин Compose:

sudo apt install docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

Проверьте службу и тестовый контейнер:

sudo systemctl status docker --no-pager
sudo docker run --rm hello-world
sudo docker compose version

Группа docker фактически даёт пользователю возможности уровня root через Docker API. Для небольшой инструкции безопаснее выполнять команды через sudo, а не бездумно добавлять повседневного пользователя в эту группу.

Отдельно учтите предупреждение Docker: опубликованные контейнером порты могут обходить ожидаемые правила UFW. В нашем Compose используется network_mode: "host", поэтому контейнеры слушают сеть хоста напрямую, а правила нужно проверять на самом сервере. Если вы измените схему и добавите ports:, изучите цепочку DOCKER-USER и фактическое прохождение трафика, а не полагайтесь только на вывод ufw status.

Развёртывание hbbs и hbbr через Docker Compose

Создадим отдельный каталог приложения. Команды ниже не удаляют существующие данные, но перед выполнением убедитесь, что /opt/rustdesk-server не занят другим развёртыванием:

sudo install -d -m 0750 /opt/rustdesk-server/data
cd /opt/rustdesk-server

Создайте файл compose.yml:

sudo tee /opt/rustdesk-server/compose.yml >/dev/null <<'EOF'
services:
  hbbs:
    container_name: rustdesk-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: rustdesk-hbbr
    image: rustdesk/rustdesk-server:1.1.16
    command: hbbr
    volumes:
      - ./data:/root
    network_mode: "host"
    restart: unless-stopped
EOF

Почему оба контейнера используют один каталог ./data? В нём сервер хранит созданную ключевую пару и рабочие данные. Каталог смонтирован внутрь контейнеров как /root, как в официальном примере RustDesk. Если оставить данные только в записываемом слое контейнера, пересоздание может привести к потере ключей и потребует перенастройки клиентов.

Проверьте итоговую конфигурацию до запуска:

cd /opt/rustdesk-server
sudo docker compose config

Команда должна вывести два сервиса с образом rustdesk/rustdesk-server:1.1.16, общей директорией данных и host network. Если Compose сообщает об ошибке YAML, не запускайте проект, пока не исправите отступы.

Загрузите образ и запустите службы:

sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps

Ожидаемый результат — оба контейнера находятся в состоянии Up. Названия будут rustdesk-hbbs и rustdesk-hbbr.

Посмотрите журналы без бесконечного ожидания:

sudo docker compose logs --tail=100 hbbs
sudo docker compose logs --tail=100 hbbr

Не публикуйте полные журналы в открытом тикете, не просмотрев их: там могут присутствовать IP-адреса и другие сведения о подключениях.

Настройка UFW и портов RustDesk

Для RustDesk Server OSS без веб-клиента нужны:

ПортПротоколСлужбаНазначение
21115TCPhbbsпроверка типа NAT
21116TCPhbbsTCP hole punching и соединение
21116UDPhbbsрегистрация ID и heartbeat
21117TCPhbbrrelay-трафик

Порт 21114/TCP относится к веб-консоли Pro. Порты 21118/TCP и 21119/TCP нужны веб-клиенту. Для обычного RustDesk Server OSS и нативных клиентов они не обязательны, поэтому принцип минимальной доступности требует оставить их закрытыми.

Если UFW ещё не включён, сначала разрешите текущий SSH-порт. Для стандартного SSH на 22:

sudo ufw allow 22/tcp comment 'SSH'

Затем добавьте только необходимые правила RustDesk:

sudo ufw allow 21115/tcp comment 'RustDesk NAT test'
sudo ufw allow 21116/tcp comment 'RustDesk ID TCP'
sudo ufw allow 21116/udp comment 'RustDesk ID UDP'
sudo ufw allow 21117/tcp comment 'RustDesk relay'

Проверьте список до включения:

sudo ufw show added

Только убедившись, что SSH разрешён, включите UFW:

sudo ufw enable
sudo ufw status numbered

После этого откройте новое окно терминала и заново подключитесь по SSH. Не закрывайте старое соединение до успешной проверки.

Убедитесь, что процессы действительно слушают ожидаемые порты:

sudo ss -lntup | grep -E ':(21115|21116|21117)\b'

Должны присутствовать TCP-сокеты на 21115–21117 и UDP-сокет на 21116. Отсутствие порта — повод проверить журналы контейнера, а не открывать дополнительные диапазоны наугад.

С внешнего Linux-компьютера можно проверить TCP-порты:

nc -vz SERVER_IP 21115
nc -vz SERVER_IP 21116
nc -vz SERVER_IP 21117

Замените SERVER_IP на адрес VPS. Успешное TCP-подключение подтверждает доступность порта, но не полноценную работу протокола RustDesk. UDP нельзя надёжно подтвердить одним обычным nc; окончательная проверка выполняется реальными клиентами и по журналам hbbs.

Почему не стоит открывать 21118 и 21119 «на всякий случай»

Официальная документация отдельно предупреждает о WebSocket-портах. При включённом веб-клиенте hbbs и hbbr доверяют заголовкам X-Real-IP и X-Forwarded-For, но не проверяют их. Если разрешить прямой доступ к 21118 и 21119, отправитель может подделать IP в заголовках, повлиять на IP-зависимые ограничения и исказить журналы.

Если веб-клиент не используется, порты должны оставаться закрытыми. Если он понадобится позже, пропускайте WebSocket через контролируемый reverse proxy и файрволом разрешайте доступ к внутренним WebSocket-портам только от этого прокси. Не применяйте обычный HTTP-конфиг Nginx к RustDesk вслепую: сначала сверяйтесь с актуальной документацией конкретной редакции RustDesk.

Получение публичного ключа и настройка клиентов

При первом запуске hbbs создаёт ключевую пару в постоянном каталоге данных. Проверьте файлы:

sudo ls -la /opt/rustdesk-server/data

В каталоге должны появиться id_ed25519 и id_ed25519.pub.

  • id_ed25519 — приватный ключ сервера. Его нельзя отправлять пользователям, публиковать в статье, коммите или чате;
  • id_ed25519.pub — публичный ключ. Его значение вводится в клиентах RustDesk.

Выведите только публичный ключ:

sudo cat /opt/rustdesk-server/data/id_ed25519.pub

Скопируйте строку целиком без дополнительных пробелов и переносов. Затем на каждом клиентском устройстве откройте настройки RustDesk и найдите раздел сети или ID/Relay Server. Для RustDesk Server OSS обычно достаточно заполнить:

  • ID Server — публичный IPv4 или доменное имя VPS;
  • Key — содержимое id_ed25519.pub;
  • Relay Server — оставьте пустым, если клиент получает адрес relay через hbbs, как рекомендует официальный сценарий;
  • API Server — не заполняйте для OSS: это поле связано с возможностями Pro.

Название пунктов интерфейса может отличаться между версиями клиента и операционными системами. После сохранения настроек перезапустите клиент, если он не зарегистрировался автоматически.

Настройте как минимум два устройства и убедитесь, что оба используют одинаковые ID Server и Key. Если на одном устройстве осталась публичная инфраструктура RustDesk, клиенты могут не найти друг друга.

Как проверить прямое и relay-соединение

Проверка должна отвечать на четыре разных вопроса:

  1. запущены ли контейнеры;
  2. слушаются ли необходимые порты;
  3. регистрируются ли клиенты на вашем hbbs;
  4. работает ли hbbr, когда прямое соединение невозможно.

Проверка контейнеров

cd /opt/rustdesk-server
sudo docker compose ps
sudo docker inspect -f '{{.Name}} {{.State.Status}} {{.RestartCount}}' \
  rustdesk-hbbs rustdesk-hbbr

Оба статуса должны быть running. Растущий RestartCount указывает на цикл падений — смотрите логи и права каталога данных.

Наблюдение за регистрацией клиентов

Откройте журнал hbbs:

sudo docker compose logs -f --tail=50 hbbs

Затем перезапустите клиент RustDesk. В журнале должна появиться активность. Завершить просмотр можно сочетанием Ctrl+C; контейнер при этом не остановится.

Проверка обычного соединения

Подключитесь с одного настроенного клиента к другому. Проверьте:

  • отображается ли удалённое устройство;
  • проходит ли запрос подключения;
  • работает ли ввод;
  • восстанавливается ли соединение после краткого разрыва сети;
  • не появляются ли повторяющиеся ошибки в логах hbbs и hbbr.

Проверка relay

Прямое соединение часто работает между обычными домашними сетями, поэтому один успешный тест ещё не подтверждает hbbr. Для проверки relay используйте две сети с ограничивающим NAT или тестовую настройку клиента, которая принудительно использует relay, если такая опция присутствует в вашей версии. В серверном Compose параметр ALWAYS_USE_RELAY=Y тоже существует в официальном примере, но включать его постоянно без необходимости не стоит: весь трафик пойдёт через VPS.

Если вы временно добавляете ALWAYS_USE_RELAY=Y для диагностики, заранее оцените влияние на пользователей, внесите изменение в hbbs, примените конфигурацию и после теста верните исходное состояние. Перед любым изменением сохраните копию compose.yml:

sudo cp /opt/rustdesk-server/compose.yml \
  /opt/rustdesk-server/compose.yml.before-relay-test

После теста сравните журналы hbbr и сетевую активность:

sudo docker compose logs --tail=100 hbbr
sudo ss -tnp | grep ':21117'

Не делайте вывод о производительности по одному короткому сеансу. Для планирования собирайте собственные метрики: сколько соединений ушло через relay, какой объём трафика передан, какова задержка до VPS из реальных сетей пользователей.

Безопасность и типичные ошибки

Ошибка 1. Использование latest без контроля

Плавающий тег удобен для теста, но затрудняет повторяемость. Сегодня и через месяц latest может указывать на разные образы. Фиксируйте проверенную версию, следите за релизами и обновляйте её осознанно.

Ошибка 2. Потеря приватного ключа

Если удалить id_ed25519 и создать новую пару, ранее настроенным клиентам понадобится новый публичный ключ. Резервируйте весь каталог data, храните копию шифрованно и ограничивайте доступ.

Проверьте права:

sudo stat -c '%a %U:%G %n' \
  /opt/rustdesk-server/data/id_ed25519 \
  /opt/rustdesk-server/data/id_ed25519.pub

Не пытайтесь произвольно менять владельца файлов внутри bind mount, пока не проверили UID процесса контейнера и работоспособность после изменения.

Ошибка 3. Открытие полного диапазона 21114–21119

Такой диапазон встречается в универсальных инструкциях, потому что охватывает OSS, Pro и веб-клиент. Для базового OSS достаточно 21115–21117 и UDP 21116. Чем меньше публичных точек входа, тем проще аудит.

Ошибка 4. Открыт SSH, но забыта защита самого VPS

RustDesk не заменяет обновления Ubuntu, SSH-ключи, запрет лишних сервисов и контроль журналов. Регулярно проверяйте:

sudo apt update
apt list --upgradable
sudo ufw status verbose
sudo ss -lntup
sudo docker compose -f /opt/rustdesk-server/compose.yml ps

Команда apt list --upgradable только показывает обновления. Устанавливайте их в обслуживаемое окно, особенно если будет перезапуск Docker или ядра.

Ошибка 5. Непроверенный UDP после обновления

Релиз 1.1.16 содержит исправление, связанное с неаутентифицированными UDP-запросами. После обновления убедитесь, что реально запущен нужный образ:

sudo docker inspect -f '{{.Config.Image}}' rustdesk-hbbs
sudo docker inspect -f '{{.Config.Image}}' rustdesk-hbbr

Обе команды должны показать rustdesk/rustdesk-server:1.1.16 или более новую версию, которую вы сознательно указали после проверки release notes.

Ошибка 6. Публикация приватной информации

Не вставляйте в открытые отчёты:

  • приватный id_ed25519;
  • полные журналы соединений без очистки;
  • резервные архивы каталога data;
  • SSH-ключи и пароли VPS;
  • скриншоты панели с токенами или адресами, которые не должны быть публичными.

Публичный ключ RustDesk предназначен для клиентов, но его всё равно лучше распространять через контролируемый канал вместе с адресом сервера, чтобы снизить риск ошибочной конфигурации.

Бэкап, обновление и откат

Резервное копирование

Для RustDesk критичен каталог /opt/rustdesk-server/data. Файл Compose тоже стоит включить в копию, но помните: архив содержит приватный ключ и должен храниться как секрет.

Создайте закрытый каталог для локальной копии:

sudo install -d -m 0700 /var/backups/rustdesk

Перед архивированием можно кратко остановить контейнеры, чтобы получить согласованную копию файлов:

cd /opt/rustdesk-server
sudo docker compose stop
sudo tar -C /opt -czf \
  /var/backups/rustdesk/rustdesk-server-$(date +%F-%H%M%S).tar.gz \
  rustdesk-server
sudo docker compose start

Остановка прервёт регистрацию и relay-сеансы, поэтому выполняйте её в согласованное окно. После запуска проверьте состояние:

sudo docker compose ps
sudo docker compose logs --since=5m hbbs hbbr

Сохраните точное имя архива из предыдущей команды и проверьте его без распаковки:

sudo tar -tzf /var/backups/rustdesk/rustdesk-server-2026-07-31-120000.tar.gz | head

Замените пример даты и времени на фактическое имя созданного файла. Для автоматизации используйте переменную с точным именем текущего архива и отдельно проверяйте код возврата, а не удаляйте старые копии широкими масками. Внешнюю копию следует шифровать и хранить отдельно от VPS.

Обновление

Перед обновлением:

  1. прочитайте release notes;
  2. проверьте официальный Docker-тег;
  3. сделайте бэкап;
  4. сохраните текущий compose.yml;
  5. запланируйте короткое окно недоступности;
  6. подготовьте номер предыдущей версии для отката.

Допустим, проверена версия X.Y.Z. Измените только тег образа в обоих сервисах. Затем:

cd /opt/rustdesk-server
sudo docker compose config
sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs --since=10m hbbs hbbr

После обновления выполните реальное подключение между двумя клиентами и отдельно проверьте relay.

Откат

Если новая версия не работает, верните предыдущий тег в compose.yml и снова выполните:

sudo docker compose pull
sudo docker compose up -d

Если обновление изменило формат данных, одного возврата образа может быть недостаточно. Именно поэтому перед обновлением нужен полный бэкап каталога. Не восстанавливайте архив поверх работающих контейнеров: сначала остановите проект, сохраните проблемное состояние отдельно и только затем выполняйте восстановление в обслуживаемое окно.

Как выбрать тариф Cheap-Host

Для личного RustDesk Server с несколькими устройствами требования к CPU и памяти обычно невелики, но точную вместимость нельзя обещать без измерений. Смотрите на четыре фактора:

  1. Публичный IPv4 и порты. Для простой схемы нужен доступ к 21115–21117 и UDP 21116. Обычный VPS с выделенным IPv4 удобнее NAT-конфигурации.
  2. Локация. Если соединения часто идут через relay, маршрут клиент → VPS → клиент влияет на задержку. Выбирайте локацию ближе к большинству пользователей.
  3. Сеть. Не оценивайте число одновременных сеансов только по указанной скорости порта. Измерьте реальный relay-трафик и учитывайте прочие сервисы на VPS.
  4. Диск и бэкапы. Сами серверные контейнеры компактны, но на сервере должны оставаться место для системных обновлений, Docker-слоёв, журналов и резервных копий.

По текущему каталогу Cheap-Host обычный тариф Start включает 6 vCPU, 8 ГБ RAM, 96 ГБ NVMe, выделенный IPv4 и канал 100 Mbit/s в Москве за 450 ₽/мес. Не воспринимайте это как обещание определённого количества RustDesk-сеансов: сначала разверните сервер, соберите статистику реальных подключений и масштабируйте по факту.

NAT VPS начинается от 59 ₽/мес., размещается в Германии и использует общий IPv4 с 999 TCP/UDP-портами плюс SSH. Такая схема может быть интересна для тестового стенда, но перед заказом именно под RustDesk нужно подтвердить возможность нужного сопоставления TCP и UDP, доступность адреса клиентам и корректную работу relay. Актуальные условия смотрите на странице NAT VPS.

FAQ

Можно ли установить RustDesk Server на тот же VPS, где уже работает сайт?

Технически можно, если хватает ресурсов и нет конфликтов портов. RustDesk использует 21115–21117 и UDP 21116, поэтому с Nginx на 80/443 прямого конфликта нет. Но совместное размещение увеличивает последствия сбоя и усложняет обслуживание. Проверьте загрузку сети, резервное копирование, правила UFW и окна перезапуска Docker.

Нужен ли домен?

Нет, клиенты могут использовать публичный IPv4. Домен упрощает замену IP и конфигурацию пользователей, но добавляет зависимость от DNS. Если используете домен, создайте A-запись на IPv4 VPS и проверьте её через dig +short example.com до настройки клиентов.

Нужен ли Nginx и HTTPS?

Для базовых нативных клиентов RustDesk Server OSS — нет. hbbs и hbbr работают на собственных TCP/UDP-портах. Nginx или другой reverse proxy становится актуален для веб-клиента и WSS, но тогда нужно строго ограничить прямой доступ к 21118/21119 и учесть предупреждение о доверии к forwarded-заголовкам.

Можно ли открыть только 21116?

Нет. Для стандартной схемы также нужен 21115/TCP для NAT-теста и 21117/TCP для relay. На 21116 должны быть разрешены оба протокола: TCP и UDP.

Что произойдёт, если потерять приватный ключ сервера?

При создании новой ключевой пары публичный ключ изменится. Клиенты со старым Key перестанут доверять новой конфигурации, и их придётся перенастроить. Поэтому резервная копия data/id_ed25519 критична.

Почему клиент видит сервер, но соединение не устанавливается?

Проверьте одинаковый Key на обоих клиентах, доступность 21116/TCP и UDP, работу hbbs, затем 21117/TCP и журнал hbbr. Также возможны ограничения корпоративной сети. Не открывайте дополнительные порты без понимания их назначения.

Как понять, что используется relay?

Смотрите активность и журналы hbbr, а также сетевые соединения на 21117 во время сеанса. Для контролируемого теста можно временно принудить relay официальной настройкой, но это направит трафик через VPS и повлияет на сеть.

Подходит ли RustDesk Server OSS для компании?

Для базового самостоятельного ID/relay — да, если организация готова администрировать VPS, обновления, ключи, мониторинг и бэкапы. Если нужны централизованная консоль, управление устройствами, LDAP, OIDC, 2FA или API, сравните OSS и Pro по официальной документации, не предполагая наличие этих функций в бесплатной версии.

Нужно ли автоматически обновлять контейнер?

Автоматическая замена образа без чтения release notes может неожиданно изменить поведение сервиса. Для удалённого доступа разумнее фиксировать тег, получать уведомления о релизах, тестировать обновление и иметь план отката.

Итоги

Собственный RustDesk Server на VPS — это отдельная практическая задача: вы разворачиваете hbbs для регистрации и согласования соединений, hbbr для relay, сохраняете серверную ключевую пару и направляете клиенты на свой адрес. Безопасная базовая конфигурация не требует веб-консоли и лишних портов: достаточно 21115/TCP, 21116/TCP+UDP и 21117/TCP.

Используйте актуальный проверенный релиз, фиксируйте тег Docker-образа, не публикуйте приватный ключ, проверяйте реальный relay и делайте резервную копию перед обновлением. На 31 июля 2026 года релиз 1.1.16 особенно важен из-за исправления злоупотребления UDP hole-punching для reflection/amplification.

Для первой установки удобнее обычный VPS с выделенным IPv4 и понятной схемой портов. Выберите подходящую конфигурацию в каталоге Cheap-Host, выполните базовую защиту сервера, разверните два контейнера и обязательно проверьте соединение между реальными устройствами до перевода пользователей на новую инфраструктуру.

Источники