企业官网建设流程全解析

内网里做远程协助，最难受的从来不是"连不上"这一个问题，而是连不上之后你还不知道卡在哪一层。我这几年前前后后在办公网、机房隔离区、车间工控网里折腾过不少远程方案，最后留在工具箱里反复用的，是自建一套 RustDesk 服务端。它把 ID 注册和中继转发这两个环节交到你自己手里，客户端装的还是那个熟悉的界面，但流量全程不出内网，跨网段也能通，配好之后基本不用再管。这篇就把内网里用 RustDesk 做远程协助这件事从头拆一遍：为什么值得自己搭、服务端两个组件 hbbs 和 hbbr 各自干什么、端口怎么规划、Docker 和二进制两种部署方式怎么落地、客户端怎么填参数、断线卡死怎么排查。刚接触的可以照着抄命令，已经有环境在跑的，可以直接跳到端口规划、离线部署和排查那几节，那些才是真正耗时间的地方。

1. 内网搞远程协助，为什么最后选了自建 RustDesk

1.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 主要处理注册和心跳，几乎不吃 CPU；hbbr 做的是数据转发，吃的是网络 IO，CPU 占用和并发流量成正比，但也很有限。我在一台 2 核 4G 的虚拟机上跑过 30 人规模的日常使用，CPU 长期在 5% 以下，内存占用两百多兆，真正需要关注的是网络带宽和文件描述符上限。

给几个参考档位：

有个容易忽略的点是文件描述符。Linux 默认 1024，中继并发一多就会报 "too many open files"，表现是连接随机断开、重连。所以不管什么规模，我上来先改 limits，后面 systemd 那节会给出配置。

2.2 端口与网络规划

这张表建议直接存下来，跟网络同事沟通的时候照着开就行，别背：

必须放行的其实就四个：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.15：

docker run --name hbbs \ --net=host \ --restart=always \ -v /data/rustdesk/hbbs:/root \ -d rustdesk/rustdesk-server hbbs -r 10.10.20.15

启动 hbbr：

docker run --name hbbr \ --net=host \ --restart=always \ -v /data/rustdesk/hbbr:/root \ -d rustdesk/rustdesk-server hbbr

这里有几个点值得单独说明。

--net=host的意思是容器共享宿主机网络栈。用它的原因是 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 \ --restart=always \ -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已经在当前目录生成了。按 Ctrl+C 停掉，写 systemd 单元。

/etc/systemd/system/hbbs.service：

[Unit] Description=RustDesk hbbs (ID server) After=network-online.target Wants=network-online.target [Service] Type=simple WorkingDirectory=/opt/rustdesk ExecStart=/opt/rustdesk/hbbs -r 10.10.20.15 Restart=always RestartSec=5 LimitNOFILE=1000000 [Install] WantedBy=multi-user.target

/etc/systemd/system/hbbr.service：

[Unit] Description=RustDesk hbbr (relay server) After=network-online.target Wants=network-online.target [Service] Type=simple WorkingDirectory=/opt/rustdesk ExecStart=/opt/rustdesk/hbbr Restart=always RestartSec=5 LimitNOFILE=1000000 [Install] WantedBy=multi-user.target

LimitNOFILE=1000000这一行是必须的。默认值太小，中继并发一上来就报文件描述符耗尽，连接会莫名其妙断掉，而且日志里不一定有直观提示，极易误判成网络抖动。

启用并启动：

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.pub

Docker 部署的话：

cat /data/rustdesk/hbbs/id_ed25519.pub

输出的是一长串 base64 字符，比如xxxxxxx...=这种形式，整串复制，前后的换行不要带进去。

校验这一步别省。我一般的做法是取完公钥之后，在服务端机器上先自测一下端口通不通：

ss -lntup | grep -E '21115|21116|21117'

正常应该看到 hbbs 监听 21115、21116（TCP 和 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-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 firewall-cmd --list-ports

ufw 的话：

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 防火墙"→ 入站规则 → 新建规则 → 端口，四个端口一条一条加，或者用 PowerShell：

New-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 Allow

3.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 高频问题速查表

把这几年的问题攒成一张表，遇到问题先查表，能省不少时间：

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 分离部署时，两个密钥文件都要拷，只拷公钥不够，私钥也得在。
• --net=host和-p不要同时写，前者会让后者失效，容易误导排错方向。
• LimitNOFILE一定要调，这是最容易忽略又最影响稳定性的参数。
• UDP 21116 是隐形门槛，只开 TCP 会出现"看着通但老掉线"的怪现象。
• 客户端和服务端版本别差太远，尤其是加密相关的行为在不同代际之间有变化。
• 内网 DNS 记录比裸 IP 好维护，换机器只改解析。
• 定制客户端和标准客户端各留一份，定制版给用户，标准版给运维排障。
• 中继放在链路质量好的位置，不是放在性能最好的机器上。
• 测试顺序固定为：本机互连、同网段互连、跨网段互连，逐层排除，不要跳步。

关于带宽，我实测下来的参考值是：普通办公远程操作在中继模式下 2 到 4 Mbps 比较舒服，低于 1.5 Mbps 会有明显操作滞后；文件传输如果走中继，建议控制在几百兆以内，更大的文件走内网文件共享更快。直连模式下基本不用担心带宽，瓶颈在两端网卡。

我个人在实际操作中的体会是，这套东西真正的门槛不在技术，在"一次配好、长期别动"。服务端部署两小时就能搞定，但后续的密钥管理、版本对齐、配置文件分发，才是决定这套方案能不能在内网里稳定跑三年的东西。所以我的建议是：部署的时候多花半小时把文档和备份做好，后面能少加很多班。