自建远程桌面：RustDesk 服务端部署与客户端接入
帮朋友远程修电脑本来是举手之劳，用商业远控做起来却越来越别扭。免费版三天两头弹「疑似商业用途」然后直接断连，你正操作到一半画面卡死，人还在那头等。按设备数买的套餐也不便宜，你只是想同时管自己的台式机、家里的 NAS 和给爸妈那台老笔记本，一年也要几百块。更难受的是链路：节点在国外，晚高峰连过去画面糊成一团色块，鼠标点下去半秒才有反应。
这套自建方案把三件事一次解决：中转服务器在自己手上，速度可控，也没有「判定商用」这回事。你只要一台带公网 IP 的服务器，2 核 2G 完全够，带宽比配置重要。
自建到底图什么
| 维度 | 公共服务器 | 自建服务端 |
|---|---|---|
| 延迟 | 取决于到国外节点，常 200ms 起 | 同城机房可到 20ms |
| 成功率 | 受公共节点负载影响，高峰排队 | 自己的机器自己扛 |
| 受限 | 可能被判定商用而限速断连 | 规则由你定 |
| 数据路径 | 经过第三方 | 全程只经过你的机器 |
| 成本 | 免费或按设备订阅 | 一台小服务器的钱，可复用 |
注意最后一条：那台服务器你本来就有，跑着博客或者别的服务，加两个容器几乎不增加成本。
三个组件各干什么
很多人卡在第一步就是因为没弄清服务端有两个进程、职责不同：
- ID 服务器（hbbs）：相当于通讯录。每个客户端启动后向它注册自己的设备 ID 和网络地址，你要连对方时先用 ID 找到对方在哪。没有它，两台机器互相不认识。
- 中继服务器（hbbr）：相当于中转站。两台机器因为 NAT 或防火墙打不通时，数据绕经它转发。不走中继时它闲着不干活。
- 客户端：装在被控端和控制端的软件，负责画面编码和键鼠事件传输，两边都要装。
中继是不是必须的？技术上不是。同一局域网或者 NAT 类型友好能打洞时，连接走点对点直连，最快且不吃服务器带宽。但现实里很多网络（双向 NAT、移动网络、企业防火墙）打不通，就得靠中继兜底。所以中继建议一直开着，平时不占资源，关键时刻是救命绳。
服务端部署
官方服务端镜像 rustdesk/rustdesk-server，同一镜像靠参数决定起 hbbs 还是 hbbr。用 --net=host 最省事，避免 UDP 在 bridge 网络下转发出问题。先起 hbbs，-r 参数要写你服务器的公网 IP，这是告诉客户端中继在哪：
mkdir -p /opt/rustdesk/data
docker run -d \
--name hbbs \
--restart unless-stopped \
--net=host \
-v /opt/rustdesk/data:/root \
rustdesk/rustdesk-server hbbs -r 你的公网IP:21117再起 hbbr，两个容器共用同一个数据目录，密钥文件就在里面生成：
docker run -d \
--name hbbr \
--restart unless-stopped \
--net=host \
-v /opt/rustdesk/data:/root \
rustdesk/rustdesk-server hbbrdocker logs hbbs --tail 30
docker logs hbbr --tail 30习惯 compose 就写成这样（host 网络下不需要写 ports）：
services:
hbbs:
image: rustdesk/rustdesk-server
container_name: hbbs
command: hbbs -r 你的公网IP:21117
network_mode: "host"
restart: unless-stopped
volumes:
- ./data:/root
hbbr:
image: rustdesk/rustdesk-server
container_name: hbbr
command: hbbr
network_mode: "host"
restart: unless-stopped
volumes:
- ./data:/rootdocker compose up -d
docker compose logs -f端口一个都不能少
| 端口 | 协议 | 用途 |
|---|---|---|
| 21115 | TCP | 打洞与连接测试 |
| 21116 | TCP + UDP | ID 注册与心跳，两个协议都要开 |
| 21117 | TCP | 中继数据转发 |
| 21118 / 21119 | TCP | 网页版客户端才需要，用不到可不开放 |
重点强调 21116 的 UDP。只放 TCP 的话客户端能注册上（注册走 TCP），但连接阶段一直卡在「正在连接」，转很久最后失败或退化到极慢路径。看到这个症状先去查 UDP。
拿到密钥填进客户端
服务端首次启动会自动生成一对密钥，私钥留在服务器不动，公钥要填到每个客户端里：
cat /opt/rustdesk/data/id_ed25519.pub拿到那串字符复制下来，然后在客户端打开设置里的网络一栏，勾选「使用自己的服务器」，填三项：
- ID 服务器：填公网 IP 或解析好的域名，端口不用写，默认 21116。
- 中继服务器：可留空，客户端默认用 ID 服务器同一台；中继在别的机器上就填那台的地址。
- Key：粘贴刚才的公钥。
点应用后客户端会重连，顶部状态应该显示就绪，被控端能看到自己的 ID。让朋友那边也填同样三项，控制端输入对方 ID 就能连。
客户端配置
Windows
设置里勾选开机自启和允许被控，再设一个固定访问密码。想做到锁屏也能连（比如给家里老电脑当备用），装成服务模式。
macOS
必须到系统设置的隐私与安全里，手动给屏幕录制和辅助功能两项授权，否则能连上但看不到画面，或者看得到点不动。这两个权限在系统升级后会失效，需要重新授权，是 macOS 的老毛病。
手机
手机当控制端比较顺，应急够用。当被控端就麻烦些——安卓各家省电策略不同，要单独允许后台运行并授予相关权限，否则一锁屏就断。
画质和带宽的关系
远端画面本质是持续的视频流，会自适应调整清晰度。实际经验值：
- 1080p 日常办公（看文档、改代码、点按钮）：1 到 3 Mbps 就够，观感清晰流畅。
- 看视频、拖大窗口：5 Mbps 以上，低于这个会明显掉帧和糊块。
- 4K 或高刷新率显示器：需求翻倍，小服务器带宽容易被打满。
所以在客户端里把画质从「最佳」改成「平衡」或「速度优先」，往往立竿见影。服务器带宽很小的时候，尽量让连接走直连，或者把中继单独放到带宽大的机器上。
这几个坑很常见
UDP 没放行，一直正在连接
最经典的问题。检查顺序：云服务商的安全组 → 服务器本机防火墙 → 有没有装什么面板自己又管了一套规则。三层都放行才行。
只开 TCP，能用但巨慢
连接成功了，但画面延迟好几秒、几乎不能用，通常是走了一条很糟糕的退化路径。把 UDP 放开让打洞正常走，速度立刻回来。
密钥填错或忘填
密钥可留空（能通，但等于任何人都能借你的服务器转发流量，安全上很糟）。填了但填错，握手失败，表现是连不上又看不出原因。逐字符核对，或者清空重贴。公钥和私钥文件名很接近，别搞混。
服务器在 NAT 后面
如果你的「服务器」其实是家里一台内网机器，必须在路由器上把 21115 到 21117 的 TCP 和 21116 的 UDP 都映射出去，否则客户端根本连不到。而且 -r 参数里要写公网 IP，写内网地址的话客户端拿到的是个访问不到的中继地址。
被控端休眠就失联
笔记本合盖后网络断了，再连也没用。在被控端关掉自动休眠，或者配合局域网唤醒。这跟远程方案无关，是物理规律。
自建不等于安全
服务端摆在公网，任何人都能向 21115 发起尝试。所以：被控端一定设强密码，别用四位数字；开启仅允许白名单设备连接，把可信设备 ID 加进去；私钥文件当宝，别备份到公开位置；如果版本支持，把「允许 IP 直接访问」这类宽松选项关掉。有公网入口的东西，配置再简单也要按「随时会被扫」来设。
适用与不适用
适合：经常帮家人朋友远程处理问题、管理自己多台机器、对延迟敏感、不放心把屏幕内容交给第三方中转的人。一台小服务器加十几分钟配置，换来长期免打扰的体验，很难找到更划算的方案。
不适合：需要企业级审计日志、批量设备分组策略、工单和权限体系——那是商业产品的价值所在，这套东西的定位是「够用、可控、不折腾你」。另外自建意味着服务器要你自己维护，包括续费、升级、盯端口，连服务器都懒得管的话，用现成的更合适。
起步建议：先只部署服务端，把两台自己的机器连通，确认 ID 解析、密钥、中继都正常；再去折腾手机端和各种权限。一次只改一个变量，出问题时才知道是哪里变了。
