Infrastructure Case
从商用订阅，到自建中转，再到端到端直连——外加一只 4G 插座补上最后的物理兜底
同一个需求被我重做了三遍：先用 ToDesk 把场景跑通，再用腾讯云上海轻量服务器自建 RustDesk 中转换回控制权，最后用 Tailscale 把中转节点整个去掉，让两台机器直接建立加密隧道。每一代解决上一代暴露的问题，也各自带来新的代价。终态是月度固定成本归零、没有带宽瓶颈、没有需要运维的公网服务；再给远端电脑配上 4G 远程插座 + BIOS 通电自启，让软件全部失效时仍有一条物理恢复路径，无人值守才算真正落地。
需求本身很朴素——人在外地，要能随时接管家里/办公点的那台电脑，跑任务、取文件、改配置。真正的难点不在「连上」，而在这几条同时成立的约束：
这是长期自用的基础设施，不能接受按坐席、按设备数逐年上涨的订阅账单。设备越加越多时，成本不应该跟着线性涨。
不只是看看桌面，还要实际操作 IDE、看日志、拖文件。帧率和清晰度一旦被中间环节的带宽掐住，远程就退化成「能看不能用」。
最怕的不是慢，是连不上：蓝屏、系统更新卡在重启、临时断电后没开机。此时所有远程软件同时失效，而现场没有人。
下面按代列出：做法、换来了什么、付出的代价、遗留问题——而每一代的遗留问题，正是下一代存在的理由。
开箱即用的托管方案 · 厂商云完成调度与中继
两端装客户端，设置固定密码开启无人值守，剩下的 NAT 穿透、中继调度、断线重连全部由厂商云托管。这一步的价值是先把场景跑通：验证「远程接管这台机器」这件事到底需要什么画质、什么响应速度、多久用一次，而不是一上来就造轮子。
自托管 hbbs / hbbr · 自持密钥 · 就近选点降低 RTT
在腾讯云上海轻量应用服务器上用 Docker 跑起 RustDesk 的两个服务端组件——hbbs（ID 注册与打洞协调）和 hbbr（中继转发），生成密钥对，把客户端的 ID / 中继服务器地址和公钥填成自己的，Windows 端安装为系统服务以便在登录界面也能接管。选上海而不是更便宜的其他区，是因为主控端与被控端都在华东：中转节点就近，RTT 才不会被绕路叠掉一倍。
hbbr，画质被服务器带宽上限掐死WireGuard 端到端加密 · 控制平面只分发密钥 · 开源免费
两端装 Tailscale 加入同一个 tailnet，基于 WireGuard 在两台机器之间直接建立加密隧道；控制平面只负责分发公钥和端点信息，业务流量根本不经过它，只有在极端 NAT 下打洞失败时才退到 DERP 中继兜底。组网之后，远程桌面改走 tailnet 内网地址（100.64.0.0/10 段）直连——用 RustDesk 的 IP 直连模式，或干脆直接 RDP/VNC。这一步的本质，是把「公网穿透问题」降级成了「局域网访问问题」：公网那一层的复杂度被整个绕开了。
三代方案的差别，一句话说清就是「业务流量要不要经过一个中间节点，以及那个节点归谁管、谁付带宽」。
连接调度与数据转发都在厂商云内完成。好处是几乎总能连上；代价是画质、并发和数据路径都不由自己控制。
打洞成功时是纯 P2P，服务器几乎不耗流量；一旦失败就全量回落到自建中继，画质直接由那台机器的带宽决定。
控制平面不碰业务流量，两端直接建隧道。少一个节点就少一处成本、少一处带宽瓶颈、少一处要维护的攻击面。
三代方案的成本形态完全不同：第一代是按设备数的经常性支出，第二代是固定月费 + 流量 + 运维时间，第三代把软件侧压到零，只剩一次性的硬件投入和一张物联网卡。
| 代际 | 方案 | 一次性投入 | 经常性支出 | 画质 / 带宽上限 | 单点风险 |
|---|---|---|---|---|---|
| 第一代 | ToDesk 商业订阅 | 无 | 按账号/设备年付，随设备数增长 | 由套餐档位决定 | 厂商云 |
| 第二代 | RustDesk 自建 + 腾讯云上海轻量 | 部署与调试时间 | 云服务器月费 + 中继流量 | 中继回落时 = 服务器带宽 | 自建中转服务器 |
| 第三代 | Tailscale 直连 + 4G 插座兜底 | 4G 远程插座（百元级） | 软件 ¥0 + 物联网卡年费（几十元级） | = 两端实际上行带宽 | 无自建中转；控制平面可自托管替换 |
关于数字：本表按当时所用套餐的量级口径对比，用于说明成本结构的变化而非精确报价——三家的价格都在变，真正稳定的结论是：第一代的成本随设备数增长，第二代把它换成了固定月费与带宽约束，第三代让软件侧的经常性支出消失，只留下一次性硬件。
软件做到第三代已经到头了，但所有远程软件都有一个共同前提——那台机器还活着、还联网。系统卡死、显卡驱动崩溃、Windows 更新卡在重启界面、临时停电后没有自动开机：这几种情况下三代方案会同时失效，而人在外地。服务器领域早就有答案（IPMI / iDRAC 这类带外管理），消费级电脑没有——所以我用一只插座把它补上了。
WiFi 智能插座依赖现场的路由器和宽带——而「路由器挂了 / 宽带断了」恰恰是需要兜底的故障之一，那样兜底通道会和主链路一起失效。
4G 插座自带物联网卡走蜂窝网络，与被控点的宽带完全独立，宽带断了、路由器死了、机器蓝屏了，它照样能收到断电/上电指令。这是整套方案里最关键的一个选型判断。
插座只解决「能不能上电」，剩下的要靠主板和系统配合成一条无人干预的链路：BIOS 把 Restore on AC Power Loss 设为 Power On，通电即自动开机；系统侧配置自动登录；Tailscale 与远程桌面都装成系统服务并开机自启，不依赖任何人在本地点一下。
三者缺一，远程重启就变成「断了电但起不来」——反而把小故障升级成必须到现场的大故障。
这条链路把「远程控制」从「能连上就行」变成了「有明确的故障恢复路径」。对自用是省一趟车程，对生产环境则是 SLA 能不能成立的分界线——没有兜底通道的远程运维，承诺的可用性是假的。
这套方案里真正耗时间的不是「装软件」，而是下面这些不配就会在关键时刻失效的细节。
hbbs 需要 21115/TCP（NAT 类型测试）、21116/TCP+UDP（ID 注册与打洞协调）、21118/TCP（Web 客户端）；hbbr 需要 21117/TCP（中继）、21119/TCP（Web 中继）。少放通 UDP 21116 是最常见的错误——表现为能注册但永远打不通洞，全部流量回落中继。100.64.0.0/10 段），并用 MagicDNS 分配固定主机名。这样连接路径完全不经过任何公共 ID 服务器——即使外部服务异常，只要 tailnet 通就能接管。Restore on AC Power Loss（不同主板也叫 AC Back Function / After Power Failure）设为 Power On。默认值通常是 Power Off 或 Last State，不改的话远程插座就只剩「断电」一半功能。具体用哪个软件会过时，下面这几条判断不会。它们同样适用于把任何一项「先买服务」的能力逐步转成自有能力。
第一代看似「走了弯路」，但它用最低的时间成本确认了真实的使用频率与画质门槛。没有这个基线，自建时会在错误的指标上过度优化。
它换回了控制权，却把成本从「按人付费」换成了「按带宽付费 + 运维时间」，并引入了一个新的单点。设备数不多时，这笔账不一定划算——要算清楚再上。
每删掉一个中间节点，同时删掉的是一处固定成本、一处带宽瓶颈、一处攻击面和一处运维负担。第三代之所以「无成本」，不是找到了更便宜的服务器，而是不再需要服务器。
并且兜底通道必须独立于主链路——用 4G 而不是现场 WiFi，正是因为「现场网络挂了」本身就是待兜底的故障之一。没有带外通道的远程运维，可用性承诺无法兑现。
开源方案的成本不在采购，而在于是否清楚 NAT 打洞在什么情况下会失败、服务为什么要装成系统服务、无人值守模式不开会怎样。把这些搞明白，账单自然就归零了。