Как проверить сохранение self-hosted ID-сервера RustDesk до и после перезапуска, не раскрывая адрес, ключ, конфигурацию и полный журнал.
Не принимайте высокую задержку за доказательство смены сервера
Начните с наблюдаемого факта: после перезапуска RustDesk соединение стало медленнее, появилось иное сообщение о готовности или пропала ожидаемая доступность устройства. Одна задержка не показывает, какой именно сервер выбрал клиент: на неё одновременно влияют Wi‑Fi, маршрут провайдера, загрузка узлов и способ установления конкретного сеанса. Не запускайте тест скорости и не меняйте сеть ради первого шага. Запишите версию RustDesk, способ установки, операционную систему и точное время наблюдения. Затем откройте штатный раздел Settings → Network. Официальная документация помещает настройку собственного сервера именно туда. Не копируйте содержимое окна: достаточно отметить «наш ID-сервер виден — да или нет», «ключ присутствует — да или нет» и «Relay задан явно — да или нет».
Разделите роли ID Server и Relay
В self-hosted схеме RustDesk сервер hbbs выполняет роль ID, rendezvous и сигнализации, а hbbr используется как ретранслятор, если прямое соединение не получилось. Поэтому поле ID Server и поле Relay отвечают за разные части пути. Официальное руководство называет ID Server обязательным для большинства self-hosted клиентов, публичный ключ — необходимым для зашифрованного соединения с собственным сервером, а Relay часто оставляет необязательным, потому что клиент может определить его без отдельного значения. Не делайте вывод «пустой Relay означает публичную инфраструктуру»: это не следует из документации. Для текущей проверки важнее, сохранились ли принадлежность ID Server вашей инфраструктуре и наличие ожидаемого публичного ключа. Сам ключ не переписывайте в заметки и не показывайте на скриншоте.
Сделайте два минимальных снимка состояния
Первый снимок снимите до перезапуска. Зафиксируйте только булевы признаки: собственный ID Server распознан, ключ присутствует, Relay задан или оставлен для автоматического определения, клиент показывает готовность. Адрес замените нейтральной меткой «свой сервер»; RustDesk ID, IP, домен и ключ не сохраняйте. Закройте окно настроек и выполните обычный перезапуск только приложения тем способом, которым вы пользуетесь ежедневно. Не перезапускайте сервер, роутер, VPN, систему и сетевой интерфейс: иначе изменится сразу несколько факторов. После появления штатного состояния готовности откройте тот же раздел и заполните второй снимок теми же четырьмя признаками. Один цикл достаточен. Повторные рестарты могут затереть полезную последовательность событий и не превращают единичный симптом в подтверждённый дефект.
Прочитайте результат по матрице, не назначая причину
Матрица содержит четыре полезных исхода. Первый: собственный ID Server виден до и после, ключ присутствует, соединение работает — потеря настройки не воспроизведена; исследуйте изменение сети отдельно. Второй: до перезапуска виден собственный сервер, после него уже нет, остальные условия не менялись — локализован переход между сохранённым и загруженным состоянием клиента, но причина ещё неизвестна. Третий: признаки одинаковы, а меняется только задержка — данных о смене инфраструктуры нет. Четвёртый: на двух устройствах после одинакового развёртывания получаются разные снимки — сравнивайте версию, канал установки и способ применения настроек, а не содержимое чужого конфигурационного файла. Такая матрица отделяет наблюдение от предположения и не требует угадывать внутренний алгоритм клиента по одному открытому обращению.
Проверяйте штатный способ конфигурации, не редактируя файлы вслепую
Официальное руководство RustDesk рекомендует для небольшого self-hosted развёртывания ручную настройку через Network, а для повторного применения известного состояния — штатные import/export или управляемое развёртывание. Если второй снимок отличается от первого, сначала выясните, каким поддерживаемым способом настройки были применены на этом устройстве и действует ли над ними организационная политика. Не переносите значения из случайной инструкции, не редактируйте внутренние файлы клиента и не отключайте проверку ключа. Также не меняйте одновременно ID Server, Relay, ключ и пакет приложения: успешный результат после четырёх изменений не покажет, какое из них было существенным. Любое действие, требующее повышения прав, правки службы или централизованной политики, является стоп-критерием для самостоятельного эксперимента.
Передайте поддержке минимальный и обезличенный пакет
Для воспроизводимого отчёта достаточно версии и канала установки RustDesk, операционной системы, времени теста и таблицы «до/после» с четырьмя признаками. Добавьте, применялась ли настройка вручную через Network, штатным импортом или централизованно, и подтвердите, что между снимками перезапускалось только приложение. Если сопровождающий проекта попросит журнал, сначала вырежьте RustDesk ID, IP-адреса, домены, публичный ключ, имена устройств, локальные пути и любые токены; полный файл по публичной ссылке не размещайте. Не утверждайте, что клиент выбрал конкретный публичный узел, пока это не подтверждено сопровождающим по безопасному фрагменту. Остановитесь, если следующий шаг требует раскрыть секрет, изменить серверную инфраструктуру или отключить защитный механизм.
Материал подготовлен редакцией VOne с применением ИИ для протокола двух снимков и матрицы исходов; роли компонентов и штатные способы настройки проверены по официальной документации RustDesk, а issue использован только как обезличенный сигнал пользовательской боли.
Источники и проверка
- RustDesk Documentation — Client Configuration проверено 2026-08-14
- RustDesk Documentation — Self-host проверено 2026-08-14
- RustDesk Documentation — Client проверено 2026-08-14
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.