内网里做远程协助最难受的从来不是连不上这一个问题而是连不上之后你还不知道卡在哪一层。我这几年前前后后在办公网、机房隔离区、车间工控网里折腾过不少远程方案最后留在工具箱里反复用的是自建一套 RustDesk 服务端。它把 ID 注册和中继转发这两个环节交到你自己手里客户端装的还是那个熟悉的界面但流量全程不出内网跨网段也能通配好之后基本不用再管。这篇就把内网里用 RustDesk 做远程协助这件事从头拆一遍为什么值得自己搭、服务端两个组件 hbbs 和 hbbr 各自干什么、端口怎么规划、Docker 和二进制两种部署方式怎么落地、客户端怎么填参数、断线卡死怎么排查。刚接触的可以照着抄命令已经有环境在跑的可以直接跳到端口规划、离线部署和排查那几节那些才是真正耗时间的地方。1. 内网搞远程协助为什么最后选了自建 RustDesk1.1 内网远程协助的真实痛点先说清楚场景。绝大多数内网远程协助的需求本质上就三类一是运维要连服务器和办公机做故障处理二是技术支持要连同事的电脑看问题三是生产线、实验室、值班室这类地方的终端需要有人远程盯着。这三类需求有个共同点——被控端和主控端往往都在同一个大内网里或者至少在一个能被内网路由打通的范围内。这时候用商业远程工具就会碰到一堆别扭事。第一是登录环节很多工具要账号体系账号要走公网认证内网一断就废第二是流量路径画面数据经常被绕到厂商的公网节点转一圈再回来本来两台机器就在同一个交换机下愣是绕出几十毫秒延迟第三是合规和审计数据出了内网这件事在很多环境里根本过不了评审。RustDesk 的价值就在于它把服务端这个东西开源出来了。官方提供两个可执行程序一个叫 hbbs负责 ID 注册和心跳你可以理解成通讯录一个叫 hbbr负责在两端打不通直连的时候帮忙转发数据你可以理解成中转站。这两个程序往内网任意一台服务器上一放客户端把地址指过去整条链路就完全闭环在自己的网络里了。1.2 RustDesk 的自建架构到底跑在哪几层很多人第一次配的时候是懵的因为客户端设置页里有两个输入框ID 服务器和中继服务器。搞不清这两个是什么关系就会出现填了 ID 服务器还是连不上的情况。我一般这么解释ID 服务器是介绍人中继服务器是传话筒。两台客户端启动后先连上 ID 服务器报到告诉它我叫这个号我在这个 IP 和端口上。主控端要连某个号时先问 ID 服务器这个号在哪然后尝试直接连过去。如果两边的网络环境允许比如同一个网段、或者 NAT 类型比较友好数据就直接点对点走这时候中继服务器完全不参与速度是局域网级别的。只有当直连打不通——比如两边在不同 VLAN 且中间有严格策略、或者一方在多层 NAT 后面——才会回落到中继模式数据从 A 发给中继服务器中继服务器再转给 B。这时候速度取决于中继服务器所在的网络位置和它的上行带宽。所以一个常见误区是我配了中继就万事大吉实际上中继是兜底能直连才应该有最好的体验。理解了这一层配置逻辑就顺了ID 服务器必须填对这是硬性前提中继服务器可以不填客户端会自动用 ID 服务器地址加固定端口去尝试但如果你的中继单独部署在别的机器上就必须显式填。1.3 直连与中继决定体验的关键那一步我在一个跨三个网段的环境里实测过办公网 10.10.x.x、测试网 10.20.x.x、机房管理网 10.30.x.x三张网之间有路由但没有做任何 NAT 转换防火墙默认放行内网互访。这种情况直连成功率极高两台机器协商出直连后画面几乎是即时的传大文件也能跑到百兆网卡的线速。换了另一个环境办公网和车间网之间隔了一道做源地址转换的边界设备直连就基本协商不上了全部回落到中继。这时候中继服务器放在办公网一侧车间那台机器连上来之后画面在 1080p 下大概占用 3 到 8 Mbps操作有轻微延迟但可以接受需要传大文件的时候会明显变慢。这里有个经验值可以记一下中继模式下普通办公操作文档、表格、网页大概 1 到 3 Mbps 就够看视频或者拖窗口会有明显掉帧需要 5 Mbps 以上如果要做设计类的工作老实说远程方案都不太合适。所以规划中继服务器的时候我一般按同时在线的中继会话数 × 4 Mbps来估算上行带宽20 个人同时在线就预留 80 Mbps。2. 动手前的准备与方案选型2.1 服务器配置怎么估RustDesk 服务端本身极轻。hbbs 主要处理注册和心跳几乎不吃 CPUhbbr 做的是数据转发吃的是网络 IOCPU 占用和并发流量成正比但也很有限。我在一台 2 核 4G 的虚拟机上跑过 30 人规模的日常使用CPU 长期在 5% 以下内存占用两百多兆真正需要关注的是网络带宽和文件描述符上限。给几个参考档位使用规模CPU内存带宽说明10 人以内基本直连1 核1 GB10 Mbps最低配够用中继偶发30 人左右部分走中继2 核2 GB50 Mbps最常见的内网配置100 人以上或大量中继4 核4 GB200 Mbps 起建议 hbbs 与 hbbr 分开部署有个容易忽略的点是文件描述符。Linux 默认 1024中继并发一多就会报 too many open files表现是连接随机断开、重连。所以不管什么规模我上来先改 limits后面 systemd 那节会给出配置。2.2 端口与网络规划这张表建议直接存下来跟网络同事沟通的时候照着开就行别背端口协议所属组件用途是否必需21114TCPhbbsWeb 控制台/接口部分版本提供否21115TCPhbbsNAT 类型检测是21116TCPhbbsID 注册与心跳TCP 通道是21116UDPhbbsID 注册与心跳UDP 通道是21117TCPhbbr中继数据转发是21118TCPhbbsWeb 客户端访问可选否21119TCPhbbrWeb 客户端访问可选否必须放行的其实就四个21115/TCP、21116/TCP、21116/UDP、21117/TCP。我见过太多配了半天连不上的案例最后都是 21116 的 UDP 那一条没开——TCP 通了你看着像是好了但心跳走 UDP 不通客户端就会一直转圈。地址规划上我通常把 hbbs 和 hbbr 放在同一台机器上省事共享密钥方便IP 选一个所有目标网段都能路由到的地址。如果公司有内部 DNS给它配个 A 记录比如 rd.内网域名客户端填域名比填 IP 好维护将来换机器只改解析。注意不要把服务端 IP 规划成只有某个网段能访问的地址。一旦客户端填了这个地址而它恰好不可达客户端会表现为未就绪而且不会告诉你是网络问题还是配置问题。2.3 三种部署形态选哪个实际可选的路径有三条各有适配场景Docker 部署最省事两条命令起服务适合有容器环境、追求快速验证的团队。缺点是排错时要多穿透一层日志和密钥文件都在容器卷里新手容易找不到 id_ed25519.pub 在哪。另外 Docker 下强烈建议用 host 网络模式原因后面细说。二进制 systemd最适合内网长期维护。没有额外依赖开机自启日志进 journald升级就是替换文件重启服务。尤其是完全离线的环境Docker 镜像还得导入导出二进制压缩包拷过去解压就能跑明显更舒服。自己编译只在一种情况下有必要你需要定制客户端把服务器地址和公钥预置进去做分发。这个后面 4.3 会讲。日常部署没必要从源码编服务端构建环境依赖一堆收益为零。我的默认建议是先在测试机上用 Docker 十分钟验证服务端能起来、客户端能连上确认端口和密钥没问题之后再在生产机上用二进制 systemd 落地。这样排错成本最低。3. 服务端部署全流程实操3.1 Docker 一把梭hbbs 与 hbbr先把目录建好两个组件分别挂一个卷主要是为了让密钥文件持久化——容器删了重建如果密钥丢了所有客户端都要重新填一遍很麻烦。mkdir -p /data/rustdesk/hbbs /data/rustdesk/hbbr启动 hbbs假设本机内网 IP 是 10.10.20.15docker run --name hbbs \ --nethost \ --restartalways \ -v /data/rustdesk/hbbs:/root \ -d rustdesk/rustdesk-server hbbs -r 10.10.20.15启动 hbbrdocker run --name hbbr \ --nethost \ --restartalways \ -v /data/rustdesk/hbbr:/root \ -d rustdesk/rustdesk-server hbbr这里有几个点值得单独说明。--nethost的意思是容器共享宿主机网络栈。用它的原因是 21116 的 UDP 端口在部分 Docker 版本和宿主机内核组合下用-p映射会出现丢包或者不稳定表现为客户端能注册上去但心跳断断续续。用 host 模式最省心。但要清楚一个副作用host 模式下-p参数是无效的写了也不生效别以为两样都配上就双保险了——这是我在一个环境里排查了两小时才发现的问题当时一直以为是端口没映射对实际上是映射根本不起作用而 host 模式本身已经把所有端口暴露了。-r 10.10.20.15这个参数是告诉客户端中继服务器在这个地址。填了它客户端即使用户没手动配中继也能自动用这个地址走中继。如果 hbbr 部署在另一台机器上这里就填那台的 IP。如果你确实要用桥接网络比如宿主机上还有别的容器要隔离端口命令就得改成显式映射docker run --name hbbs \ -p 21115:21115 -p 21116:21116 -p 21116:21116/udp -p 21118:21118 \ --restartalways \ -v /data/rustdesk/hbbs:/root \ -d rustdesk/rustdesk-server hbbs -r 10.10.20.15桥接模式下还要注意一点容器内的服务监听的是 0.0.0.0映射到宿主机后外部访问的地址就是宿主机 IP这个没问题。但如果你还做了端口转发或者反向代理转发规则要保证 UDP 也能过去很多代理只处理 TCP一过代理 UDP 就废了。3.2 二进制 systemd适合离线与长期维护从项目的发布页下载对应架构的压缩包一般是rustdesk-server-linux-amd64.zip这种命名解压出来就是 hbbs 和 hbbr 两个可执行文件。整个过程不依赖网络包拷进去就行。mkdir -p /opt/rustdesk cd /opt/rustdesk unzip rustdesk-server-linux-amd64.zip chmod x hbbs hbbr先手动跑一次确认能起来并且生成密钥./hbbs -r 10.10.20.15看到日志里出现类似 Key: 和一段公钥内容就说明密钥文件id_ed25519和id_ed25519.pub已经在当前目录生成了。按 CtrlC 停掉写 systemd 单元。/etc/systemd/system/hbbs.service[Unit] DescriptionRustDesk hbbs (ID server) Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple WorkingDirectory/opt/rustdesk ExecStart/opt/rustdesk/hbbs -r 10.10.20.15 Restartalways RestartSec5 LimitNOFILE1000000 [Install] WantedBymulti-user.target/etc/systemd/system/hbbr.service[Unit] DescriptionRustDesk hbbr (relay server) Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple WorkingDirectory/opt/rustdesk ExecStart/opt/rustdesk/hbbr Restartalways RestartSec5 LimitNOFILE1000000 [Install] WantedBymulti-user.targetLimitNOFILE1000000这一行是必须的。默认值太小中继并发一上来就报文件描述符耗尽连接会莫名其妙断掉而且日志里不一定有直观提示极易误判成网络抖动。启用并启动systemctl daemon-reload systemctl enable --now hbbs hbbr systemctl status hbbs hbbr这里有个细节二进制方式下hbbs 和 hbbr 放在同一个目录会自动共享同一对密钥文件。如果把 hbbr 放到另一台机器上一定要把 hbbs 目录下的id_ed25519和id_ed25519.pub两个文件都拷过去否则中继用的密钥跟 ID 服务器不一致客户端走中继时会被拒绝。这个坑我在一个双机部署的环境里踩过表现是直连正常、一中继就失败日志里只看到握手失败不告诉你是密钥问题。3.3 公钥怎么取、怎么校验客户端在新版本里要求在Key字段填公钥内容不填或者填错就注册不上。取法很简单cat /opt/rustdesk/id_ed25519.pubDocker 部署的话cat /data/rustdesk/hbbs/id_ed25519.pub输出的是一长串 base64 字符比如xxxxxxx...这种形式整串复制前后的换行不要带进去。校验这一步别省。我一般的做法是取完公钥之后在服务端机器上先自测一下端口通不通ss -lntup | grep -E 21115|21116|21117正常应该看到 hbbs 监听 21115、21116TCP 和 UDP 都有hbbr 监听 21117。如果 UDP 那条没出现说明 hbbs 启动参数有问题或者被什么占用了先解决这个再往下走不然客户端一定连不上。还可以用 telnet 或者 nc 从另一台机器验证 TCP 通不通nc -zv 10.10.20.15 21115 nc -zv 10.10.20.15 21116 nc -zv 10.10.20.15 21117三条都通网络层面就没问题了。UDP 没法用 nc 简单验证只能靠客户端实际连一次看结果。3.4 防火墙与系统层放行内网服务器上通常有三层拦截系统自带的 firewalld 或 ufw、云平台的或虚拟化层的安全组、以及网络设备上的 ACL。三层都要过少一层都白搭。firewalld 的放行方式firewall-cmd --permanent --add-port21115/tcp firewall-cmd --permanent --add-port21116/tcp firewall-cmd --permanent --add-port21116/udp firewall-cmd --permanent --add-port21117/tcp firewall-cmd --reload firewall-cmd --list-portsufw 的话ufw allow 21115/tcp ufw allow 21116/tcp ufw allow 21116/udp ufw allow 21117/tcp ufw status numbered如果这台机器上还跑着别的服务建议不要图省事直接关防火墙。我见过有人图快systemctl stop firewalld然后忘了开回来机器在网里裸奔了几个月。另外 Windows 服务端虽然少见但确实有人把 hbbs 跑在 Windows Server 上需要单独的入站规则而且 Windows Defender 防火墙默认对 UDP 的处理跟 TCP 不一样容易漏。图形界面里高级安全 Windows Defender 防火墙→ 入站规则 → 新建规则 → 端口四个端口一条一条加或者用 PowerShellNew-NetFirewallRule -DisplayName RustDesk ID TCP -Direction Inbound -Protocol TCP -LocalPort 21115,21116,21117 -Action Allow New-NetFirewallRule -DisplayName RustDesk ID UDP -Direction Inbound -Protocol UDP -LocalPort 21116 -Action Allow3.5 客户端配好并验证第一次连接客户端装好之后打开设置 → 网络会看到 ID 服务器、中继服务器、Key 三个输入框。填法就是ID 服务器填10.10.20.15或者你配的内网域名中继服务器留空因为 hbbs 启动时用-r指定了客户端会自动拿Key 填刚才 cat 出来的那串公钥。填完点应用返回主界面。主界面右下角会显示一个状态正常应该是就绪。如果显示未就绪请检查网络连接先别急着改配置按这个顺序看服务端进程在不在、端口通不通、Key 填没填错、客户端版本和服务端版本差多少。验证连接的时候我一般做三步第一步同一台机器上装两个客户端实例或者一台虚拟机互相连一次确认服务端和客户端配置本身是通的。这一步排除了配置问题。第二步跨网段连接确认网络策略允许。这一步排除了 ACL 和路由问题。第三步传一个几百兆的文件看速度顺便判断走的是直连还是中继。直连速度应该接近千兆网线速百兆到几百兆每秒中继速度会明显低一个档次几兆到几十兆每秒。这个判断比看界面上的连接方式显示更靠谱。提示客户端版本和服务端版本尽量保持在相近的代际。新版本客户端对加密的要求更严格服务端版本太老可能出现密钥对不上、握手失败的情况而且错误提示往往不直观。我一般建议服务端取一个稳定的较新版本客户端跟着服务端走别单独升级一端。4. 内网环境下的进阶配置与调优4.1 完全离线内网的部署与版本升级有些环境是彻底断网的连补丁都要走摆渡。这种环境下 RustDesk 一样能用关键是所有东西都要提前准备齐全。需要准备的东西清单服务端二进制压缩包对应服务器架构注意是 amd64 还是 arm64、客户端安装包Windows 的 exe/msi、Linux 的 deb/rpm 或 AppImage 各来一份、以及一份部署文档。别小看最后一项换个人来接手没有文档就得重新摸一遍。部署时有个小技巧先在一台能上外网的机器上把所有包下载齐打个压缩包用 U 盘拷进去。客户端装完之后不需要立刻联网直接进设置填地址和 Key 就能用。RustDesk 客户端在首次启动时可能会尝试一些网络请求但离线状态下不影响核心功能最多是某些在线服务不可用远程控制本身完全正常。升级策略上我倾向于服务端先动客户端后动。因为服务端换了密钥或者换了版本之后老客户端可能就连不上了。稳妥的做法是选一个低峰时段先把服务端升级并保持密钥文件不变密钥文件不换客户端就不用改配置验证几个关键机器能正常连再分批推客户端。密钥文件不变这一点特别重要。升级时只替换可执行文件id_ed25519和id_ed25519.pub原样保留这样所有已配置的客户端都无感。我见过有人图干净把整个目录删了重装结果全公司客户端集体连不上还得挨个重新填 Key。4.2 跨网段、多层 NAT 下的中继策略内网跨网段的场景里影响最大的是中间有没有做源地址转换。如果只是三层路由打通、策略放行那大概率能直连体验最好。一旦中间有 NAT直连的握手就很容易失败。这种情况下我一般做两个动作。第一个是把 hbbr 部署在中间位置。什么意思如果 A 网段的机器和 B 网段的机器都要连那中继放在一个双方都能低延迟访问的位置比如核心交换区或者两个网段都能路由到的服务器区。别把中继放在某一个末端网段里那样另一个网段的所有中继流量都要经过骨干绕一圈延迟和带宽都不好看。第二个是显式指定中继地址。虽然 hbbs 的-r参数能让客户端自动获取但在复杂网络里我倾向于在客户端手动填中继地址把控制权握在手里。因为一旦将来 hbbs 换了位置或者-r参数改了手动填了的客户端不受影响。还有一种情况是内网里有多个隔离区彼此完全不互通。这种时候就只能在每个区各部署一套服务端用不同的 ID 服务器地址。客户端配置是跟着网络环境走的跨区的人配两套也没用因为一次只能填一个地址。实际上这时候更现实的方案是在每个区内部解决远程协助需求而不是追求一套打通所有区。中继的性能还有一个隐性瓶颈是并发会话数。hbbr 是单进程转发理论上能撑很多并发但实际受限于网卡和 CPU。我在一台 2 核机器上压测过20 个并发中继会话每路大约 4 Mbps时 CPU 大概 30%40 个并发开始出现零星卡顿。所以规模上去之后要么加机器做多套服务端要么升级网卡和 CPU。4.3 无人值守、批量预置配置内网远程协助里无人值守是个高频需求——被控端在机房或者车间没人会去点接受。这个在 RustDesk 里靠两件事实现安装为系统服务开机自启以及设置固定的访问密码。安装层面Windows 客户端在安装时可以选择安装为服务或者在设置里勾选开机启动使用系统服务。Linux 端则是把客户端装成服务用 systemd 管理。Mac 上需要授权屏幕录制和辅助功能权限这一步必须人工点没法绕过。固定密码在设置 → 安全里配置设好之后主控端直接输 ID 和密码就能连不需要被控端确认。这个功能很实用但也意味着密码就是唯一的门槛所以密码强度要够而且别用全公司统一的弱密码。批量部署的时候逐个填地址和 Key 太蠢。RustDesk 客户端会把配置写在本地文件里Windows 下大致在用户的 AppData 目录下有一个配置文件Linux 下在用户目录的 .config 里具体路径不同版本略有差异建议先在测试机上配好一份然后把那个配置文件搜出来看内容照着做模板。更规范的做法是定制客户端。项目本身提供了定制化构建的脚本可以在编译时把 ID 服务器、中继地址、公钥甚至界面信息写死进去生成一个开箱即配好的安装包。内网规模超过几十台设备的时候这个投入是值得的省下来的沟通和返工成本远超构建时间。不过要注意定制客户端里写死的配置用户在界面里是看不到也改不了的这对统一管理是好事但对临时排障是障碍。所以我的做法是保留一个标准版客户端在运维手里定制版只发给普通用户。4.4 安全加固把口子收窄自建服务端的一个隐性风险是一旦这个服务端被内网之外的人摸到等于给了一条进入内网的通道。所以安全这块不能糊弄。第一层是网络位置。服务端只监听内网地址不要做公网映射。如果确实有出差人员在外的需求那属于另一个话题走专门的安全接入通道不要图省事把 21115-21117 直接开放出去。第二层是访问控制。如果服务端所在网段有 ACL 能力把 21115-21117 的访问来源限制在需要的网段范围内。这一条能挡掉大部分扫描和误连。第三层是密码策略。所有开启无人值守的机器密码单独设置长度足够定期更换。别用生日、别用设备编号这些在内部太容易猜。第四层是版本维护。开源软件的漏洞修复通常比较及时服务端和客户端保持在一个受支持的版本上别用几年前的老包。内网虽然相对封闭但一个内网里如果有几百台设备跑着同一个老版本一旦出问题就是面状的。还有一点容易被忽略连接日志。RustDesk 客户端有连接记录服务端日志也能看到注册和连接情况。定期翻一翻看看有没有异常的 ID 频繁尝试连接、有没有非预期网段的注册这比事后追溯有用得多。5. 常见问题与排查实录5.1 高频问题速查表把这几年的问题攒成一张表遇到问题先查表能省不少时间现象最可能的原因排查动作客户端显示未就绪请检查网络连接服务端没起 / 端口不通 / 地址填错服务端ss -lntup看监听客户端侧nc -zv测端口提示密钥不匹配或握手失败Key 填错 / 服务端与客户端版本代际差太多重新 cat 公钥逐字符比对两端版本对齐能注册但连不上对方对方未开机 / 对方客户端未就绪 / 防火墙拦了会话让对方看一眼自己界面状态试同网段互连直连一直协商不上全走中继中间有 NAT / ACL 严格接受中继或调整中继位置也可调整网络策略中继模式下卡顿明显中继上行带宽不足 / 中继机器负载高看中继机器网卡流量和 CPU扩容或分流连接随机断开文件描述符耗尽 / UDP 丢包调高LimitNOFILE检查 UDP 21116 质量服务重启后所有客户端要重配密钥文件被覆盖或丢失恢复id_ed25519备份或统一重发 Key中继单独部署后一中继就失败hbbr 缺密钥文件从 hbbs 目录拷id_ed25519和.pub过去开机后无人值守连不上客户端没装成系统服务检查服务状态改成服务模式安装传文件特别慢走的中继且带宽不足确认是否直连大文件建议走内网共享5.2 三个真实排查过程复盘案例一改完之后全公司连不上。某次例行维护有人把服务端机器重装了系统服务端重新部署密钥自然是新的。结果第二天一上班所有人反馈连不上界面提示密钥错误。原因很直接老客户端的 Key 是旧的。解决方式是把新公钥导出来但这样要挨个改客户端几十台设备人工改不现实。最后的做法是从备份里找回原来的id_ed25519和id_ed25519.pub覆盖回去重启服务客户端无感恢复。这次之后我在部署文档第一页加了加粗的一行字密钥文件必须单独备份重装系统前先备份。案例二只有某个网段连不上。现象很怪办公网 10.10 网段的机器一切正常测试网 10.20 网段的机器全部未就绪。服务端在同一台机器上地址是 10.10.20.15按理说 10.20 网段能路由到 10.10 网段。排查路径是这样走的先在 10.20 的机器上 ping 服务端通nc 测 21115通测 21116 TCP通测 21117通。四个端口都通那问题就不在网络层。回头查服务端日志发现有 10.20 网段客户端的注册请求进来但立刻被拒绝了。再往下看是服务端所在机器上的应用层访问控制列表只放行了 10.10 网段。这件事的教训是端口通不代表业务通。以后排查我都是先看服务端日志有没有请求进来如果有请求但失败问题就在服务端侧如果日志里干干净净问题在链路上。案例三卡顿换了三台机器都没解决。一个车间环境反馈远程操作卡得没法用怀疑是中继机器性能不行换了两台服务器还是一样。我过去看了一眼发现他们的网络拓扑是车间 → 汇聚 → 核心 → 服务器区中继放在服务器区。这条路径上每一跳都是千兆按理说不该卡。最后用抓包和流量统计发现卡的原因不是带宽是丢包。车间到汇聚那一段的链路质量有问题TCP 会重传UDP 直接丢表现出来就是画面撕裂和操作延迟。把中继挪到车间本地的接入交换机旁边之后问题立刻消失了——因为中继变近了丢包段被绕开了。这个案例说明一点中继位置的选择不是看哪台机器性能好而是看能不能避开质量差的链路。5.3 踩坑清单与实测参数建议最后整理一份我自己会照着做的清单都是踩过的密钥文件单独备份别放在服务端机器上服务端挂了备份也没了。hbbs 和 hbbr 分离部署时两个密钥文件都要拷只拷公钥不够私钥也得在。--nethost和-p不要同时写前者会让后者失效容易误导排错方向。LimitNOFILE一定要调这是最容易忽略又最影响稳定性的参数。UDP 21116 是隐形门槛只开 TCP 会出现看着通但老掉线的怪现象。客户端和服务端版本别差太远尤其是加密相关的行为在不同代际之间有变化。内网 DNS 记录比裸 IP 好维护换机器只改解析。定制客户端和标准客户端各留一份定制版给用户标准版给运维排障。中继放在链路质量好的位置不是放在性能最好的机器上。测试顺序固定为本机互连、同网段互连、跨网段互连逐层排除不要跳步。关于带宽我实测下来的参考值是普通办公远程操作在中继模式下 2 到 4 Mbps 比较舒服低于 1.5 Mbps 会有明显操作滞后文件传输如果走中继建议控制在几百兆以内更大的文件走内网文件共享更快。直连模式下基本不用担心带宽瓶颈在两端网卡。我个人在实际操作中的体会是这套东西真正的门槛不在技术在一次配好、长期别动。服务端部署两小时就能搞定但后续的密钥管理、版本对齐、配置文件分发才是决定这套方案能不能在内网里稳定跑三年的东西。所以我的建议是部署的时候多花半小时把文档和备份做好后面能少加很多班。