最近更新: 2026-07-09
magic-wormhole 悄悄积累了一批忠实用户:运行它,得到一段像 7-crossover-clockwork 这样简短易读的代码,把代码念给对方听,文件就到了——全程加密,不需要账号,也不用操心什么服务器。Relayium CLI 的思路与之相似,用一段简短代码直接配对两台电脑,并加密两者之间传输的一切。
两者重合之处不少,不重合的地方也值得说清楚——包括一处 magic-wormhole 今天确实比 Relayium CLI 更稳健的地方。
两个工具用同样老实的方式解决同一个核心问题:不需要账号,文件不会滞留在你无法掌控的服务器上,两端唯一需要线下约定的就是一段简短代码。
这是需要老实说明的一处权衡,而不是含糊带过。magic-wormhole 自带一个 Transit Relay,当两端无法彼此建立直连时(比如双方都处在严格或对称 NAT 之后,怎么都打不通),传输可以退化到走这个中继。中继始终只能看到密文,但正因为它存在,传输依然能够完成。
Relayium 的 send/receive 是纯直连的:在握手结束后它会花几秒钟尝试建立一条直连,如果找不到,传输会直接失败,而不会退回到任何中继——按设计,Relayium 的服务器完全不会碰跨网络 CLI 传输的文件字节。实际中这种情况并不常见(大多数家庭和办公网络都能打通直连路径),但如果你要在两台都处于异常严格 NAT 之后的机器之间传文件,magic-wormhole 更有可能直接成功。如果打不通直连路径,而可靠性比“避免中继”更重要,那正是该用 magic-wormhole 的场景——或者改用 Relayium 的 push/pull 或对一台你能真正连到的服务器做 daemon-direct,这两者根本不依赖那一跳点对点直连。
Relayium CLI 真正多出来的能力,在一次性配对码传输之外:还有两种传输方式,用的是你本就已有的基础设施,这是 magic-wormhole 没有覆盖的场景。
relayium push / pull 复用你现有的 SSH 权限,因此没有新增的信任关系,也无需分享任何代码。push 甚至能在远程完全没装 relayium 的服务器上工作,退化为通过 SSH 连接传输一段普通的 tar 流——但这个兜底只属于 push;pull 始终需要远程装有 relayium,因为在那里它要充当发送方。
relayium serve 能把你拥有的任何一台机器变成一个 daemon-direct 目标,通过锁定的 TLS 1.3 访问,无需 SSH、无需代码——信任建立在第一次连接时(可交互批准,或提前授权以支持无人值守),此后一直锁定,思路和 SSH 的 host key 一样。
relayium push ./photos user@your-server:backups/
relayium serve --dir ~/incoming
relayium push ./build relayium://your-server
magic-wormhole 发送一批文件(或打包成一个压缩包的文件夹)后就退出——要更新对方就得再发一次,也没有“该删除什么”的概念。Relayium CLI 增加了 relayium sync,在上面两种传输方式之上做增量单向镜像:只传发生变化的内容;--delete 会删除目标端上源端已经消失的文件(daemon 只有在以 --allow-delete 启动时才会执行,接收方必须自己选择开启);--watch 会在文件变化时实时持续重新同步,不需要额外的定时任务。
如果你不想依赖 relayium.com,Relayium 的服务器也可以以单个 Docker 容器的形式自行托管;用 --server 让 CLI 指向它。
relayium sync ./photos user@your-server:backups/photos --delete --watch
把最关键的差别并排列出:
完全免费。没有付费档位,也没有什么可计量的——每种模式都是两端直接连接,CLI 开源。
不需要。push/pull 用你自己的 SSH 权限,daemon-direct 用你机器之间锁定的 TLS 证书信任,send/receive 用你们线下约定的一段简短代码。三者都不涉及 Relayium 账号。
这种情况下 Relayium 的 send/receive 是纯直连的,会失败——它不会退回到任何中继。magic-wormhole 的 Transit Relay 依然可以承载加密数据流,完成传输。如果你需要不管网络环境如何都能成功,magic-wormhole 目前能处理这种情况;改用 Relayium 的 push/pull 或对一台你能连到的服务器做 daemon-direct 同样可行,因为它们不依赖那一跳点对点直连。
目前还不能实时配对传输——CLI 的 send/receive 用的是自己的直连握手协议,和浏览器基于 WebRTC 的配对流程不是一回事,两者暂不互通。如果只想用浏览器把文件交给对方,可以用 Relayium 的存储下载链接,或者浏览器版自己的配对码模式。
可以。Relayium 的服务器以 Docker 镜像形式发布(docker compose up -d --build),你也可以用 --server https://your-domain 让 CLI 的 send/receive 指向你自己的实例。
安装免费的 Relayium CLI,试试 push、sync 或 send——无需账号,基于代码的传输上手速度不输 magic-wormhole。
获取 CLI