企业官网建设流程全解析

1. RustDesk中继服务到底解决了什么问题

1.1 远程控制的链路架构拆解

先把话说清楚：RustDesk不是一个简单的点对点远程桌面工具，它的完整链路里有一个很容易被忽略的角色——中继服务器。很多人第一次用RustDesk，下载客户端填个ID和密码就能连上，体验起来和TeamViewer、向日葵差不多，这是因为RustDesk官方帮你兜底跑了一组公共服务器。但公网服务器资源有限、延迟不受控，而且一旦官方服务波动，你手头正在维护的机器可能说断就断。

RustDesk的通信逻辑可以拆成三层。第一层是ID注册和心跳，客户端启动后需要去注册服务器（hbbs）报到，告诉它"我在线，我的ID是xxx"。第二层是连接协商，你要控制一台机器时，控制端会通过hbbs拿到被控端当前的网络地址信息。第三层才是真正的数据通道，如果双方能建立P2P直连就走直连，如果双方网络环境都严格受限（典型的就是两边都在不同内网、都有NAT），P2P打洞失败，数据就走中继服务器（hbbr）转发。

自建中继，本质上就是同时部署hbbs和hbbr这两个组件。hbbs管"登记"和"撮合"，hbbr管"转发"。所以搭建RustDesk服务器，核心就是让这两个进程在公网机器上稳定跑起来，并且让所有客户端都指向你自己的服务器。这个逻辑一旦想清楚，后面的操作全部都是围绕它展开的。

1.2 官方公共服务器和自建中继的差距

先说官方服务器的体验：小规模用、网络环境简单的场景下，确实还不错。但一旦你需要长期维护几十台内网机器，就会发现几个切肤之痛。

第一是延迟不可控。官方中继服务器部署在海外，国内机器互连时数据要绕一圈，画面操作延迟经常跑到200ms以上，鼠标拖拽有明显滞后感，在内网机器上做数据库导出这类精细操作非常难受。第二是不稳定。官方服务偶尔会调整策略，高峰期连接失败率明显上升，你在外面突然发现连不上公司内网的机器，只能干等。第三是安全的隐忧。所有客户端的ID信息都集中登记在官方服务器上，虽然密码是加密存储的，但对于有安全洁癖、特别是手里管着生产环境服务器的人来说，这始终是个心理疙瘩。

自建中继解决的就是这三个问题。服务器放国内云主机，延迟能压到20~50ms；服务完全自己掌控，升级、重启、故障排查都透明；ID和Key掌握在自己手里，访问行为只存在于你自己的服务器日志里。代价就是你得多花一台云主机的钱，以及花半小时做一次完整的部署和配置。

1.3 什么情况下值得自建

我见过不少朋友一上来就问"我要不要自建"，其实得先看场景。如果你只是偶尔远程连一下家里的一台电脑，控制端和被控端网络条件都不算太差，官方服务器完全够用，没必要折腾。但下面这几类情况，我强烈建议自建：

• 需要跨多个内网维护生产机器，每天都要远程操作，对稳定性和延迟有要求。
• 公司内部有多台服务器、工控机、收银终端，需要一套统一的远控方案，并且不想把设备信息暴露给第三方云服务。
• 在内网断网隔离环境部署特定系统，需要在外网构建后向内网机器分发镜像，RustDesk正好作为前期维护通道（这个场景我还真踩过不少坑，后面细说）。
• 对访问安全有制度化要求，需要自己掌握完整的注册和转发链路。

明白了这些，下面就直接进入正题。服务器怎么选、端口怎么规划、进程怎么跑、客户端怎么填，每一步我都会把原因讲清楚，而不是只给你一串复制粘贴的命令。

2. 服务端搭建前的硬件规划与端口设计

2.1 带宽、内存、CPU的最低要求和推荐配置

RustDesk自建服务器的资源消耗，其实比你想象的低得多。hbbs是轻量注册服务，平时CPU占用几乎可以忽略，内存占用大概在几十MB级别。hbbr是中继转发服务，这个就看你的并发量和流量了。如果你只是自己用、偶尔同时连一两台机器，1核1G的云主机跑起来毫无压力。如果你要给一个团队提供服务，同时可能有5~10路转发，那么2核4G会更从容。

