返回博客列表

Tailscale + ZeroTier + FRP：11 台跨国设备的三层 Overlay 分工

2026年3月21日 | Ruichen Zhou | 约 8 分钟阅读
Tailscale ZeroTier FRP 网络 Overlay

系列文章：本文是「OpenClaw + 基础设施」系列的第 4 篇。

  1. OpenClaw (Clawdbot) 多端部署：Gateway + Tailscale Serve + Node 配对
  2. OpenClaw Cron 监控实战：QQ Bot 通知链路排障与 Prompt 调优
  3. OpenClaw 多节点运维：Token 持久化、Gateway 冲突排障
  4. Tailscale + ZeroTier + FRP：11 台跨国设备的三层 Overlay 分工（本文）
  5. 1C1G VPS 服务编排：MetAPI 网关 + Nanobot + DERP 的资源取舍

本文记录 11 台跨国设备的三层 overlay 分工：Tailscale 负责管理面，ZeroTier 负责数据面，FRP 负责公网兜底。环境覆盖德国、中国和香港，目标是在长期在线节点、移动设备和路由器之间，建立一套可维护的远程管理、数据同步和故障恢复方案。

  • 设备清单：air、macmini、tower、thinkpad、server、2 台 OpenWrt 路由器、1 台香港 VPS、2 部手机等，共 11 台设备。
  • Tailscale：负责设备身份、SSH 控制、OpenClaw 组网和日常远程开发。
  • ZeroTier：负责 Syncthing 同步、大文件传输和需要局域网发现的数据流量。
  • FRP：负责前两条链路不可用时的公网兜底入口。
  • 约束：链路跨国、NAT 与运营商策略不一致；部分节点必须长期在线；并非所有设备都适合安装全套客户端。

先说约束

  1. 设备跨两个国家。德国这边有宿舍和学校，中国那边有家里常驻设备，再加上一台香港 VPS 作为中间点。链路质量、NAT 类型、运营商策略都不一样，不能指望所有设备都能稳定直连。

  2. 很多设备需要长期在线。server、macmini、tower、两台路由器和 vps 都是基础设施，不是临时开机的测试节点。我需要的是一套能长期维持的分工，而不是某次测速里跑得最快的方案。

  3. 不是所有设备都适合装全套工具。笔记本和 Linux 主机当然最自由，但路由器能跑什么客户端、怎么更新、稳定不稳定，是另一回事；手机就更不可能按桌面端的思路配置。现实里一定会有“某些节点只能接入部分 overlay”的情况。

为什么不统一到一个 overlay

把所有流量都塞进一个 overlay，在这个规模下会放大链路职责冲突。

Tailscale 的管理体验确实很好，设备身份、ACL、SSH、hostname 都很顺手，我现在所有设备也都在同一个 Tailnet 里。但它更适合承担控制面、SSH 和远程开发，不适合长期承载 Syncthing 和大文件传输这类持续数据流量。

ZeroTier 更像一条适合放数据面的链路，局域网发现和大流量同步都更对路子。但在我的环境里，它作为“日常第一入口”的稳定性和确定性，还是不如 Tailscale。用它传文件可以，把所有 SSH 控制都押给它不合适。

FRP 从一开始就不是主路。它走公网、经香港 VPS 中转、延迟更高、路径更长，能救命，但不适合常态使用。

工程上的结论不是“选一个最好的”，而是不要让一条链路同时承担三种职责。

三条链路各负责什么

后来我把它们明确拆成了三层：

  • Tailscale 负责管理面。设备身份、SSH 控制、OpenClaw 组网、日常远程开发，全部优先走这条。它的优点不是峰值带宽，而是我知道 ssh server、ssh thinkpad 这种入口大多数时候都可靠。
  • ZeroTier 负责数据面。Syncthing 同步、大文件传输、需要局域网发现的流量，我尽量放到这条链路上。这样数据流量和控制流量天然隔离，排障时也更清楚。
  • FRP 负责兜底。只有当前两条都不通，或者某个场景必须走公网入口时，我才用它。它通过香港 VPS 中转，不常态使用，但必须一直可用。

这样分完之后，拓扑会简单很多：Tailscale 管“我怎么进去”，ZeroTier 管“数据怎么跑”，FRP 管“前两条都挂了怎么办”。

SSH config 命名体系

链路分工清楚之后，SSH Host 名也必须能表达“设备”和“入口类型”两个信息。Host a、Host b、Host work 这类命名在同一台设备同时存在 Tailscale 和 FRP 入口时没有辨识度。

统一规则是：设备名用 Tailscale hostname，链路差异用后缀表示。

Host thinkpad
  HostName thinkpad
  ProxyCommand nc -X 5 -x router-de:1080 %h %p

Host thinkpad-frp
  HostName my-frp-server.example.com
  Port 6001
  User ruichen

这里最重要的不是 ProxyCommand 本身，而是这个命名约定：thinkpad 表示“这台机器的默认入口”，thinkpad-frp 表示“同一台机器的公网兜底入口”。名字对应的是设备，后缀对应的是链路。

这样我平时只需要记 ssh thinkpad、ssh server、ssh vps。只有进入事故模式时，才会显式去敲 -frp。

服务绑定策略

三条 overlay 长期共存时，另一个很重要的问题是：服务到底绑在哪张网卡上。

我的做法很直接。

  • SSH、管理面服务、只希望 Tailnet 内可见的调试端口，只监听 Tailscale IP。
  • Syncthing、需要大流量同步的数据服务，只监听 ZeroTier IP。
  • 少数必须保留的救援入口，才额外给 FRP / 公网 留一条兜底。

关键点不是“让所有服务都三网可达”，而是尽量避免一个服务同时挂在三张网卡上。服务一旦哪里都能进，路由、代理、防火墙和性能问题就会缠在一起，最后排障成本高得离谱。

我现在更倾向于让每个服务一开始就有明确归属：它属于控制面，还是属于数据面；它是日常入口，还是灾难恢复入口。职责清楚之后，配置反而更少。

代理和 overlay 打架

这套分工里，最坑的一次问题不是 NAT，也不是 ACL，而是本地代理软件。

这次故障的详细过程在OpenClaw 运维复盘里写过，这里只说结论。

Clash Verge 这类透明代理如果没有把 Tailscale 和 ZeroTier 的网段加入白名单，就可能把 overlay 流量一起接管。表面上看像是“节点之间不通”，本质上其实是本机代理规则先把虚拟网卡流量截断了。

这类问题的教训很明确：只要机器上还有 Clash、v2rayN、系统代理之类的东西，排查 overlay 故障时，先检查一遍代理规则。很多“网络问题”根本不在远端，而是在本机。

结论

这套网络的核心不是“只选一个 overlay”，而是明确谁负责控制面、谁负责数据面、谁负责兜底。对这 11 台设备来说，Tailscale、ZeroTier 和 FRP 的职责一旦固定，远程访问、数据同步和故障恢复就都有了清晰边界。分工稳定之后，整张网络才是可维护的系统，而不是一组临时可用的技巧。

评论