向日葵太贵了：我用 RustDesk 在自己的 VPS 上搭远程桌面

去年年底我给客户做运维，最后被一件小事卡住了：客户办公室里的电脑要远程看，改路由、换 IP 都太麻烦，第三方远程控制软件按人数收费，人一多就吃不消。我本来想直接用现成的方案，但用着总觉得不对劲控制台挂在别人的服务器上，流量绕一圈绕一圈，我这个做服务器的人看着难受。后来干脆自己在 VPS 上搭了一套 RustDesk 的服务端，客户端还是官方那个，连接地址换成自己的 IP，整个体验立刻变了。

写下来不是为了吹这个软件有多神，而是想把这套东西从"能连上"到"用得顺手"之间那几道坎讲清楚：到底什么时候走直连、什么时候被迫走中继，公网服务器上需要开哪些端口，以及我为了压那几十毫秒延迟做过的那些无用功。

如果你打算自己搭一套远程桌面，那台负责中继和握手的主机是整套方案的核心，机器的位置和线路直接决定你操作的手感，可以先看看这几家的报价和技术说明：GoMami（中国优化线路 VPS），如果只是给团队几个人用、并发不高，也可以看看 OneTechCloud 易科云（多种云服务器方案），机器到位之后下面的步骤就能照着做。

一、先搞清楚 RustDesk 是怎么连起来的

RustDesk 的连接过程分两段：先"握手"，再"传画面"。握手阶段，客户端先向 ID 服务器（官方叫 hbbs）登记自己，登记的时候会把能不能被直连打洞的探测结果一起报上去；之后客户端根据探测结果决定是直接连对方，还是去中继服务器（官方叫 hbbr）取数据。

关键就在这里：能不能直连，取决于双方网络环境。如果两台机器都在 NAT 后面、都没有公网 IP，直连就一定失败，只能走中继。我第一次搭的时候就是吃了这个亏两台机器都在公司网络里，我以为能直连，结果每次操作画面都是一卡一卡，抓包才看到所有流量都在服务器上绕。

所以在动手之前，先明确你的场景：

1. 客户端机器有公网 IP 或者做了端口映射，且不在严格对称 NAT 后，能走直连，延迟接近本地网络；

2. 双方都在 NAT 后，只能走中继，延迟等于 客户端→服务器→客户端 这条路的两倍；

3. 一端在服务器机房、有公网 IP，另一端在 NAT 后，这种通常也能直连，打洞成功的概率不低。

顺带说一句，很多人以为"直连就一定比中继好"，其实也不绝对。直连走的是运营商之间的路由，质量取决于家宽和机房之间的互联；中继虽然多一跳，但如果你的中继节点和两端都在同一条优化线路上，体验反而更稳。我自己两台客户端分别在上海和法兰克福，直连时法兰克福那端偶尔会飙到 300ms，切到中继反而稳定在 90ms 左右。

二、公网服务器上要开哪些端口

RustDesk 默认用 21115 到 21119 这一段端口，每一条都有用途，官方文档里是一张表格，但我把它按自己的理解再说一遍，因为很多人漏开之后排查起来非常折磨：

21115 用于 NAT 类型探测（如果用的是 Docker 或者改过端口类型，这个得对上）；21116 是 ID 服务器（hbbs）的主要监听端口，也就是客户端登记和取密钥的地方；21117 是中继服务器（hbbr）给客户端回传数据的端口；21118 和 21119 主要是给 WebSocket 和非 TCP 传输用的，我实测没用到，但官方建议一起开，省得以后换传输方式再折腾。

另外自建服务端时最好给它配个域名和证书，走 hbbs 的 WebSocket 端口（21118）通过 Nginx 反代出去，这样即使被网络环境挡了直接连接，也有 HTTPS 这条路兜底。我第一台机器是裸 IP，客户端偶尔提示"无法连接到 ID 服务器"，后来就是靠反代 WebSocket 解决的。

需要说明的是，如果你的服务器有安全组或者面板防火墙（宝塔、腾讯云、阿里云那种），这些端口要在两个地方同时放行，只开一个是最常见的坑。系统内部的 firewalld、ufw 也算一层，我见过太多人在云控制台开好了，本机 ufw 挡着，然后怀疑是 RustDesk 的锅。

