RustDesk 内网无公网 IP 怎么搭中继？端口映射、frp 中转与多分支机构组网实战

很多企业 IT 同事都遇到过这样的场景：公司内网没有公网 IP，员工出差在外想连回办公电脑做远程支持；分支机构的内网设备需要总部运维远程看一眼；给客户交付的工控机、ERP 服务器要随时远程维护，却又不想把远程控制权限交给第三方商业软件。这时候 RustDesk 是性价比最高的选择——开源、可自建中继服务器、数据不出企业。RustDesk 中继服务器搭建本身并不复杂，真正让人卡住的是”内网没有公网 IP”这个前提：端口映射怎么做、frp 该怎么配、多分支机构怎么组网、Key 怎么强制。本文从架构讲起，把这三条落地路线一次讲透，并附完整端口清单、安全加固清单和排障表，照着做就能在企业内网里跑起来一套自主可控的远程桌面中继服务。

一、为什么企业内网搭 RustDesk 中继，比公网服务器更麻烦

在阿里云、腾讯云买一台轻量应用服务器，装个 Docker，两条命令把 hbbs 和 hbbr 拉起来，中继服务就通了——这是大部分教程的内容，也是我此前在群晖 NAS 上写过的那套思路。但企业真实环境往往不给你这个条件，难点集中在四个方面。

第一，没有可用的公网 IP。 家宽和企业宽带多数已经转入运营商 NAT，路由器 WAN 口拿到的地址落在 100.64.0.0/10 这个 CGNAT 网段里。这个地址在运营商内部是私有的，你在路由器上做端口映射，外部根本找不到你，映射规则等于写在空气上。很多同事折腾半天映射失败，原因就是这一步没判断对。

第二，即使有公网 IP，运营商也可能封端口。 常见的 80、443、8080、3389 在不少省份是被封的。RustDesk 用的 21115-21119 属于高位端口，被封锁的概率低，但个别地区仍会对 UDP 流量做限制，而 RustDesk 的 ID 注册与打洞恰恰依赖 UDP。

第三，UDP 打洞在企业多级 NAT 下几乎必然失败。 RustDesk 的直连体验之所以好，是因为它优先尝试 P2P 打洞。但企业网络常见”光猫 NAT + 路由器 NAT + 防火墙 NAT”三层结构，加上出口做了源端口随机化，属于典型的对称型 NAT（Symmetric NAT），打洞成功率很低。打洞失败不是故障，RustDesk 会自动降级走中继（relay），只是流量要绕一圈，带宽和延迟取决于中继节点。

第四，多分支机构互访与合规要求。 总部、分公司、工厂、门店各有一套内网。老板的诉求通常是”我在任何地方都能连到任何一台授权设备”，而 IT 的诉求是”只开必要的口、只让必要的人进来、留下审计痕迹”。这两个诉求只有靠合理的拓扑设计才能同时满足。

所以本文不写”买个云服务器两条命令搞定”的简化版，而是按企业真实网络条件分成三条路线：有公网 IP 做端口映射、完全没有公网出口用 frp 反向穿透、多分支机构异地组网。你可以先看第二节的端口和架构，再跳到符合自己场景的那一节。

二、RustDesk 中继架构与端口全解（先搞懂再动手）

RustDesk 自建服务端由两个进程组成，名字很像，职责完全不同，这是新手最容易混淆的地方。

hbbs（ID 服务器）：负责设备 ID 注册、心跳保活、NAT 类型探测、以及帮两个客户端交换连接信息。你可以把它理解成”通讯录 + 媒人”，它不传输你的屏幕画面。

hbbr（中继服务器）：负责在两个客户端无法 P2P 直连时，把画面和键鼠流量中转过去。它才是真正吃带宽的那个进程。

两者的关系可以这样记：hbbs 决定”你们俩怎么连”，hbbr 负责”实在连不上我来搬数据”。企业内网场景里，因为打洞大概率失败，hbbr 承担的流量比例会非常高，所以 hbbr 部署在哪里、带宽多大，直接决定了远程桌面的使用体验。

