RustDesk私有化部署指南：自建中继服务器实现远程办公不求人-代码聚汇网

RustDesk私有化部署指南：自建中继服务器实现远程办公不求人

王瑞恩·2026-09-09·阅读 34 GEO检测（免费）

RustDesk远程桌面私有化部署

|难度：普通|阅读约 32 分钟

前阵子因为临时要处理一台客户机器上的问题，远程软件偏偏在高峰期排队，画质糊成马赛克，操作延迟能让你怀疑人生。也就是那几天，我把目光彻底转向了RustDesk，并且花了一个晚上把中继服务器私有化部署到位。今天这篇就把整个过程、踩过的坑、以及为什么这么部署的思路完整捋一遍，给同样想"远程办公不求人"的朋友一个可复现的参考。

先说结论：RustDesk是一款开源的远程桌面软件，私有化部署指的是自己搭建中继服务器，包含ID/中继两个核心服务，数据全部走自己的服务器，不依赖任何第三方。适合对数据隐私有要求、受够商业软件排队限速、或者需要在多台设备间稳定互访的团队和个人。整个过程不需要太深的运维基础，但需要有一台带公网IP的Linux服务器，以及一点命令行操作经验。

1. 远程办公的真实痛点与自建RustDesk的决策逻辑

1.1 商业远程软件哪里让人不痛快

很多人一开始用远程软件，图的是省事。注册账号、登录、复制ID和密码，完事。但用久了就会发现几个绕不开的问题：首先是免费版的功能限制，比如帧率限制、清晰度限制，还有高峰期的服务器排队。我印象最深的一次，是下午三点多想要连回办公室电脑调一份文件，结果等了将近两分钟才连上，进去之后鼠标操作至少有一秒的延迟，那种感觉就像隔着一条河在操控电脑。其次是隐私顾虑，你的屏幕内容、剪贴板、文件传输记录都要经过第三方服务器转发，虽然多数商业软件声称加密，但"数据不过我的手"和"数据在别人那里加密存放"是两件完全不一样的事。

1.2 RustDesk私有化部署解决的核心问题

RustDesk的逻辑和主流商业软件类似：客户端连上ID服务器，通过ID服务器拿到对端的网络位置信息，然后尝试点对点直连；如果直连不通，就通过中继服务器转发流量。私有化部署RustDesk中继服务器，本质上是把你自己的服务器变成那个"ID服务器+中继服务器"，所有信令和流量都在自己的机器上完成转发。

这个方案解决了几件很实际的事：

数据不出自己的服务器，传输链路完全可控；
不再受第三方服务器排队、限速影响；
客户端数量、设备数量完全自己管理，不按并发收费；
断网或第三方服务故障时，自己的中继不受影响（只要你的服务器和网络正常）。

1.3 什么样的场景适合自建

先泼一盆冷水，不是所有情况都适合自建。如果你只是偶尔在家连一下公司电脑，而且对延迟不敏感，那直接用商业软件可能更省事。但如果你属于下面任何一种情况，自建的价值就非常明显：

经常需要远程协助客户或家人的电脑，中继服务器不稳定会让你非常被动；
团队内部有多台设备需要互相访问，不想每台都装商业客户端还受账号数限制；
公司或个人的数据敏感度较高，远程桌面的流量不想经过第三方服务器；
需要长期、频繁地远程办公，希望有更流畅的体验和更稳定的连接。

我自己属于"经常远程协助客户+数据敏感"的类型，自建之后基本上不再看商业远程软件的脸色。下面进入正题，讲部署前需要准备什么。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 部署前要确认的三件事：服务器、网络与端口规划

2.1 服务器选型：2核2G够不够

RustDesk的服务端其实非常轻量，主要包含两个进程：hbbs（ID注册/信令服务）和hbbr（中继服务）。hbbs负责客户端ID的注册和双方连接信息的交换，流量非常小；hbbr负责实际的远程桌面画面、剪贴板、文件传输等数据转发，带宽和CPU消耗主要看使用强度。

从配置需求来看，我自己用的是2核2G内存的云服务器，系统是Debian 12。实测同时支持我自己加一位同事共两个并发远程会话，CPU占用基本在10%以下，内存占用不到500MB。如果你预计同时会有3~5个活跃会话，或者经常传输大文件，建议上4核4G，带宽也要相应提升。这里有个容易忽略的点：中继服务器的带宽直接决定了远程画面的流畅度。RustDesk的默认画质设置下，一个1080P会话大概需要2~4Mbps带宽，如果你的云服务器带宽只有1M，那自建之后体验可能还不如商业软件。

