1. 项目概述1.1 项目背景与应用场景在Linux服务器上工作数据传输是个绕不开的话题。无论是从本地Windows/Mac上传文件到服务器还是从服务器下载文件到本地没有图形界面的纯命令行环境里这事情做起来总是有点别扭。传统方案里scp、sftp、ftp或者rsync都是选择但它们都需要额外的客户端点几下鼠标或者敲几行命令尤其当服务器处于内网环境、没有外网暴露端口时工具链就显得更重了。我的日常工作是运维一堆Linux服务器经常要处理日志收集、补丁包分发、配置文件备份这类轻量级文件传输需求。这类场景有个共同点文件不大、频率高、操作人要变。最省事的办法其实是让操作者直接在SSH终端里拖拽文件就完事。这时候lrzsz的价值就出来了。lrzsz是一套基于Unix/Linux的通信工具包它由两个核心命令组成rz接收文件即从终端上传到服务器和sz发送文件即从服务器下载到本地。它依赖ZModem协议工作这套协议最初是为老式串口调制解调器设计的现在在SSH终端里反而发扬光大成为Xshell、SecureCRT、MobaXterm等主流终端工具的标配能力。很多刚接触Linux的同事会问我“为啥不直接scp”说实话scp在处理需要跟交互式终端配合的场景时效率远不如rz/sz来得直接。scp需要你单独开一个会话输入完整路径甚至还要配密钥或输入密码。而lrzsz的体验是你登录服务器后敲个rz命令文件选择窗口直接弹出来选完文件进度条一跑就完事下载更是简单敲个sz加文件名文件就落到本地了。对运维和开发来说是真正省时间的工具。1.2 核心功能与解决的问题lrzsz主要解决三类问题第一类是交互式终端内的快速文件传输。你正在终端里跟服务器对话忽然需要把本地配置文件推上去或者把服务器某个日志拉下来不需要离开会话不需要再开一个sftp窗口rz/sz一条命令搞定。第二类是没有图形界面的服务器环境下的文件交换。很多企业服务器为了安全做最小化安装没有桌面包没有图形化FTP客户端甚至没有外网。lrzsz体积小几百KB纯命令行运行部署成本几乎为零也正因为这样它成了很多自动化脚本里的标配工具。第三类是跨平台文件传输的兼容性问题。Windows和Linux之间文件传输容易踩编码、换行符的坑但lrzsz配合合适终端的时候传过去是什么就是什么不会擅自转换内容。尤其传压缩包、二进制文件、程序包这类对完整性有要求的文件时这个特性非常关键——很多FTP工具在ASCII/Binary模式之间切换出错但ZModem协议自带校验传错了直接重传可靠性很好。根据我多年的实际使用经验lrzsz最舒服的地方在于它和终端仿真器的深度集成。Xshell、SecureCRT、MobaXterm、FinalShell这些主流Windows终端都内置了ZModem支持你甚至不需要学会ZModem协议的任何细节——rz对应上传sz对应下载就这两个命令人人能上手。这也是为什么它在Linux运维这个圈子里几十年了还是没人能取代它的位置。2. 环境准备与安装方式详解2.1 安装前置条件解析在正式安装lrzsz之前有几个前置条件值得先确认一下。lrzsz本身对系统资源的要求可以忽略不计但它的运行依赖一个完整的SSH终端链路如果你当前的环境缺少哪怕一环装好了也跑不起来。第一SSH服务必须正常运行。lrzsz的工作机制说白了就是把文件数据编码成字符串通过SSH通道传输到终端再由终端软件解析还原成文件。所以你的Linux服务器上必须跑着sshd服务并且你能够通过SSH正常登录。可以用下面命令检查systemctl status sshd如果看到active (running)就说明没问题。第二本地终端软件必须支持ZModem协议。这一点很多教程都会忽略但恰恰是最容易让新手困惑的地方。假如你用的是Windows自带的CMD或者PowerShell直接SSH连接那对不起即使服务器上装了lrzszrz命令也可能没反应或者直接报错。这是我踩过坑的地方——Windows的OpenSSH客户端原生不支持ZModem必须配合Xshell、SecureCRT这类支持ZModem的终端才能实现文件传输。第三服务器需要能够访问软件源。无论用yum还是apt安装lrzsz都需要从软件仓库拉取安装包。如果服务器处于纯内网环境要提前配置好本地yum源或apt源或者手动下载rpm/deb包安装。不过好在lrzsz包很小几百KB级别从外网下载后拷进内网成本也不高。第四你当前登录的用户需要有sudo权限或者直接用root。安装软件属于系统级操作普通用户没有写/usr/bin等目录的权限。如果你用的是普通用户安装命令前要加sudo。实在权限不够的可以联系管理员帮忙安装——反正也就一分钟的事。2.2 CentOS/RHEL系安装CentOS和RHEL系包括Rocky Linux、AlmaLinux、Oracle Linux是服务器领域占有率最高的发行版它们的包管理工具是yum老版本或dnfRHEL8。lrzsz很早就被纳入了官方软件源所以安装很简单# CentOS 6/7 及老版本 yum install -y lrzsz # CentOS 8 / Rocky Linux / AlmaLinux dnf install -y lrzsz一条命令搞定装完以后可以用which rz sz验证安装结果。正常情况下会输出类似/usr/bin/rz和/usr/bin/sz的路径。这里补充一个细节RHEL8系列里yum命令实际是指向dnf的软链接所以你用yum install也一样能装。但需要注意的是如果系统里之前通过源码编译方式装过lrzsz再用yum安装可能产生版本冲突。遇到这种情况先rpm -qa | grep lrzsz看看装了没有再决定是覆盖还是卸载重装。如果你的服务器真的连不上外网源也可以准备一个rpm包手动安装。去EPEL或者镜像站下载对应系统版本的rpm包然后rpm -ivh lrzsz-0.12.20-43.el8.x86_64.rpm注意这里的包名和版本号要根据实际系统来CentOS 7用的是0.12.20系列RHEL 8/9也类似但具体小版本可能不同。手动安装最需要注意依赖问题好在lrzsz没有依赖下载对应包直接装就行。2.3 Ubuntu/Debian系安装Ubuntu和Debian系的包管理工具是apt安装同样简单apt update apt install -y lrzsz第一行apt update一定要先执行因为apt的软件源缓存是快照制的不刷新的话可能找不到最新版本的包或者直接报404。如果服务器是全新的这一步尤其重要。装完以后验证方式同上which rz which sz如果输出两个路径说明安装成功。这里再提一个Debian系特有的注意事项有些精简版容器镜像比如Docker的debian:bullseye-slim默认可能没有装lrzsz而且可能缺少基础工具链。如果你打算写脚本自动安装记得把apt update和apt install放到同一条命令链上比如apt update apt install -y lrzsz这个习惯能避免不少新手在写Dockerfile时踩到“安装失败”的坑。2.4 源码编译安装备选方案如果你用的是比较冷门的Linux发行版例如某些国产化系统、ARM架构的嵌入式系统包管理源里可能找不到lrzsz或者版本太老。这种情况我建议走源码编译安装。lrzsz的源码托管在GitHub上仓库地址是https://github.com/trzsz/lrzsz这是当前比较活跃的维护分支。编译安装流程如下# 安装编译工具链 yum install -y gcc make # RHEL系列 apt install -y build-essential # Ubuntu/Debian系列 # 下载源码 wget https://github.com/trzsz/lrzsz/releases/download/v0.12.20/lrzsz-0.12.20.tar.gz # 解压并编译安装 tar zxvf lrzsz-0.12.20.tar.gz cd lrzsz-0.12.20 ./configure --prefix/usr/local make make install编译过程一般一两分钟就能完成不挑环境。装完以后路径可能不在默认PATH里你可以加个软链接ln -s /usr/local/bin/lrz /usr/local/bin/rz ln -s /usr/local/bin/lsz /usr/local/bin/sz源码编译的坑主要在configure阶段如果提示缺少编译器gcc: command not found说明你需要先安装基础工具链。另外有些精简系统连wget都没有可以用curl -O代替或者从本地把源码包传上去再解压。我第一次在ARM嵌入式设备上编译lrzsz就是卡在没装gcc这事儿上所以这块经验分享给后来人。3. 核心操作rz与sz命令的使用技巧3.1 rz命令从本地向服务器上传文件rz命令是lrzsz包里最重要的命令功能是将本地文件上传到服务器。它的用法简单到令人发指rz然后如果你用的是支持ZModem的终端Xshell、SecureCRT等会直接弹出文件选择窗口选中本地文件确认后就开始上传了。上传完成后的文件默认落在你当前所在目录。这里展开几个使用细节关于目录位置rz上传的默认保存目录是当前工作目录pwd显示的那个。所以上传之前确认一下你人在哪别传完了找不到文件。我习惯性先执行cd /指定目录再rz从来不让文件乱飞。关于目录参数-D选项可以指定保存目录即rz -D /tmp这个选项在写脚本时很好用能保证文件路径明确。不过也要注意-D后面的目录必须真实存在否则会报错。关于多文件上传Xshell之类终端的文件选择窗口支持Ctrl/Shift多选可以一次传多个文件。但如果你用SecureCRT需要确认版本支持。传多个文件时lrzsz会逐个传输、逐个显示进度条顺序是按你选择的顺序进行的。关于目录上传rz不能直接上传整个文件夹。如果你要上传一个目录先把目录打包成tar.gz或者zip再传。这是新手最容易踩的“想当然”的坑——文件选择器里看起来能选文件夹实际上选中后要么直接没反应要么报错。就老老实实tar czf folder.tar.gz folder/ rz然后上传tar包到服务器再解压。关于中断与重传ZModem协议自带断点续传和校验功能。如果上传了一半网断了重新执行rz选择同一个文件lrzsz会检测到文件已存在并询问是否覆盖。但这里的“断点续传”不是像迅雷那样从断点接着传而是重新传整个文件协议层负责保证完整性。对大文件来说体验稍差但实际场景里传大文件走rz的并不多它更适合传几十MB以内的小文件。3.2 sz命令从服务器下载文件到本地sz命令send zmodem的功能与rz相反是把服务器上的文件下载到本地。基础用法sz filename sz filename1 filename2 filename3 # 支持多文件 sz *.log # 支持通配符执行后同样是在支持ZModem的终端里会弹出本地保存窗口让你选择保存位置然后开始下载。sz有几个比较实用的参数我用得很多sz -y filename # 覆盖本地同名文件不再反复询问 sz -b filename # 以二进制模式传输 sz -E filename # 传输完成后删除服务器源文件相当于“移动”-y参数在批量下载同名文件时体验提升巨大。默认情况下如果本地已有同名文件终端会弹窗询问你是否覆盖一个个点确认非常烦人加了-y之后直接覆盖。下载多个文件时这个参数我是必加的。-b参数的意义在于保证二进制文件的完整性。lrzsz默认是文本模式如果传的是可执行文件、压缩包、图片等二进制文件建议显式加-b参数。虽然现代ZModem实现一般能自动识别文件类型但手动指定总归更稳妥。传文本文件用默认模式有个额外好处它会自动转换换行符但如果你传的是代码文件反而不希望它转换——所以代码、脚本这类文件我建议也用-b。-E参数我一般只在明确要清理服务器临时文件时才用因为它把源文件删了万一本地传输失败服务器上的源文件也没了这个风险我明确提醒一下——这个参数慎用尤其在处理业务数据日志时我更推荐你先sz下载再手动rm路径清晰不容易出事。3.3 借助通配符和管道的高阶用法sz命令支持shell通配符这使得它在批量日志提取场景里非常顺手。比如# 下载当前目录所有.txt文件 sz -y *.txt # 下载app.log及其轮转日志 sz -y /var/log/app/app.log* # 下载文件名包含日期关键字的文件 sz -y *20240601*.log通配符的匹配规则由shell负责所以跟平时ls用的通配符行为完全一致。如果你要下载的文件分布在不同的子目录里sz本身不会递归查找需要结合find命令find /opt/app -name *.log -exec sz -y {} \;这个命令会遍历/opt/app下所有.log文件逐个调用sz下载到本地。注意每条sz命令只处理一个文件所以会弹多次保存窗口如果你不想被窗口轰炸更推荐先把文件聚拢到一个目录再批量下载mkdir -p /tmp/downloads find /opt/app -name *.log -mtime -7 -exec cp {} /tmp/downloads/ \; sz -y /tmp/downloads/*先复制合并再统一下载整个过程窗口少、效率高。这是我在处理多服务器日志归档时最常用的操作组合。另外rz和sz还有一个极为有用的管道用法。你可以像使用cat一样通过管道把命令输出直接发送到本地文件也可以把本地文件内容灌进服务器某个命令。比如# 将服务器命令输出保存到本地文件 echo show status | mysql -u root -p | sz # 把本地SQL文件内容直接导入服务器数据库 rz | mysql -u root -p database_name虽然这种用法不如直接落盘文件再用rz/sz那么直观但在特殊场景下内存中没有临时文件的场景或者干脆懒得清理临时文件用管道方式省一步操作。需要提醒的是管道用法对二进制不友好文本场景下用用就好。4. 终端配合不同终端下的使用配置与坑4.1 Xshell、SecureCRT与MobaXterm的配合体验lrzsz能火这么多年跟几款主流终端对ZModem协议的内置支持密不可分。这里逐一说下我的实际体验。Xshell是我主力使用的工具它对lrzsz的支持可以说是开箱即用。安装lrzsz后什么都不用配置rz和sz就能直接弹文件选择窗口。Xshell有几个快捷键值得记住在会话中直接拖拽文件到终端窗口相当于自动执行rz在终端中选中文件路径再拖到本地相当于自动执行sz。这个拖拽功能特别好用实际操作中省掉了敲命令的麻烦但有一个小坑Xshell的拖拽上传在部分Linux版本上需要在“连接属性-用户身份验证”勾选“接受ZModem”相关选项否则拖拽无效。SecureCRT也是lrzsz的老牌搭档。它默认就能处理rz/sz弹窗的界面虽然没有Xshell漂亮但稳定性没话说。SecureCRT有个选项叫“日志文件保存路径”它同时也控制sz下载的默认保存位置在“会话选项-终端-日志文件”里可以改成你惯用的下载目录。SecureCRT同样支持拖拽上传但它的拖拽体验不如Xshell流畅。MobaXterm是近几年比较流行的全能终端内置了很多小工具。在处理ZModem协议时MobaXterm会弹一个自己的传输管理器进度清晰支持同时跑多个传输任务。MobaXterm的缺点是在部分Linux发行版上终端类型如果设置成了xterm-256color而不是xtermrz/sz的弹窗可能不自动出现——这时候你在终端输入rz回车终端响应速度会变慢看起来像卡住实际是弹窗没有正确唤起。解决办法是把会话的终端类型改成xterm这个问题就消失了。FinalShell是国产终端中我比较喜欢的因为内置了图形化的文件管理和流量监控。它对lrzsz的支持比较完善rz/sz弹窗和进度显示都正常。它最有意思的地方是不用lrzsz也能通过自带的SFTP面板传文件——但既然都装了lrzsz两个方案可以并存看个人习惯。4.2 Windows原生命令行的限制与应对Windows 10/11自带的OpenSSH客户端用ssh命令直连默认不支持ZModem协议。具体表现是你在CMD或PowerShell里ssh登录服务器执行rz命令后终端没有任何反应不弹窗也不报错就像一个永远在执行中的命令。这时按CtrlC可以终止但你已经浪费了一分钟。这个问题在WSLWindows Subsystem for Linux里同样存在——如果你是通过WSL里的bash直接SSH到另一台服务器除非你在WSL里也装一个支持ZModem的终端模拟器比较复杂否则rz/sz同样用不了。应对方案有两个方案一是换终端装个Xshell、MobaXterm或FinalShell这是最省事、最推荐的路径。这些终端本质上只是一个exe文件不需要额外配置系统环境变量就能用。方案二是使用trzsz-go这类兼容工具。trzsz项目是lrzsz的现代替代品它不仅支持ZModem协议还支持在普通SSH命令下直接工作原理是把文件传输编码通过终端对话直接完成不依赖终端模拟器支持ZModem。在Windows的PowerShell里装trzsz-go之后你也可以用类似rz/sz的命令行完成文件传输——但说实话日常使用中还是建议直接用Xshell学习成本最低老运维传下来的经验基本都是这条路。不过需要说明一个现实问题现在很多运维和开发工作干脆直接不依赖lrzsz了而是靠VS Code Remote-SSH里的内置文件管理器拖放文件。VS Code里连上远程服务器后左侧资源管理器里直接就能浏览远程文件右键下载、拖拽上传体验完全不输图形化FTP。但lrzsz的优势在于“轻”——你登录的服务器即使啥都没装只要能装lrzsz任何终端都能用它传文件。VS Code的重型方案在极简环境中反而施展不开。4.3 终端类型对ZModem支持的影响在深入使用lrzsz的过程中我还发现一个隐藏变量终端类型TERM环境变量。可能很多人不会注意到但TERM的值会影响终端模拟器对ZModem协议的响应方式。查看当前终端类型echo $TERM常见的值有xterm、xterm-256color、linux、vt100、screen等。多数现代终端模拟器默认是xterm或xterm-256color两者对lrzsz的影响不大。但如果你用tmux或screen这类终端复用器需要确认它们对ZModem有额外的转发支持。这里有一个我实际踩过的坑在tmux会话里运行rz/sz经常出现弹窗不出现或乱码的情况。这是因为tmux在内部虚拟了一个终端层ZModem的转义序列被tmux拦截了。解决方法是安装tmux的ZModem插件比如tmux-zmodem或者在tmux里临时使用SETENV方式执行rz/sz更简单粗暴的办法是让用户在tmux会话外执行rz/sz传完文件再回到tmux继续干活。有趣的是很多终端模拟器实际上拦截的是SSH通道里的特定转义序列。ZModem协议在传输前会发送一串特殊的控制字符如**\x13终端捕获到这个信号后弹窗响应用户交互。如果终端捕获逻辑有问题或者终端类型设置得过于古老比如纯vt100控制字符合法性检查可能失败rz/sz就“静默失败”了。遇到这类问题优先检查终端类型设置把它改成xterm或xterm-256color90%的疑难杂症能解决。5. 常见问题与排查技巧实录5.1 问题速查表从现象到根因lrzsz本身是个比较简单的工具但在实际使用中各种环境的差异会导致一些莫名其妙的问题。我把这几年遇到和听到的典型问题整理成一个速查表方便大家按图索骥。问题现象可能原因解决方法执行rz/sz后终端无任何反应终端不支持ZModem协议换用Xshell/SecureCRT/MobaXterm等支持ZModem的终端执行rz/sz后乱码或终端直接卡住终端类型不正确TERM变量异常检查TERM变量改为xterm或xterm-256color上传文件时报错rz: command not foundlrzsz未安装或路径不在PATH中安装lrzsz或检查软链接是否建立上传不了超过2GB的大文件32位系统限制ZModem协议限制换用rsync或sftp传输大文件中文文件名上传后乱码终端编码与服务端编码不一致统一终端和服务端的字符集为UTF-8上传文件到一半断了重新传提示文件存在lrzsz不真正支持续传会重新传整个文件需要续传时使用rsync替代下载文件时弹窗保存但不落盘终端下载目录权限或磁盘空间问题检查本地下载目录空间和权限在tmux/screen里rz/sz没反应tmux拦截了ZModem转义序列安装tmux的ZModem插件或在tmux外执行从串口连接的设备上rz/sz不能使用串口控制台不支持ZModem协议交互串口场景不需要lrzsz直接minicom等工具提示Permission denied当前用户对目标目录没有写权限先cd到可写目录或使用sudo rz这个表是针对我实际运维生涯中遇到问题的总结不同发行版情况可能有些差异但方向大致如此。尤其第一条80%的“rz不起作用”都是因为终端不支持协议——这个问题在给同事排障时出现频率最高每次一排查都发现对方在Windows CMD里直接ssh连服务器那当然不行。5.2 编码问题中文文件名乱码的根治法中文文件名乱码是我见过最多人踩坑的问题尤其在与Windows用户协作时更常见。核心原因在于Windows终端默认用GBK/GB18030编码显示而Linux服务器几乎全部使用UTF-8编码。当文件名含中文时rz上传过程实际上传的是UTF-8编码的字节序列Windows终端再用GBK去解析这些字节自然显示成乱码。排查步骤如下第一步检查服务器的locale设置locale如果LANG不是en_US.UTF-8或zh_CN.UTF-8说明系统基本编码有问题。可以临时设置export LANGzh_CN.UTF-8第二步检查终端软件的编码设置。Xshell里是“文件-属性-终端-编码”SecureCRT在“会话选项-外观-字符编码”里。确保它设置为UTF-8。第三步避免中文文件名。说实话这是最彻底的办法。上传或下载时提前重命名文件不用中文路径。如果文件是客户那边给的中文名绕不开那就先在本地区域里重命名再传用完再改回来。这个土办法看着笨但真的能杜绝一堆麻烦。5.3 大文件与性能边界分析lrzsz虽然好用但它毕竟是为小文件设计的工具性能上限要心里有数。实测下来在局域网环境内千兆网络lrzsz的传输速度大约在5~20MB/s之间取决于你的终端软件实现和CPU性能。这个速度比scp、rsync慢不少因为ZModem协议本身要处理编码、校验、确认等开销而且它走的是终端IO通道本身就不是为高速传输设计的。跨公网传输时速度还受SSH会话本身的瓶颈限制延迟越高ZModem的确认机制就越影响吞吐。如果你要传超过500MB的文件到生产服务器更推荐用rsync它既是增量传输、又支持断点续传、还能限速。lrzsz适合的是大小几KB到几十MB的配置类、日志类、小压缩包类文件。还有一个很多人没注意到的性能杀手是rz/sz在慢速网络下的表现。ZModem协议的确认机制比较啰嗦在延迟超过100ms的链路上时延会成为主要瓶颈传输几MB的文件可能需要几分钟。真遇到这种环境传文件还是优先用支持并发和断点续传的工具吧别折腾lrzsz了。5.4 安全性与权限控制建议lrzsz虽小但用它的时候还是要注意安全细节。我梳理几条实际工作中需要注意的点第一别在不可信的终端里执行rz。因为rz是从“本地”接收文件到服务器如果终端本身被植入恶意脚本对方可能在你敲下rz命令时弹出伪造的传输窗口诱导你上传敏感文件到攻击者控制的路径。虽然这种攻击门槛较高但在混合环境中防人之心不可无。第二下载文件渠道的一致性。sz命令将文件内容发送到“当前会话的终端”也就是说它走的是SSH通道不是额外的网络连接。所以只要你的SSH会话是加密的sz传输过程也是加密的——它不会额外开端口、不会绕过防火墙。很多安全审计同事问过这个问题这里专门说明一下。第三最小权限原则。给运维同事们授权时注意别让普通用户随手往系统关键目录如/etc、/usr/lib里rz上传文件这可能导致配置被意外覆盖或系统文件被篡改。更稳妥的做法是让日常操作用普通用户只有在明确需要时才用sudo写系统目录。6. 从lrzsz到trzsz现代替代方案与扩展思路6.1 trzsz兼容版协议与现代体验lrzsz火了三十多年但它的协议设计毕竟针对旧时代终端。这几年一个叫trzsz的开源项目逐渐进入视野作者是国内的工程师GitHub仓库名为trzsz/trzsz。它完全兼容lrzsz的使用习惯但协议更现代有两个关键改进一是支持普通SSH环境下的文件传输。前面提到Windows原生OpenSSH不支持ZModemtrzsz的方案是用普通终端对话完成传输不依赖终端模拟器的ZModem支持。换句话说你可以在PowerShell里直接ssh连服务器然后执行trz命令弹窗选取本地文件上传这在以前是不可能的。二是更快的传输速度和更好的断点续传。trzsz采用Python实现传输时内存占用可控编码效率比传统ZModem高特别是在高延迟网络下体验提升明显。安装方式也比较简单以Debian系为例# 服务端安装 sudo apt update sudo apt install -y trzsz # 客户端安装Windows下用pip pip install trzsz # 或者直接用trzsz-ssh替代普通ssh命令 trzsz-ssh userservertrzsz工作原理是把文件编码成可打印字符流在SSH会话里通过普通stdin/stdout传输客户端和服务端各自负责编解码。由于它不走ZModem转义序列所以现有的任何终端包括Windows自带CMD理论上都能用——只要该终端能正常显示普通文本输出。在我看来trzsz更适合那些工作环境锁定为Windows原生终端的开发者。但如果你像我一样日常就在Xshell里操作lrzsz其实已经完全够用。两者的使用成本和学习曲线都很低迁移过去没有壁垒。6.2 与scp、rsync、sftp的选型对照在Linux文件传输这个领域工具选择其实没有绝对的优劣关键看场景。我画了一张基于我经验的选型对照方便大家决策工具适用场景优势劣势rz/sz (lrzsz)交互式终端内临时传小文件无需运维之外的额外工具一条命令大文件、大批量文件效率低scp单文件/少量文件安全传输简单可靠支持认证不支持断点续传sftp稳定的文件管理需求支持目录浏览、删除、限速需要交互式客户端rsync大文件、目录同步、增量备份增量传输、断点续传、压缩命令复杂学习曲线较陡trzsz不依赖终端ZModem的临时传普通SSH下可用兼容lrzsz习惯相对较新社区资料少实际选择时我的判断标准是临时、交互、小文件用rz/sz自动化、批量、大文件用rsync需要浏览远程目录结构时用sftp。没有哪一个是银弹不同场景切换使用才是老运维的常规操作。6.3 自动化脚本里的lrzsz虽然lrzsz主要被当成交互式工具使用但在特定自动化场景下你也能看到它的身影。比如在批量交付服务器、需要往二十台服务器分发相同配置文件的场景下如果这些服务器还没有配置好SSH互信rsync反而用起来麻烦。这时候用rz先传到一台机器再用scp分发是比较顺手的操作流# 上传到当前机器 rz # 批量分发到其他服务器 for host in 192.168.1.101 192.168.1.102 192.168.1.103; do scp /tmp/app.conf root${host}:/opt/app/conf/ done还有一个用法是配合expect实现半自动上传。不过说实话expect脚本调rz这个组合在实践里不太稳定因为rz需要终端弹窗交互expect很难捕获这种窗口事件。如果一定要全自动化文件传输建议直接用scp或者rsync加密钥认证。另外提醒一句在CI/CD流水线里不要用rz/sz。流水线是无人为干预的自动化执行环境rz/sz的弹窗交互设计在这里根本走不通。该用scp、rsync、s3cmd、ossutil这些静默工具的时候就老老实实用专业工具。lrzsz的价值定位始终是人机交互场景。7. 实际项目经验与优化心得7.1 服务器批量部署lrzsz的最佳实践如果公司有几十上百台服务器需要统一安装lrzsz一台台手敲命令太傻了。这里分享一套我整理过的批量安装方案。利用psshParallel SSH一次性完成# 安装pssh工具Ubuntu/Debian系 apt install -y pssh # 准备服务器清单文件 cat servers.txt EOF root192.168.1.101 root192.168.1.102 root192.168.1.103 EOF # 批量执行安装命令 pssh -h servers.txt -i yum install -y lrzsz || sudo apt install -y lrzsz如果没有pssh也可以用读者更熟悉的Ansible- hosts: all tasks: - name: Install lrzsz package: name: lrzsz state: present - name: Verify installation shell: | which rz which sz register: result changed_when: falseAnsible的优势在于幂等——不管执行多少次只要系统里已装了lrzsz它就不会重复安装。批量安装以后可以用一个快速循环验证所有服务器的安装结果pssh -h servers.txt -i which rz which sz rz --version | head -n1这一套操作下来五十台服务器的部署大概两三分钟就能完成比我早年一台台SSH上去敲yum install的效率高了一个数量级。7.2 日志归档与定时清理配合在生产环境的日志服务器上lrzsz常与日志归档配合使用。常规做法是先压缩再下载避免传一堆小文件tar czf /tmp/logs_$(date %Y%m%d).tar.gz /var/log/app/ ls -lh /tmp/logs_*.tar.gz sz -y /tmp/logs_$(date %Y%m%d).tar.gz这个流程看起来简单但我操作时习惯加一步校验。因为sz下载后本地文件是否与服务器源文件完全一致肉眼无法确认。我的做法是在服务器上先算好校验值下载后本地再算一次两者比对# 服务器端 md5sum /tmp/logs_$(date %Y%m%d).tar.gz # 本地下载后 md5sum logs_$(date %Y%m%d).tar.gz两次输出的MD5值一致才说明文件传输完整可靠。虽然ZModem协议有校验机制但双保险的习惯值得培养——尤其在传输配置文件、程序包这类万一损坏就麻烦的文件时。归档下载完之后记得清理服务器上的临时压缩包别让/tmp被撑爆rm -f /tmp/logs_*.tar.gz这套“打包→校验→下载→清理”四步走是我在大量日志处理任务中总结出的标准流程。对我这种需要经常从服务器拉日志排查问题的人来说它几乎成了肌肉记忆。7.3 团队协作中的规范制定lrzsz虽然简单但在团队环境中如果每个人用得随意还是会出现文件混乱的情况。我在带团队时立了几条约定效果还挺好统一上传目录。不让同事们在任意目录下rz。约定专用上传暂存区比如/data/upload/上传后的文件由本人尽快移动到目标位置。这样可以避免“文件传上去了但不知道落在哪”的窘境。重要文件必须做校验。传输压缩包、程序安装包等文件时要求服务器端md5sum生成校验值并同步给接收方。这条规范虽然此时只用lrzsz但养成的习惯在ftp或网盘传输时同样受用。下载文件名可追溯。下载到本地的文件建议保持原来的文件名或者补充日期标记。比如app_20240601.log而不要统一改成a.log。听起来是小事但真到追溯问题的时候一个规范命名的日志文件能省去大量时间。这些规范不重但对秩序帮助很大。工具本身不会约束人的行为团队协作的顺畅程度取决于共同恪守的习惯。8. 写在最后的个人体会Linux里的小工具很多lrzsz算是那种乍看不起眼、用上就离不开的类型。它不适合传几十GB的数据库备份也不适合在无人值守的流水线里干活但在日常交互式运维这个场景里几乎找不到比它更顺手的方案。我到现在都记得第一次在Xshell里敲完rz弹出选择窗口时的惊讶——原来文件传输可以这么直接。如果你刚开始用lrzsz我给你的建议很简单遇到传不了大文件、终端不响应这类问题先查看终端软件是否支持ZModem遇到中文乱码先检查UTF-8编码配置遇到tmux里不好用先跳出tmux再执行。这三板斧能解决九成问题。最后分享一个小技巧Xshell里把rz和sz的默认目录都配置好上传目录设成/data/upload/下载目录设成本地的D:\Downloads\。这样敲完命令连路径都不用改传输完的文件自动落在该在的地方——这大概就是工具顺手之后人真正能感受到的效率提升。 lrzsz工具详解：Linux下rz/sz命令安装与使用指南
1. 项目概述1.1 项目背景与应用场景在Linux服务器上工作数据传输是个绕不开的话题。无论是从本地Windows/Mac上传文件到服务器还是从服务器下载文件到本地没有图形界面的纯命令行环境里这事情做起来总是有点别扭。传统方案里scp、sftp、ftp或者rsync都是选择但它们都需要额外的客户端点几下鼠标或者敲几行命令尤其当服务器处于内网环境、没有外网暴露端口时工具链就显得更重了。我的日常工作是运维一堆Linux服务器经常要处理日志收集、补丁包分发、配置文件备份这类轻量级文件传输需求。这类场景有个共同点文件不大、频率高、操作人要变。最省事的办法其实是让操作者直接在SSH终端里拖拽文件就完事。这时候lrzsz的价值就出来了。lrzsz是一套基于Unix/Linux的通信工具包它由两个核心命令组成rz接收文件即从终端上传到服务器和sz发送文件即从服务器下载到本地。它依赖ZModem协议工作这套协议最初是为老式串口调制解调器设计的现在在SSH终端里反而发扬光大成为Xshell、SecureCRT、MobaXterm等主流终端工具的标配能力。很多刚接触Linux的同事会问我“为啥不直接scp”说实话scp在处理需要跟交互式终端配合的场景时效率远不如rz/sz来得直接。scp需要你单独开一个会话输入完整路径甚至还要配密钥或输入密码。而lrzsz的体验是你登录服务器后敲个rz命令文件选择窗口直接弹出来选完文件进度条一跑就完事下载更是简单敲个sz加文件名文件就落到本地了。对运维和开发来说是真正省时间的工具。1.2 核心功能与解决的问题lrzsz主要解决三类问题第一类是交互式终端内的快速文件传输。你正在终端里跟服务器对话忽然需要把本地配置文件推上去或者把服务器某个日志拉下来不需要离开会话不需要再开一个sftp窗口rz/sz一条命令搞定。第二类是没有图形界面的服务器环境下的文件交换。很多企业服务器为了安全做最小化安装没有桌面包没有图形化FTP客户端甚至没有外网。lrzsz体积小几百KB纯命令行运行部署成本几乎为零也正因为这样它成了很多自动化脚本里的标配工具。第三类是跨平台文件传输的兼容性问题。Windows和Linux之间文件传输容易踩编码、换行符的坑但lrzsz配合合适终端的时候传过去是什么就是什么不会擅自转换内容。尤其传压缩包、二进制文件、程序包这类对完整性有要求的文件时这个特性非常关键——很多FTP工具在ASCII/Binary模式之间切换出错但ZModem协议自带校验传错了直接重传可靠性很好。根据我多年的实际使用经验lrzsz最舒服的地方在于它和终端仿真器的深度集成。Xshell、SecureCRT、MobaXterm、FinalShell这些主流Windows终端都内置了ZModem支持你甚至不需要学会ZModem协议的任何细节——rz对应上传sz对应下载就这两个命令人人能上手。这也是为什么它在Linux运维这个圈子里几十年了还是没人能取代它的位置。2. 环境准备与安装方式详解2.1 安装前置条件解析在正式安装lrzsz之前有几个前置条件值得先确认一下。lrzsz本身对系统资源的要求可以忽略不计但它的运行依赖一个完整的SSH终端链路如果你当前的环境缺少哪怕一环装好了也跑不起来。第一SSH服务必须正常运行。lrzsz的工作机制说白了就是把文件数据编码成字符串通过SSH通道传输到终端再由终端软件解析还原成文件。所以你的Linux服务器上必须跑着sshd服务并且你能够通过SSH正常登录。可以用下面命令检查systemctl status sshd如果看到active (running)就说明没问题。第二本地终端软件必须支持ZModem协议。这一点很多教程都会忽略但恰恰是最容易让新手困惑的地方。假如你用的是Windows自带的CMD或者PowerShell直接SSH连接那对不起即使服务器上装了lrzszrz命令也可能没反应或者直接报错。这是我踩过坑的地方——Windows的OpenSSH客户端原生不支持ZModem必须配合Xshell、SecureCRT这类支持ZModem的终端才能实现文件传输。第三服务器需要能够访问软件源。无论用yum还是apt安装lrzsz都需要从软件仓库拉取安装包。如果服务器处于纯内网环境要提前配置好本地yum源或apt源或者手动下载rpm/deb包安装。不过好在lrzsz包很小几百KB级别从外网下载后拷进内网成本也不高。第四你当前登录的用户需要有sudo权限或者直接用root。安装软件属于系统级操作普通用户没有写/usr/bin等目录的权限。如果你用的是普通用户安装命令前要加sudo。实在权限不够的可以联系管理员帮忙安装——反正也就一分钟的事。2.2 CentOS/RHEL系安装CentOS和RHEL系包括Rocky Linux、AlmaLinux、Oracle Linux是服务器领域占有率最高的发行版它们的包管理工具是yum老版本或dnfRHEL8。lrzsz很早就被纳入了官方软件源所以安装很简单# CentOS 6/7 及老版本 yum install -y lrzsz # CentOS 8 / Rocky Linux / AlmaLinux dnf install -y lrzsz一条命令搞定装完以后可以用which rz sz验证安装结果。正常情况下会输出类似/usr/bin/rz和/usr/bin/sz的路径。这里补充一个细节RHEL8系列里yum命令实际是指向dnf的软链接所以你用yum install也一样能装。但需要注意的是如果系统里之前通过源码编译方式装过lrzsz再用yum安装可能产生版本冲突。遇到这种情况先rpm -qa | grep lrzsz看看装了没有再决定是覆盖还是卸载重装。如果你的服务器真的连不上外网源也可以准备一个rpm包手动安装。去EPEL或者镜像站下载对应系统版本的rpm包然后rpm -ivh lrzsz-0.12.20-43.el8.x86_64.rpm注意这里的包名和版本号要根据实际系统来CentOS 7用的是0.12.20系列RHEL 8/9也类似但具体小版本可能不同。手动安装最需要注意依赖问题好在lrzsz没有依赖下载对应包直接装就行。2.3 Ubuntu/Debian系安装Ubuntu和Debian系的包管理工具是apt安装同样简单apt update apt install -y lrzsz第一行apt update一定要先执行因为apt的软件源缓存是快照制的不刷新的话可能找不到最新版本的包或者直接报404。如果服务器是全新的这一步尤其重要。装完以后验证方式同上which rz which sz如果输出两个路径说明安装成功。这里再提一个Debian系特有的注意事项有些精简版容器镜像比如Docker的debian:bullseye-slim默认可能没有装lrzsz而且可能缺少基础工具链。如果你打算写脚本自动安装记得把apt update和apt install放到同一条命令链上比如apt update apt install -y lrzsz这个习惯能避免不少新手在写Dockerfile时踩到“安装失败”的坑。2.4 源码编译安装备选方案如果你用的是比较冷门的Linux发行版例如某些国产化系统、ARM架构的嵌入式系统包管理源里可能找不到lrzsz或者版本太老。这种情况我建议走源码编译安装。lrzsz的源码托管在GitHub上仓库地址是https://github.com/trzsz/lrzsz这是当前比较活跃的维护分支。编译安装流程如下# 安装编译工具链 yum install -y gcc make # RHEL系列 apt install -y build-essential # Ubuntu/Debian系列 # 下载源码 wget https://github.com/trzsz/lrzsz/releases/download/v0.12.20/lrzsz-0.12.20.tar.gz # 解压并编译安装 tar zxvf lrzsz-0.12.20.tar.gz cd lrzsz-0.12.20 ./configure --prefix/usr/local make make install编译过程一般一两分钟就能完成不挑环境。装完以后路径可能不在默认PATH里你可以加个软链接ln -s /usr/local/bin/lrz /usr/local/bin/rz ln -s /usr/local/bin/lsz /usr/local/bin/sz源码编译的坑主要在configure阶段如果提示缺少编译器gcc: command not found说明你需要先安装基础工具链。另外有些精简系统连wget都没有可以用curl -O代替或者从本地把源码包传上去再解压。我第一次在ARM嵌入式设备上编译lrzsz就是卡在没装gcc这事儿上所以这块经验分享给后来人。3. 核心操作rz与sz命令的使用技巧3.1 rz命令从本地向服务器上传文件rz命令是lrzsz包里最重要的命令功能是将本地文件上传到服务器。它的用法简单到令人发指rz然后如果你用的是支持ZModem的终端Xshell、SecureCRT等会直接弹出文件选择窗口选中本地文件确认后就开始上传了。上传完成后的文件默认落在你当前所在目录。这里展开几个使用细节关于目录位置rz上传的默认保存目录是当前工作目录pwd显示的那个。所以上传之前确认一下你人在哪别传完了找不到文件。我习惯性先执行cd /指定目录再rz从来不让文件乱飞。关于目录参数-D选项可以指定保存目录即rz -D /tmp这个选项在写脚本时很好用能保证文件路径明确。不过也要注意-D后面的目录必须真实存在否则会报错。关于多文件上传Xshell之类终端的文件选择窗口支持Ctrl/Shift多选可以一次传多个文件。但如果你用SecureCRT需要确认版本支持。传多个文件时lrzsz会逐个传输、逐个显示进度条顺序是按你选择的顺序进行的。关于目录上传rz不能直接上传整个文件夹。如果你要上传一个目录先把目录打包成tar.gz或者zip再传。这是新手最容易踩的“想当然”的坑——文件选择器里看起来能选文件夹实际上选中后要么直接没反应要么报错。就老老实实tar czf folder.tar.gz folder/ rz然后上传tar包到服务器再解压。关于中断与重传ZModem协议自带断点续传和校验功能。如果上传了一半网断了重新执行rz选择同一个文件lrzsz会检测到文件已存在并询问是否覆盖。但这里的“断点续传”不是像迅雷那样从断点接着传而是重新传整个文件协议层负责保证完整性。对大文件来说体验稍差但实际场景里传大文件走rz的并不多它更适合传几十MB以内的小文件。3.2 sz命令从服务器下载文件到本地sz命令send zmodem的功能与rz相反是把服务器上的文件下载到本地。基础用法sz filename sz filename1 filename2 filename3 # 支持多文件 sz *.log # 支持通配符执行后同样是在支持ZModem的终端里会弹出本地保存窗口让你选择保存位置然后开始下载。sz有几个比较实用的参数我用得很多sz -y filename # 覆盖本地同名文件不再反复询问 sz -b filename # 以二进制模式传输 sz -E filename # 传输完成后删除服务器源文件相当于“移动”-y参数在批量下载同名文件时体验提升巨大。默认情况下如果本地已有同名文件终端会弹窗询问你是否覆盖一个个点确认非常烦人加了-y之后直接覆盖。下载多个文件时这个参数我是必加的。-b参数的意义在于保证二进制文件的完整性。lrzsz默认是文本模式如果传的是可执行文件、压缩包、图片等二进制文件建议显式加-b参数。虽然现代ZModem实现一般能自动识别文件类型但手动指定总归更稳妥。传文本文件用默认模式有个额外好处它会自动转换换行符但如果你传的是代码文件反而不希望它转换——所以代码、脚本这类文件我建议也用-b。-E参数我一般只在明确要清理服务器临时文件时才用因为它把源文件删了万一本地传输失败服务器上的源文件也没了这个风险我明确提醒一下——这个参数慎用尤其在处理业务数据日志时我更推荐你先sz下载再手动rm路径清晰不容易出事。3.3 借助通配符和管道的高阶用法sz命令支持shell通配符这使得它在批量日志提取场景里非常顺手。比如# 下载当前目录所有.txt文件 sz -y *.txt # 下载app.log及其轮转日志 sz -y /var/log/app/app.log* # 下载文件名包含日期关键字的文件 sz -y *20240601*.log通配符的匹配规则由shell负责所以跟平时ls用的通配符行为完全一致。如果你要下载的文件分布在不同的子目录里sz本身不会递归查找需要结合find命令find /opt/app -name *.log -exec sz -y {} \;这个命令会遍历/opt/app下所有.log文件逐个调用sz下载到本地。注意每条sz命令只处理一个文件所以会弹多次保存窗口如果你不想被窗口轰炸更推荐先把文件聚拢到一个目录再批量下载mkdir -p /tmp/downloads find /opt/app -name *.log -mtime -7 -exec cp {} /tmp/downloads/ \; sz -y /tmp/downloads/*先复制合并再统一下载整个过程窗口少、效率高。这是我在处理多服务器日志归档时最常用的操作组合。另外rz和sz还有一个极为有用的管道用法。你可以像使用cat一样通过管道把命令输出直接发送到本地文件也可以把本地文件内容灌进服务器某个命令。比如# 将服务器命令输出保存到本地文件 echo show status | mysql -u root -p | sz # 把本地SQL文件内容直接导入服务器数据库 rz | mysql -u root -p database_name虽然这种用法不如直接落盘文件再用rz/sz那么直观但在特殊场景下内存中没有临时文件的场景或者干脆懒得清理临时文件用管道方式省一步操作。需要提醒的是管道用法对二进制不友好文本场景下用用就好。4. 终端配合不同终端下的使用配置与坑4.1 Xshell、SecureCRT与MobaXterm的配合体验lrzsz能火这么多年跟几款主流终端对ZModem协议的内置支持密不可分。这里逐一说下我的实际体验。Xshell是我主力使用的工具它对lrzsz的支持可以说是开箱即用。安装lrzsz后什么都不用配置rz和sz就能直接弹文件选择窗口。Xshell有几个快捷键值得记住在会话中直接拖拽文件到终端窗口相当于自动执行rz在终端中选中文件路径再拖到本地相当于自动执行sz。这个拖拽功能特别好用实际操作中省掉了敲命令的麻烦但有一个小坑Xshell的拖拽上传在部分Linux版本上需要在“连接属性-用户身份验证”勾选“接受ZModem”相关选项否则拖拽无效。SecureCRT也是lrzsz的老牌搭档。它默认就能处理rz/sz弹窗的界面虽然没有Xshell漂亮但稳定性没话说。SecureCRT有个选项叫“日志文件保存路径”它同时也控制sz下载的默认保存位置在“会话选项-终端-日志文件”里可以改成你惯用的下载目录。SecureCRT同样支持拖拽上传但它的拖拽体验不如Xshell流畅。MobaXterm是近几年比较流行的全能终端内置了很多小工具。在处理ZModem协议时MobaXterm会弹一个自己的传输管理器进度清晰支持同时跑多个传输任务。MobaXterm的缺点是在部分Linux发行版上终端类型如果设置成了xterm-256color而不是xtermrz/sz的弹窗可能不自动出现——这时候你在终端输入rz回车终端响应速度会变慢看起来像卡住实际是弹窗没有正确唤起。解决办法是把会话的终端类型改成xterm这个问题就消失了。FinalShell是国产终端中我比较喜欢的因为内置了图形化的文件管理和流量监控。它对lrzsz的支持比较完善rz/sz弹窗和进度显示都正常。它最有意思的地方是不用lrzsz也能通过自带的SFTP面板传文件——但既然都装了lrzsz两个方案可以并存看个人习惯。4.2 Windows原生命令行的限制与应对Windows 10/11自带的OpenSSH客户端用ssh命令直连默认不支持ZModem协议。具体表现是你在CMD或PowerShell里ssh登录服务器执行rz命令后终端没有任何反应不弹窗也不报错就像一个永远在执行中的命令。这时按CtrlC可以终止但你已经浪费了一分钟。这个问题在WSLWindows Subsystem for Linux里同样存在——如果你是通过WSL里的bash直接SSH到另一台服务器除非你在WSL里也装一个支持ZModem的终端模拟器比较复杂否则rz/sz同样用不了。应对方案有两个方案一是换终端装个Xshell、MobaXterm或FinalShell这是最省事、最推荐的路径。这些终端本质上只是一个exe文件不需要额外配置系统环境变量就能用。方案二是使用trzsz-go这类兼容工具。trzsz项目是lrzsz的现代替代品它不仅支持ZModem协议还支持在普通SSH命令下直接工作原理是把文件传输编码通过终端对话直接完成不依赖终端模拟器支持ZModem。在Windows的PowerShell里装trzsz-go之后你也可以用类似rz/sz的命令行完成文件传输——但说实话日常使用中还是建议直接用Xshell学习成本最低老运维传下来的经验基本都是这条路。不过需要说明一个现实问题现在很多运维和开发工作干脆直接不依赖lrzsz了而是靠VS Code Remote-SSH里的内置文件管理器拖放文件。VS Code里连上远程服务器后左侧资源管理器里直接就能浏览远程文件右键下载、拖拽上传体验完全不输图形化FTP。但lrzsz的优势在于“轻”——你登录的服务器即使啥都没装只要能装lrzsz任何终端都能用它传文件。VS Code的重型方案在极简环境中反而施展不开。4.3 终端类型对ZModem支持的影响在深入使用lrzsz的过程中我还发现一个隐藏变量终端类型TERM环境变量。可能很多人不会注意到但TERM的值会影响终端模拟器对ZModem协议的响应方式。查看当前终端类型echo $TERM常见的值有xterm、xterm-256color、linux、vt100、screen等。多数现代终端模拟器默认是xterm或xterm-256color两者对lrzsz的影响不大。但如果你用tmux或screen这类终端复用器需要确认它们对ZModem有额外的转发支持。这里有一个我实际踩过的坑在tmux会话里运行rz/sz经常出现弹窗不出现或乱码的情况。这是因为tmux在内部虚拟了一个终端层ZModem的转义序列被tmux拦截了。解决方法是安装tmux的ZModem插件比如tmux-zmodem或者在tmux里临时使用SETENV方式执行rz/sz更简单粗暴的办法是让用户在tmux会话外执行rz/sz传完文件再回到tmux继续干活。有趣的是很多终端模拟器实际上拦截的是SSH通道里的特定转义序列。ZModem协议在传输前会发送一串特殊的控制字符如**\x13终端捕获到这个信号后弹窗响应用户交互。如果终端捕获逻辑有问题或者终端类型设置得过于古老比如纯vt100控制字符合法性检查可能失败rz/sz就“静默失败”了。遇到这类问题优先检查终端类型设置把它改成xterm或xterm-256color90%的疑难杂症能解决。5. 常见问题与排查技巧实录5.1 问题速查表从现象到根因lrzsz本身是个比较简单的工具但在实际使用中各种环境的差异会导致一些莫名其妙的问题。我把这几年遇到和听到的典型问题整理成一个速查表方便大家按图索骥。问题现象可能原因解决方法执行rz/sz后终端无任何反应终端不支持ZModem协议换用Xshell/SecureCRT/MobaXterm等支持ZModem的终端执行rz/sz后乱码或终端直接卡住终端类型不正确TERM变量异常检查TERM变量改为xterm或xterm-256color上传文件时报错rz: command not foundlrzsz未安装或路径不在PATH中安装lrzsz或检查软链接是否建立上传不了超过2GB的大文件32位系统限制ZModem协议限制换用rsync或sftp传输大文件中文文件名上传后乱码终端编码与服务端编码不一致统一终端和服务端的字符集为UTF-8上传文件到一半断了重新传提示文件存在lrzsz不真正支持续传会重新传整个文件需要续传时使用rsync替代下载文件时弹窗保存但不落盘终端下载目录权限或磁盘空间问题检查本地下载目录空间和权限在tmux/screen里rz/sz没反应tmux拦截了ZModem转义序列安装tmux的ZModem插件或在tmux外执行从串口连接的设备上rz/sz不能使用串口控制台不支持ZModem协议交互串口场景不需要lrzsz直接minicom等工具提示Permission denied当前用户对目标目录没有写权限先cd到可写目录或使用sudo rz这个表是针对我实际运维生涯中遇到问题的总结不同发行版情况可能有些差异但方向大致如此。尤其第一条80%的“rz不起作用”都是因为终端不支持协议——这个问题在给同事排障时出现频率最高每次一排查都发现对方在Windows CMD里直接ssh连服务器那当然不行。5.2 编码问题中文文件名乱码的根治法中文文件名乱码是我见过最多人踩坑的问题尤其在与Windows用户协作时更常见。核心原因在于Windows终端默认用GBK/GB18030编码显示而Linux服务器几乎全部使用UTF-8编码。当文件名含中文时rz上传过程实际上传的是UTF-8编码的字节序列Windows终端再用GBK去解析这些字节自然显示成乱码。排查步骤如下第一步检查服务器的locale设置locale如果LANG不是en_US.UTF-8或zh_CN.UTF-8说明系统基本编码有问题。可以临时设置export LANGzh_CN.UTF-8第二步检查终端软件的编码设置。Xshell里是“文件-属性-终端-编码”SecureCRT在“会话选项-外观-字符编码”里。确保它设置为UTF-8。第三步避免中文文件名。说实话这是最彻底的办法。上传或下载时提前重命名文件不用中文路径。如果文件是客户那边给的中文名绕不开那就先在本地区域里重命名再传用完再改回来。这个土办法看着笨但真的能杜绝一堆麻烦。5.3 大文件与性能边界分析lrzsz虽然好用但它毕竟是为小文件设计的工具性能上限要心里有数。实测下来在局域网环境内千兆网络lrzsz的传输速度大约在5~20MB/s之间取决于你的终端软件实现和CPU性能。这个速度比scp、rsync慢不少因为ZModem协议本身要处理编码、校验、确认等开销而且它走的是终端IO通道本身就不是为高速传输设计的。跨公网传输时速度还受SSH会话本身的瓶颈限制延迟越高ZModem的确认机制就越影响吞吐。如果你要传超过500MB的文件到生产服务器更推荐用rsync它既是增量传输、又支持断点续传、还能限速。lrzsz适合的是大小几KB到几十MB的配置类、日志类、小压缩包类文件。还有一个很多人没注意到的性能杀手是rz/sz在慢速网络下的表现。ZModem协议的确认机制比较啰嗦在延迟超过100ms的链路上时延会成为主要瓶颈传输几MB的文件可能需要几分钟。真遇到这种环境传文件还是优先用支持并发和断点续传的工具吧别折腾lrzsz了。5.4 安全性与权限控制建议lrzsz虽小但用它的时候还是要注意安全细节。我梳理几条实际工作中需要注意的点第一别在不可信的终端里执行rz。因为rz是从“本地”接收文件到服务器如果终端本身被植入恶意脚本对方可能在你敲下rz命令时弹出伪造的传输窗口诱导你上传敏感文件到攻击者控制的路径。虽然这种攻击门槛较高但在混合环境中防人之心不可无。第二下载文件渠道的一致性。sz命令将文件内容发送到“当前会话的终端”也就是说它走的是SSH通道不是额外的网络连接。所以只要你的SSH会话是加密的sz传输过程也是加密的——它不会额外开端口、不会绕过防火墙。很多安全审计同事问过这个问题这里专门说明一下。第三最小权限原则。给运维同事们授权时注意别让普通用户随手往系统关键目录如/etc、/usr/lib里rz上传文件这可能导致配置被意外覆盖或系统文件被篡改。更稳妥的做法是让日常操作用普通用户只有在明确需要时才用sudo写系统目录。6. 从lrzsz到trzsz现代替代方案与扩展思路6.1 trzsz兼容版协议与现代体验lrzsz火了三十多年但它的协议设计毕竟针对旧时代终端。这几年一个叫trzsz的开源项目逐渐进入视野作者是国内的工程师GitHub仓库名为trzsz/trzsz。它完全兼容lrzsz的使用习惯但协议更现代有两个关键改进一是支持普通SSH环境下的文件传输。前面提到Windows原生OpenSSH不支持ZModemtrzsz的方案是用普通终端对话完成传输不依赖终端模拟器的ZModem支持。换句话说你可以在PowerShell里直接ssh连服务器然后执行trz命令弹窗选取本地文件上传这在以前是不可能的。二是更快的传输速度和更好的断点续传。trzsz采用Python实现传输时内存占用可控编码效率比传统ZModem高特别是在高延迟网络下体验提升明显。安装方式也比较简单以Debian系为例# 服务端安装 sudo apt update sudo apt install -y trzsz # 客户端安装Windows下用pip pip install trzsz # 或者直接用trzsz-ssh替代普通ssh命令 trzsz-ssh userservertrzsz工作原理是把文件编码成可打印字符流在SSH会话里通过普通stdin/stdout传输客户端和服务端各自负责编解码。由于它不走ZModem转义序列所以现有的任何终端包括Windows自带CMD理论上都能用——只要该终端能正常显示普通文本输出。在我看来trzsz更适合那些工作环境锁定为Windows原生终端的开发者。但如果你像我一样日常就在Xshell里操作lrzsz其实已经完全够用。两者的使用成本和学习曲线都很低迁移过去没有壁垒。6.2 与scp、rsync、sftp的选型对照在Linux文件传输这个领域工具选择其实没有绝对的优劣关键看场景。我画了一张基于我经验的选型对照方便大家决策工具适用场景优势劣势rz/sz (lrzsz)交互式终端内临时传小文件无需运维之外的额外工具一条命令大文件、大批量文件效率低scp单文件/少量文件安全传输简单可靠支持认证不支持断点续传sftp稳定的文件管理需求支持目录浏览、删除、限速需要交互式客户端rsync大文件、目录同步、增量备份增量传输、断点续传、压缩命令复杂学习曲线较陡trzsz不依赖终端ZModem的临时传普通SSH下可用兼容lrzsz习惯相对较新社区资料少实际选择时我的判断标准是临时、交互、小文件用rz/sz自动化、批量、大文件用rsync需要浏览远程目录结构时用sftp。没有哪一个是银弹不同场景切换使用才是老运维的常规操作。6.3 自动化脚本里的lrzsz虽然lrzsz主要被当成交互式工具使用但在特定自动化场景下你也能看到它的身影。比如在批量交付服务器、需要往二十台服务器分发相同配置文件的场景下如果这些服务器还没有配置好SSH互信rsync反而用起来麻烦。这时候用rz先传到一台机器再用scp分发是比较顺手的操作流# 上传到当前机器 rz # 批量分发到其他服务器 for host in 192.168.1.101 192.168.1.102 192.168.1.103; do scp /tmp/app.conf root${host}:/opt/app/conf/ done还有一个用法是配合expect实现半自动上传。不过说实话expect脚本调rz这个组合在实践里不太稳定因为rz需要终端弹窗交互expect很难捕获这种窗口事件。如果一定要全自动化文件传输建议直接用scp或者rsync加密钥认证。另外提醒一句在CI/CD流水线里不要用rz/sz。流水线是无人为干预的自动化执行环境rz/sz的弹窗交互设计在这里根本走不通。该用scp、rsync、s3cmd、ossutil这些静默工具的时候就老老实实用专业工具。lrzsz的价值定位始终是人机交互场景。7. 实际项目经验与优化心得7.1 服务器批量部署lrzsz的最佳实践如果公司有几十上百台服务器需要统一安装lrzsz一台台手敲命令太傻了。这里分享一套我整理过的批量安装方案。利用psshParallel SSH一次性完成# 安装pssh工具Ubuntu/Debian系 apt install -y pssh # 准备服务器清单文件 cat servers.txt EOF root192.168.1.101 root192.168.1.102 root192.168.1.103 EOF # 批量执行安装命令 pssh -h servers.txt -i yum install -y lrzsz || sudo apt install -y lrzsz如果没有pssh也可以用读者更熟悉的Ansible- hosts: all tasks: - name: Install lrzsz package: name: lrzsz state: present - name: Verify installation shell: | which rz which sz register: result changed_when: falseAnsible的优势在于幂等——不管执行多少次只要系统里已装了lrzsz它就不会重复安装。批量安装以后可以用一个快速循环验证所有服务器的安装结果pssh -h servers.txt -i which rz which sz rz --version | head -n1这一套操作下来五十台服务器的部署大概两三分钟就能完成比我早年一台台SSH上去敲yum install的效率高了一个数量级。7.2 日志归档与定时清理配合在生产环境的日志服务器上lrzsz常与日志归档配合使用。常规做法是先压缩再下载避免传一堆小文件tar czf /tmp/logs_$(date %Y%m%d).tar.gz /var/log/app/ ls -lh /tmp/logs_*.tar.gz sz -y /tmp/logs_$(date %Y%m%d).tar.gz这个流程看起来简单但我操作时习惯加一步校验。因为sz下载后本地文件是否与服务器源文件完全一致肉眼无法确认。我的做法是在服务器上先算好校验值下载后本地再算一次两者比对# 服务器端 md5sum /tmp/logs_$(date %Y%m%d).tar.gz # 本地下载后 md5sum logs_$(date %Y%m%d).tar.gz两次输出的MD5值一致才说明文件传输完整可靠。虽然ZModem协议有校验机制但双保险的习惯值得培养——尤其在传输配置文件、程序包这类万一损坏就麻烦的文件时。归档下载完之后记得清理服务器上的临时压缩包别让/tmp被撑爆rm -f /tmp/logs_*.tar.gz这套“打包→校验→下载→清理”四步走是我在大量日志处理任务中总结出的标准流程。对我这种需要经常从服务器拉日志排查问题的人来说它几乎成了肌肉记忆。7.3 团队协作中的规范制定lrzsz虽然简单但在团队环境中如果每个人用得随意还是会出现文件混乱的情况。我在带团队时立了几条约定效果还挺好统一上传目录。不让同事们在任意目录下rz。约定专用上传暂存区比如/data/upload/上传后的文件由本人尽快移动到目标位置。这样可以避免“文件传上去了但不知道落在哪”的窘境。重要文件必须做校验。传输压缩包、程序安装包等文件时要求服务器端md5sum生成校验值并同步给接收方。这条规范虽然此时只用lrzsz但养成的习惯在ftp或网盘传输时同样受用。下载文件名可追溯。下载到本地的文件建议保持原来的文件名或者补充日期标记。比如app_20240601.log而不要统一改成a.log。听起来是小事但真到追溯问题的时候一个规范命名的日志文件能省去大量时间。这些规范不重但对秩序帮助很大。工具本身不会约束人的行为团队协作的顺畅程度取决于共同恪守的习惯。8. 写在最后的个人体会Linux里的小工具很多lrzsz算是那种乍看不起眼、用上就离不开的类型。它不适合传几十GB的数据库备份也不适合在无人值守的流水线里干活但在日常交互式运维这个场景里几乎找不到比它更顺手的方案。我到现在都记得第一次在Xshell里敲完rz弹出选择窗口时的惊讶——原来文件传输可以这么直接。如果你刚开始用lrzsz我给你的建议很简单遇到传不了大文件、终端不响应这类问题先查看终端软件是否支持ZModem遇到中文乱码先检查UTF-8编码配置遇到tmux里不好用先跳出tmux再执行。这三板斧能解决九成问题。最后分享一个小技巧Xshell里把rz和sz的默认目录都配置好上传目录设成/data/upload/下载目录设成本地的D:\Downloads\。这样敲完命令连路径都不用改传输完的文件自动落在该在的地方——这大概就是工具顺手之后人真正能感受到的效率提升。