端口	协议	所属进程	作用	内网场景是否必开
21114	TCP	hbbs	HTTP API（授权版/Web 管理能力使用）	否，开源基础版可不开
21115	TCP	hbbs	NAT 类型测试	是
21116	TCP + UDP	hbbs	ID 注册、心跳、TCP 打洞与连接服务	是，UDP 最容易被漏
21117	TCP	hbbr	中继（relay）数据转发	是，内网场景必开
21118 / 21119	TCP	hbbs / hbbr	Web 客户端（HTTP / HTTPS）	否，不用 Web 客户端就关掉

客户端里有四个填写项，含义必须分清，填错一个就连不上：ID 服务器是 hbbs 的地址；中继服务器是 hbbr 的地址（留空时客户端默认用 ID 服务器同地址的 21117 端口）；API 服务器只在授权版需要；Key 是 hbbs 生成的公钥内容，用于强制校验合法客户端。如果 hbbs 的 21116 不是默认端口，ID 服务器要写成 地址:端口 的形式。

连接过程也值得说清楚：客户端启动 → UDP 21116 向 hbbs 注册 ID 并心跳 → 发起远程时由 hbbs 交换双方地址 → 双方尝试打洞（21115 测 NAT 类型，21116 打洞）→ 打洞成功则 P2P 直连，画面不经服务器；打洞失败则由 hbbs 通知双方连 hbbr 的 21117 → 画面经中继转发。理解这条链路，后面所有排障都有依据：连不上多半是 hbbs 的 21116 不通；能连上但卡顿、延迟高，多半是走了中继而中继带宽不够。

三、先判断场景：你属于哪一类网络环境

动手之前，务必花两分钟把网络归属判断清楚。判断错误会导致后面所有配置白做。

场景	判断方法	可行方案	流量路径
A. 有真公网 IP	路由器 WAN 口地址与 curl ip.sb 查询结果一致，且不在 100.64/10、10/8、172.16/12、192.168/16 段内	端口映射 + 内网部署	打洞成功可 P2P，失败走本机 hbbr
B. CGNAT / 无公网 IP	WAN 口拿到 100.64.x.x，或查询到的公网 IP 与 WAN 口不一致	frp 反向穿透（方案二）	全部流量经公网 VPS 中转
C. 多分支机构	总部 + 2 个以上分支，各有一套出口和网段	统一中继 / VPN 打通（方案三）	视拓扑而定
D. 已有 VPN / SD-WAN	分支与总部已三层互通	总部内网直接放 hbbs/hbbr	走专线/VPN，不暴露公网

判断公网 IP 有三个动作，建议都做一遍：查看路由器 WAN 口地址；在服务器上执行 curl ip.sb 或访问任意查 IP 网站；把两个结果对比。如果路由器 WAN 口是 100.64.x.x、10.x.x.x、192.168.x.x，而网站显示的是另一个地址，说明你在运营商或上级路由的 NAT 后面，端口映射无效，直接走方案二。另外还要确认运营商是否封锁入向端口——即使 IP 是真公网，部分地区的家宽也禁止入向 80、443 等常用端口，这时候换高位端口（如 21115-21117）通常可用。

四、方案一：有公网 IP，用端口映射把中继暴露出去

这是最节省成本的路线：hbbs 和 hbbr 直接跑在企业内网的一台常开设备上——群晖 NAS、NVR 主机、超融合里的一台轻量虚机、或者一台 4 核 8G 的工控机都可以，然后通过路由器端口映射把必要端口暴露到公网。

4.1 部署 hbbs 与 hbbr

以 Docker 部署为例，先在设备上创建数据目录，用于持久化 ID、密钥和数据库。hbbs 与 hbbr 必须共用同一个数据目录，否则 Key 对不上，客户端会报错。

mkdir -p /volume1/docker/rustdesk && cd /volume1/docker/rustdesk

启动 hbbs 时用 -r 参数指定中继地址，用 -k _ 强制启用密钥校验（下划线表示让程序自动生成密钥并强制校验）。hbbr 同样带 -k _。使用 host 网络模式时不需要逐个映射端口；如果你的环境必须用桥接网络，就把 21115、21116（TCP 与 UDP）、21117 逐个 -p 发布出来。具体镜像标签和参数以官方 self-host 文档为准，不同版本参数可能有增减，建议先跑一次 --help 确认。