2.2 域名与固定公网IP

RustDesk客户端的配置需要指定服务器的地址，这个地址可以是IP也可以是域名。如果条件允许，我强烈建议用域名而不是裸IP，原因有几个：一是云服务器的公网IP可能因为回收、迁移等原因变更，域名可以随时解析到新IP；二是客户端里填域名比填一串数字更清晰，尤其你要管理多台设备时；三是后续如果要做HTTPS加密（RustDesk支持通过证书加密通信），域名是必须的。

如果你的服务器没有固定公网IP，而是家里或办公室的宽带，那就要考虑内网穿透或者动态域名解析（DDNS）。这一步会引入额外的中间层，延迟和稳定性都会受影响。我的建议是：既然是自建，就老老实实买一台带固定公网IP的云服务器，省心，也避免后续排查问题时分不清是哪一层出了问题。

2.3 端口规划：4个端口谁负责什么

RustDesk服务端需要开放的端口不多，但每个端口的作用必须搞清楚，不然排错的时候会一头雾水。整个服务涉及以下端口：

端口	协议	服务/用途
21115	TCP	NAT类型测试，客户端用于检测直连可行性
21116	TCP + UDP	hbbs主端口，处理ID注册、信令交换（UDP用于打洞）
21117	TCP	hbbr中继端口，负责远程桌面实际数据转发
21118/21119	TCP	Web客户端连接端口（可选，不用Web端可以不开）

这里最容易踩的坑是只开了TCP没开UDP。RustDesk在尝试直连时，依赖UDP 21116端口做UDP打洞，如果这个端口没放通，那么即使有公网IP，客户端之间也永远无法建立P2P直连，所有流量都会走中继，延迟和带宽消耗都会显著上升。我自己第一次部署就漏了UDP端口，导致两台在同一局域网内的机器连起来都慢半拍，检查了半天才发现是防火墙只放了TCP。

3. hbbs与hbbr落地实操：从下载到systemd托管

3.1 下载服务端程序

RustDesk服务端的发布方式比较友好，官方GitHub的Releases页面会根据系统架构直接提供编译好的二进制包。对于常见的x86_64 Linux服务器，下载对应的rustdesk-server-linux-amd64.zip即可。如果你的服务器是ARM架构（比如一些轻量云服务器），需要下载rustdesk-server-linux-arm64.zip，这个别搞错，不然后面跑起来全是花式报错。

下载之后执行解压：

bash复制wget https://github.com/rustdesk/rustdesk-server/releases/download/1.1.13/rustdesk-server-linux-amd64.zip
unzip rustdesk-server-linux-amd64.zip
cd rustdesk-server-linux-amd64
ls -l

解压后你会看到hbbs和hbbr两个可执行文件，还有几个lib目录（存放依赖的链接库文件）。这里有一个细节要注意：最好不要让这两个二进制文件直接裸奔在根目录下，规范做法是放到/usr/local/bin/或者单独建一个目录，例如/opt/rustdesk-server，然后把可执行文件复制过去。这样后续维护、查看进程、更新版本都比较清晰。

3.2 首次运行与密钥生成

RustDesk服务端和客户端之间的安全机制基于一对密钥。服务端启动时如果指定了-k参数并传入一个密钥字符串，它会在运行目录下生成id_ed25519和id_ed25519.pub两个文件。客户端连接时需要填入同样的公钥内容，否则服务端会拒绝握手。

首次运行建议手动执行一次，确认是否能正常工作：

bash复制cd /opt/rustdesk-server
./hbbs -r <你的公网IP或域名>:21117 -p <你自定义的密钥> &
./hbbr -p <你自定义的密钥> &

-r参数告诉hbbs，客户端需要连接的中继服务器地址和端口是什么；-p参数用于生成密钥对，这个密钥可以是一段任意字符串，比如your-secret-key-2024，后续客户端配置里要填它的哈希值作为key，这一点后面细说。

执行完之后，查看当前目录下会生成id_ed25519和id_ed25519.pub，用cat id_ed25519.pub就能看到公钥内容。如果一切正常，日志里会出现监听地址信息，说明服务已经跑起来了。

3.3 用systemd托管，重启不丢

直接后台启动的问题在于，服务器如果重启，服务不会自动拉起来。正确做法是写systemd服务文件，让系统来管理进程生命周期。我习惯在/etc/systemd/system/下建两个服务文件，一个管hbbs，一个管hbbr。

先创建hbbs.service：

ini复制[Unit]
Description=RustDesk ID Server (hbbs)
After=network.target

