企业官网建设流程全解析

这次我们来补上 Linux 命令系列的第 159 篇：rz。很多工程师第一次用 rz 是在 Xshell 里想给服务器传个文件，输入 rz 回车，弹出文件选择框，选完文件很快就传完了。看起来确实方便，但实际用起来会发现几个高频问题：rz 上传的文件到底传到哪了？为什么传库文件经常卡死？rz -y 是不是直接覆盖？为什么有的终端里输入 rz 完全没有反应？

rz 是 lrzsz 软件包提供的一个命令行工具，全称 Receive ZMODEM，作用是通过终端模拟器的 ZMODEM 协议把本地文件上传到远程 Linux 服务器。它不需要在服务器上额外启动 FTP 或 HTTP 服务，也不需要在本地记住服务器 IP 和端口，只要 SSH 能连上、终端支持 ZMODEM，就能直接把本地文件“拉”上去。这种交互方式在中小文件临时传输场景下，比 scp 更直观，尤其适合运维和开发在远程调试时快速传配置、脚本和日志文件。

这篇文章会围绕 rz 的安装部署、参数说明、文件目录定位、覆盖策略、二进制文件传输、批量上传、与 scp/sftp/rsync 的选型对比以及常见问题排查展开。重点解释几个搜索热度很高的疑问：rz 上传的文件在哪、rz 传输库文件老死掉怎么办、rz -y 的覆盖行为到底是什么。无论你是运维、后端开发还是刚接触 Linux 的初学者，这篇文章都值得收藏备用。

1. rz 核心能力速览

先给一张速览表，后面再逐个展开细节。

从这张表能看出，rz 的优势是“轻量”和“直观”，但它的短板也很明显：依赖终端模拟器、文件默认放当前目录、不擅长超大文件。这些短板不是 bug，而是协议本身的定位决定的。理解了这层关系，后面遇到问题就很好排查。

2. rz 适用场景与使用边界

2.1 适合什么场景

rz 最典型的场景就是临时上传小文件。比如你在本地写好了一个 nginx 配置文件，想放到服务器的 /etc/nginx/conf.d/ 下，执行 cd /etc/nginx/conf.d && rz，选中文件就完成了。再比如排查问题时需要把服务器上的一个日志传到本地分析，对应的是 sz 命令，逻辑一样，方向相反。这类操作如果走 scp，还得先记住用户名、IP、目标路径，rz 显然更符合“人在终端里顺手传个文件”的使用习惯。

另外，rz 适合在内网服务器、跳板机环境里使用。只要通过 SSH 连上了服务器，终端支持 ZMODEM，文件就能直接传。它不依赖额外的 FTP 端口或 HTTP 端口，对防火墙更友好，很多时候运维在客户现场不能用 scp 的情况下，rz 就是最方便的兜底方案。

2.2 不适合什么场景

rz 不适合超大文件传输。因为 ZMODEM 协议走的是终端通道，文件内容要经过终端模拟器的转发和缓冲区，整体传输效率明显低于 scp、rsync 这类基于 SSH 通道直接传输的方式。我自己见过的案例中，超过 500MB 的文件用 rz 传，速度慢是一方面，中途断线后没有断点续传，只能从头再来，非常浪费时间。

rz 也不适合传数据库备份、虚拟机镜像这类高频的大文件。如果你在搜索“rz 传输库文件老死掉”，多半就是踩了二进制文件用文本模式传输的坑，或者是文件太大导致终端缓冲区出了问题。这种场景下，更推荐 scp、sftp 或 rsync。

2.3 安全与合规边界

rz 虽然走的是 SSH 加密通道，但在生产服务器上使用仍然要注意几点：一是上传前先确认目标目录的权限和磁盘空间，不要覆盖系统关键配置；二是涉及敏感数据时，确认你具备相应的授权；三是部分终端软件会记录会话日志，文件内容可能被写入日志，如果传输的是密钥、账密文件，需要谨慎处理。总的原则是：能传什么、传到哪、谁来传，都要在可控范围内。

3. rz 环境准备与安装部署

3.1 检查是否已安装

在服务器上先看 rz 是否已经存在。

which rz

如果输出类似 /usr/bin/rz，说明已经安装了 lrzsz。如果提示 command not found，就需要安装。

3.2 安装 lrzsz