启动后进入数据目录，会看到 id_ed25519 和 id_ed25519.pub 两个文件。公钥文件的内容就是客户端要填的 Key，把整段字符串复制下来（不要带换行和空格），妥善保存，后面每个客户端都要用。如果误删数据目录，Key 会重新生成，所有已配置客户端都会失联——这是运维中最常见的翻车点之一，务必把数据目录纳入备份。

4.2 路由器端口映射

在路由器的”端口转发 / 虚拟服务器 / NAT”页面添加规则，把外网端口指向内网设备的固定 IP。三条必需规则：21115 TCP、21116 TCP、21116 UDP；再补一条 21117 TCP 指向 hbbr。最容易漏的是 21116 的 UDP 那条——很多路由器添加规则时默认只选 TCP，结果 TCP 映射成功、ID 能注册、连接却始终走不通，现象非常有迷惑性。

如果光猫和路由器是两层设备（光猫拨号 + 路由器再 NAT），要么把光猫改成桥接、由路由器 PPPoE 拨号，只在路由器上做一层映射；要么在光猫上把 DMZ 指向路由器 WAN 口，再在路由器上做映射。两层 NAT 下只做其中一层的映射是无效的。给内网设备分配静态 IP 或用 DHCP 保留地址，避免重启后 IP 变化导致映射失效。

4.3 验证与客户端填写

映射做完不要急着开客户端，先用外部网络验证端口是否真的通了：在手机 4G/5G 热点下（不要用公司 WiFi）执行端口探测，或者找一台外网机器用 telnet、nc 测 21115 和 21116。TCP 能通只说明一半，UDP 需要另外确认——这一步没有好用的公网工具时，直接看 hbbs 日志里是否出现客户端的注册记录更可靠。

客户端填写：ID 服务器填公网 IP 或绑定好的域名；中继服务器留空（同机部署时默认用 21117）；Key 填 id_ed25519.pub 的内容。保存后重启客户端，状态栏显示”就绪”且能拿到 ID，说明注册成功。

五、方案二：没有公网 IP，用 frp 把中继反向穿透出去

这是企业内网最常见的落地方式，也是本文的重点。核心思路：在公网买一台带宽足够的小 VPS 跑 frps（服务端），在企业内网跑 hbbs/hbbr 的机器上跑 frpc（客户端），由内网主动向外建立长连接，把端口反向映射到 VPS 上。这样不需要企业有任何公网 IP，也不需要动运营商。

5.1 为什么要用 frp，而不是别的穿透工具

市面上常见的内网穿透工具分两类：一类是 HTTP 隧道（只转发七层协议），RustDesk 走的是自定义 TCP/UDP，用不了；另一类是组网型（ZeroTier、Tailscale），效果是把所有设备拉进一个虚拟局域网，运维侧配置更简单，但客户端要额外装组网软件，且部分企业网络对这类流量有额外限制。frp 的优势是纯端口转发、行为透明、企业防火墙容易放行，缺点是需要自己维护 VPS 和配置。

5.2 frps 服务端配置

在公网 VPS 上部署 frps，配置文件 frps.toml 只需要三件事：监听端口、鉴权 token、日志。监听端口建议改成非默认值以减少扫描，token 一定要设置强口令，否则任何人都能把你的 VPS 当成穿透跳板。VPS 安全组/防火墙放行 frps 监听端口，以及 21115、21116（TCP 与 UDP）、21117。

5.3 frpc 客户端配置

在企业内网机器上配置 frpc.toml，一条代理对应一个端口。至少需要四条：21115 TCP、21116 TCP、21116 UDP、21117 TCP。每条代理都要指定本地 IP（跑 hbbs/hbbr 的内网地址）、本地端口、远端端口。UDP 那条的 type 必须写 udp，这一点在很多 frp 教程里被忽略，而 RustDesk 的 ID 注册依赖它。如果还要用 Web 客户端，再加 21118、21119 两条 TCP。

配置完成后先在前台运行看日志，确认每条代理都是 start proxy success 再去配置成开机自启。Windows 机器可以用 winsw 或计划任务，Linux 用 systemd，NAS 用计划任务或容器自带的守护能力。务必做成自启——内网机器断电重启后 frpc 没起来，表现就是”昨天还好用，今天全公司都连不上了”。

5.4 一个必须知道的真相：frp 下打洞基本会失败