[Service]
Type=simple
WorkingDirectory=/opt/rustdesk-server
ExecStart=/opt/rustdesk-server/hbbs -r <你的公网IP或域名>:21117 -p <你的密钥>
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

再创建hbbr.service：

ini复制[Unit]
Description=RustDesk Relay Server (hbbr)
After=network.target

[Service]
Type=simple
WorkingDirectory=/opt/rustdesk-server
ExecStart=/opt/rustdesk-server/hbbr -p <你的密钥>
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

然后执行：

bash复制systemctl daemon-reload
systemctl enable hbbs hbbr
systemctl start hbbs hbbr
systemctl status hbbs hbbr

这里WorkingDirectory很重要。hbbs和hbbr会在当前工作目录下读取、生成密钥文件和日志文件，如果这个目录指定错了，可能会出现启动报错或者密钥文件生成在奇怪位置的情况。我建议所有服务和密钥文件都集中在/opt/rustdesk-server目录下，便于打包备份。

3.4 防火墙与安全组配置

这一步是针对云服务器而言的。云服务器通常有两层防火墙逻辑：一层是云控制台里的安全组规则，一层是系统本身的iptables/firewalld/ufw。两层都要放行，漏掉任何一个端口都可能导致服务不可用。

用ufw的话，配置方式如下：

bash复制ufw allow 21115/tcp
ufw allow 21116/tcp
ufw allow 21116/udp
ufw allow 21117/tcp
ufw reload

如果用的是云控制台安全组，就把同样的端口加入入方向规则。注意21116端口要同时加TCP和UDP规则，很多云控制台默认只开放TCP，UDP需要单独添加。我在腾讯云上就遇到过这种情况，安全组里加了TCP 21116，结果UDP是通的，让我一度以为服务有问题，后来才发现是UDP打洞失败导致所有流量都走中继。

3.5 验证服务是否正常

服务配置完成后，执行ss -lntup查看端口监听状态：

bash复制ss -lntup | grep -E '21115|21116|21117'

正常情况下，你应该看到hbbs监听21115（TCP）、21116（TCP和UDP），hbbr监听21117（TCP）。如果某个端口没有监听，检查服务状态日志：

bash复制journalctl -u hbbs -f
journalctl -u hbbr -f

日志能看到具体的报错信息，比如端口被占用、密钥目录无权访问、配置文件路径错误等。这一步跑通了，服务端就算正式上岗了。

4. 客户端接入与踩坑复盘：连接失败的完整排查过程

4.1 客户端配置三步走

服务端部署完成后，客户端配置反而更简单。以Windows客户端为例（Linux和macOS类似），在RustDesk主界面的右上角找到"设置"或菜单栏的"网络"选项，会看到"ID/中继服务器"的配置入口。勾选"使用自定义服务器"，然后填入三样东西：

ID服务器地址：填你的服务器公网IP或域名；
中继服务器地址：同样的IP或域名；
Key：填服务端生成的id_ed25519.pub公钥内容。

这里有个小细节，Key的填写：如果服务端指定了-p参数，那么客户端填的Key是服务端生成的id_ed25519.pub里的内容，而不是启动命令里的原始密钥字符串。这个内容是一长串类似base64编码的文本，直接整段复制粘贴即可。

配置完之后，理论上一台机器看到的ID就是你的服务器IP或域名分配的ID，另外一台机器也做同样配置，两边就能互连了。如果两台机器在同一局域网内，应该会自动走P2P直连，延迟在几毫秒级别；如果不在同一网络，就通过中继服务器转发，延迟取决于两边到服务器的网络质量。

4.2 踩坑实录：只有电脑能连，手机连不上

这是我第一次部署时遇到的真实问题。电脑端配置之后可以正常连接，但手机端（Android客户端）始终提示"连接失败"或者"Key不匹配"。排查过程我按下面的顺序进行，最终定位到是手机端应用版本与服务端版本不匹配造成的。

排查链路：

先看服务端日志，执行journalctl -u hbbs -f和journalctl -u hbbr -f，观察是否有连接请求进来。如果没有请求，说明客户端的网络路径根本到不了服务端，优先检查防火墙和安全组。
再在手机端上尝试ping服务器IP，如果ping不通，那就是网络路径问题；如果能ping通但连接失败，说明端口或协议层有问题。
用nc -uv <服务器IP> 21116测试UDP端口是否可达。如果UDP不通，说明安全组或防火墙漏了UDP放行。
如果TCP和UDP都通，但仍然连接失败，大概率是版本或Key问题。检查手机端RustDesk版本，如果与服务端版本差距过大，建议升级到一致版本再试。