三、部署过程本身并不复杂

官方镜像一条命令就能跑起来，Docker Compose 的写法大致是这样：

hbbs 负责 ID 服务，hbbr 负责中继，两者用同一个网络，端口映射出来。hbbr 需要挂载一个数据目录，用来存证书和密钥；hbbs 需要指定 hbbs 的公网地址，因为客户端拿到地址后要主动去连它。

配置里有几个参数值得单独说：

- key：服务端与客户端之间约定的加密密钥，默认是公用的值，务必改成自己的一串随机字符，并且所有客户端都用同一个；

- relay：指向 hbbr 的地址，格式是 hbbs 客户端连你的 hbbs 用的那个地址加上 relay 端口，两边保持一致；

- enc：传输加密方式，默认是自动协商。如果你的客户端都是新版本，显式指定一种编码方式可以让两边行为一致，省掉一点协商开销；

- websocket：打开之后，21118 端口由 WebSocket 承载，方便走反向代理；

- nat：NAT 类型探测模式，Docker 部署时保持默认即可，如果部署在有 1:1 NAT 的机房（比如某些家宽型 IP），可以按官方的说明调整。

启动之后检查日志是最直接的办法：日志里会打印 hbbs 和 hbbr 各自监听的地址和端口，还会打印你的公网地址。如果客户端连不上，先看这两行日志有没有正确打印出来，比盲目改配置快得多。

四、四个让我折腾过的坑

坑一：直连失败了却没有任何提示。客户端界面上照样显示"已连接"，但操作延迟高得离谱。这种情况说明流量全走了中继。判断方法是在服务端看 hbbr 的连接数，如果连接数一直在涨而 hbbs 的直连日志一条没有，那就是没打洞成功。我的处理办法是给客户端开 UDP 端口映射，或者干脆接受中继，换一条更短的路走。

坑二：密钥没改。默认密钥是公开的，意味着任何人只要知道你的 ID 服务器地址就能用你的中继带宽。这个不难改，但它属于那种不提醒就永远没人会主动去改的配置，我见过不少自建服务还带着默认密钥跑在公网上。

坑三：内存不够被 OOM。hbbr 本身不吃内存，但中继转发是有缓冲的，如果你的客户端要传剪贴板、传文件、多路并发，1G 内存的机器在高峰期被 OOM Killer 干掉，日志里只留下 "Killed process"，看起来像莫名其妙断线。我现在的配置是 2G 内存，比较稳。

坑四：把中继当成了数据中转站。如果两台客户端都在国内，中继服务器放在美国，多半会得到一个让人绝望的延迟。后来我把这台机器换到离两边都近的香港节点，同样的配置，延迟直接砍掉一半。有时候问题不在软件，在机器的位置。

五、想再快一点，能做些什么

首先，选机器。中继节点的作用就是把两段最慢的路径各截一段，所以理想位置是"离大多数客户端都近"的地方，而不是"离公司总部近"。如果你的使用者在国内和海外都有，那多半要准备两台中继，或者干脆做多中继轮询。

其次，关掉一些花里胡哨的功能。文件传输、剪贴板同步、录制这些功能在需要的时候会开，平时用不上就关掉，能省带宽也省内存。画质方面，把"图像质量"调到"平衡"就够，我试过改成"最佳"，帧率没提升多少，流量倒是翻了一倍。

再就是别指望自己在客户端调参数。RustDesk 的传输层没有太多可调项，真正决定体验的是三件事：服务器线路、客户端的 NAT 类型、以及服务器本身的带宽。把这三个搞明白，剩下的都是细节。

最后提醒一句：这套东西装好之后，请务必把默认密钥改掉、给你的客户端设置访问密码或者开启二次验证，然后定期更新镜像。远程控制类工具一旦被利用，入侵者拿到的就是完整的桌面控制权，甚至可以绕过系统密码读取文件。我的习惯是给专门的运维账号用，权限和日常账号分开，出问题也不至于全线沦陷。

总的来说，RustDesk 自建服务端这件事，投入产出比挺高：一台最便宜的 VPS 就能撑起一个小团队的远程需求，客户端体验和商业软件几乎没有差别，代价只是第一次要花两三个小时把端口和密钥理清楚。如果你正在为远程访问发愁，不妨试试这条路。