这是实战中最需要提前说清楚的一点。RustDesk 判断能否 P2P 直连，依赖 hbbs 观察客户端真实的外网地址与端口变化。走 frp 之后，hbbs 看到的连接来源是 frps 的地址，NAT 类型判断失真，绝大多数情况下会被判定为中继模式，也就是画面全部经 frps 转发。这不是配置错误，而是穿透方案的固有特性。

由此带来两个直接后果：一是带宽成为唯一瓶颈，VPS 带宽多大，同时远程的流畅度上限就是多少；二是延迟会叠加，链路变成”被控端 → 企业出口 → VPS → 控制端”，跨省使用时延迟可能到 60-100ms。实践中的经验值：单路 1080p 办公桌面在”流畅/均衡”画质下大约占用 1-3 Mbps，10 路并发建议 VPS 至少 50 Mbps 带宽并选就近地域，不要贪便宜选 1M 小水管，那样只能勉强传画面，操作会明显拖影。

如果企业非常在意 P2P 直连效果，正确的方向不是折腾 frp，而是向运营商申请固定公网 IP（专线或商务宽带通常可申请），或者用方案三的 VPN 组网方式，让打洞在对等网络里完成。RustDesk 也提供授权版本，包含官方全球中继节点、API 与定制客户端能力，适合不愿自建带宽的团队——这部分在第十节对比。

六、方案三：多分支机构异地组网怎么做

当企业有总部加多个分支（工厂、门店、仓储），单点中继的设计要重新考虑。RustDesk 客户端只支持配置一组 ID 服务器，这意味着全网设备必须注册到同一个 hbbs 才能互相寻址、互相远程。基于这个约束，常见的三种拓扑如下。

6.1 拓扑一：公网 VPS 单点中继（推荐）

在公网 VPS 上跑一套 hbbs + hbbr 作为全公司唯一的中继中心，总部和每个分支的内网机器用 frpc 反向接入（或者分支本身有公网 IP 就直接让客户端连 VPS）。所有客户端填同一个 ID 服务器地址和同一把 Key。优点是结构最简单、跨分支互控天然可行、运维只需要维护一台 VPS；缺点是所有远程流量都经 VPS 转发，带宽成本集中在这一台机器上，需要按并发数规划带宽。

6.2 拓扑二：总部集中 + 分支只做客户端

总部有公网 IP 或能做映射时，把 hbbs/hbbr 放在总部内网，分支不部署任何服务端，分支设备只作为客户端注册到总部的 ID 服务器。这样分支不需要额外设备和带宽投入，总部的 hbbr 承担全部中继流量。适合分支数量多、分支无 IT 人员的连锁型门店场景。注意总部出口的上行带宽要留足，宽带的上行通常远小于下行，而中继吃的是上行。

6.3 拓扑三：既有 VPN/SD-WAN 时把中继放进内网（最安全）

如果企业已经用 IPSec、SSL VPN 或 SD-WAN 把各分支三层打通，最干净的做法是把 hbbs/hbbr 部署在总部内网，客户端 ID 服务器直接填总部的内网地址（如 10.10.1.20）。远程流量全程走企业自己的加密隧道，一个端口都不暴露到公网，审计和合规最好做。这是我最推荐给中大型企业的方案，前提是 VPN 带宽和稳定性要够——远程桌面是持续流量，VPN 抖动会直接体现为画面卡顿。

6.4 不建议的做法：每个分支一套 hbbs

有些方案让每个分支各部署一套 hbbs，看似分流，实际会带来问题：客户端只能连一个 ID 服务器，分支 A 的设备无法通过分支 B 的 hbbs 找到，跨分支互控直接失效；多套 Key 管理也更复杂。如果确实需要分流，正确做法是一套 hbbs + 多个 hbbr，在 hbbs 启动参数里指定多个中继地址，让不同区域的客户端就近中继；具体多中继参数的写法以官方文档和 --help 为准，不要凭记忆硬写。

七、客户端配置与 Key 强制：把安全底裤穿上

服务端通了只是第一步。企业环境里如果不强制 Key，相当于把中继服务器变成公共设施——任何人只要知道你的 IP，填上地址就能注册设备、发起连接。安全配置必须做，而且要下发到位。