不同发行版的安装命令不一样，常见的有下面几种。

# CentOS / RHEL / 麒麟 / 统信等基于 yum 的系统 yum install -y lrzsz # Debian / Ubuntu apt update && apt install -y lrzsz # openSUSE zypper install -y lrzsz

安装完成后再次执行 which rz 验证。部分国产 Linux 发行版可能默认没有该软件包，需要先配置好系统自带的 yum 源或 apt 源。

注意：rz 是安装在 Linux 服务器上的，不是你本机 Windows 上的程序。你在本地终端里执行 rz，本质是远程 Linux 服务器上的命令在响应，弹窗的是本地终端软件。

3.3 终端客户端要求

rz 能不能弹窗，取决于本地终端是否支持 ZMODEM 协议。

• Xshell：内置支持，直接弹窗，最常用的组合。
• SecureCRT：内置支持，弹窗稳定。
• FinalShell：内置支持。
• MobaXterm：内置支持。
• Windows Terminal：原生不直接支持 ZMODEM 弹窗选择文件，需要配置额外插件，默认体验不如 Xshell。
• 纯 SSH 命令行环境：如果终端不支持 ZMODEM，执行 rz 后可能没有任何窗口弹出，甚至出现乱码。

所以如果你在某个终端里输入 rz 没反应，先别急着怀疑服务器，先确认本地终端是不是支持 ZMODEM。换回 Xshell 这类终端，大概率就正常了。

4. rz 参数详解与基础用法

4.1 常用参数表

rz 的参数不算多，但有几个非常关键，尤其是 -b 和 -y。

4.2 第一次上传：执行 rz

最简单的用法就是直接输入 rz 并回车。

cd /tmp rz

这时终端会弹出文件选择框，选中本地文件后开始上传。上传完成后，文件默认保存在当前目录，也就是你执行 rz 时所在的目录。

4.3 上传的文件到底去哪了

这是搜索热度非常高的问题：rz 上传的文件在哪？

答案很直接：在当前目录。执行 rz 前先执行 pwd，确认一下当前目录，你就能预判文件会传到哪里。

pwd cd /opt/upload rz

如果你没有先 cd 到一个明确目录，文件就会落在你登录时所在的默认目录，经常是 /root 或 /home/用户名。很多用户上传完找不到文件，就是因为没注意当前目录。

这里还有一个容易混淆的点：某些终端在 rz 弹窗时会显示一个“本地目录”，让你选择本地文件。这个目录指的是你要从本机哪个目录选择文件，而不是上传到服务器上的目标目录，两者不要弄混。

4.4 覆盖策略：-y 与 -E

rz 遇到同名文件时默认会询问你如何处理。想直接覆盖，就用 -y：

rz -y

想跳过已存在的文件，避免误覆盖，就用 -E：

rz -E

生产环境里我建议优先用 -E，或者先 ls 确认目录内容再决定。如果目录里已经有同名配置文件，直接 rz -y 会把旧配置覆盖掉，一旦新配置有问题，回滚成本会很高。

5. rz 功能测试与效果验证

这一节给出一套可以照着操作的验证流程。测试目标不是“能弹窗”，而是“传得对、文件完整、位置正确”。

5.1 测试场景一：单个小文件上传

先创建一个接收目录，然后上传一个本地文本文件。

mkdir -p /tmp/rz_test cd /tmp/rz_test rz

选择本地一个 test.txt 文件上传。上传完成后执行 ls -lh 和 pwd，确认文件位置和大小是否正确。

判断成功的标准：文件出现在当前目录，大小与本地一致，内容用 cat 查看正常。

5.2 测试场景二：二进制文件上传

这一步针对“rz 传输库文件老死掉”的疑问。准备一个本地压缩包，比如 app.tar.gz，执行：

cd /tmp/rz_test rz -b

加 -b 的意义在于告诉 rz 使用二进制模式传输，避免文本模式对二进制内容做转义或换行转换。传完之后用下面的命令验证压缩包完整性：

tar -tzf app.tar.gz md5sum app.tar.gz

如果 tar 命令能正常列出压缩包内容，说明压缩包没有损坏。如果你不加 -b 传二进制文件，很可能出现文件大小变了、解压失败、甚至进程卡死的问题。

5.3 测试场景三：批量上传