我这个案例的最终结果是手机端版本比较旧，服务端用的新版本，密钥交换协议有了变化，升级客户端后问题解决。

4.3 踩坑实录：同一局域网内连接却延迟很高

有一次我调试两台都在同一办公室局域网内的电脑，理论上应该走P2P直连，延迟应该在个位数毫秒。实际操作却一直走中继，延迟飙升到100多毫秒。排查过程如下：

先怀疑是防火墙阻断了UDP打洞，检查了一遍安全组和ufw，确保21116的UDP已放行。然后又怀疑是路由器的AP隔离功能，但两台电脑在同一网段，互相ping都通，AP隔离应该不是问题。

最终定位到问题出在客户端的"连接方式"设置上。RustDesk客户端在设置里有一个"连接方式"选项，可以强制走中继或者允许直连。如果当时为了排查别的问题把连接方式改成了"强制中继"，那即使处于同一局域网也会绕路走服务器。改回"自动"或"直连优先"之后，延迟立刻降下来了。

这个坑提醒我一件事：RustDesk的很多设置是"记忆"在客户端的，换网络环境后可能仍然沿用之前的连接策略，遇到异常延迟第一时间检查这个设置，而不是急着动服务端配置。

4.4 踩坑实录：服务器重启后客户端全部连不上

还有一次是云服务器因维护被重启，之后所有客户端都连不上。我登上去一看，hbbs和hbbr进程都没在跑。原因很直接：当时只是用命令行后台启动的，没有做成systemd服务。重启之后，进程自然就没了。

这就是为什么前面我强调要用systemd托管。如果你也遇到了"服务端重启后连接失败"的问题，第一步就是检查两个服务进程是否在运行：

bash复制ps aux | grep hbbs
ps aux | grep hbbr

如果进程不在，直接systemctl start hbbs hbbr，然后确认是否设置开机自启：

bash复制systemctl is-enabled hbbs hbbr

如果显示disabled，执行systemctl enable hbbs hbbr。这一步做完，以后服务器重启服务会自动恢复。别小看这个细节，远程办公最怕的就是关键时刻连不上，而自建服务器一旦断连，你还没法通过远程软件去修复它——除非你还有别的访问通道。

4.5 网络环境变化导致的直连失效

很多人的使用场景是：在公司固定IP的网络下用得挺好，回到家用同一个客户端就连不上。这类问题大概率不是服务端挂了，而是家用网络对UDP打洞的限制更多。国内很多家用路由器默认开启防火墙，UDP入站往往被限制，导致P2P直连建不起来，只能走中继。中继服务器的带宽和网络质量这时候就成了瓶颈。

这类问题的处理思路：优先确认中继服务器是通的，客户端能连；然后判断是不是直连不通。在RustDesk的连接详情里，连接成功后可以看到"直连"还是"中继"的标识，如果始终是中继，且延迟偏高，可以考虑在路由器上给对应设备做端口转发或开启UPnP，但这需要路由器固件支持。相比之下，接受走中继也是一种务实的选择，毕竟自建中继的目的就是保证能连上、不排队。

5. 安全加固、密钥管理与长期维护经验

5.1 防火墙白名单与端口收敛

RustDesk自建服务暴露在公网上，任何端口都不能随意开放。安全组和防火墙层面，我建议做端口收敛，只开放上面提到的那几个端口，其余一律拒绝。尤其是服务器的SSH端口，不要使用默认的22端口，改成高位端口，并用密钥登录而不是密码登录，减少被暴力破解的风险。

针对RustDesk本身，如果使用场景相对固定，可以考虑在防火墙层面对ID服务器和中继服务器的访问IP做白名单。比如只允许公司固定IP段访问，个人家庭宽带如果IP经常变化，可以配置动态IP白名单脚本。这个方案需要一定运维能力，但对数据安全要求高的场景来说非常有效。如果团队使用，也可以在hbbs和hbbr前面加一层反向代理的限制，但这会增加部署复杂度，本人暂时没有深入，适合有更强安全需求的团队评估。

另一个细节：要定期查看服务端日志，看是否有非预期的连接尝试。RustDesk的日志会记录IP和连接时间，如果发现来自异常IP段的扫描或连接，要立刻检查密钥是否泄露、防火墙规则是否有效。

5.2 密钥管理：丢了密钥等于丢了服务

RustDesk的id_ed25519私钥非常重要，它决定了你的服务器如何校验客户端身份。一旦私钥丢失或泄露，恶意客户端可能伪造连接，或者你的合法客户端全部无法连接。

