RustDesk 私有化高可用部署双信令节点加四层负载均衡落地【免费下载链接】rustdeskAn open-source remote desktop application designed for self-hosting, as an alternative to TeamViewer.项目地址: https://gitcode.com/GitHub_Trending/ru/rustdesk凌晨一点告警群弹出信令服务器无响应客户端开始成批报连接服务器失败——单台自建 RustDesk 信令/中继服务器宕机所有远程会话同时断开。本文给出可落地的方案2 台无状态 RustDesk 信令/中继服务器 1 台四层负载均衡客户端填双 IP 自动切换从克隆仓库到验证会话约 20 分钟。部署全景图信令双节点加四层负载均衡图 1客户端首页ID 由信令服务器签发[RustDesk 客户端 xN] | 信令 UDP 21116 / TCP 21117中继 TCP 21118 [ nginx stream 四层负载均衡 ] | | [rustdesk-server A] [rustdesk-server B] [ relay 中继节点独立只挂 21118]客户端负责会话建立与 P2P 打洞负载均衡层做四层转发无状态信令/中继服务器无本地状态任意一台可承接新会话这是双机切换的前提relay 节点独立部署避免信令故障连带拖死在途流量。前置准备2C4G 起与端口清单2 台 2C4G Linux 服务器Ubuntu 20.04 或 Debian 111 台 nginx 负载均衡机可复用其中一台端口UDP21116信令、TCP21117备用信令、TCP21118中继转发构建机需要 Rust 工具链、vcpkg 及libvpx libyuv opus aom编译依赖见仓库 Dockerfile 的依赖清单客户端版本与服务端版本保持同一主线跨大版本可能协议不兼容克隆源码并编译客户端git clone https://gitcode.com/GitHub_Trending/ru/rustdesk cd rustdesk cargo build --release--release全量编译约 15~30 分钟产物落在target/release/供下一步 systemd 路径引用核心部署步骤从防火墙到双节点切换开放信令与中继端口的防火墙配置服务器防火墙ufw allow 21116/udp # 信令主通道P2P 打洞 ufw allow 21117/tcp # 信令备用通道 ufw allow 21118/tcp # 中继转发 ufw enableUDP21116不通时打洞协商无法进行TCP21117是 UDP 受阻时的兜底信令TCP21118承载所有 P2P 失败流量的中转部署 RustDesk 服务单元并开启自动拉起服务单元模板在res/rustdesk.service不要整篇照抄——官方模板缺Restart行⚠️ 进程崩溃后 systemd 默认不会拉起按下面三处改完再装[Service] ExecStart/opt/rustdesk/rustdesk --server Restartalways RestartSec3 LimitNOFILE100000ExecStart指向二进制真实路径装错路径服务起不来RestartalwaysRestartSec3异常退出 3 秒后自动拉起LimitNOFILE决定单机可承载的并发会话上限配置 nginx 四层负载均衡与中继粘滞编辑 nginx 配置在events块后加入stream { upstream sig_udp { server 10.0.0.11:21116; server 10.0.0.12:21116; } upstream sig_tcp { server 10.0.0.11:21117; server 10.0.0.12:21117; } upstream relay { server 10.0.0.13:21118; server 10.0.0.14:21118; hash $remote_ip consistent; } server { listen 21116 udp; proxy_pass sig_udp; } server { listen 21117; proxy_pass sig_tcp; } server { listen 21118; proxy_pass relay; } }信令 UDP/TCP 做普通轮询连接短命、无状态中继hash $remote_ip consistent同一会话必须粘滞在固定节点漂移即断流consistent保证节点增减时大部分哈希桶不动存量会话不迁移在客户端填入双节点地址完成接入客户端设置页的自定义中继服务器分别填10.0.0.11:21117、10.0.0.12:21117与对应中继地址IP 列表两个节点都填客户端会自动完成切换。验证链路sudo nginx -s reload systemctl status rustdesk-server ss -lntu | grep -E 2111[6-8]图 2远程会话建立后的文件传输页关键参数深度解读最容易配错的三处将 LimitNOFILE 调到 100000 防 fd 耗尽默认值systemd 默认1024推荐值100000res/rustdesk.service模板中的取值为什么每个远程会话占用多个 fd——视频流、音频、剪贴板、文件传输通道各占一份并发 500 台设备时1024上限会被快速吃满新连接在握手阶段就被拒100000基本不会触发上限。中继端口 21118 的定位兜底通道而非主路默认值relay 监听21118推荐值保持不变为什么P2P 打洞成功时客户端之间直连中继不走流量打洞失败才经21118中转。中继节点带宽按预期走中继的流量规划通常是全量的零头把它当主路规划会白白多买带宽。把 Restart 设为 always 并保留 3 秒间隔默认值systemdRestartno推荐值RestartalwaysRestartSec3为什么进程被 OOM killer 或段错误杀掉后no意味着 systemd 不再拉起要等人工发现而会话已经断了RestartSec3给 3 秒缓冲避免进程反复崩溃时的重启风暴。故障诊断路径从连接失败现象逐级定位现象客户端卡在正在连接信令服务器。先查服务是否还活着——systemctl status rustdesk-server已退出就journalctl -u rustdesk-server -n 50看崩溃前最后几行OOM 记录里会写明被杀的时机再查端口是否真的在监听——ss -lntu | grep 21117端口没起来通常是进程异常退出端口在但客户端连不上则是网络问题最后从客户端侧抓包——tcpdump -i any port 21116 or port 21117包发出去了收不到回应问题在中间链路安全组、NAT把 UDP 丢了此时改用 TCP 21117 兜底。现象信令通了但延迟高、流量走了中继。在 relay 节点上同时抓两个端口tcpdump -i any port 21118 or port 21116 -n媒体流全在21118而21116上几乎没有打洞流量说明 P2P 长期失败常见根因是客户端侧对称型 NAT打洞成功率极低可在客户端设置里启用disable-udp让信令强制走 TCPsrc/lang/cn.rs中有该选项的说明文案打洞成功率下降换的是连接建立的稳定性生产环境建议按规模选边界信令双机 四层负载均衡单台宕机时客户端切到另一台全程不断信代价是两台都要预留完整会话容量平时利用率约 50%relay 节点独立部署不要把信令和中继塞进同一个进程或容器信令挂了不该连带拖死在途流量代价是多占一台 2C4G客户端填双节点 IP 列表切换由客户端本地完成对业务无感代价是每个节点都要持有完整设备密钥中继带宽按中继流量预留别按全量买实际 P2P 成功的会话不经它代价是 P2P 失败比例突增时会出现排队这套方案适合几十到几百台被控设备的私有化部署单机房或双机房都够用一旦需要账号体系、Web 管理台或多租户隔离应升级到商业版 Server Pro再往上按 K8s 加多可用区规划本文的单机 systemd 方案就不适用了。【免费下载链接】rustdeskAn open-source remote desktop application designed for self-hosting, as an alternative to TeamViewer.项目地址: https://gitcode.com/GitHub_Trending/ru/rustdesk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考