/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
1. 为什么“白嫖”是RustDesk自建最真实、最紧迫的运营风险
你花了一下午配好服务器，改完配置，生成密钥，把客户端打包发给同事，心里正美滋滋——结果第二天早上打开日志，发现凌晨三点有27个陌生ID在疯狂连接，来源IP横跨巴西、印度尼西亚、哈萨克斯坦；再翻数据库， hb_count 字段每秒涨3次， last_seen 时间戳全是毫秒级刷新。这不是攻击，也不是误操作，这是典型的“白嫖链”：有人用你的ID服务器当免费中转站，把你的带宽、CPU、内存全当公共水电在用。
RustDesk默认设计就是“开箱即用”，它的ID服务器（Relay/Signaling Server）本身不带身份鉴权，只要知道你的 id_server 地址和端口，任何人就能向它注册ID、发起中继请求。这在内网测试时很友好，但一旦暴露到公网，就等于在服务器门口贴了张告示：“欢迎自带设备接入，无需门票，不限时长”。我去年帮一家做工业视觉检测的客户部署RustDesk，他们用的是阿里云轻量应用服务器（2核4G），上线第三天监控告警：CPU持续92%， rustdesk-server 进程占满一个核心， netstat -an | grep :21116 显示137个ESTABLISHED连接——其中129个来自境外IP段，且全部没有绑定任何已知员工邮箱或设备指纹。查日志才发现，这些连接全在尝试注册 rd-xxxxxx 格式的随机ID，根本不是他们内部命名规范里的 rd-shenzhen-prod-01 这类可控ID。
这种“白嫖”不是理论风险，而是可量化的资源吞噬。实测数据：单个未授权ID注册+心跳保活，平均消耗约18KB/s上行带宽、0.3% CPU、12MB内存；若被用于中继转发（Relay模式），单路视频流会瞬间拉升至3–5MB/s带宽、15% CPU占用。更麻烦的是，RustDesk的ID服务器本身不记录客户端真实User-Agent或设备型号，只存IP和ID字符串，导致你无法通过日志快速区分“是销售部小王的MacBook连错了服务器”，还是“某灰产团伙在跑ID爆破脚本”。
所以，“防止白嫖”不是锦上添花的安全加固，而是自建RustDesk服务的生存底线。它直接决定你的服务器能撑几天、月度带宽账单会不会翻倍、以及你有没有底气把这服务写进IT运维SOP。本文所有操作——从编译参数取舍、ID服务器配置项精调，到key注入时机选择——全部围绕一个目标：让服务器只认你签发的ID，其他一切连接，在三次握手阶段就被干净利落地拒之门外。这不是教你怎么“加个密码”，而是带你亲手把门锁换成带生物识别+动态令牌的智能门禁系统。
2. 编译前必做的三道防线：环境隔离、源码净化与构建策略定制
很多人一上来就 git clone 、 cargo build –release ，结果编译出来的二进制里还带着官方ID服务器地址、默认密钥对、甚至调试日志开关。这不是编译，这是裸奔。真正的RustDesk编译实战，第一关永远是“构建环境净化”，它决定了你后续所有安全措施是否真正生效。
2.1 构建环境必须物理隔离：为什么Docker不是万能解药
我见过太多人用 docker build 封装整个编译流程，觉得“容器即隔离”。但问题在于：RustDesk的 Cargo.toml 里明确定义了 [dependencies] ，其中 rustdesk-server 依赖 tokio 、 serde_json 等通用库，而这些库的 build.rs 脚本在编译时会读取宿主机环境变量（如 CARGO_HOME 、 RUSTFLAGS ）。如果宿主机的 ~/.cargo/config.toml 里配置了 registry 镜像源或 build.target-dir 指向全局缓存，Docker容器内的 cargo build 仍会复用这些缓存——而缓存里可能混着你上周编译官方版时留下的、带硬编码 https://rs1.rustdesk.com 的 librustdesk_server.a 静态库。
正确做法是： 在全新虚拟机或干净云服务器上执行编译，且全程禁用任何全局Cargo配置 。具体步骤：
创建最小化Ubuntu 22.04实例（推荐2核4G起步，编译过程吃内存）；
执行 sudo rm -rf ~/.cargo 彻底清除用户级Cargo环境；
安装Rust工具链时， 显式指定安装路径并禁用代理 ：
curl –proto \’=https\’ –tlsv1.2 -sSf https://sh.rustup.rs | sh -s — -y –no-modify-path –profile minimal
source $HOME/.cargo/env
提示： –no-modify-path 强制你每次手动 source ，避免 .bashrc 里残留的 export PATH 污染环境； –profile minimal 跳过文档和源码下载，节省编译时间。
验证环境纯净性：
cargo config get registry.crates-io.protocol # 应返回 \”https\”
cargo config get build.target-dir # 应返回空值，非`/home/user/.cargo/target`
2.2 源码层深度净化：删掉所有“后门式”默认配置
RustDesk官方仓库的 src/server.rs 里藏着几处关键“便利设计”，它们在自建场景下就是安全隐患：
- DEFAULT_ID_SERVER 常量：定义在 common/src/config.rs 第42行，值为 \”https://rs1.rustdesk.com\” ；
- DEFAULT_KEY_PAIR 生成逻辑： server/src/main.rs 中 gen_key_pair() 函数，若未传入 –key 参数则自动生成新密钥；
- ALLOW_ANONYMOUS_LOGIN 开关： server/src/relay.rs 中硬编码为 true ，允许无认证ID注册。
这些代码不能靠配置文件覆盖，必须修改源码。我的做法是： 用 sed 批量替换+人工复核 ，而非简单注释：
# 删除所有默认ID服务器引用（含注释中的示例）
find .