真正要重点看的是带宽。中继转发的特点是：控制端和被控端之间的屏幕图像数据全部经过你的服务器，所以服务器的带宽决定了你能达到的远控画质和帧率。以RustDesk默认画质为例，1920x1080分辨率下，一帧压缩后的屏幕数据大概在50~200KB之间，如果每秒传10帧，单路流量大约在4~16Mbps。这意味着如果你用一台1Mbps小水管服务器做中继，那基本只能看个静态桌面，动一下就糊成一片。

我个人的推荐配置是：个人使用选1核2G、带宽5Mbps以上的云主机；团队使用选2核4G、带宽10Mbps以上，带宽不够时优先开"画质优先"模式让RustDesk自动帧率自适应。国内云主机厂商的轻量应用服务器性价比很高，流量包基本够日常维护使用，按量付费往往反而更划算。

2.2 三个关键端口的功能划分

RustDesk服务端最核心的端口是21115、21116、21117，它们各管一摊，理解清楚了后面的防火墙配置才不会乱。

• 21115：TCP端口，用于NAT类型测试。客户端启动后，会通过这个端口向服务器发送探测包，判断它自己当前的网络环境。
• 21116：TCP和UDP双栈端口，这是hbbs的主端口。客户端的ID注册、心跳保活、连接请求都走这里。UDP主要用于大量短消息的传输和打洞探测，TCP用于可靠的长连接。
• 21117：TCP端口，它是hbbs的"连接入口"。客户端要建立远程会话时，会先通过这个端口和hbbs交互，拿到中继服务器的地址信息，然后数据流再转向hbbr。

如果开了Web客户端支持，还会用到21118和21119，但基础场景下这三个端口就是全部。很多初次搭建的朋友只放了TCP端口没放UDP，结果客户端能注册但P2P打洞一直失败，最后所有流量都走中继，白白浪费带宽。这个坑我下面会重点提醒。

2.3 安全组策略与防火墙放行

搞清楚了端口，防火墙配置就顺理成章了。以国内主流云厂商的安全组为例，你需要添加入站规则：TCP 21115、TCP/UDP 21116、TCP 21117。注意21116的UDP一定要放行，很多人就是漏了它。

服务器本身的firewalld或ufw也要同步放行。CentOS Stream / Rocky Linux习惯用firewalld，执行：

firewall-cmd --permanent --add-port=21115/tcp firewall-cmd --permanent --add-port=21116/tcp firewall-cmd --permanent --add-port=21116/udp firewall-cmd --permanent --add-port=21117/tcp firewall-cmd --reload

Ubuntu/Debian用ufw的话：

ufw allow 21115/tcp ufw allow 21116/tcp ufw allow 21116/udp ufw allow 21117/tcp ufw enable

另外强烈建议把SSH端口改成非默认端口，或者在安全组里限制SSH只允许你自己的办公网IP访问。中继服务器是公网暴露的，每天被扫描爆破是常态，RustDesk端口反倒不用太担心，因为协议本身有Key校验，但SSH是重灾区。一次部署顺手做掉这个加固，能省掉后面一堆麻烦。

3. 公网中继服务器完整搭建流程

3.1 部署方式选型：Docker还是二进制

RustDesk服务端有两种主流部署方式：官方Docker镜像和直接跑二进制文件。我两种都用过，说说感受。Docker方式适合图省事、不折腾系统环境的场景，镜像拉下来一条命令就能跑，升级也简单，但前提是你的机器能访问镜像仓库。二进制的优势是部署逻辑完全透明，进程直接挂在systemd下面，出问题排查链路更直接，而且不依赖容器环境。

考虑到很多人的服务器是国内云主机，拉Docker镜像偶尔会遇到源不稳定，我建议两种方式都掌握。这里先讲二进制方式，因为它能让你看清楚每个组件到底在干什么，Docker方式只是把下面这些步骤封装起来了而已。

3.2 hbbs和hbbr两个核心进程的启动参数

首先下载服务端二进制。到RustDesk的GitHub Release页面，找rustdesk-server-linux-amd64的压缩包，个人使用选免费版（开源版）即可。解压后你会看到两个核心可执行文件：hbbs和hbbr，还有一个后缀为.so的依赖库文件，这三个必须放在同一个目录下。

启动hbbs：

cd /opt/rustdesk-server ./hbbs -r your.domain.com:21117 -k _

启动hbbr：

cd /opt/rustdesk-server ./hbbr -k _