第一步，服务端强制 Key。 hbbs 和 hbbr 启动时都带 -k _（或显式指定密钥文件），程序会自动生成密钥并拒绝无 Key 的客户端。两个进程必须共用同一数据目录，Key 才能一致。

第二步，客户端填齐四项。 ID 服务器、中继服务器（同机可留空）、Key 三项必填。Key 是 id_ed25519.pub 的完整内容，复制时注意不要带空格、换行或引号，粘贴后保存重启客户端生效。

第三步，批量下发。 几十上百台设备不能一台台手填。Windows 客户端支持通过配置文件或安装包预置参数的方式批量部署，也可以在域环境里用组策略推配置文件；Linux 客户端直接下发配置文件到用户目录。具体文件路径和字段名以客户端版本为准，建议先在一台机器上手动配置成功，再把生成的配置文件作为模板下发——这是最稳妥的做法。

第四步，设置访问密码与权限。 每台被控端设置固定密码，密码强度按企业口令规范执行；关闭不需要的功能（如文件传输、剪贴板同步、语音），尤其在对外的工控机、收银机上，避免数据外带。需要更细的管控时，在客户端安全设置里限制允许发起连接的来源 IP 段，把权限收敛到运维网段。

八、安全加固清单（照着勾）

自建中继最大的风险不是 RustDesk 本身，而是暴露在公网的服务端被滥用。以下配置建议逐项确认。

1. 强制 Key。 hbbs/hbbr 都带 -k 参数，客户端无 Key 无法注册。这是第一道也是最重要的一道门。

2. 最小端口暴露。 不用 Web 客户端就关闭 21118、21119；不用授权版 API 就关闭 21114。只暴露 21115、21116、21117 三类必需端口。

3. 服务端最小权限。 Docker 容器不要用 privileged，数据目录权限收紧；VPS 上只开放必要端口，SSH 改密钥登录并限制来源 IP。

4. 源地址收敛。 如果能确定控制端所在网段（比如只允许公司出口 IP、只允许 VPN 网段），在云安全组或防火墙层做白名单，把 21116、21117 的访问来源限制住。这是比任何软件配置都硬的管控手段。

5. 监控与日志。 定期检查 hbbs 日志中的设备注册记录，异常 ID 大量出现、异地 IP 反复尝试连接，都是被扫描或滥用的信号。VPS 侧建议开启连接数告警。

6. 版本与镜像来源。 只使用官方镜像与官方发布的客户端，不要用来源不明的”定制版”安装包。自建服务的优势就是可控，装个来路不明的客户端等于白建。

7. 备份数据目录。 id_ed25519 私钥、公钥、数据库都在数据目录里。丢了私钥，所有客户端失联；被人拿走私钥，等于拿到中继通行证。备份要加密存放，不要放在公开网盘。

九、性能调优与常见故障排查

部署完成后，体验好坏主要看三件事：是否走了中继、中继带宽够不够、画质与编码设置合不合理。

判断是否走了中继。 客户端连接建立后，会话信息里会显示连接方式（直连或中继），延迟数值也能反映问题：同城中继一般 10-30ms，跨省 40-80ms，如果超过 150ms 基本可以确认链路绕远或带宽拥塞。中继模式下，服务器带宽跑满是导致卡顿的最主要原因。

画质与编码。 RustDesk 提供流畅、均衡、高清等画质档位，以及自适应码率选项。跨地域或带宽紧张时，把画质降到”流畅”、关闭”显示远端光标特效”、限制帧率，主观体验提升往往比升级带宽更明显。批量运维场景（看日志、点按钮）不需要高画质，把码率按住能显著提高并发数。

带宽估算。 单路办公桌面 1-3 Mbps，设计类、视频监控类画面 4-8 Mbps，按并发峰值乘 1.5 的余量规划。注意企业宽带的上行通常只有下行的十分之一，用总部做中继时一定要看上行。

