远程连着服务器排查问题的时候，想从上面拿一个日志文件回本地，这事有多常见？多让人头疼？一开始我也习惯性用scp，但很快就遇到了麻烦：本地这台电脑没有公网IP，又没有和服务器互通的路由，scp根本找不到回来的路。后来发现，其实压根不用绕那么大一圈——在远程终端里敲一行sz 文件名，弹窗就出现了，文件直接落到你面前。这个命令救了我不止一次命，值得好好讲讲。sz其实是lrzsz这个软件包提供的命令，和rz是一对：rz负责把本地文件上传到服务器，sz负责把服务器上的文件推到本地。它基于ZModem协议，最妙的是，它就搭在你当前这根SSH会话里跑，不需要额外开端口、不需要知道本机IP、不需要配什么服务端。只要你能正常连上服务器，就能用它拿文件。这篇我把自己用sz的完整经验和各种坑梳理一遍，从安装、参数、实战到问题排查都覆盖到，新手看完能直接上手，老手也可以对照看看有没有漏掉什么细节。1. sz到底是个什么工具1.1 为什么"从服务器拿文件"这种小事会卡住很多人先讲个我踩过的真实场景。有一次在客户现场排查服务异常，服务器在一个专网里，我只能通过一个跳板机登录上去。想把这个异常时刻的日志拷贝回本地分析，结果发现：本地电脑和跳板机之间不在一个网段，scp传不了；sftp服务没有对外开放；我们连的完全是一个临时隧道。我当时急得想把日志直接复制到屏幕上。后来旁边一位同事看不下去，敲了一句sz -y /var/log/app/error.log，几秒钟后弹窗就出现了，日志稳稳落进了本地的下载目录。这个经历给了我一个很重要的认知：很多人想当然地认为"传文件就必须靠scp/ftp/sftp"，但实际上，只要你的SSH终端还开着，sz是最后一道保底方案。它不依赖公网地址、不需要额外开放任何端口，数据走的还是当前这条已经建立好的安全通道。这种特性，让它在跳板机、堡垒机、内网隔离这些场景里特别吃香。1.2 sz与rz、lrzsz、ZModem之间的关系sz不是Linux内核自带的命令，它来自一个叫lrzsz的软件包。这个包里最重要的两条命令就是rz和sz：rz（receive）表示我当前这台服务器要"接收"从本地客户端发来的文件，作用是把文件从你的电脑上传到服务器。sz（send）表示我当前这台服务器要"发送"文件到本地客户端，作用是把服务器上的文件下载到你的电脑。这两条命令搭配使用的场景非常多。比如你在本地写好了一个部署脚本，用rz上传上去；跑完之后想拿回一份日志，再用sz拉下来。整个过程完全不需要切换工具。ZModem则是它们底层的传输协议。这个协议最早被设计出来就是为了串口和调制解调器时代的高效文件传输，后来被SSH终端软件集成支持。它有几个挺明显的优点：传输时自带CRC校验，出错会重传；支持一批文件连续传输；可以通过转义机制适应不可靠信道。几十年过去了，这套协议依然又稳又轻，这也是sz至今没有被淘汰的重要原因。1.3 sz的工作方式：一次看似简单实则精巧的握手我刚开始用sz的时候，心里一直有个疑问：我是在终端里输入的命令，它怎么就能不把文件内容哗啦啦地显示在屏幕上，而是精准确认地交给终端软件去保存？后来了解之后才明白，sz运行时和本地终端软件之间有一次协议握手。大概过程是这样：服务器端的sz命令发起一个ZModem的"接收请求"，向客户端（比如Xshell、SecureCRT这类软件）发出一个特定的起始标识。如果这个软件支持ZModem，它就会自动进入接收模式，弹出保存窗口，然后按照协议逐个接收数据包。整个传输过程中，原始字节不会直接打印在你的终端屏幕上，而是被客户端软件截获并写入磁盘。这也是为什么纯命令行终端（比如Windows自带的cmd窗口、某些不含ZModem支持的SSH工具）会卡住——因为没有人响应这个协议请求。好用之处就在于，这个手写识别过程对用户几乎是透明的。你只需要记住：在服务器上敲sz 文件，然后等弹窗，选个保存目录，完事。2. 装好sz：安装、终端配置与验证2.1 主流发行版的安装命令安装lrzsz非常简单，大多数Linux发行版都有现成的软件包。Debian/Ubuntu系列：sudo apt update sudo apt install -y lrzszCentOS/RHEL系列：sudo yum install -y lrzsz新一点的CentOS/RHEL版本用：sudo dnf install -y lrzsz如果服务器没有root权限，也没关系，可以下载源码包手动编译安装，但这种情况相对少见。大多数场景下，只要你拥有sudo权限，一行命令就搞定了。安装完成后，可以确认一下命令是否就位：which sz sz -h我自己的习惯是先跑一下sz -h，它会把所有支持的参数列出来，这比查文档直观得多。只要能正常列出帮助信息，说明安装没问题。2.2 "装好了却不能用"才是最常见的坑很多人装完lrzsz，兴冲冲地敲了一条sz file.txt，然后发现终端跟死了一样，光标闪半天没反应。这里要重点提醒：sz能不能用，其实取决于你本地用的终端软件是否支持ZModem协议，而不是服务器端装没装好。我实测过，下面这几类终端软件是支持的：Xshell：默认支持，传输时会弹出接收/发送文件的对话框，用起来很顺手。SecureCRT：支持，需要在会话选项里确认开启了ZModem，还可以自定义本地接收目录。MobaXterm：支持，自带文件传输按钮，和sz/rz配合很丝滑。FinalShell：内置了rz/zmodem支持，很多运维朋友在用。不支持的也很明显：Windows自带的PowerShell或cmd窗口。纯Putty（除非配合配套工具，否则本身不带ZModem）。macOS自带的Terminal直接ssh，也不支持。如果你平时用的是这些不支持的终端，那么服务器上sz装得再完美也没用，敲下去自然就卡着不动。解决办法很简单：换一个支持ZModem的终端软件登录，再敲sz试试。2.3 三分钟确认环境可用分享一个我每次都会用的验证流程。在一台装好lrzsz的服务器上，先随便生成一个测试文件：echo "sz test content" > /tmp/sz_test.txt sz -y /tmp/sz_test.txt如果终端软件弹出保存窗口，保存之后查看内容，能看到上面那行字，就说明整条链路——服务器lrzsz、SSH连接、本地终端协议支持——全部打通了。这样后面正式传文件才不会被"为什么卡住"这种问题干扰判断。3. sz命令参数详解：常用选项与背后的取舍3.1 最基础用法：sz file最基础的用法就是sz 文件路径。比如：sz /var/log/nginx/access.log命令执行后，本地终端会弹出一个文件保存对话框，选好位置，文件就传过来了。默认情况下，如果本地已经有同名文件，终端软件通常会问你是覆盖还是忽略，不同软件交互方式不一样。这里有个细节：sz支持同时传多个文件，直接把文件名罗列在后面就行：sz /var/log/nginx/access.log /var/log/nginx/error.log /tmp/a.txt传多个文件时，ZModem协议会按顺序一个一个来，终端软件一般会在一个对话框里批量接收，或者逐个提示。我建议如果你要传的文件比较多、且都在同一个目录下，先cd到那个目录，再用相对路径传，命令看起来更干净，也不容易拼错绝对路径。3.2 参数对比表与逐个说明sz的命令参数不算多，但有几个在实际工作中很有价值。我整理了一个常用参数表：参数作用我常用的场景-y同名文件自动覆盖，不再提问批量传输、脚本里自动执行-b强制二进制模式传输压缩包、可执行文件、图片等-aASCII模式传输纯文本日志，会把换行符做转换-e转义所有控制字符网络不稳定、卡片式连接时更稳-k跳过本地已经存在的同名文件批量传文件时不想覆盖已有文件-q安静模式，减少提示输出传文件时不想看一堆状态信息-v详细输出模式排查问题时看传输过程-d传输完成后删除服务器上的源文件清理临时文件时很实用-E接收端重命名文件，避免覆盖文件已经存在于本地且不想覆盖-h查看帮助任何时候需要查参数这里需要特别强调一下-y和-k的区别。-y是"本地只要有同名文件就直接覆盖"，适合你明确知道就是要用最新文件替换本地旧文件的情况。-k恰恰相反，是"本地只要已有同名文件就自动跳过"，适合你只是想补齐缺失文件、不想动已有文件的情况。两个命令都用过之后，我建议你在不确定的时候宁可先用-k，多传一次也不至于弄丢本地已有的东西。-d这个参数很多人可能没注意过。它的效果是文件传输成功后，服务器端的源文件会被删掉。有一次我在服务器上打包了一个临时目录，准备拉到本地后清掉服务器上的压缩包，直接把-d加上，省了一条rm命令。不过使用前要非常确定文件确实传成功了，毕竟删除操作不可逆。3.3 参数组合实例：一条带参命令的完整解读再分享一条我平时用得最多的命令：sz -bye /var/log/nginx/access.log拆开看：-b表示二进制传输，不管这是什么类型的文件都原样发；-y表示本地已有同名文件就直接覆盖，不用弹窗问我；-e表示对传输内容做转义，提高在长连接、弱网环境下的成功率。三者合在一起，基本就是"快速、省事、尽量稳"的组合。为什么不建议每次都手动敲这三个参数？因为确实比较容易记混。我自己更常用的方式是在Shell里配置一个别名，比如：alias szb='sz -bye'之后想传文件就敲szb 文件名，既省事又不容易漏参数。这种小技巧用顺了会相当顺手。还要提醒一点：-a和-b不要混着用。-a适合纯文本，它会对换行符做处理；如果用它传二进制文件，文件内容很有可能会被改坏。反过来，-b传纯文本也能用，只是本地保存的换行符样式可能和你预期的不同。所以，通用原则是：只要是压缩包、可执行文件、图片、视频，一律用-b。4. 实战案例：从日志下载到批量打包4.1 案例一：把单个日志文件拉回本地先说最常见的场景：服务器上某个应用日志已经好几百兆了，我想把它拉到本地仔细搜。常规做法是分两步走。第一步，先看看文件在哪、有多大：ls -lh /var/log/myapp/app.log第二步，直接传：cd /var/log/myapp sz -bye app.log终端弹出保存窗口后，选一个本地目录，比如D:\logs，文件就会开始传。传完以后，我看一眼本地文件大小，和服务器上对比一致，就说明传输完整。为什么先cd到日志目录再传？因为sz支持相对路径，这样命令更简洁，而且可以避免不小心拼错一长串绝对路径的问题。4.2 案例二：整个目录传输前先打包很多人第一次用sz传目录会问：sz能直接传文件夹吗？答案是不能。sz只传文件，不传目录结构。所以如果需要把一个目录完整搬回本地，正确做法是先打包再传。我跑过一次模拟项目X的配置备份迁移，整个目录几十个小文件，直接逐个传太啰嗦。我的操作是：cd /opt/myapp tar czf myapp_backup.tar.gz config/ scripts/ static/ ls -lh myapp_backup.tar.gz sz -bye myapp_backup.tar.gz传完之后在本地解压：tar xzf myapp_backup.tar.gz这样目录结构、文件权限都保留下来了。打包这一步还能顺便做一下压缩，几十兆的文件压到几兆，传输时间明显缩短。我建议打包的时候尽量在目标目录的父目录里操作，这样生成的压缩包里不会带一串无用的绝对路径，本地解压时也更干净。4.3 案例三：批量文件传输与自动覆盖还有一种很常见的情况：服务器上有一个目录里存着最近几天的业务报表，文件名有规律，比如report_20250101.csv、report_20250102.csv。我想把这几个文件一起传到本地。先看一下目录内容确认文件名：ls /data/reports/然后一次性传：cd /data/reports sz -bye report_20250101.csv report_20250102.csv report_20250103.csv终端会依次接收三个文件。加了-y的好处是，如果本地之前已经存过同名文件，不会再弹窗反复问，直接覆盖，整个流程非常连贯。如果某天你只是想把缺失的报表补上，已经下载过的不想再重复拉一遍，这时候把-y换成-k更合适，本地已有的会跳过，只传缺失的。4.4 案例四：全流程梳理最后分享一个把sz放进完整工作流的例子。某次需要从线上服务器提取一批数据处理结果，过程是这样的：先进入结果目录，查看文件大小和数量：cd /data/output du -sh * | sort -h发现结果文件有7个，总计约120MB。因为数据结果比较大，我决定先打包再传：tar czf result_all.tar.gz result_*.csv sz -bye result_all.tar.gz传到本地后，先做一下校验，确认文件没缺没坏：ls -l result_all.tar.gz tar tzf result_all.tar.gz | head再解压使用。这个过程看起来平平无奇，但我实际体验下来非常省心，尤其是不用等scp去建连接，也不用担心端口不通的问题，整个流程一气呵成。5. 常见问题与排查技巧实录5.1 sz敲下去没反应、终端卡住这是我被问过最多的问题，也是我最初自己卡住过的坑。原因我在前面已经讲过了：本地终端软件不支持ZModem协议。排查顺序是这样：你先确认sz命令本身没问题——直接看命令是否存在于系统里：which sz如果命令存在，但你敲完sz 文件名之后终端没有任何反馈，试试按Ctrl+C取消，然后检查本地终端是不是Xshell、SecureCRT、MobaXterm等支持ZModem的软件。如果是纯命令行SSH客户端（比如用Windows Terminal直接ssh、或者Putty），那基本可以确定就是不支持ZModem。解决方式很粗暴：换一个终端软件重连一下，再敲一次。还有一种情况比较隐蔽——终端软件支持ZModem，但相关设置被关掉了。SecureCRT里需要确认会话选项中有没有启用ZModem，Xshell里可以看看协议过滤器设置。一般默认都是开着的，但如果你之前改过配置，确实可能被关掉。5.2 文件传下来打不开、内容变乱码乱码分两种情况：文件名乱码和文件内容乱码。文件名乱码通常是编码不一致引起的。服务器上的文件名是UTF-8编码的中文，传到Windows本地后，如果终端软件不支持或者配置不对，显示出来就是一堆乱码。这个我试过，内容本身一般没有问题，纯粹是显示层的问题。解决办法是，要么改文件名成英文再传，要么在终端软件的编码设置里统一调整。文件内容乱码或者文件直接打不开，最常见的原因就是传输模式选错了。如果你用了-a传二进制文件（比如zip包、可执行程序），传输过程中换行符被转换了，文件结构也就破坏了。解决方式就是老老实实用-b二进制模式重新传一次。另外一个可能的坑是传输过程中网络异常，导致文件不完整，这时需要重新传或者用-v打开详细输出看看有没有报错。5.3 传了一半断了，怎么办ZModem协议本身有CRC校验和错误重传机制，但在网络抖动特别厉害的环境下，传输中断仍然可能发生。我遇到这种情况的处理方式很务实：如果传的是大文件，先想清楚能不能拆小再传，或者先压缩再传，把传输时长降下来，中断概率自然就小了。如果文件已经传到一半断了，本地通常只会留下一个不完整的文件，这时候我一般直接删掉本地这个残次品，重新传一遍完整的。因为ZModem虽然理论上支持续传，但终端软件的支持程度参差不齐，与其在续传配置上折腾，不如重传一遍来得稳。另外，长连接如果经常断，建议先检查SSH连接本身是否稳定。我实际用过-e参数后，在不太稳定的链路上传输成功率确实高了一些，原理是它会转义控制字符，避免一些误触发。5.4 文件保存到哪里去了：找文件的痛点很多人第一次用sz成功弹窗保存后，第二次就找不到文件存哪里了。这是因为终端软件的默认保存目录各不相同：Xshell一般会弹窗让你选择，SecureCRT可以在全局设置里指定ZModem接收文件目录，MobaXterm通常会在会话设定里指定下载目录。我的建议是，用哪个终端软件，就先把它的ZModem下载目录固定下来。比如我在SecureCRT里就把接收目录设置成固定的D:\downloads\zmodem，以后不管在哪个会话里点接收，文件都会稳稳地落进这个目录，再也不会出现"文件传哪里去了"的尴尬。这个设置就在全局选项 → 传输/文件传输 → ZModem 相关的配置里，不同版本位置略有差异。5.5 安全顾虑：sz传输是不是明文有过一个同学问过我，sz传文件是不是像老式ftp那样明文裸奔，中间会不会被人截获？这个问题要分两层看。sz本身跑在你当前已经建立的SSH连接里，只要你的SSH是加密的，那么ZModem传输的数据也是通过这个加密通道走的，并不会像ftp那样以明文形式暴露在网络上。从我实际使用经历来说，sz传文件的安全性取决于你的SSH会话安全性。比起ftp，它要好得多。但要注意另一个安全细节：如果你通过一台不安全的跳板机在使用sz，文件内容会以明文形式出现在跳板机所在环境里，因为sz是在服务器侧发起协议交互的。所以，涉及敏感数据时，不要只依赖sz是否加密，还要考虑你的登录链路是否全程可信。另外传输结束后，记得检查一下命令历史，不要留下明显的文件路径痕迹，有些服务器被人翻history也是麻烦事。6. sz与scp、ftp、sftp的选型思考6.1 一张表看完区别用了这么久，我自己的体会是，sz不是万能的，它只是众多文件传输工具里的一把好手。为了帮大家做一个更明智的选型，我把自己常用的几个方式放在一起对比：工具依赖条件方向突出优点明显短板sz/rzSSH会话 + 终端支持ZModem服务器 ↔ 本机免开端口，交互自然，协议校验强不适合脚本化海量传输，依赖终端软件scpSSH服务端支持服务器 ↔ 本机/服务器命令简单，自动化友好需要一条可直达的网络路径sftpSSH服务端支持服务器 ↔ 本机/服务器可浏览目录，适合交互操作依赖SSH子系统支持rsync两端安装rsync本机 ↔ 服务器增量传输、断点续传、同步目录配置稍微复杂，需要路径可达ftp/tftp专门的FTP服务服务器 ↔ 本机老设备支持多明文传输，端口多，安全性差我平时选型的逻辑是这样的：如果是临时拉一个文件下来，用sz最顺手；如果是要做一个自动化的同步任务，rsync是第一选择；如果只是想偶尔看看服务器上有哪些文件再决定拿哪个，sftp浏览目录比sz盲猜文件名舒服得多。6.2 什么时候我应该用sz，什么时候别用sz适合用sz的场景，我总结下来有四个：SSH已经连接上了，但网络路径不是很直接（比如通过跳板机登录），scp根本通不了，sz是保底方案。文件量不大，就是几十上百MB以内，sz交互式传一下很轻快。目标设备是网络设备、嵌入式系统，不支持sftp子系统，但装了lrzsz。你要反复在服务器和本地之间传配置、传日志，sz + 终端软件弹窗的模式效率很高。不适合用sz的场景也有几个：要传几个GB的大文件，而且网络很一般，建议用rsync，支持断点续传。要把一个目录树原封不动搬过去，tar+scp或rsync更靠谱，sz没法直接带目录结构。自动化脚本里需要稳定传输，sz有时候会弹窗等人操作，不如scp/rsync安静执行。本地终端不支持ZModem，那就别在sz上较劲，直接用scp或其他工具。为什么我强调要基于场景选型？因为有一次我为了省事，在自动化脚本里用了sz，结果每次都要在终端弹个窗出来手工确认，脚本等于白写。后来改成rsync，整晚无人值守跑完，体验天差地别。工具本身没有绝对的好坏，用对场景才顺手。最后再补一个小技巧：如果你偶尔需要在服务器上快速发个文件给别人，又不想暴露服务器路径，可以考虑把文件放到一个临时目录，改个简单文件名，用sz下发之后顺手加上-d参数删掉源文件。这样既方便了协作，也减少文件散落在服务器上的风险。这套玩法我用了很长一段时间，一直很顺手。
远程连着服务器排查问题的时候，想从上面拿一个日志文件回本地，这事有多常见？多让人头疼？一开始我也习惯性用scp，但很快就遇到了麻烦：本地这台电脑没有公网IP，又没有和服务器互通的路由，scp根本找不到回来的路。后来发现，其实压根不用绕那么大一圈——在远程终端里敲一行sz 文件名，弹窗就出现了，文件直接落到你面前。这个命令救了我不止一次命，值得好好讲讲。sz其实是lrzsz这个软件包提供的命令，和rz是一对：rz负责把本地文件上传到服务器，sz负责把服务器上的文件推到本地。它基于ZModem协议，最妙的是，它就搭在你当前这根SSH会话里跑，不需要额外开端口、不需要知道本机IP、不需要配什么服务端。只要你能正常连上服务器，就能用它拿文件。这篇我把自己用sz的完整经验和各种坑梳理一遍，从安装、参数、实战到问题排查都覆盖到，新手看完能直接上手，老手也可以对照看看有没有漏掉什么细节。1. sz到底是个什么工具1.1 为什么"从服务器拿文件"这种小事会卡住很多人先讲个我踩过的真实场景。有一次在客户现场排查服务异常，服务器在一个专网里，我只能通过一个跳板机登录上去。想把这个异常时刻的日志拷贝回本地分析，结果发现：本地电脑和跳板机之间不在一个网段，scp传不了；sftp服务没有对外开放；我们连的完全是一个临时隧道。我当时急得想把日志直接复制到屏幕上。后来旁边一位同事看不下去，敲了一句sz -y /var/log/app/error.log，几秒钟后弹窗就出现了，日志稳稳落进了本地的下载目录。这个经历给了我一个很重要的认知：很多人想当然地认为"传文件就必须靠scp/ftp/sftp"，但实际上，只要你的SSH终端还开着，sz是最后一道保底方案。它不依赖公网地址、不需要额外开放任何端口，数据走的还是当前这条已经建立好的安全通道。这种特性，让它在跳板机、堡垒机、内网隔离这些场景里特别吃香。1.2 sz与rz、lrzsz、ZModem之间的关系sz不是Linux内核自带的命令，它来自一个叫lrzsz的软件包。这个包里最重要的两条命令就是rz和sz：rz（receive）表示我当前这台服务器要"接收"从本地客户端发来的文件，作用是把文件从你的电脑上传到服务器。sz（send）表示我当前这台服务器要"发送"文件到本地客户端，作用是把服务器上的文件下载到你的电脑。这两条命令搭配使用的场景非常多。比如你在本地写好了一个部署脚本，用rz上传上去；跑完之后想拿回一份日志，再用sz拉下来。整个过程完全不需要切换工具。ZModem则是它们底层的传输协议。这个协议最早被设计出来就是为了串口和调制解调器时代的高效文件传输，后来被SSH终端软件集成支持。它有几个挺明显的优点：传输时自带CRC校验，出错会重传；支持一批文件连续传输；可以通过转义机制适应不可靠信道。几十年过去了，这套协议依然又稳又轻，这也是sz至今没有被淘汰的重要原因。1.3 sz的工作方式：一次看似简单实则精巧的握手我刚开始用sz的时候，心里一直有个疑问：我是在终端里输入的命令，它怎么就能不把文件内容哗啦啦地显示在屏幕上，而是精准确认地交给终端软件去保存？后来了解之后才明白，sz运行时和本地终端软件之间有一次协议握手。大概过程是这样：服务器端的sz命令发起一个ZModem的"接收请求"，向客户端（比如Xshell、SecureCRT这类软件）发出一个特定的起始标识。如果这个软件支持ZModem，它就会自动进入接收模式，弹出保存窗口，然后按照协议逐个接收数据包。整个传输过程中，原始字节不会直接打印在你的终端屏幕上，而是被客户端软件截获并写入磁盘。这也是为什么纯命令行终端（比如Windows自带的cmd窗口、某些不含ZModem支持的SSH工具）会卡住——因为没有人响应这个协议请求。好用之处就在于，这个手写识别过程对用户几乎是透明的。你只需要记住：在服务器上敲sz 文件，然后等弹窗，选个保存目录，完事。2. 装好sz：安装、终端配置与验证2.1 主流发行版的安装命令安装lrzsz非常简单，大多数Linux发行版都有现成的软件包。Debian/Ubuntu系列：sudo apt update sudo apt install -y lrzszCentOS/RHEL系列：sudo yum install -y lrzsz新一点的CentOS/RHEL版本用：sudo dnf install -y lrzsz如果服务器没有root权限，也没关系，可以下载源码包手动编译安装，但这种情况相对少见。大多数场景下，只要你拥有sudo权限，一行命令就搞定了。安装完成后，可以确认一下命令是否就位：which sz sz -h我自己的习惯是先跑一下sz -h，它会把所有支持的参数列出来，这比查文档直观得多。只要能正常列出帮助信息，说明安装没问题。2.2 "装好了却不能用"才是最常见的坑很多人装完lrzsz，兴冲冲地敲了一条sz file.txt，然后发现终端跟死了一样，光标闪半天没反应。这里要重点提醒：sz能不能用，其实取决于你本地用的终端软件是否支持ZModem协议，而不是服务器端装没装好。我实测过，下面这几类终端软件是支持的：Xshell：默认支持，传输时会弹出接收/发送文件的对话框，用起来很顺手。SecureCRT：支持，需要在会话选项里确认开启了ZModem，还可以自定义本地接收目录。MobaXterm：支持，自带文件传输按钮，和sz/rz配合很丝滑。FinalShell：内置了rz/zmodem支持，很多运维朋友在用。不支持的也很明显：Windows自带的PowerShell或cmd窗口。纯Putty（除非配合配套工具，否则本身不带ZModem）。macOS自带的Terminal直接ssh，也不支持。如果你平时用的是这些不支持的终端，那么服务器上sz装得再完美也没用，敲下去自然就卡着不动。解决办法很简单：换一个支持ZModem的终端软件登录，再敲sz试试。2.3 三分钟确认环境可用分享一个我每次都会用的验证流程。在一台装好lrzsz的服务器上，先随便生成一个测试文件：echo "sz test content" > /tmp/sz_test.txt sz -y /tmp/sz_test.txt如果终端软件弹出保存窗口，保存之后查看内容，能看到上面那行字，就说明整条链路——服务器lrzsz、SSH连接、本地终端协议支持——全部打通了。这样后面正式传文件才不会被"为什么卡住"这种问题干扰判断。3. sz命令参数详解：常用选项与背后的取舍3.1 最基础用法：sz file最基础的用法就是sz 文件路径。比如：sz /var/log/nginx/access.log命令执行后，本地终端会弹出一个文件保存对话框，选好位置，文件就传过来了。默认情况下，如果本地已经有同名文件，终端软件通常会问你是覆盖还是忽略，不同软件交互方式不一样。这里有个细节：sz支持同时传多个文件，直接把文件名罗列在后面就行：sz /var/log/nginx/access.log /var/log/nginx/error.log /tmp/a.txt传多个文件时，ZModem协议会按顺序一个一个来，终端软件一般会在一个对话框里批量接收，或者逐个提示。我建议如果你要传的文件比较多、且都在同一个目录下，先cd到那个目录，再用相对路径传，命令看起来更干净，也不容易拼错绝对路径。3.2 参数对比表与逐个说明sz的命令参数不算多，但有几个在实际工作中很有价值。我整理了一个常用参数表：参数作用我常用的场景-y同名文件自动覆盖，不再提问批量传输、脚本里自动执行-b强制二进制模式传输压缩包、可执行文件、图片等-aASCII模式传输纯文本日志，会把换行符做转换-e转义所有控制字符网络不稳定、卡片式连接时更稳-k跳过本地已经存在的同名文件批量传文件时不想覆盖已有文件-q安静模式，减少提示输出传文件时不想看一堆状态信息-v详细输出模式排查问题时看传输过程-d传输完成后删除服务器上的源文件清理临时文件时很实用-E接收端重命名文件，避免覆盖文件已经存在于本地且不想覆盖-h查看帮助任何时候需要查参数这里需要特别强调一下-y和-k的区别。-y是"本地只要有同名文件就直接覆盖"，适合你明确知道就是要用最新文件替换本地旧文件的情况。-k恰恰相反，是"本地只要已有同名文件就自动跳过"，适合你只是想补齐缺失文件、不想动已有文件的情况。两个命令都用过之后，我建议你在不确定的时候宁可先用-k，多传一次也不至于弄丢本地已有的东西。-d这个参数很多人可能没注意过。它的效果是文件传输成功后，服务器端的源文件会被删掉。有一次我在服务器上打包了一个临时目录，准备拉到本地后清掉服务器上的压缩包，直接把-d加上，省了一条rm命令。不过使用前要非常确定文件确实传成功了，毕竟删除操作不可逆。3.3 参数组合实例：一条带参命令的完整解读再分享一条我平时用得最多的命令：sz -bye /var/log/nginx/access.log拆开看：-b表示二进制传输，不管这是什么类型的文件都原样发；-y表示本地已有同名文件就直接覆盖，不用弹窗问我；-e表示对传输内容做转义，提高在长连接、弱网环境下的成功率。三者合在一起，基本就是"快速、省事、尽量稳"的组合。为什么不建议每次都手动敲这三个参数？因为确实比较容易记混。我自己更常用的方式是在Shell里配置一个别名，比如：alias szb='sz -bye'之后想传文件就敲szb 文件名，既省事又不容易漏参数。这种小技巧用顺了会相当顺手。还要提醒一点：-a和-b不要混着用。-a适合纯文本，它会对换行符做处理；如果用它传二进制文件，文件内容很有可能会被改坏。反过来，-b传纯文本也能用，只是本地保存的换行符样式可能和你预期的不同。所以，通用原则是：只要是压缩包、可执行文件、图片、视频，一律用-b。4. 实战案例：从日志下载到批量打包4.1 案例一：把单个日志文件拉回本地先说最常见的场景：服务器上某个应用日志已经好几百兆了，我想把它拉到本地仔细搜。常规做法是分两步走。第一步，先看看文件在哪、有多大：ls -lh /var/log/myapp/app.log第二步，直接传：cd /var/log/myapp sz -bye app.log终端弹出保存窗口后，选一个本地目录，比如D:\logs，文件就会开始传。传完以后，我看一眼本地文件大小，和服务器上对比一致，就说明传输完整。为什么先cd到日志目录再传？因为sz支持相对路径，这样命令更简洁，而且可以避免不小心拼错一长串绝对路径的问题。4.2 案例二：整个目录传输前先打包很多人第一次用sz传目录会问：sz能直接传文件夹吗？答案是不能。sz只传文件，不传目录结构。所以如果需要把一个目录完整搬回本地，正确做法是先打包再传。我跑过一次模拟项目X的配置备份迁移，整个目录几十个小文件，直接逐个传太啰嗦。我的操作是：cd /opt/myapp tar czf myapp_backup.tar.gz config/ scripts/ static/ ls -lh myapp_backup.tar.gz sz -bye myapp_backup.tar.gz传完之后在本地解压：tar xzf myapp_backup.tar.gz这样目录结构、文件权限都保留下来了。打包这一步还能顺便做一下压缩，几十兆的文件压到几兆，传输时间明显缩短。我建议打包的时候尽量在目标目录的父目录里操作，这样生成的压缩包里不会带一串无用的绝对路径，本地解压时也更干净。4.3 案例三：批量文件传输与自动覆盖还有一种很常见的情况：服务器上有一个目录里存着最近几天的业务报表，文件名有规律，比如report_20250101.csv、report_20250102.csv。我想把这几个文件一起传到本地。先看一下目录内容确认文件名：ls /data/reports/然后一次性传：cd /data/reports sz -bye report_20250101.csv report_20250102.csv report_20250103.csv终端会依次接收三个文件。加了-y的好处是，如果本地之前已经存过同名文件，不会再弹窗反复问，直接覆盖，整个流程非常连贯。如果某天你只是想把缺失的报表补上，已经下载过的不想再重复拉一遍，这时候把-y换成-k更合适，本地已有的会跳过，只传缺失的。4.4 案例四：全流程梳理最后分享一个把sz放进完整工作流的例子。某次需要从线上服务器提取一批数据处理结果，过程是这样的：先进入结果目录，查看文件大小和数量：cd /data/output du -sh * | sort -h发现结果文件有7个，总计约120MB。因为数据结果比较大，我决定先打包再传：tar czf result_all.tar.gz result_*.csv sz -bye result_all.tar.gz传到本地后，先做一下校验，确认文件没缺没坏：ls -l result_all.tar.gz tar tzf result_all.tar.gz | head再解压使用。这个过程看起来平平无奇，但我实际体验下来非常省心，尤其是不用等scp去建连接，也不用担心端口不通的问题，整个流程一气呵成。5. 常见问题与排查技巧实录5.1 sz敲下去没反应、终端卡住这是我被问过最多的问题，也是我最初自己卡住过的坑。原因我在前面已经讲过了：本地终端软件不支持ZModem协议。排查顺序是这样：你先确认sz命令本身没问题——直接看命令是否存在于系统里：which sz如果命令存在，但你敲完sz 文件名之后终端没有任何反馈，试试按Ctrl+C取消，然后检查本地终端是不是Xshell、SecureCRT、MobaXterm等支持ZModem的软件。如果是纯命令行SSH客户端（比如用Windows Terminal直接ssh、或者Putty），那基本可以确定就是不支持ZModem。解决方式很粗暴：换一个终端软件重连一下，再敲一次。还有一种情况比较隐蔽——终端软件支持ZModem，但相关设置被关掉了。SecureCRT里需要确认会话选项中有没有启用ZModem，Xshell里可以看看协议过滤器设置。一般默认都是开着的，但如果你之前改过配置，确实可能被关掉。5.2 文件传下来打不开、内容变乱码乱码分两种情况：文件名乱码和文件内容乱码。文件名乱码通常是编码不一致引起的。服务器上的文件名是UTF-8编码的中文，传到Windows本地后，如果终端软件不支持或者配置不对，显示出来就是一堆乱码。这个我试过，内容本身一般没有问题，纯粹是显示层的问题。解决办法是，要么改文件名成英文再传，要么在终端软件的编码设置里统一调整。文件内容乱码或者文件直接打不开，最常见的原因就是传输模式选错了。如果你用了-a传二进制文件（比如zip包、可执行程序），传输过程中换行符被转换了，文件结构也就破坏了。解决方式就是老老实实用-b二进制模式重新传一次。另外一个可能的坑是传输过程中网络异常，导致文件不完整，这时需要重新传或者用-v打开详细输出看看有没有报错。5.3 传了一半断了，怎么办ZModem协议本身有CRC校验和错误重传机制，但在网络抖动特别厉害的环境下，传输中断仍然可能发生。我遇到这种情况的处理方式很务实：如果传的是大文件，先想清楚能不能拆小再传，或者先压缩再传，把传输时长降下来，中断概率自然就小了。如果文件已经传到一半断了，本地通常只会留下一个不完整的文件，这时候我一般直接删掉本地这个残次品，重新传一遍完整的。因为ZModem虽然理论上支持续传，但终端软件的支持程度参差不齐，与其在续传配置上折腾，不如重传一遍来得稳。另外，长连接如果经常断，建议先检查SSH连接本身是否稳定。我实际用过-e参数后，在不太稳定的链路上传输成功率确实高了一些，原理是它会转义控制字符，避免一些误触发。5.4 文件保存到哪里去了：找文件的痛点很多人第一次用sz成功弹窗保存后，第二次就找不到文件存哪里了。这是因为终端软件的默认保存目录各不相同：Xshell一般会弹窗让你选择，SecureCRT可以在全局设置里指定ZModem接收文件目录，MobaXterm通常会在会话设定里指定下载目录。我的建议是，用哪个终端软件，就先把它的ZModem下载目录固定下来。比如我在SecureCRT里就把接收目录设置成固定的D:\downloads\zmodem，以后不管在哪个会话里点接收，文件都会稳稳地落进这个目录，再也不会出现"文件传哪里去了"的尴尬。这个设置就在全局选项 → 传输/文件传输 → ZModem 相关的配置里，不同版本位置略有差异。5.5 安全顾虑：sz传输是不是明文有过一个同学问过我，sz传文件是不是像老式ftp那样明文裸奔，中间会不会被人截获？这个问题要分两层看。sz本身跑在你当前已经建立的SSH连接里，只要你的SSH是加密的，那么ZModem传输的数据也是通过这个加密通道走的，并不会像ftp那样以明文形式暴露在网络上。从我实际使用经历来说，sz传文件的安全性取决于你的SSH会话安全性。比起ftp，它要好得多。但要注意另一个安全细节：如果你通过一台不安全的跳板机在使用sz，文件内容会以明文形式出现在跳板机所在环境里，因为sz是在服务器侧发起协议交互的。所以，涉及敏感数据时，不要只依赖sz是否加密，还要考虑你的登录链路是否全程可信。另外传输结束后，记得检查一下命令历史，不要留下明显的文件路径痕迹，有些服务器被人翻history也是麻烦事。6. sz与scp、ftp、sftp的选型思考6.1 一张表看完区别用了这么久，我自己的体会是，sz不是万能的，它只是众多文件传输工具里的一把好手。为了帮大家做一个更明智的选型，我把自己常用的几个方式放在一起对比：工具依赖条件方向突出优点明显短板sz/rzSSH会话 + 终端支持ZModem服务器 ↔ 本机免开端口，交互自然，协议校验强不适合脚本化海量传输，依赖终端软件scpSSH服务端支持服务器 ↔ 本机/服务器命令简单，自动化友好需要一条可直达的网络路径sftpSSH服务端支持服务器 ↔ 本机/服务器可浏览目录，适合交互操作依赖SSH子系统支持rsync两端安装rsync本机 ↔ 服务器增量传输、断点续传、同步目录配置稍微复杂，需要路径可达ftp/tftp专门的FTP服务服务器 ↔ 本机老设备支持多明文传输，端口多，安全性差我平时选型的逻辑是这样的：如果是临时拉一个文件下来，用sz最顺手；如果是要做一个自动化的同步任务，rsync是第一选择；如果只是想偶尔看看服务器上有哪些文件再决定拿哪个，sftp浏览目录比sz盲猜文件名舒服得多。6.2 什么时候我应该用sz，什么时候别用sz适合用sz的场景，我总结下来有四个：SSH已经连接上了，但网络路径不是很直接（比如通过跳板机登录），scp根本通不了，sz是保底方案。文件量不大，就是几十上百MB以内，sz交互式传一下很轻快。目标设备是网络设备、嵌入式系统，不支持sftp子系统，但装了lrzsz。你要反复在服务器和本地之间传配置、传日志，sz + 终端软件弹窗的模式效率很高。不适合用sz的场景也有几个：要传几个GB的大文件，而且网络很一般，建议用rsync，支持断点续传。要把一个目录树原封不动搬过去，tar+scp或rsync更靠谱，sz没法直接带目录结构。自动化脚本里需要稳定传输，sz有时候会弹窗等人操作，不如scp/rsync安静执行。本地终端不支持ZModem，那就别在sz上较劲，直接用scp或其他工具。为什么我强调要基于场景选型？因为有一次我为了省事，在自动化脚本里用了sz，结果每次都要在终端弹个窗出来手工确认，脚本等于白写。后来改成rsync，整晚无人值守跑完，体验天差地别。工具本身没有绝对的好坏，用对场景才顺手。最后再补一个小技巧：如果你偶尔需要在服务器上快速发个文件给别人，又不想暴露服务器路径，可以考虑把文件放到一个临时目录，改个简单文件名，用sz下发之后顺手加上-d参数删掉源文件。这样既方便了协作，也减少文件散落在服务器上的风险。这套玩法我用了很长一段时间，一直很顺手。