参数讲一下。-r指定的是中继服务器的地址和端口，这里要填你自己的域名或公网IP，端口就是前面说的21117。-k _表示自动生成一个随机的Key（公钥），第一次启动后会在当前目录下生成一个id_ed25519私钥文件和对应的公钥字符串。这个公钥很重要，客户端配置时需要填它，用来做通信加密握手。

如果你已经有固定Key想复用，-k后面直接填之前生成的公钥内容也可以。实际运维中我建议用自动生成的，把私钥文件妥善备份，别泄露出去。私钥一旦丢失，所有已配置的客户端都得重新更新Key，那场面很酸爽。

启动hbbr时不需要指定监听端口，它默认就监听21117之后的端口范围，负责转发数据。

3.3 开机自启与守护进程配置

直接用命令行跑进程有个毛病：SSH断开或者进程崩溃，服务就没了。生产环境必须把它注册成systemd服务。

创建hbbs服务文件/etc/systemd/system/rustdesk-hbbs.service：

[Unit] Description=RustDesk ID/Registration Server After=network.target [Service] Type=simple WorkingDirectory=/opt/rustdesk-server ExecStart=/opt/rustdesk-server/hbbs -r your.domain.com:21117 -k _ Restart=always RestartSec=5 LimitNOFILE=1048576 [Install] WantedBy=multi-user.target

再创建hbbr服务文件/etc/systemd/system/rustdesk-hbbr.service：

[Unit] Description=RustDesk Relay Server After=network.target [Service] Type=simple WorkingDirectory=/opt/rustdesk-server ExecStart=/opt/rustdesk-server/hbbr -k _ Restart=always RestartSec=5 LimitNOFILE=1048576 [Install] WantedBy=multi-user.target

然后依次执行：

systemctl daemon-reload systemctl enable --now rustdesk-hbbs systemctl enable --now rustdesk-hbbr

启动后用socket查看监听状态：

ss -lntup | grep -E '2111[567]'

正常情况下你能看到21115、21116的tcp监听，21116的udp监听，以及hbbr占用的tcp端口。如果哪个端口没起来，检查一下是不是被其他进程占用了，这个坑我也在后面统一说。

3.4 域名解析与Web控制台配置（可选但推荐）

如果你有域名，强烈建议解析一个A记录到服务器IP，比如relay.yourdomain.com。这不仅仅是好看，更重要的是如果你以后换服务器IP，客户端这边只需要改一下域名解析，不用挨台机器重配。没有域名直填IP也能用，适合临时场景。

新版RustDesk服务端自带了一个简单的Web控制台，通过21118/21119端口访问，可以查看当前注册的ID列表和在线状态。我个人的使用习惯是：不加HTTPS反向代理的话，这个端口不对外开放，需要查在线状态时SSH到服务器上本地访问或者临时放行端口。如果确实想通过浏览器安全访问，Nginx反代加Let's Encrypt证书是最常规的做法，具体配置网上很多，这里不展开。

3.5 获取Key与中继地址

服务跑起来后，去/opt/rustdesk-server目录下找.pub后缀的文件，里面就是公钥字符串。用cat打开，复制整段内容，后面填客户端要用。整个文件内容通常长这样：

9fJ3Pz8G5XkQwE2rT7uYbNaCcDdEeFfGgHhIiJjKkLlMm=

公钥的作用是客户端和服务器握手时验证对方身份，防止有人冒名顶替你的服务器。这也是自建RustDesk和直接用官方服务器最核心的区别之一——通信链路只信任你自己声明的Key。

4. 客户端接入配置与内网机器绑定

4.1 Windows客户端的中继地址填写

客户端配置是所有环节里最容易出错的一步。RustDesk的Windows客户端双击打开主界面，右上角菜单里找到"ID/中继服务器"设置项，会弹出一个对话框。这里不是简单填三个框就完事，很多人的问题就出在"中继服务器"这一栏到底要不要带端口。

正确填法：

• ID服务器：填你的域名或公网IP，不需要带端口，默认就是21116。
• 中继服务器：填your.domain.com:21117，注意这里的格式是域名冒号端口，端口必须带，因为hbbr的数据入口走21117。
• Key：填刚才复制的那串公钥。

填完点确定，客户端会重新连接服务器。此时看主界面的"ID"是否正常显示。如果ID变成了-----或者一长串0，说明和hbbs的通信没建立成功，后面会专门排查。

