---
publishDate: 2026-06-30T13:46:00Z
lang: 'zh-cn'
translationKey: 'rustdesk-unknown-devices-antivirus-scanning'
draft: false
title: 'RustDesk 控制台中出现未知设备？请先排查'
excerpt: '在 RustDesk 控制台中看到陌生设备？杀毒软件沙盒是可能原因之一，但必须先排除配置泄露或未经授权注册的可能性。'
image: '~/assets/images/blog/rustdesk-unknown-devices-antivirus-scanning-og.webp'
category: '部署'
tags: ['RustDesk', '部署', '安全']
author: 'RustDesk Team'
slug: 'rustdesk-unknown-devices-antivirus-scanning-zh-cn'
faq:
  - question: '为什么我的 RustDesk 控制台中会出现我从未安装过的未知设备？'
    answer: '杀毒软件或终端防护的沙盒机制可能会产生临时注册记录，但未知设备也可能意味着配置泄露、部署令牌暴露、未经授权的注册，或部署失误。在通过日志、凭据、密钥、令牌和部署记录查明原因之前，应将其视为安全事件处理；随后再限制新设备注册。'
  - question: '如何彻底阻止未知设备注册？'
    answer: '如果您的设备列表基本稳定，并不经常添加新设备，可以在控制台的设置 → 其他 → 禁止在 Web 控制台上添加新设备中禁用新设备注册。此后无论是沙盒环境还是其他情况，都无法再注册任何新设备。如果您仍需定期上线新设备，则应改用部署令牌，以确保真实的部署流程不受影响。'
  - question: '如何要求新设备必须使用部署令牌？'
    answer: '在 Web 控制台中启用设置 → 其他 → 新设备需要部署，创建一个将设备权限设置为读写的 API 令牌，并让您的安装流程在每台新设备上运行 rustdesk --deploy --token <api_token>（在 macOS 和 Linux 上需要使用 sudo）。只有提供有效令牌的设备才能完成注册，因此沙盒中的杀毒软件扫描无法自行注册，而您的 RMM 或脚本化部署流程则可以照常运行。'
  - question: '如何区分良性的杀毒软件扫描和真正的入侵？'
    answer: '如果一次短暂的注册记录与已知的安全扫描时间吻合，且之后没有发生任何会话，则可以支持沙盒这一解释。而意外的会话、重复注册、使用有效凭据，或配置好的客户端在预期渠道之外被分发，都不属于良性情况，需要启动事件响应。'

metadata:
  description: 'RustDesk 控制台中出现的未知设备需要进行排查。了解如何区分杀毒软件沙盒与配置泄露或未经授权的注册。'
  keywords: 'rustdesk 未知设备, rustdesk 幽灵设备, rustdesk 随机设备注册, rustdesk 杀毒软件沙盒, 禁用 rustdesk 新设备, rustdesk --deploy'
---

仅凭 RustDesk 控制台中出现陌生设备，并不足以判断其成因。杀毒软件沙盒是已知的可能原因之一，但同样的现象也可能源于配置泄露、未经授权的注册、令牌暴露，或部署失误。

## 简要回答

部分杀毒软件/EDR（终端检测与响应）产品会在云端沙盒中执行陌生的二进制文件。如果沙盒获取了包含您服务器配置的客户端构建版本，并且能够连接到 ID 服务器，就可能会短暂注册。但是，云服务商的 IP 地址或异常的硬件名称**并不能**证明就是这种情况——攻击者同样会使用云主机。在排除此事件之前，请先保留并审查相关证据。

## 详细说明

### 为什么会发生这种情况

RustDesk 客户端在运行时，只要能够连接到所配置的 ID/信令服务器，就会向其注册。这使得沙盒执行成为一种合理的解释——正如某个公开的 [GitHub 讨论帖](https://github.com/rustdesk/rustdesk-server-pro/discussions/307)中所述——但这同时也意味着，任何获取了配置好的客户端或有效部署材料的人，都可能产生类似的注册记录。

在对该事件下结论之前，请先审查服务器的注册和连接日志、设备的首次出现时间及来源 IP、部署记录，以及自定义客户端的分发路径。视情况轮换可能已暴露的密码、API/部署令牌，以及服务器配置或密钥。同时检查相同凭据是否在其他地方被重复使用，以及该未知设备是否尝试或完成过任何会话。

### 如何阻止此类情况

控制台中有两项设置可以解决此问题，具体选用哪一项，取决于您是否仍在持续上线真实的新设备。

**方案一——彻底禁用新设备注册。** 如果您的设备列表基本稳定，且不经常添加新机器，这是最简单的解决办法：前往 **设置 → 其他 → 禁止在 Web 控制台上添加新设备**。此后无论是沙盒环境还是其他任何情况，都无法注册任何新设备。

**方案二——要求使用部署令牌。** 如果您仍在定期上线新设备（例如 MSP 为新客户上线、IT 团队为新机器安装系统镜像），一刀切地禁止新设备注册反而会给自己的工作带来不便。此时应改为启用 **设置 → 其他 → 新设备需要部署**，创建一个 API 令牌（设备权限设置为"读写"），并让您的安装流程在每台设备上运行文档中的[部署命令](https://rustdesk.com/docs/en/self-host/client-deployment/#explicit-deployment-for-new-devices)：

```
rustdesk --deploy --token <api_token>
```

具体参数在不同版本之间可能会有变化，因此请将其视为示例，在编写脚本之前，请先在 RustDesk Server Pro 文档中确认当前的准确语法。只有提供有效令牌的设备才会被添加到您的设备清单中。沙盒中的杀毒软件扫描由于无法获知、也无法提供该令牌，因此注册会失败，而您真实的部署流程则会照常正常运行。这也是 MSP 通过 RMM 或脚本化安装来批量注册设备、而无需技术人员在每台机器上手动登录的实现机制。

**一项相关但适用范围更窄的控制选项：** 如果您希望保持注册开放，但只是想在审查之前隐藏未分配的设备，还可以使用 **设置 → 其他 → 只有管理员可以访问未分配设备**——这项设置并不会阻止注册，但可以确保普通用户在您有机会查看之前，既看不到、也无法操作任何新出现的设备。

### 如何评估结果

仅凭注册记录本身，并不能证明攻击者已控制了另一台终端，但在得到合理解释之前，它仍应被视为未经授权的活动。如果一次短暂的注册记录与已知的安全扫描时间相吻合，且之后没有发生任何访问，则可以支持沙盒这一假设。而意外的会话、重复注册、使用有效凭据，或配置好的客户端在预期渠道之外被分发，都需要启动事件响应。

## 谁会遇到这个问题

无论是 IT 管理员还是 MSP，新的服务器运维人员往往会在部署自建服务器后的几天内、在尚未收紧注册控制之前遇到这个问题。及早排查非常重要，因为良性扫描和未经授权的注册，在控制台中可能表现得十分相似。

## 相关问题

- 生成自定义品牌客户端：请参阅 [RustDesk 文档](https://rustdesk.com/docs)。
- [在 RustDesk 中，什么算作受管设备？](/zh-cn/blog/what-counts-as-a-managed-device-zh-cn)
- [查看当前 RustDesk 版本发布与安全修复](https://github.com/rustdesk/rustdesk/releases)
- [面向 MSP 的 RustDesk：一款可自建、可打造品牌的工具](/zh-cn/blog/rustdesk-for-msps-zh-cn)
  发现了无法识别的设备？请保留相关日志、限制新设备注册、轮换任何可能已泄露的密钥，如果原因仍不明确，请携带非敏感的诊断信息联系 RustDesk 支持团队。