rz 一次可以选中多个文件。在终端弹窗里按住 Ctrl 或 Shift 多选，然后点击上传即可。

服务器端建议先建好接收目录：

mkdir -p /data/upload cd /data/upload rz -b -y

批量上传后，逐个用 md5sum 对比本地文件哈希值，确认没有哪个文件在传输过程中出错。

5.4 传输成功判断标准

不要只看终端提示“传输完成”，建议做三层验证：

1. 看文件是否在当前目录，大小是否正确。
2. 文本文件用 head 或 cat 抽查内容。
3. 压缩包、固件、库文件用 tar -t 或 md5sum 做完整性校验。

只有完整通过这些验证，才算一次真正成功的 rz 传输。

6. rz 批量上传与脚本化实践

6.1 交互式批量选择

在 Xshell、SecureCRT 这类终端里，rz 弹窗后可以一次选择多个文件。批量上传本身不需要额外写脚本，但要注意：文件越多，越要在传完后做完整性校验。如果只是在终端弹窗里刷刷刷地选了一堆文件传完就走，后面发现某个文件坏了，很难定位是哪一个出了问题。

6.2 固定接收目录脚本

如果你经常需要把文件传到同一个目录，可以写一个简单脚本，把目录切换和参数固定下来，减少手动操作。

#!/bin/bash # 固定 rz 接收目录，避免文件散落在随机目录 DEST_DIR="/data/upload" mkdir -p "$DEST_DIR" cd "$DEST_DIR" || exit 1 echo "文件将上传到: $DEST_DIR" rz -b -y

保存为 upload.sh，每次需要接收文件时，执行 bash upload.sh 即可。这一步能有效避免“文件不知道传到哪里”的问题。

6.3 自动化传输的替代方案

如果你打算在无人值守的脚本里自动上传文件，rz 并不是好选择。因为 rz 依赖终端模拟器弹出 ZMODEM 窗口，纯命令行的自动化环境很难可靠触发这个交互过程。更稳妥的方案是：

# scp 自动上传 scp local_file user@remote:/data/upload/ # rsync 增量同步 rsync -avz local_file user@remote:/data/upload/

如果你的场景是定时批量同步，rsync 的增量能力和断点续传能力远超 rz。 rz 更适合“人坐在终端前手动传文件”，而不是程序自动调用。

6.4 上传后自动校验

在脚本里加上校验逻辑，可以及时发现传输问题。比如接收目录固定后，再写一个校验脚本：

#!/bin/bash cd /data/upload || exit 1 echo "计算所有文件的 md5 值：" md5sum *

传输前在本地生成一份 MD5 列表，传输后在服务器端执行 md5sum -c 对照检查，这是最保险的做法。

7. rz 与 sz、scp、sftp、rsync 的选型对比

7.1 rz / sz 组合

rz 是接收文件，sz 是发送文件。两者是同一个软件包 lrzsz 里的命令，比如要把服务器的日志拉到本地：

sz /var/log/nginx/access.log

sz 的参数逻辑与 rz 类似，也支持 -y、-b、-E。rz/sz 组合适合中小文件在终端界面里的快速互传，不需要额外工具。但它们的传输效率依赖终端通道，超大文件用起来比较吃力。

7.2 scp

scp 是最常见的 SSH 文件传输命令，适合大文件、命令行自动化。它的缺点是不支持增量同步，也不支持断点续传，文件传一半断了只能重来。

scp local_file user@server:/data/upload/

7.3 sftp

sftp 是交互式文件传输工具，适合需要浏览远端目录、手动上传下载多文件的场景。它天然走 SSH 通道，安全性有保障。

sftp user@server cd /data/upload put local_file

7.4 rsync

rsync 是最适合批量、增量、断点续传同步的工具。它在性能上的优势远超 rz，适合大目录、构建产物同步、备份等场景。

rsync -avz --partial local_dir/ user@server:/data/upload/

7.5 选型建议表

从性能角度看，rz 的传输效率通常低于 scp 和 rsync。观察方式很简单：在传输过程中用 top 查看 rz 进程状态，再用同样的网络环境对比 scp 的速度，差距会很明显。这不是说 rz 不行，而是它的定位不同。

8. 常见问题与排查方法

这一节直接面对几个搜索热度最高的问题。