Windows客户端还有一个细节：如果你在内网机器上装了Windows版RustDesk，并且以后想通过无人值守方式远程连接，就必须在"安全"设置里设置一个固定密码，而不是使用每次启动都随机变化的临时密码。固定密码用RustDesk的加密选项保存，安全强度也够。

4.2 Linux、Android、macOS客户端的配置

Linux客户端同样在设置里配置ID/中继服务器，和Windows大同小异。唯一注意点是Linux的RustDesk客户端可能依赖部分图形库，在纯命令行服务器上部署要注意有没有libxcb和libgtk这些基础依赖，否则打不开界面。

Android客户端的坑主要在两个地方。第一是填写界面路径：新版客户端在左上角菜单里选"设置"然后进入"网络"进行修改。第二是Android的后台运行限制：如果被控端是Android设备，你要远程控制它，务必在系统设置里允许RustDesk后台运行、忽略电池优化，否则屏幕一灭、系统一杀进程，连接就断了。这部分和各家手机ROM的后台管理策略有关，不是RustDesk本身的问题。

4.3 手机端安装受限的实际情况

最近不少人的手机上装了RustDesk被系统弹窗拦截，特别是小米澎湃（HyperOS）系统。这里先说清楚：RustDesk本身是正规的开源远控软件，不需要任何敏感权限，它只需要屏幕录制、悬浮窗这类常规权限。澎湃系统拦截的根本原因是默认开启了"纯净模式"或"安全防护"，对外部来源APK的安装做了限制。

解决办法很直接：安装时选择"允许来自此来源的应用"，系统弹出风险提示时选择"仍然安装"。如果安装到一半被拦截了，去"手机管家"的"隐私与安全"设置里，把纯净模式、安全防护的开关暂时关掉，装完再开回去。装好之后首次启动，会提示需要开启无障碍服务和悬浮窗权限，这个按指引授权即可。

这里顺便说一句：网上有些帖子把"无法安装"解读得很夸张，其实不用慌，它和那些需要绕过系统权限的灰色软件性质完全不同，RustDesk只要走正规渠道下载，按正常流程授权就行。

4.4 内网机器离线环境部署的特殊情况

热搜词里有一条"mineru docker离线打包"，虽然和RustDesk不直接相关，但这类场景在内网运维中很常见：外网一台机器上构建好Docker镜像，然后导出为tar包，再拷贝到内网断网机器上加载，整个流程里需要一个可靠的工具来监视和维护这些内网机器。RustDesk中继服务器正好能帮忙：前期给内网机器装上RustDesk客户端，外网通过中继随时接入，镜像传输和灰度发布都能远程完成。

具体到离线打包，常规套路是在外网机器上：

docker save -o myapp.tar myapp:latest

然后压缩传输到内网机器，再执行：

docker load -i myapp.tar

这个过程中RustDesk的价值就是让你不用每次拷镜像都跑一趟机房，远程就能完成上传、加载、重启容器。如果内网机器部署了RustDesk服务端，你把整个离线镜像包拉进去加载，效果等同于内网专用私有仓库。这条路径跑通后，真正能做到"外网构建、内网部署、全程远程"。

5. 安全加固、防火墙策略与日常维护

5.1 端口最小化开放

RustDesk运行需要哪些端口，前面已经讲清楚了。安全加固的第一原则就是：除了这些必要端口，别的不要裸奔在公网。特别是服务器如果有Web管理面板或者其它业务服务，建议全部绑内网IP，或者通过安全组限制源IP。端口最小化开放，不是说要你封死一切，而是每个暴露出来的端口都得知道它是干什么用的，不知道用处的端口一律不放行。

另外提一个我踩过的坑：21116的UDP端口在部分云厂商安全组里，如果你用的是"来源IP"白名单模式，记得把UDP和TCP分别加规则，有些控制台不会自动把两者一并放行。

5.2 Key管理与访问控制

Key是RustDesk自建服务器的安全命门。公钥下发到所有客户端，私钥只保留在服务器上。如果私钥泄露，攻击者可以伪造你的服务器身份，诱导客户端误连到他的机器上。所以私钥文件id_ed25519权限建议设为640，并且定期备份到安全位置。

还有一点容易被忽略：hbbs监听的21116端口同时提供注册服务，如果你不想让任何人都能往你的服务器上注册ID，可以在服务配置文件里通过-R <地址>参数限制hbbs的地址绑定范围。不过这个参数实际用得不多，因为RustDesk的ID本身是随机生成的字符串，攻击者就算注册了ID也影响不了你的客户端。