我建议部署完成后立刻备份/opt/rustdesk-server下的id_ed25519和id_ed25519.pub文件到本地或其他安全位置。备份时要注意：整套服务器目录里还有rustdesk-server相关数据，但最重要的就是这两个密钥文件和可能存在的数据库目录。恢复时，把这两个文件放回原目录并设置正确权限即可。

如果你是团队使用，那么Key的分发也要谨慎。客户端配置里需要填写的公钥是公开的，这不敏感；敏感的是私钥，绝对不要发给任何客户端。服务端的-p参数，也建议在systemd服务里通过环境变量或单独配置文件读取，而不是直接明文写在ExecStart命令行里。关于这一点，我个人的做法是在服务文件里挂载一个权限600的密钥文件，启动时读取，具体因发行版而异，但至少要避免密钥出现在进程列表里。

5.3 多人多设备场景的规划建议

如果你自己用，一台服务器配一个Key就够了。但如果是团队使用，我建议在规划阶段就想好几件事：

是否所有成员共用同一个ID服务器和服务端Key？RustDesk支持多个用户共用同一台服务器，这一点没问题。但所有客户端看到的ID都是基于同一服务端生成，区分成员主要靠设备ID和客户端名称，建议约定命名规则。
是否需要限制成员之间的互访权限？RustDesk的默认逻辑是，如果你知道对方的ID和密码，并且Key是一致的，就能连上。如果需要更细粒度的权限控制，需要用到RustDesk Pro版或企业版的功能，开源版不支持。这种情况下要考虑用其他方案或者等待开源版的演进。
中继服务器的带宽负载。团队多人同时使用中继，带宽消耗是线性的。如果你的服务器带宽只有5M，三个人同时玩1080P远程估计就开始卡了。根据团队实际使用频率调整带宽，或者限制使用分辨率、帧率来降低带宽占用。

就我自己而言，属于那种"平时一个人用，偶尔配合同事处理一台服务器"的场景，2核2G+8Mbps带宽完全够用。如果你的团队需求更大，要么升级带宽，要么让客户端尽可能走直连减少中继负载。RustDesk的直连技术在公网环境下成功率并不低，尽量创造条件让P2P工作。

5.4 更新维护与版本跟进

RustDesk的更新节奏不算慢，服务端和客户端版本升级通常伴随协议优化或Bug修复。我的维护习惯是每两个月左右查看一次GitHub Release页面，对比服务端版本与当前使用的版本，如果需要升级就按下面的流程操作：

bash复制systemctl stop hbbs hbbr
cp -r /opt/rustdesk-server /opt/rustdesk-server-backup-$(date +%Y%m%d)
# 下载新版解压后覆盖可执行文件
systemctl start hbbs hbbr
systemctl status hbbs hbbr

升级前一定要备份密钥文件，确认新的可执行文件能正确读取旧密钥。一般来说，协议是向后兼容的，但为了保险起见，升级后拿一台客户端实测连接一遍再收工。

另外，云服务器的安全补丁也要按时更新，尤其是负责中继转发的机器，一旦被入侵，所有流量都会被窥探，后果非常严重。系统层面建议开启自动安全更新，但不要开启自动内核更新，避免服务器重启后服务没有自动拉起造成的尴尬。

5.5 个人使用中的几点深刻体会

部署完成后的实际体验，和商业软件相比，最大的感受是"心里有底"。不再有排队界面、不再有强制广告或者限速提示，远程桌面的延迟和画质完全由自己的服务器质量和两端网络决定。我这个服务器放在国内，自己从家里连公司的电脑，同一个城市内延迟基本在30毫秒以内，操作起来很跟手，剪贴板和文件传输也正常。

踩了这些坑之后，我总结出一套最省事的维护口袋清单：部署完第一步备份密钥；第二步确认systemd开机自启；第三步检查TCP和UDP端口是否都放行；第四步修改SSH默认端口并关闭密码登录。这四步做完，基本上不会遇到致命性问题。

最后再分享一个很多人没注意到的小技巧：RustDesk客户端在设置里可以打开"自动接受连接"或者"开机启动"选项，配合Windows的自动登录，你就能做到人不在办公室、电脑开机即可随时被连。但开启"自动接受连接"时要谨慎，确保操作系统的账号有密码保护，且屏幕锁定功能正常，不然相当于给任何人开了一扇门。整体来说，RustDesk自建中继服务器是一件投入产出比很高的事情，花一晚上部署，收获的是长期稳定、不受制于人的远程办公体验。