下面展开说几个重点问题。

8.1 rz 上传的文件在哪去了

重复一遍：rz 命令本身不接收远程目录路径，文件默认保存到执行 rz 时的当前工作目录。如果你执行 rz 前没有 cd，文件就会落在登录后的默认目录。遇到找不到文件的情况，先执行 pwd 和 ls -lh，不要盲目用 find 全盘搜索。

8.2 rz 传输库文件老死掉

这个现象大概率是文本模式和二进制模式的区别造成的。rz 默认使用文本模式，会把一些字节解释成控制字符，遇到二进制文件时可能触发异常，轻则文件损坏，重则传输进程卡死。解法很简单：传 .tar.gz、.jar、.so、.zip、.bin 这类文件时，一律加 -b。

rz -b

如果加 -b 后仍然不稳定，说明问题可能出在文件大小或网络环境上。超过几百 MB 的文件建议拆分成小包，或者直接改用 scp/rsync。

8.3 同一终端里 scp 和 rz 的选择

当你觉得 rz 不靠谱时，请记住一句话：rz 追求的是交互方便，scp 追求的是传输效率和稳定性。同一个终端里，两者可以共存。日常小文件用 rz，大文件和自动化任务用 scp。不要在一个不适合 rz 的场景里死磕。

8.4 服务器上没有 lrzsz

某些精简系统或容器镜像里默认没有安装 lrzsz。这时候执行 rz 会提示 command not found。容器环境建议进入容器后使用 apt/yum 安装，或者直接在宿主机用 docker cp 传文件，比在容器里折腾 rz 更高效。

9. rz 最佳实践与使用建议

结合前面所有内容，给出可以落地的操作建议。

第一，执行 rz 之前一定要 cd 到目标目录。这一条看起来简单，但能避免一半的“文件不知道去哪了”问题。建议每次都用绝对路径进入目录再执行 rz，例如 cd /data/upload && rz -b -y。

第二，二进制文件必须加 -b。压缩包、安装包、库文件、可执行文件全部用二进制模式。文本文件例如 .conf、.txt、.log，默认文本模式问题不大，但为了统一，你也可以一律使用 rz -b，二进制模式能覆盖绝大多数场景。

第三，批量上传后要做完整性验证。tar -tzf 只能验证压缩包，最通用的方式是 md5sum。本地先生成 md5 列表，服务器端再校验，这一步在传输敏感文件或上生产环境时不能省略。

第四，超大文件直接放弃 rz。超过几百 MB 的文件，优先考虑 scp 和 rsync。没有必要为了“方便”让一个几 GB 的备份文件卡在终端通道里，既占会话又浪费等待时间。

第五，谨慎使用 -y 覆盖。生产环境的配置文件，建议先用 ls 和 diff 确认差异。如果确实要覆盖，先备份旧文件：

cp /etc/nginx/conf.d/test.conf /etc/nginx/conf.d/test.conf.bak rz -y

第六，关注终端会话安全。远程操作生产服务器时，不要在本人不知情的终端记录环境中传输密钥、明文账密等敏感文件。上传前确认文件内容不违反公司安全策略和版权要求。

第七，如果需要稳定的自动化上传，不要在 rz 上做文章。部署 sftp 服务或者使用 rsync 做增量同步，会更符合工程化要求。

10. 总结与下一步

rz 是 Linux 日常运维中上传小文件最方便的命令之一，它的核心价值在于“交互直观”：一行 rz，弹窗选文件，传到当前目录。它最大的问题也来自这个机制：依赖终端 ZMODEM 支持、文件默认放当前目录、二进制文件需要加 -b、大文件效率低且不能断点续传。

你现在可以做的验证很简单：先确认服务器安装了 lrzsz，再执行 cd /tmp && rz -b 上传一个小文件，然后用 ls -lh 和 md5sum 确认文件位置与完整性。如果遇到不弹窗或卡死的情况，回到第 8 节的排查表，大多数问题都能定位。

后续如果你想进一步规范文件传输流程，可以把 rsync 的增量同步和 sftp 的交互式目录浏览也一起学起来，形成一套“小文件用 rz、大文件用 scp/rsync、目录浏览用 sftp”的组合方案。这套组合足够覆盖日常开发、运维和项目交付中的绝大多数文件传输需求。