最近更新: 2026-07-09
发送只是故事的一半——迟早你也会是接收方:同事想跨网络给你一个文件,你自己的一台机器想把东西交给另一台,或者你想主动从你管理的服务器上取点东西回来。Relayium CLI 用三个不同的命令覆盖这三种情形,而且都不需要账号。
对方用配对码推给你时用 receive;想要一个常驻收件箱、让受信任的机器随时可以推送过来时用 serve;而你主动去连接一台已能 SSH 登录的服务器取文件时用 pull。
用哪个命令,取决于谁在发起传输,以及两台机器是怎么互相认识的:
这是 relayium send 的接收端。对方选一个简短的码,并通过你们都信任的渠道告诉你——打个电话、发条消息——然后在他那边运行 relayium send <path> <code>。你则用同一个码运行 receive:
relayium receive 428571
# or into a specific directory
relayium receive 428571 ./downloads
serve 的方向正相反:不是你去连别人,而是其他机器通过 relayium:// 直接推送给你——专为你已经信任的机器设计,比如你自己的笔记本推给一台 NAS,或者构建服务器把产物投递到你的机器上——走的是锁定的 TLS 1.3 连接,无需 SSH,无需中转撮合。
relayium serve
# a specific directory, port, and allowing delete requests
relayium serve --dir ~/incoming --port 9031 --allow-delete
对于无人值守运行的 serve(systemd、后台脚本),让推送方运行 relayium id 打印出它的指纹,然后在接收方这边提前批准它:
relayium authorize <fingerprint>
pull 是 push 的镜像:不是等别人发东西给你,而是你通过已有的 SSH 权限主动连过去,把文件取回来。
relayium pull user@host:/path/to/files ./local-dest
不需要。三种方式——receive、serve、pull——都完全免费,两端都不需要 Relayium 账号。
不互通。CLI 的配对码协议和 relayium.com 浏览器端的加入链接、二维码流程是分开的——它们的握手方式不同,目前也无法互相通信。这是路线图上的事,现在还不能指望。
在终端中,会在它首次推送时提示你按地址和指纹批准,批准结果会被记住。没有终端时——比如作为 systemd 服务或 cron 任务——没有人来回应,未知推送方会被拒绝;应先用 relayium authorize <fingerprint> 预先授权。
不能。pull 始终需要远程装有 relayium;不像 push 那样有 tar 兜底方案。请先在远程安装 relayium。
默认在 ~/.config/relayium 中——在任何涉及身份或信任的命令上,都可以用 --config-dir 覆盖这个位置。
准备好接收第一次传输了吗?装上 CLI,选择 receive、serve 或 pull。
获取 CLI