现象	最可能原因	处理
客户端一直”未就绪”，拿不到 ID	hbbs 的 21116（尤其 UDP）未通，或 Key 填错	查端口映射含 UDP、查 Key 与数据目录是否一致
能拿到 ID 但连接超时	21117 中继端口未映射/未转发，打洞又失败	打通 21117 TCP，确认 hbbr 进程在跑
连接成功但画面很卡、拖影	走了中继且中继带宽不足	降画质/码率，扩中继带宽，就近部署 hbbr
昨天正常今天全部连不上	内网设备重启后 frpc/容器未自启，或公网 IP 变了	配置开机自启，改用域名 + DDNS
部分分支能连、部分不能	分支出口封锁 UDP 或 NAT 类型不同	该分支改走中继，检查分支防火墙策略
提示密钥不正确 / 校验失败	Key 复制带了空格换行，或 hbbs 重建导致 Key 变更	重取 id_ed25519.pub 原文，检查数据目录是否被重置

十、自建中继、授权版与商业远控的选型对比

最后说选型。RustDesk 的开源核心（hbbs/hbbr/客户端）完全免费，可以自建、可以内网闭环，这是它相对商业远控最大的价值。官方同时提供完整授权版，包含自建 API、定制客户端品牌、Web 客户端与管理能力，并且可以直接使用官方全球中继节点，适合没有带宽条件、又需要对外交付的 IT 服务商和集成商——自己搭中继再对外交付，一旦客户量上来，带宽和稳定性会成为长期负担，用授权版等于把这部分运维转交出去。

维度	自建开源中继	完整授权版	商业远控软件
数据归属	完全自有，可内网闭环	自有为主，中继可用官方节点	经厂商云，需评估合规
带宽成本	自付，按并发规划	随授权方案	含在订阅费中
内网无公网 IP	需 frp/VPN 自行解决	仍建议 VPN 或穿透	开箱可用
运维投入	高，需专人维护端口与带宽	中	低
适用对象	有 IT 能力、重视数据自主	集成商/服务商对外交付	小团队快速上线

我的建议很直接：十台以内、内网闭环诉求强，用自建开源中继 + frp/VPN；几十台以上、要对外交付给客户、自己没有稳定带宽资源，用完整授权版；如果只是临时远程几台电脑、对数据合规无要求，商业远控最省事。企业选型的核心永远是”数据在哪里、责任由谁承担”，把这两点想清楚，方案自然就定了。

落地时还需要注意几件事：中继服务器要做成”基础设施”来管——固定内网 IP、纳入监控、配置开机自启、数据目录定期备份、变更记录留档；客户端配置下发前先在测试机验证一遍 Key 与中继地址；跨省市分支机构优先就近部署 hbbr，而不是把所有流量压到一台机器上。把这套中继搭好之后，它不只服务远程桌面，后续的远程巡检、批量运维、甚至给客户做远程支持，都能复用同一套入口。

十一、官方参考（发布前请实时核对）

RustDesk 与 frp 迭代较快，端口参数、镜像标签、配置字段名都可能随版本变化。以下页面建议在实施前逐个打开确认，本文内容以官方页面为准：

1. RustDesk 自建服务器总览：https://rustdesk.com/docs/zh-cn/self-host/

2. RustDesk 安装与端口说明：https://rustdesk.com/docs/zh-cn/self-host/install/

3. RustDesk 客户端配置（ID/中继/Key）：https://rustdesk.com/docs/zh-cn/self-host/configure/

4. RustDesk 服务端仓库（Docker 命令与参数）：https://github.com/rustdesk/rustdesk-server

5. RustDesk 授权与版本对比：https://rustdesk.com/pricing/

6. frp 中文文档（frpc/frps 配置语法）：https://github.com/fatedier/frp/blob/dev/README_zh.md

7. frp 官方示例配置：https://github.com/fatedier/frp/tree/dev/conf

以上参数我按官方文档的逻辑梳理，但不同版本存在差异，实施时以你所用版本的 --help 输出和官方页面为准。

结语

企业内网搭 RustDesk 中继，真正需要想清楚的只有三件事：网络能不能打洞（决定要不要 frp）、中继放在哪里（决定带宽和延迟）、Key 和端口开了多少（决定安全边界）。把这三件事定下来，剩下的就是按端口清单逐一打通、按加固清单逐项确认。自建的价值不在于省钱，而在于数据走自己的链路、权限握在自己手里——这也是越来越多企业把远程控制从 SaaS 收回到内网的原因。

如果你的企业有多分支机构、无公网 IP、又需要把远程运维做成可交付的服务，欢迎联系我们做一次网络与方案梳理，我们会按你的实际出口条件给出拓扑建议，而不是套模板。