1. 为什么我还在用lrzsz这种“老古董”传文件先说实话我第一次用lrzsz的时候内心是拒绝的。那时候我习惯用scp和sftp传文件觉得命令行里有rsync、scp、sshfs这么多现代化工具谁还用rz、sz这种看起来像是上个世纪的东西。直到有一次客户现场割接服务器在带外管理的内网里只有一台Windows跳板机SSH能连但scp端口被封了FTP更是想都别想我整个人就傻在那儿了。后面老同事甩给我两个命令——rz和sz二十秒把文件传完了。那一瞬间我才反应过来在很多真实的生产环境里你根本不知道对方给你开了什么端口、装了什么服务你唯一确定能用的就是一个SSH终端甚至可能还是串口。这种场景下lrzsz就是你最后的底牌。lrzsz是一个经典的Unix/Linux串口文件传输套件包含rz接收文件即从本地终端往服务器传和sz发送文件即从服务器往本地终端下载两个核心命令。它基于ZMODEM、YMODEM、XMODEM协议家族通过标准的终端输入输出通道完成文件传输不依赖网络端口、不依赖SSH服务端额外开洞只要你能敲命令它就能传文件。现在很多刚入行的同事听到rz/sz的第一反应是“这不就是个Windows和Linux之间传文件的小工具吗”这个认知不能算错但严重低估了它的价值。在嵌入式开发、网络设备维护、服务器带外管理、内网隔离环境这些场景里lrzsz经常是唯一能用的文件传输途径甚至可以这么说一个运维或者嵌入式工程师如果不会用lrzsz在不少特殊环境里会寸步难行。这篇文章我会把lrzsz的安装方式、核心用法、协议原理、常见坑和实战技巧一次性讲透同时把我和它死磕多年总结出来的经验也一并放进去。无论你是刚接触Linux的新手还是经验丰富的运维老手这里应该都有你可能没注意到的细节。2. 装好之前的准备工作先搞清楚你的环境lrzsz的安装其实非常简单但安装之前有两件事必须先确认清楚不然装完你也用不了甚至可能把自己搞懵。2.1 确认终端软件是否支持ZMODEM这个点很多人会忽略但恰恰是最关键的。rz和sz不是独立开一个通道去传文件它们是往标准输入输出里塞数据然后由终端软件负责把数据捞出来。Windows自带的cmd、PowerShell、老版本的Windows Terminal默认都不支持ZMODEM协议你敲下rz命令后终端会直接卡死或者乱码。常用的终端软件支持情况我直接列个表方便大家对照终端软件ZMODEM支持情况使用说明Xshell内置支持弹窗提示文件选择最省心SecureCRT内置支持支持rz/sz协议重命名稳定MobaXterm内置支持上传下载都有图形化界面FinalShell内置支持国产工具双栏文件管理PuTTY不支持需要搭配winscp等辅助工具Windows Terminal默认不支持新版有插件但配置麻烦不推荐macOS Terminal不支持macOS建议用内置的scp或者iTerm2配合trzsziTerm2支持需安装插件配合trzsz-ssh插件使用看到这儿你就明白了与其说是Linux服务器上要装lrzsz不如说是“服务器和终端两端配合”才能用起来。服务器端提供rz/sz命令以及ZMODEM协议的应答能力终端软件负责弹出文件选择框、接收数据流、把收到的信息流转成文件。任何一端缺了这事儿都成不了。我个人的习惯是服务器端装好lrzsz之后第一件事永远是用一个已知支持ZMODEM的终端测试rz和sz是否通了再交付给业务方。否则业务方用PuTTY连上去敲个rz没反应第一反应是找我来“修一下服务器”——其实服务器根本没毛病是终端不支持。2.2 常见发行版的安装命令lrzsz在主流Linux发行版里都有官方软件包用自带的包管理器装就行不需要编译源码。这里我把常见发行版的安装命令整理一下# Debian / Ubuntu / Linux Mint 等 sudo apt update sudo apt install -y lrzsz # RHEL / CentOS 7 及以下 sudo yum install -y lrzsz # RHEL / CentOS 8 / Rocky / AlmaLinux 等 sudo dnf install -y lrzsz # Fedora sudo dnf install -y lrzsz # openSUSE sudo zypper install -y lrzsz # Arch Linux / Manjaro sudo pacman -S lrzsz # Alpine Linux sudo apk add lrzsz装完之后验证一下which rz sz rz --version sz --version如果能正常打印出版本信息说明安装成功。如果你用的是那种极度精简的发行版或者容器镜像包里连包管理器都没有那就只能走编译安装了。源码编译我也不展开太多lrzsz的源码下载解压后就是标准的autotools三连wget https://www.ohse.de/uwe/re/lrzsz-0.12.20.tar.gz tar zxvf lrzsz-0.12.20.tar.gz cd lrzsz-0.12.20 ./configure --prefix/usr/local/lrzsz make sudo make install sudo ln -s /usr/local/lrzsz/bin/rz /usr/local/bin/rz sudo ln -s /usr/local/lrzsz/bin/sz /usr/local/bin/sz源码包里默认会编译出多个可执行文件比如rz、sz、rb、sb、rx、sx等它们不同的名字对应不同的传输协议这个后面讲。对绝大多数人来说用包管理器安装就够了源码编译主要是为了应付那些连基础仓库都没有的离线环境。2.3 一个容易忽略的细节会话复用工具的影响如果你习惯在服务器上用screen或者tmux那我建议你在测试rz/sz之前先想清楚一个问题你敲rz的时候终端里有没有挂着screen/tmux会话为什么我要专门说这个因为rxs/tmux这类终端复用器会拦截和重定向输入输出流偶尔会把ZMODEM的传输数据搞乱。早期版本可能会有兼容性问题我遇到过不少次在tmux会话里传文件传到一半卡死或者文件损坏的情况。现在的版本大多能正常工作但稳妥起见第一次测试rz/sz时建议先脱离screen/tmux把它当作一个基准测试。如果脱离了就能正常传在screen/tmux里传不了那基本就是会话复用器设置的问题不是你服务器的问题。3. rz/sz的核心用法和参数一次讲透安装和验证都搞定了接下来就是把rz和sz的日常用法彻底讲明白。注意这里是“讲明白”而不是简单“列参数”因为我发现很多人用lrzsz只会裸敲一个rz遇到稍微复杂点的场景就不知道怎么处理了。3.1 rz命令从本地上传文件到服务器rz命令的作用是从本地终端往服务器传文件最基础的用法是cd /path/to/upload/target rz执行后如果你的终端支持ZMODEM会弹出一个文件选择对话框选中你要上传的文件确认后就开始传输。这里有三件事必须强调第一先cd到目标目录再敲rz。rz把文件收到哪儿取决于你当前的工作目录。很多人习惯性在根目录或者家目录敲rz回头找文件找不到其实文件就在你敲命令时候所在的那个目录里。第二生产环境建议加-e参数。rz -e表示对传输内容做转义escape避免某些控制字符被误判。虽然现在绝大多数情况下不加-e也没问题但在串口、老网络、特殊字符文件名这类场景下加上-e能省掉一堆莫名其妙的传输损坏问题。第三-y参数控制同名文件覆盖行为。不加-y的时候如果目标目录里已经有同名文件rz会提醒你是否覆盖加了-y就会自动覆盖适合批处理场景。我平时最常敲的命令是rz -ey一句话解释转义传输、同文件自动覆盖最丝滑的组合。当然如果你担心误覆盖重要文件可以不使用-y。3.2 sz命令从服务器下载文件到本地sz命令是rz的反向操作把服务器上的文件下载到本地。基本用法sz filename.txt sz /var/log/nginx/access.log同样下载到哪儿由你的本地终端设置决定。Xshell、SecureCRT这类软件默认会下载到一个固定的目录一般在软件设置里可以改。我习惯把Xshell的下载目录设置成一个专门的D:\downloads\server文件夹避免下载的文件和项目文件混在一起。sz也支持批量下载sz file1.txt file2.txt /tmp/test.log还可以用通配符sz /var/log/nginx/access.log.*批量下载的情况下终端软件一般会自动用日期或序号重命名文件避免冲突。不同终端的命名规则略有差异比如Xshell是自动加数字前缀SecureCRT会弹出确认框。这个属于终端软件的行为不归lrzsz管没必要太纠结。3.3 不要忘记还有rx、sx、rb、sb这几个兄弟lrzsz包里其实包含多个命令简单对应关系如下命令对应协议工作模式rzZMODEM接收文件szZMODEM发送文件rxXMODEM接收文件sxXMODEM发送文件rbYMODEM接收文件sbYMODEM发送文件日常大家用rz/sz就足够了因为ZMODEM是三个协议里最强大的一个支持断点续传、批量传输、文件名保持、自动重传。XMODEM/YMODEM算是老前辈协议简单、格式老现在基本只有在老嵌入式设备或者老网络设备里才会碰到。但懂他们的存在是有价值的。比如你在一台极其古老的设备上做维护设备里只有rx/sx这时候你要是连rx这个命令都不知道可能就被卡住了。作为运维人员命令不怕多记关键时刻能救命。3.4 嵌入式的例外串口控制台上的lrzsz嵌入式方向的朋友可能更关心串口场景。在串口控制台上lrzsz也是可以用的因为串口本质就是字符设备ZMODEM协议通过标准输入输出就能跑。嵌入式Linux的busybox里一般也集成有lrzsz通常以lrz、lsz出现用法一样。但是串口场景下有两个额外的坑波特率影响传输速度。115200波特率下实际传输速度大概是每秒11KB左右传大文件会怀疑人生。为了保证传输成功我一般先压缩再传文件能小则小。流控要开。串口传输时终端软件的流控选项如果设置不对大概率会传坏。建议硬件流控RTS/CTS关掉软件流控XON/XOFF也关掉ZMODEM协议自身有足够强的纠错能力反而是流控选项容易干扰数据。4. 从“能传文件”到“传得漂亮”几个最实用的场景实战工具本身不复杂但这种工具类的东西最大的价值不在于你记住了几个命令而在于你知道在什么场景下怎么组合使用它。我挑几个这些年实际工作中用得最多的场景完整过一遍。4.1 场景一Windows和Linux之间互传小文件这是出现频率最高的场景。比如我在Windows上用Xshell连上一台CentOS服务器需要把本地的jar包传上去部署或者把服务器上的日志拉下来分析。上传的完整操作是# 1. 到目标目录 cd /opt/app/deploy/ # 2. 执行上传等待弹窗 rz -ey # 3. 弹窗后在Windows本地选中app.jar # 4. 确认上传等待进度条完成下载的完整操作是# 1. 找到要下载的文件 ls -lh /var/log/app/error.log # 2. 执行下载 sz /var/log/app/error.log # 3. 终端弹窗或直接默认路径保存到本地这套组合拳打下来整个文件传输过程不超过10秒而且不需要额外开FTP服务、不需要装WinSCP、不用关心SSH端口是否映射到外网。4.2 场景二一堆服务器批量分发部署包有一类场景是你有一批服务器每台都需要上传同一个安装包但服务器之间不能直接互通你只能通过跳板机逐台登录操作。一次性每台都敲rz然后选文件其实效率也不高因为还是得逐台手动确认。这时候我的做法是先把安装包用sz传到跳板机的一个固定目录然后通过跳板机用scp或者内网端口往目标服务器推如果跳板机到目标服务器之间也走不了scp、只能通过SSH挨个登录有个取巧的办法# 在每台目标服务器上都执行 cd /opt/setup/ rz -ey /dev/null 21 然后本地批量用SecureCRT的“传输文件”功能它支持向多个会话同时发送ZMODEM文件或者Xshell如果有批处理功能也可以。我实际测试下来SecureCRT的批量传输更稳定。这个办法不依赖脚本纯靠终端软件支持适合不想在客户端装任何额外工具的团队。4.3 场景三超大日志片段按行截取下载服务器日志动辄几个GB直接sz整个文件且不说终端软件会不会卡死就算传下来也毫无意义——你只想要今天报错那一段。所以我的常规流程是# 先按行截取最近的500行 tail -n 500 /var/log/app/error.log /tmp/error_20250120.log # 如果文件里有乱码用iconv转一下编码 iconv -f UTF-8 -t UTF-8 -c /tmp/error_20250120.log /tmp/error_20250120_clean.log # 压缩后下载 gzip -k /tmp/error_20250120_clean.log sz /tmp/error_20250120_clean.log.gz为什么要把日志先gzip再下载一是传得快二是避免传输过程中因为编码、控制字符之类的因素把日志搞乱。-k参数保留源文件省得传完发现还要再查一遍原始文件。4.4 场景四传输大文件时终端闪断怎么办大文件传输最烦的就是传到一半终端断了。ZMODEM本身支持断点续传但前提是“同一个终端会话、同一个软件、同一个文件”才行。比如SecureCRT里传了一部分软件卡死你关掉软件重连再敲sz传同一个文件SecureCRT默认会问你是否续传。Xshell我记得版本更新后也支持续传但触发条件比较苛刻不是百分百生效。如果遇到不支持续传的情况最骚的操作其实是先压缩再传输把文件拆成多个小块分别传输# 把大文件拆成每个100MB的块 split -b 100M bigfile.tar.gz bigfile_part_ # 逐个下载 sz bigfile_part_aa bigfile_part_ab bigfile_part_ac # 本地合并 cat bigfile_part_aa bigfile_part_ab bigfile_part_ac bigfile.tar.gz这样即便某个块传输失败了重新传那个块就行不拖累其他文件。算是土办法但在内网不稳定或者串口低波特率的环境下比幻想ZMODEM自动续传靠谱得多。4.5 场景五自动化脚本里用lrzsz实现隐式交互有一种场景是写运维脚本希望用户在Windows本地选择文件上传到服务器比如做一个自动部署脚本。传统方式下脚本敲read命令从标准输入读路径是不行的因为rz弹的是终端软件的文件选择框不是终端文本输入。但我们可以用交互式调用的方式在Shell脚本里直接调rz让它阻塞等待用户选文件#!/bin/bash echo 请在弹窗中选择需要上传的部署包 cd /opt/deploy/ rz -ey if [ $? -eq 0 ]; then echo 文件上传成功 ls -lh /opt/deploy/ else echo 上传取消或失败 filrzsz的命令退出码也是有用的0代表成功完成1代表用户取消或者传输失败。这样脚本可以基于退出码走不同的业务逻辑。我写过不少这种“人机交互式部署”的脚本运维人员用起来很直观不需要记任何受控命令弹窗选文件就完事。5. 那些年我用lrzsz踩过的坑以及对应的排查思路工具虽小坑是真不少。我把这些年用lrzsz遇到的典型问题整理了一下每个都附上排查链路和解决方案希望能帮你少走弯路。5.1 敲下rz命令后终端卡住没有任何反应这是最常见的问题没有之一。遇到这种问题先别急着怪服务器按下面的顺序排查第一步确认终端软件是否支持ZMODEM。如果你用的是PuTTY、Windows Terminal真机环境不带插件那基本可以断定是不支持换Xshell/SecureCRT/MobaXterm即可解决。这是比例最高的原因。第二步确认服务器上是否装了lrzsz。执行which rz看有没有返回路径没有就安装。有些精简镜像本身不带lrzsz裸敲rz肯定没反应。第三步确认当前shell环境是否异常。有可能你的PS1变量里有特殊控制字符导致ZMODEM握手失败。用bash --noprofile --norc进入干净环境再试一次能通说明是shell配置的问题。第四步确认是否在tmux/screen会话里。退出tmux/screen再试能通就说明是会话复用器的兼容问题。第五步看是否已经存在rz进程残留。如果上一次rz中断后没清理干净可能导致新的rz命令卡住。执行pkill -9 rz清掉残留进程再试。5.2 上传下载的文件内容不一致或者文件损坏文件传下来后md5对不上或者解压报错这是第二高频的问题。通常有以下几种原因原因一传输过程中数据被终端软件转义或修改。尤其当文件的二进制内容含有某些特殊字节比如CtrlC并且你没有使用-e参数时ZMODEM的转义机制和终端软件之间可能产生冲突。解决办法是统一使用rz -e和sz -e。原因二使用了不支持二进制安全传输的老旧终端软件版本。某些老版本的终端软件对ZMODEM支持不完整传文本还行传二进制就损坏。升级终端软件到较新版本即可。原因三网络传输层存在问题比如SSH连接不稳定、中间有网络设备丢弃数据包。这种情况下ZMODEM虽然会重传但如果断得过于频繁最终也会失败。建议检查网络稳定性或者改用更稳健的文件拆分传输方案。原因四串口场景下流控配置不当导致丢字节。这个问题我在嵌入式章节说过了检查串口软件的流控设置同时建议加上-e。排查手段很简单传完后在服务器端和本地分别执行md5sum比对哈希值是否一致。凡是生产环境的重要文件我强烈建议养成传输后校验的习惯。哪怕99%的概率没问题校验一下又花不了几秒钟。5.3 文件名中文乱码服务器上文件名是中文sz下载到本地之后文件名变乱码。这个问题出在“终端软件的编码设置”上而不在lrzsz本身。lrzsz负责传输文件和文件名但文件名到Windows本地之后怎么展示是终端软件在管。解决办法是把终端软件的编码设置调整成和你服务器locale一致或者统一用UTF-8。比如Xshell在“文件-属性-终端-编码”里选UTF-8SecureCRT也有类似的全局编码设置。如果服务器是老的CentOS 6系统且locale是POSIX或C那建议把系统locale改成en_US.UTF-8否则中文文件名在服务器侧本来就存储有问题。另外一个更稳妥的办法是传到本地之前先把文件名改成英文例如cp 中文报告.pdf /tmp/report_20250120.pdf sz /tmp/report_20250120.pdf我的习惯是只要是跨系统传文件文件名一律改成ASCII字符集——别小看这个习惯能替你省掉大量后续处理麻烦。5.4 传一半终端断线重连之后文件不完整这个坑我前面提过。ZMODEM理论上支持断点续传但实际是否触发取决于终端软件。比如SecureCRT的断点续传做得相对成熟重连后sz同一个文件它会自动提示是否续传。Xshell的续传我记得也在新版本里加入了但我个人测试结果不稳定所以遇到重要文件传输我不赌续传直接用split拆块方案。还有一个经验传大文件之前先用df -h看一下服务器磁盘空间是否足够避免传到一半磁盘写满导致文件损坏或rz直接失败。磁盘满这个因素我踩过不止一次很冤。5.5 用sz下载文件名带特殊字符的文件失败文件名里有括号、空格、特殊符号比如my file (final).tar.gz直接用sz可能解析出问题。解决办法有两个最简单的办法是把文件复制或重命名为简单文件名再传cp my file (final).tar.gz /tmp/upload_final.tar.gz sz /tmp/upload_final.tar.gz或者用引号包裹原文件名sz my file (final).tar.gz这里面还有一个细节sz支持的是多个文件参数如果文件名以-开头会被误认为参数需要特殊处理。最稳妥的做法是先改名再加./前缀比如sz ./-weird-name.txt6. 进阶技巧lrzsz在特殊场景下的几个关键操作6.1 在容器环境里用lrzsz容器里能不能用lrzsz答案是可以但有条件。如果你用的镜像太精简比如busybox镜像里自带的lrzbusybox集成版对ZMODEM协议支持得比较有限最好还是装完整的lrzsz# 以Ubuntu基础镜像为例 apt update apt install -y lrzsz容器环境里需要注意的一个点是rz/sz依赖标准输入输出是交互式TTY。如果你用docker exec进入容器默认不分配TTYrz会立即报错。需要用docker exec -it container_id bash进入容器后再敲rz才能正常工作。同理Kubernetes里用kubectl exec -it进入Pod后rz/sz也可以正常使用。这也是一个非常实用的场景——Pod里没装过SSH服务也没有scp可用但有kubectl exec就够传文件了。6.2 用expect/shell脚本自动应答交互理论上rz/sz都是交互式工具需要人在弹窗里选文件。但有一种取巧的自动化思路是本地预先用expect脚本模拟终端接受ZMODEM数据从而绕过手动弹窗。这个方案偏小众而且折腾我实际很少推荐因为如果终端软件本身就支持ZMODEM没必要自己造轮子。只有在你要写一个完全无人值守的传输脚本时才值得研究。以Xshell为例它支持一个命令行开关/z可以把文件选择框变成命令行参数指定文件名这样你可以写一个批处理脚本调用Xshell来完成自动传输。不过这属于Xshell的使用技巧此处不展开。6.3 调整传输超时和重试次数lrzsz有一些环境变量可以调整传输行为用得比较多的是# 设置超时时间单位秒 export ZMODEM_TIMEOUT30 # 设置最大重试次数 export ZMODEM_RETRY100在极端不稳定的网络环境下适当调大重试次数能明显提高传输成功率。在正常网络环境下默认配置已经够用不用动。还有一个常用变量是ZMODEM_ESC_CTRL它的作用和-e参数类似控制是否对控制字符做转义。如果你发现-e在某些老终端上反而引发问题可以试试这个变量。6.4 和sftp/scp的取舍什么时候该用lrzsz什么时候该用别的这个话题想说的其实不是“谁替代谁”而是“不同场景用不同工具”。我根据自己的经验画一个简单的选择路径如果SSH服务正常、端口开放、网络通优先用scp/sftp或者rsync做增量同步它们更快更稳而且不需要终端软件配合。如果SSH能用但端口被防火墙限制、只有终端通道用lrzsz。如果是串口终端、没有网络只有串口线用lrzsz。如果需要远程批量同步几千个小文件用rsynclrzsz会传到你怀疑人生。如果是Windows跳板机上临时传个小文件到内网服务器的场景lrzsz就是最快的路。lrzsz不适合传超大文件它本身走的是终端通道效率上限受限于终端软件的接收能力和网络带宽。我见过有人拿它传几个GB的数据库备份结果传了三天三夜还没传完。这类场景请老老实实开FTP或者开SCP端口别跟工具特性较劲。6.5 我用lrzsz搭建过的最舒服的一套部署流程最后分享一个我目前用的比较多的小流程。我做Java后端部署时多台服务器环境都预装了lrzsz部署时就这样操作本地用IDE打成jar包Xshell连上跳板机cd /data/deploy rz -ey弹窗选jar包脚本自动把jar包分发到各目标服务器重启服务查看日志确认启动正常整套流程从选文件到服务起来应该也就一分钟左右。如果没有lrzsz这个过程要么走FTP、要么让运维帮忙传、要么开SCP端口效率完全不在一个量级上。写在最后的体会我早期对lrzsz有偏见觉得它老、它土、它不现代但这些年各种网络隔离环境跑下来反而越来越觉得它能活这么多年是有道理的它没有依赖任何复杂协议没有要求你打开额外的服务端口没有强迫你改变工作习惯只要有一个能敲命令的终端窗口就行。这种“在最有限条件下解决最实际问题”的能力其实挺值得反复品味的。如果你看完这篇之后打算在服务器上试试我建议第一次不要急着传大文件先传一个小配置文件跑通流程确认rz和sz都能正常交互再应用到实际场景。另外记住两个习惯一是上传前先cd到目标目录二是rz -ey和sz -ey是你最好的朋友。等用到顺手了你会发现这个“老古董”是真的香。