更高阶的做法是给RustDesk服务端加一层Fail2ban防护，监控hbbs的日志，对有异常行为的来源IP做封禁。对于面向生产环境的自建中继服务器，这个配置值得花十分钟做一下。

5.3 日志查看、版本升级与故障自查

日常维护主要看两块日志。hbbs的日志默认输出到stdout，systemd管理的话用journalctl -u rustdesk-hbbs -f实时查看。常见的关键信息包括：客户端ID注册成功、连接请求、NAT类型探测结果。hbbr的日志则重点看数据转发的连接建立和断开记录。

版本升级建议跟随RustDesk官方Release节奏，不要长期停在老版本。RustDesk服务端本身升级不频繁，但一旦有安全修补通常很重要。升级流程就三步：先停服务、替换二进制文件、再启动服务。注意升级时-k _这个Key配置要保持不变，否则所有客户端都要重新配Key。

6. 搭建与使用中的高频问题排查

6.1 客户端一直显示"无法连接中继服务器"

这是最多人遇到的情况。先别急着怀疑服务端，按下面顺序自查：

1. 在客户端机器上执行telnet your.domain.com 21117，看TCP能不能通。不同说明中继端口没放行。
2. 检查服务器上ss -lntup | grep 21117，确认hbbr进程在监听。
3. 用手机流量做测试，排除内网防火墙干扰。
4. 查看hbbr日志，看有没有客户端的连接记录。

还有一种隐蔽情况：域名解析到了CDN或者国内某些云厂商的"安全加速"上，这类服务不转发TCP长连接，导致21117端口探测看起来通但实际连不上。解决方法是使用纯DNS解析，不要叠加CDN或高防IP。

6.2 ID和密码获取失败

客户端界面上ID区域显示---或者全零，核心原因是连不上hbbs的21116端口。重点检查UDP端口是否放行，因为ID注册的初始握手依赖UDP通信。

排查命令在服务器上执行：

ss -lunp | grep 21116

能看到进程在监听说明服务端正常。客户端本地再试：

nc -uvz your.domain.com 21116

UDP的nc测试结果相对模糊，但至少能看出网络层是否可达。确认无误后，把客户端完全退出、在任务管理器里结束所有RustDesk进程后再重新打开，很多情况下是客户端拿到错误的网络状态缓存导致一直连接不上。

6.3 远控画面卡顿、延迟高

自建中继定位卡顿，先分清楚是P2P直连没打通、还是中继带宽不够。看主界面连接状态里的"连接类型"标识，如果显示"中继"，说明P2P打洞失败，所有流量都压在服务器带宽上。此时优先优化网络：让被控端和控制端尽量处于同一运营商网络，或者调整NAT设备的UPnP设置。

如果连接类型显示"直连"，但还是卡，那么瓶颈在两端的上传带宽或RustDesk的画质设置上。可以手动把画质从"清晰"调成"平衡"，或者限制帧率为15帧，多数办公场景下完全没有影响，带宽占用能下降一半以上。

6.4 端口被占用、配置错乱等环境坑

最后列一批我实际遇到的小问题。21116端口被系统其他进程占用时，hbbs一般会启动失败或提示"Address already in use"，用fuser -v 21116/tcp 21116/udp查到占用进程后处理。客户端配置过老的服务器地址时，旧的连接配置会残留，导致走了错误的中继，解决办法是重置客户端的配置文件，在Windows上是删除C:\Users\你的用户名\AppData\Roaming\RustDesk\config下的相关文件后重启客户端。

另外，如果你的服务器同时运行了宝塔等面板，面板自带的防火墙和系统firewalld、云安全组可能三层叠加，任何一层没放行都会导致连接失败。排查时三层一起看，不要只盯着系统防火墙。

我在实际部署中还有一个习惯：每次部署完服务端后，都会做一次"全链路自测"，就是用一台手机流量、一台家庭宽带、一台公司办公网的三台设备分别测试连接，这样能尽早暴露运营商跨网互访的问题，而不是等到真正要远程了才发现连不上。RustDesk自建中继折腾的其实不是那几条启动命令，而是网络链路上各种隐蔽的不确定性。把上面这些点都过一遍，这套系统基本就能稳定跑上很久了。