在两台 Linux 机器之间传文件这个需求听着基础真做起来门道不少。绝大多数人最先想到的是 scp一条命令就能把文件推到另一台机器上可当你需要同步几十 GB 的目录、或者机器之间只有临时网络环境、再或者 SSH 服务没开而你也没权限装东西的时候光会 scp 就远远不够了。我这些年维护过的服务器、帮人处理的临时传输需求加起来至少上百次踩过的坑包括文件传一半断掉、目录权限错乱、中文字符乱码、两端网速明明很好却卡在密钥认证上……这些经验让我养成了一个习惯先把传输场景想清楚再选工具最后才写脚本。所以这篇文章不是简单罗列几条命令而是把“两台 Linux 之间传输文件”这件事完整拆开先说“直连传输”到底指什么、什么场景最需要它再对比 scp、rsync、netcat 三种主流方式的核心原理然后给出一步步的实操过程和可直接复制的 bash 脚本。无论你是刚接触 Linux 的运维新人还是要批量同步数据的开发都能从里面拿到一套既能应急、又能长期使用的方案。1. 先盘需求直连传输到底解决什么问题1.1 直连传输为什么经常被低估所谓“直连传输”是指两台 Linux 机器之间直接建立网络连接完成数据复制不经过网盘、不经过邮件附件、也不经过一个常驻的 HTTP/FTP 中转服务器。两台机器可能在同一台交换机下面也可能通过光纤或者专线直连总之文件走的是一条专用的、点对点的通道。很多人会问直接用网盘或者搭建一个 FTP 服务不就行了在公网环境里中转确实方便但在机房内网、离线环境、或者临时应急的场景下中转服务的成本太高了。你自己搭一个 HTTP 服务器要开端口、要处理流量、还要考虑有人可能访问到别的文件用网盘更是绕了一大圈。直连传输的好处在于路径最短、速度最快、不依赖任何中间组件只要 IP 能通、端口能通双方就能直接交换数据。缺点也很明显安全性需要自己负责要么选加密通道要么接受明文裸传的风险。我接手的很多临时任务里两台 Linux 之间传文件都发生在“没有现成基础设施”的时候。比如客户机器上还没有部署配置管理系统或者某台新装的服务器连 yum 源都没配好需要从旁边一台机器拷离线包过去。这种时候直连传输不是可选项而是唯一靠谱的选项。1.2 三种常见方式分别用在什么场景Linux 下的直连传输工具非常多但真正常用的就三个scp、rsync、netcat。它们各有特点不能互相完全替代。方式核心特点最适用的场景scp基于 SSH 加密传输命令简单少量文件、SSH 已可用、需要加密rsync增量同步、断点续传、保留权限大目录、定时同步、备份场景netcat (nc)裸 TCP/UDP 直连无加密无 SSH 服务、内网环境、只求速度先说 scp。它是所有 Linux 发行版默认自带的只要 SSH 服务正常scp 就能用不需要额外安装任何东西。传输过程走 SSH 加密通道中间人偷看不到内容适合跨机房、跨地域这种不可信网络。rsync 则是同步场景的老大哥。它的核心能力不是“拷贝”而是“比较后只传差异”。比如一个目录里有 10000 个文件第一次传完以后第二次再执行 rsync它只会把新增加或修改过的文件传过去速度差距肉眼可见。对于备份、发布代码、同步日志这些重复性操作rsync 几乎是必须要会的工具。netcat 则是一个极端轻量的“裸传工具”。很多新装的 Linux 系统没有配置 SSH 密钥甚至 sshd 都没有启动但 netcat 往往一条命令就能装好或者只要有静态编译的二进制就能跑。它不做加密、不做权限校验只是简单地把数据流从一端推到另一端所以速度非常快特别适合内网中的大文件搬运。1.3 传输前的通用检查IP、端口、双方网络不管用哪种方式传输开始前都要先确认三件事双方 IP 是否可通、目标端口是否放行、目标机器的服务是否正常。这一步别省省了容易把半小时的时间浪费在排查“为什么连不上”上面。本机 IP 可以用以下命令查看ip addr hostname -I查看对端是否可达ping -c 4 192.168.1.101如果 ping 不通先查物理链路、IP 配置和网卡状态。如果 ping 通了再检查端口。SSH 默认端口是 22可以用以下命令检查对端端口是否开放nc -vz 192.168.1.101 22或者用 telnettimeout 3 telnet 192.168.1.101 22如果端口不通原因大概率在防火墙而不是传输工具本身。目标机器上需要放行对应端口。以 firewalld 为例firewall-cmd --permanent --add-port22/tcp firewall-cmd --reload如果是 iptables类似这样iptables -I INPUT -p tcp --dport 22 -j ACCEPT这些检查做完后面再执行 scp、rsync 还是 nc都顺很多。我个人习惯把“连通性检查”和“传输”分开看待前者是网络层问题后者是应用层问题千万别混在一起排查。2. 工具选型先搞懂原理再动手2.1 scp加密传输里的“快枪手”scp 的全称是 secure copy它在设计上就是“复制 SSH 加密”。你执行scp file userhost:/path的时候本地 scp 客户端会通过 SSH 协议与远端 sshd 建立连接然后启动远端 scp 服务进程来完成文件读写所有数据都经过 SSH 加密隧道。正因为底层是 SSH很多 SSH 的参数在 scp 里也适用。最常用的几个参数-P指定远端 SSH 端口注意是大写。默认 22 可以不用写。-r递归复制目录。-C传输时启用压缩适合纯文本、日志这类可压缩比高的内容。-i指定私钥文件。-l限制带宽单位是 kbit/s比如-l 8192表示限制在 8Mbps。-o ConnectTimeout10设置连接超时时间避免网络不通时一直卡着。scp 最大的优点是简单一条命令搞定加密传输不需要额外服务。它最大的缺点是“全量复制”每次都是把整个文件传过去没有断点续传、没有增量同步。文件小还好一旦有个 4GB 的数据库备份文件传了一半断网scp 不会自动续传你也只能从头再来。所以 scp 适合临时传几个小文件不适合长期的大规模同步。2.2 rsync增量同步和断点续传的老大哥rsync 之所以叫 rsync就是因为它的核心是 remote sync。它和 scp 最大的差别在于rsync 会先把远端文件的元数据大小、修改时间拿过来和本地做比对然后只传输有差异的数据块。这里有个很经典的概念叫“滚动校验”。rsync 会把要传输的文件切成固定大小的数据块对每个数据块计算校验值然后在远端寻找相同的数据块。如果两端已经有一些相同的数据块那这些块就不用再传了。这种算法对于“第一次全量传、以后只传增量”的场景简直是神器。我常用的 rsync 参数组合rsync -avz --progress /local/path/ userremote:/remote/path/参数拆开来看-a归档模式。它相当于-rlptgoD的组合递归、保留软链接、保留权限、保留时间戳、保留属主和组、保留设备文件和特殊文件。传目录时基本必加。-v显示详细输出。-z传输时启用压缩。--progress显示传输进度。--partial保留部分传输的文件断线后可以续传。--append-verify对于已经存在但可能不完整的文件直接在尾部追加数据然后做校验。--bwlimit限制传输带宽比如--bwlimit2048表示限制在 2MB/s 左右。--delete删除远端存在但本地已经不存在的文件注意这个参数有风险使用前一定要确认目录内容。如果 SSH 端口不是 22rsync 需要用-e参数指定 channelrsync -avz -e ssh -p 2222 /local/path/ userremote:/remote/path/这里 -e 后面的端口参数是小写-p因为是给 ssh 用的和 scp 的大写-P不一样很容易记混。2.3 netcat内网裸传的轻量选手netcat 有一个很贴切的评价网络界的瑞士军刀。它本身不是一个文件传输工具而是一个可以建立任意 TCP/UDP 连接的工具。你可以把它的一个端当作“数据入口”另一个端当作“数据出口”然后通过重定向把数据流引过去。典型的直连裸传格式是这样的。接收端假设 IP 是 192.168.1.101先监听端口 12345nc -l -p 12345 received.iso发送端执行nc 192.168.1.101 12345 source.iso这两条命令的工作方式很简单发送端把source.iso文件读出来塞进 TCP 数据流接收端从 TCP 数据流中读数据写入received.iso。整个过程没有加密、没有用户认证、没有进度条。它最大的优点是“零依赖”只要两台机器都有 nc就能传文件不需要 SSH 服务不需要配置密钥哪怕是救援模式下只有一个最小 shell也能靠这两条命令完成传输。缺点也很直接明文传输任何能抓包的人都能看到文件内容没有断点续传TCP 流一旦中断文件大概率不完整。传整个目录时通常通过 tar 管道合并成单个流。发送端打包同时传输tar czf - /data/pics | nc 192.168.1.101 12345接收端解包nc -l -p 12345 | tar xzf -注意不同 Linux 发行版自带的 netcat 语法略有差别。传统 netcat 用-l -p 12345而 Nmap 项目维护的 ncat 可以直接用-l 12345。建议先跑nc -h看说明避免在语法上浪费时间。3. 实操过程跑通三种最常见的直连传输3.1 环境准备与连通性验证为了演示完整过程我用一个最简单的双机环境举例。假设有两台机器机器 A192.168.1.100发送方机器 B192.168.1.101接收方用户名opsSSH 端口2222非默认方便演示端口参数先在两台机器上都确认 IPhostname -I然后在 A 上 ping Bping -c 4 192.168.1.101再检查 B 的 SSH 端口是否可达nc -vz 192.168.1.101 2222如果输出显示 connected说明网络层和应用层的端口都通了可以开始传输。如果端口不通先去 B 上确认 sshd 监听状态ss -lntp | grep 2222以及防火墙规则firewall-cmd --list-ports这个阶段要沉住气把网络问题解决在“传文件”之前。很多用户一上来就执行 scp然后报错再回头排查防火墙不仅浪费时间还容易把问题搞混。3.2 scp 实操推送文件、拉取文件与整个目录场景一把本机的/data/app.tar.gz推到 B 的/backup/目录。scp -P 2222 /data/app.tar.gz ops192.168.1.101:/backup/执行过程中会要求输入 SSH 密码。如果配置了密钥认证并且私钥不在默认路径可以用-i指定scp -P 2222 -i ~/.ssh/id_ed25519 /data/app.tar.gz ops192.168.1.101:/backup/场景二从 B 上拉取一个文件到当前目录。scp -P 2222 ops192.168.1.101:/data/logs/app.log .场景三传输整个目录加-r参数。scp -P 2222 -r /data/config ops192.168.1.101:/backup/注意一个容易踩的坑scp 在复制目录时如果远端目录已存在同名文件它不会主动删除多出来的文件只会覆盖同名文件。所以 scp 适合“复制”不适合“同步”。另外默认 scp 命令遇到主机指纹变化时会直接报Host key verification failed。这个错误经常出现在重装系统后解决方法是手动更新 known_hostsssh-keygen -R 192.168.1.101如果你不想每台机器都提示确认可以在 scp 命令前加一个选项scp -o StrictHostKeyCheckingno -P 2222 /data/app.tar.gz ops192.168.1.101:/backup/注意这种方式会降低安全性不建议在不可信网络下使用。3.3 rsync 实操目录同步、断点续传和限速先看最基本的目录同步。在 A 上执行rsync -avz --progress /data/webroot/ ops192.168.1.101:/data/webroot/由于 SSH 端口不是默认的 22需要加-ersync -avz --progress -e ssh -p 2222 /data/webroot/ ops192.168.1.101:/data/webroot/命令里的源路径末尾带不带斜杠是有讲究的。/data/webroot/带斜杠表示同步目录里面的内容/data/webroot不带斜杠表示把目录本身作为一个整体放过去。这个细节很容易记错我建议用以下方式记忆带斜杠代表“内容”不带斜杠代表“文件夹”。第一次执行时因为没有历史数据会全量传输。执行完以后在本地新增一个文件然后再次执行同样的 rsync 命令。你会发现输出里只显示新文件其他文件都跳过了。这就是 rsync 增量同步的实际效果。模拟断点续传可以这样验证先复制一个大文件到目标目录在传输过程中用 CtrlC 中断。等网络恢复后再执行带有--partial --append-verify的 rsyncrsync -avz --progress --partial --append-verify -e ssh -p 2222 /data/large.iso ops192.168.1.101:/data/large.iso--append-verify的意思是如果远端已经有一部分数据就在尾部追加剩余数据追加完成后对整个文件做一次校验防止中间数据块损坏。这个参数比单纯的--partial更可靠推荐优先使用。如果希望限制传输带宽避免影响线上业务可以用--bwlimitrsync -avz --bwlimit4096 -e ssh -p 2222 /data/webroot/ ops192.168.1.101:/data/webroot/这里的单位是 KB/s所以4096代表 4MB/s。粗算一下如果网络带宽是 1000Mbps理论峰值约 125MB/s用--bwlimit10240就是限到 10MB/s留出足够余量。--delete参数要慎用。比如本地目录里只有 3 个文件远端目录里有 5 个文件执行rsync -avz --delete /data/webroot/ ops192.168.1.101:/data/webroot/那么远端多余的那 2 个文件会被删除。这个参数非常适合发布版本时需要“远端必须与本地完全一致”的场景但在备份场景下我建议不要随手加--delete很容易误删历史文件。3.4 netcat 实操免 SSH 的直连裸传假设两台机器之间并没有配置 SSH 密钥甚至 sshd 都没起来那我们用 netcat 完成同一个文件的传输。先在接收方 B 上启动监听nc -l -p 12345 /data/app.tar.gz然后在发送方 A 上推送数据nc -v 192.168.1.101 12345 /data/app.tar.gz传输完成后在 B 上检查文件大小和 A 上是否一致ls -l /data/app.tar.gz md5sum /data/app.tar.gz同时在 A 上也跑一次 md5sum对比两边哈希值完全一致才说明传输成功。如果是目录用 tar 管道接收端nc -l -p 12345 | tar xzf - -C /data/发送端tar czf - /data/app/ | nc -v 192.168.1.101 12345如果希望看到实时传输速度可以借助pv工具发送端pv /data/app.tar.gz | nc 192.168.1.101 12345接收端保持不变。pv会显示当前速度、总流量和预估剩余时间内网传大文件的时候体验比“无输出干等”好得多。这里要特别强调一下netcat 传输没有任何加密文件内容对局域网内的其他机器完全透明。如果你传输的是账号密码、私钥、数据库明文备份强烈不建议用 nc。它只适合在受信内网中搬运“丢了也不至于出大事”的文件。4. 一个可以直接“抄作业”的 bash 脚本4.1 脚本设计什么状态下我需要这个脚本工具熟了以后你会发现每次传输都需要重复输入一长串参数端口、用户名、远端路径、是否压缩。传一两次还好每天传七八次就显得很琐碎。于是我在实际工作中维护了一个 bash 脚本把常见逻辑封装起来。脚本第一版只做了三件事统一接收参数本地路径、目标 IP、远端目录、用户名、端口。自动选择工具如果安装了 rsync优先用 rsync否则退化为 scp。执行完后可选做 md5 校验确保文件一致。后来我加了一些细节默认连接超时、网络连通性预检、日志输出、帮助信息。这些看起来不复杂但在线上环境操作时每一条都能减少一次“传完才发现文件坏了”的痛苦。4.2 完整脚本与逐段讲解下面是脚本完整内容文件名我习惯叫transfer.sh放在/usr/local/bin/下方便直接调用。#!/usr/bin/env bash # # transfer.sh - 两台 Linux 之间的直连传输脚本 # # 用法: # ./transfer.sh [--toolscp|rsync] [--verify] 本地路径 目标IP [远程目录] [用户名] [端口] # # 示例: # ./transfer.sh /data/app.tar.gz 192.168.1.101 /backup ops 2222 # ./transfer.sh --toolscp --verify /data/app.tar.gz 192.168.1.101 /backup ops 2222 # set -euo pipefail TOOLauto VERIFYfalse LOCAL_PATH REMOTE_IP REMOTE_DIR/root REMOTE_USERroot PORT22 TIMEOUT15 usage() { cat EOF 用法: $0 [选项] 本地路径 目标IP [远程目录] [用户名] [端口] 选项: --toolscp|rsync 指定传输工具默认自动选择: 优先 rsync --verify 传输完成后进行 md5 校验仅适用于单文件 -h, --help 显示帮助信息 示例: $0 /data/app.tar.gz 192.168.1.101 /backup ops 2222 $0 --toolscp --verify /data/backup.sql 192.168.1.101 /backup ops 2222 EOF exit 0 } # 解析参数 while [[ $# -gt 0 ]]; do case $1 in --tool*) TOOL${1#--tool} shift ;; --verify) VERIFYtrue shift ;; -h|--help) usage ;; *) if [[ -z $LOCAL_PATH ]]; then LOCAL_PATH$1 elif [[ -z $REMOTE_IP ]]; then REMOTE_IP$1 elif [[ -z $REMOTE_DIR ]]; then REMOTE_DIR$1 elif [[ -z $REMOTE_USER ]]; then REMOTE_USER$1 elif [[ -z $PORT ]]; then PORT$1 else echo 未知参数: $1 usage fi shift ;; esac done if [[ -z $LOCAL_PATH || -z $REMOTE_IP ]]; then echo 错误: 必须指定本地路径和目标 IP usage fi # 自动选择工具 if [[ $TOOL auto ]]; then if command -v rsync /dev/null; then TOOLrsync else TOOLscp fi fi # 检查本地路径是否存在 if [[ ! -e $LOCAL_PATH ]]; then echo 错误: 本地路径不存在: $LOCAL_PATH exit 1 fi # 网络连通性预检 echo 检查网络连通性: ping $REMOTE_IP if ! ping -c 1 -W 2 $REMOTE_IP /dev/null 21; then echo 警告: ping 不通继续尝试端口连接... fi echo 检查端口连通性: $REMOTE_IP:$PORT if ! timeout 3 bash -c echo /dev/tcp/$REMOTE_IP/$PORT 2/dev/null; then echo 警告: 无法连接到 $REMOTE_IP:$PORT请检查防火墙和 sshd 状态 fi # 执行传输 case $TOOL in rsync) echo 使用 rsync 传输 rsync -avz --partial --append-verify --progress \ -e ssh -p $PORT -o ConnectTimeout$TIMEOUT \ $LOCAL_PATH \ $REMOTE_USER$REMOTE_IP:$REMOTE_DIR ;; scp) echo 使用 scp 传输 if [[ -d $LOCAL_PATH ]]; then scp -r -P $PORT -o ConnectTimeout$TIMEOUT \ $LOCAL_PATH \ $REMOTE_USER$REMOTE_IP:$REMOTE_DIR else scp -P $PORT -o ConnectTimeout$TIMEOUT \ $LOCAL_PATH \ $REMOTE_USER$REMOTE_IP:$REMOTE_DIR fi ;; *) echo 错误: 不支持的传输工具: $TOOL exit 1 ;; esac # 单文件传输后校验 if [[ $VERIFY true -f $LOCAL_PATH ]]; then echo 开始校验文件一致性 BASENAME$(basename $LOCAL_PATH) LOCAL_MD5$(md5sum $LOCAL_PATH | awk {print $1}) REMOTE_MD5$(ssh -p $PORT $REMOTE_USER$REMOTE_IP \ md5sum $REMOTE_DIR/$BASENAME 2/dev/null | awk {print $1}) if [[ -n $REMOTE_MD5 $LOCAL_MD5 $REMOTE_MD5 ]]; then echo 校验通过: $LOCAL_MD5 else echo 校验失败! echo 本地 md5: $LOCAL_MD5 echo 远端 md5: $REMOTE_MD5 exit 1 fi fi echo 传输完成逐段讲几个关键点。参数解析部分我用了简单的while循环加case没有依赖 getopt 等外部命令兼容性更好。对于不认识的参数统一按位置参数处理这样用户不写端口、用户名时也能用默认值。网络预检部分用了一个/dev/tcp技巧这是 bash 内置能力不依赖 nc 或 telnet。它的逻辑是尝试向IP:端口建立一个 TCP 连接能连上就返回成功。这样在 SSH 端口不通时能提前告警而不是等 scp/rsync 跑起来以后才报错。选择工具的逻辑是默认“auto”如果系统里存在 rsync 就用 rsync否则退回 scp。因为脚本运行环境不一定装 rsync这种降级策略能让脚本在最小化的系统里也能跑。校验部分只针对单文件因为目录的 md5 校验需要递归遍历远端文件脚本会复杂不少。实际使用时如果传的是单文件建议加上--verify传的是目录我更建议在另一端跑一次du -sb对比总字节数或者用 rsync 自带的-c参数做 checksum 校验。4.3 运行效果与文件一致性校验脚本保存后先给执行权限chmod x transfer.sh然后执行一个单文件传输示例./transfer.sh --toolscp --verify /data/app.tar.gz 192.168.1.101 /backup ops 2222预期输出大致如下 检查网络连通性: ping 192.168.1.101 检查端口连通性: 192.168.1.101:2222 使用 scp 传输 app.tar.gz 100% 245MB 81.7MB/s 00:03 开始校验文件一致性 校验通过: 5a3a4e7f08e1a1a1a9b8c09a0d1f6e2c 传输完成每次传输完成后我都会习惯性看一遍 md5 是否通过。文件传完不等于传输成功字节数可能一样但损坏的数据块也可能恰好保持相同大小。所以“字节数一致”只能作为参考想要更稳妥就做 md5 或 sha256 校验。脚本后续还可以扩展很多功能比如传输后自动发通知、把日志写入文件、支持多文件列表传输。对我个人来说目前这个版本已经覆盖了日常 80% 的直连传输需求胜在简单和稳定。5. 常见问题与排查技巧实录5.1 连接失败端口、防火墙、密钥到底谁在捣乱连接失败是直连传输里最常遇到的问题。我见过不少同事一上来就怀疑 scp 命令写错了其实大部分情况出在 SSH 服务状态、防火墙策略或密钥权限上。先看服务端。执行ss -lntp | grep 22如果没有任何输出说明 sshd 没有监听端口。再检查服务状态systemctl status sshd如果服务没启动启动一下systemctl start sshd systemctl enable sshd再看防火墙。如果服务监听正常但外部连不上大概率是防火墙拦截。先在服务端查规则firewall-cmd --list-all如果在端口列表里看不到 22/tcp加上firewall-cmd --permanent --add-servicessh firewall-cmd --reload还有一类非常隐蔽的问题私钥权限不对。rsync 或 scp 使用非默认私钥时如果私钥文件权限是 644SSH 会直接拒绝使用。Permissions 0644 for /home/ops/.ssh/id_ed25519 are too open.解决办法是把私钥权限收紧chmod 600 ~/.ssh/id_ed25519另一个老生常谈的报错是Host key verification failed。当你重装过目标系统或者两台机器之间的 IP 被重新分配后known_hosts 里记录的指纹和目标机器当前指纹不一致SSH 会认为存在中间人攻击风险直接拒绝连接。处理方法ssh-keygen -R 192.168.1.101然后重新连接即可。5.2 传输中断网络抖动和断点续传的正确姿势网络抖动造成传输中断是所有大文件传输方式里最容易碰到的“尴尬时刻”。scp 传了一半断掉那这个文件基本就废了因为 scp 的设计里没有“从断点继续”的概念。rsync 则天然支持续传关键参数是--partial和--append-verify。有人会问这两个参数是不是加一个就行实际使用下来建议一起加。--partial让 rsync 在中断时保留已经传了一部分的临时文件不自动删除--append-verify则告诉 rsync如果确认已有数据块匹配就接着追加剩余数据传输完以后再整体校验一次。两者配合既能断点续传又能防数据错位。比如我经常在大带宽内网里搬运数据库备份偶尔会碰上核心交换机闪断。恢复后的操作非常简单重新执行带续传参数的 rsyncrsync -avz --partial --append-verify -e ssh -p 2222 /data/backup.sql.gz ops192.168.1.101:/data/注意rsync 判断“远端已有数据”依赖文件大小和校验信息所以如果远端文件已经因为中断变成一个半截文件不要手动删除直接让 rsync 续传就行。5.3 中文文件名乱码不是传输问题是编码问题很多人在 Linux 之间传文件时遇到过压缩包解压后文件名乱码的情况。注意这不是 scp、rsync 本身传错了而是文件名的字符编码在打包和解包两端不一致导致的。典型的场景是这样的Windows 机器或者某台 locale 为中文 GBK 的 Linux 机器往压缩包里添加了一个中文名文件文件名用的是 GBK 编码。压缩包传到另一台 UTF-8 编码的 Linux 系统后解压工具按 UTF-8 去解释文件名自然就乱码了。解决办法分两步。第一步传输前确认双方 localelocale重点看LANG和LC_ALL是不是带UTF-8。如果目标是中文环境但显示的是zh_CN.GBK最好统一改成 UTF-8export LANGen_US.UTF-8第二步解压时指定正确的字符集。如果压缩包是在 GBK 环境下生成的 zip可以用 unzip 的-O参数unzip -O CP936 files.zip对于 7z可以这样解压7z x files.zip然后用convmv做文件名编码转换convmv -f GBK -t UTF-8 --notest -r ./extracted_folder/如果手头没有 convmv可以先通过ls看乱码文件名的十六进制编码再手动改名。不过这种做法效率太低建议直接把目标机器 locale 统一为 UTF-8从根源上避免问题。5.4 传输速度慢瓶颈在哪用几个命令快速定位两台机器明明都是千兆网卡传文件却只有 20MB/s问题很可能不在传输工具本身而在链路中的某个环节。我排查速度问题的顺序是这样的先看基础网络带宽。用 iperf3 测一下两台机器之间的 TCP 吞吐# 服务端 iperf3 -s # 客户端 iperf3 -c 192.168.1.101如果 iperf3 测出来速度很高但 rsync 很慢那就是工具参数的问题。比如 rsync 开启了-z压缩而文件本身已经是压缩过的 tar.gz 或视频文件压缩反而增加 CPU 开销速度更慢。此时去掉-z参数会更快。如果 iperf3 测出来的带宽也低那就是链路或网卡的问题。重点检查网卡协商速率ethtool eth0看Speed字段是不是1000Mb/s。如果只有100Mb/s检查网线、交换机电口或者网卡驱动。还有一类常见原因是 MTU 不匹配大包被分片后导致吞吐大幅下降可以通过ping -M do -s 1472来测试如果丢包就尝试把 MTU 调整到 1400 或 1450。如果网络和参数都没问题但速度还是上不去就要看磁盘 IO 了。大文件传输非常依赖读盘、写盘的能力尤其是并发传输多个文件时机械磁盘很容易成为瓶颈。用iostat -x 1看磁盘使用率如果%util长期接近 100%那瓶颈基本就在磁盘工具再怎么调参也没用。6. 个人实操中的几个体会把这些年用下来的经验浓缩成几句实话。第一生产环境里的文件同步我几乎不用 scp哪怕它最简单。理由不是 scp 不好而是 rsync 的断点续传和增量机制能救我太多次了。文件传输失败不可怕可怕的是失败后没有办法低成本地恢复。第二写传输脚本时一定要加超时和校验。ConnectTimeout这个参数看起来不起眼但它能避免因为网络不通导致 SSH 进程长时间卡死。校验也不是为了每一次传输都证明自己没错而是为了在出问题时能明确地知道是网络问题、数据问题还是工具问题。第三netcat 这种裸传工具平时也许用不上但一定要会。有些应急环境里系统被精简到连 sshd 都没有netcat 可能是唯一能快速把文件搬过去的手段。它就像一把瑞士军刀不需要它的时候觉得多余真需要的时候你会发现没有它还真不知道该怎么办。最后再分享一个小技巧无论用哪种方式传输传完以后都养成跑一次md5sum或sha256sum的习惯。这一条操作成本很低却能让很多“传完就坏了”的疑难问题原地消失。数据不出错后面的工作才谈得上稳定。
在两台 Linux 机器之间传文件这个需求听着基础真做起来门道不少。绝大多数人最先想到的是 scp一条命令就能把文件推到另一台机器上可当你需要同步几十 GB 的目录、或者机器之间只有临时网络环境、再或者 SSH 服务没开而你也没权限装东西的时候光会 scp 就远远不够了。我这些年维护过的服务器、帮人处理的临时传输需求加起来至少上百次踩过的坑包括文件传一半断掉、目录权限错乱、中文字符乱码、两端网速明明很好却卡在密钥认证上……这些经验让我养成了一个习惯先把传输场景想清楚再选工具最后才写脚本。所以这篇文章不是简单罗列几条命令而是把“两台 Linux 之间传输文件”这件事完整拆开先说“直连传输”到底指什么、什么场景最需要它再对比 scp、rsync、netcat 三种主流方式的核心原理然后给出一步步的实操过程和可直接复制的 bash 脚本。无论你是刚接触 Linux 的运维新人还是要批量同步数据的开发都能从里面拿到一套既能应急、又能长期使用的方案。1. 先盘需求直连传输到底解决什么问题1.1 直连传输为什么经常被低估所谓“直连传输”是指两台 Linux 机器之间直接建立网络连接完成数据复制不经过网盘、不经过邮件附件、也不经过一个常驻的 HTTP/FTP 中转服务器。两台机器可能在同一台交换机下面也可能通过光纤或者专线直连总之文件走的是一条专用的、点对点的通道。很多人会问直接用网盘或者搭建一个 FTP 服务不就行了在公网环境里中转确实方便但在机房内网、离线环境、或者临时应急的场景下中转服务的成本太高了。你自己搭一个 HTTP 服务器要开端口、要处理流量、还要考虑有人可能访问到别的文件用网盘更是绕了一大圈。直连传输的好处在于路径最短、速度最快、不依赖任何中间组件只要 IP 能通、端口能通双方就能直接交换数据。缺点也很明显安全性需要自己负责要么选加密通道要么接受明文裸传的风险。我接手的很多临时任务里两台 Linux 之间传文件都发生在“没有现成基础设施”的时候。比如客户机器上还没有部署配置管理系统或者某台新装的服务器连 yum 源都没配好需要从旁边一台机器拷离线包过去。这种时候直连传输不是可选项而是唯一靠谱的选项。1.2 三种常见方式分别用在什么场景Linux 下的直连传输工具非常多但真正常用的就三个scp、rsync、netcat。它们各有特点不能互相完全替代。方式核心特点最适用的场景scp基于 SSH 加密传输命令简单少量文件、SSH 已可用、需要加密rsync增量同步、断点续传、保留权限大目录、定时同步、备份场景netcat (nc)裸 TCP/UDP 直连无加密无 SSH 服务、内网环境、只求速度先说 scp。它是所有 Linux 发行版默认自带的只要 SSH 服务正常scp 就能用不需要额外安装任何东西。传输过程走 SSH 加密通道中间人偷看不到内容适合跨机房、跨地域这种不可信网络。rsync 则是同步场景的老大哥。它的核心能力不是“拷贝”而是“比较后只传差异”。比如一个目录里有 10000 个文件第一次传完以后第二次再执行 rsync它只会把新增加或修改过的文件传过去速度差距肉眼可见。对于备份、发布代码、同步日志这些重复性操作rsync 几乎是必须要会的工具。netcat 则是一个极端轻量的“裸传工具”。很多新装的 Linux 系统没有配置 SSH 密钥甚至 sshd 都没有启动但 netcat 往往一条命令就能装好或者只要有静态编译的二进制就能跑。它不做加密、不做权限校验只是简单地把数据流从一端推到另一端所以速度非常快特别适合内网中的大文件搬运。1.3 传输前的通用检查IP、端口、双方网络不管用哪种方式传输开始前都要先确认三件事双方 IP 是否可通、目标端口是否放行、目标机器的服务是否正常。这一步别省省了容易把半小时的时间浪费在排查“为什么连不上”上面。本机 IP 可以用以下命令查看ip addr hostname -I查看对端是否可达ping -c 4 192.168.1.101如果 ping 不通先查物理链路、IP 配置和网卡状态。如果 ping 通了再检查端口。SSH 默认端口是 22可以用以下命令检查对端端口是否开放nc -vz 192.168.1.101 22或者用 telnettimeout 3 telnet 192.168.1.101 22如果端口不通原因大概率在防火墙而不是传输工具本身。目标机器上需要放行对应端口。以 firewalld 为例firewall-cmd --permanent --add-port22/tcp firewall-cmd --reload如果是 iptables类似这样iptables -I INPUT -p tcp --dport 22 -j ACCEPT这些检查做完后面再执行 scp、rsync 还是 nc都顺很多。我个人习惯把“连通性检查”和“传输”分开看待前者是网络层问题后者是应用层问题千万别混在一起排查。2. 工具选型先搞懂原理再动手2.1 scp加密传输里的“快枪手”scp 的全称是 secure copy它在设计上就是“复制 SSH 加密”。你执行scp file userhost:/path的时候本地 scp 客户端会通过 SSH 协议与远端 sshd 建立连接然后启动远端 scp 服务进程来完成文件读写所有数据都经过 SSH 加密隧道。正因为底层是 SSH很多 SSH 的参数在 scp 里也适用。最常用的几个参数-P指定远端 SSH 端口注意是大写。默认 22 可以不用写。-r递归复制目录。-C传输时启用压缩适合纯文本、日志这类可压缩比高的内容。-i指定私钥文件。-l限制带宽单位是 kbit/s比如-l 8192表示限制在 8Mbps。-o ConnectTimeout10设置连接超时时间避免网络不通时一直卡着。scp 最大的优点是简单一条命令搞定加密传输不需要额外服务。它最大的缺点是“全量复制”每次都是把整个文件传过去没有断点续传、没有增量同步。文件小还好一旦有个 4GB 的数据库备份文件传了一半断网scp 不会自动续传你也只能从头再来。所以 scp 适合临时传几个小文件不适合长期的大规模同步。2.2 rsync增量同步和断点续传的老大哥rsync 之所以叫 rsync就是因为它的核心是 remote sync。它和 scp 最大的差别在于rsync 会先把远端文件的元数据大小、修改时间拿过来和本地做比对然后只传输有差异的数据块。这里有个很经典的概念叫“滚动校验”。rsync 会把要传输的文件切成固定大小的数据块对每个数据块计算校验值然后在远端寻找相同的数据块。如果两端已经有一些相同的数据块那这些块就不用再传了。这种算法对于“第一次全量传、以后只传增量”的场景简直是神器。我常用的 rsync 参数组合rsync -avz --progress /local/path/ userremote:/remote/path/参数拆开来看-a归档模式。它相当于-rlptgoD的组合递归、保留软链接、保留权限、保留时间戳、保留属主和组、保留设备文件和特殊文件。传目录时基本必加。-v显示详细输出。-z传输时启用压缩。--progress显示传输进度。--partial保留部分传输的文件断线后可以续传。--append-verify对于已经存在但可能不完整的文件直接在尾部追加数据然后做校验。--bwlimit限制传输带宽比如--bwlimit2048表示限制在 2MB/s 左右。--delete删除远端存在但本地已经不存在的文件注意这个参数有风险使用前一定要确认目录内容。如果 SSH 端口不是 22rsync 需要用-e参数指定 channelrsync -avz -e ssh -p 2222 /local/path/ userremote:/remote/path/这里 -e 后面的端口参数是小写-p因为是给 ssh 用的和 scp 的大写-P不一样很容易记混。2.3 netcat内网裸传的轻量选手netcat 有一个很贴切的评价网络界的瑞士军刀。它本身不是一个文件传输工具而是一个可以建立任意 TCP/UDP 连接的工具。你可以把它的一个端当作“数据入口”另一个端当作“数据出口”然后通过重定向把数据流引过去。典型的直连裸传格式是这样的。接收端假设 IP 是 192.168.1.101先监听端口 12345nc -l -p 12345 received.iso发送端执行nc 192.168.1.101 12345 source.iso这两条命令的工作方式很简单发送端把source.iso文件读出来塞进 TCP 数据流接收端从 TCP 数据流中读数据写入received.iso。整个过程没有加密、没有用户认证、没有进度条。它最大的优点是“零依赖”只要两台机器都有 nc就能传文件不需要 SSH 服务不需要配置密钥哪怕是救援模式下只有一个最小 shell也能靠这两条命令完成传输。缺点也很直接明文传输任何能抓包的人都能看到文件内容没有断点续传TCP 流一旦中断文件大概率不完整。传整个目录时通常通过 tar 管道合并成单个流。发送端打包同时传输tar czf - /data/pics | nc 192.168.1.101 12345接收端解包nc -l -p 12345 | tar xzf -注意不同 Linux 发行版自带的 netcat 语法略有差别。传统 netcat 用-l -p 12345而 Nmap 项目维护的 ncat 可以直接用-l 12345。建议先跑nc -h看说明避免在语法上浪费时间。3. 实操过程跑通三种最常见的直连传输3.1 环境准备与连通性验证为了演示完整过程我用一个最简单的双机环境举例。假设有两台机器机器 A192.168.1.100发送方机器 B192.168.1.101接收方用户名opsSSH 端口2222非默认方便演示端口参数先在两台机器上都确认 IPhostname -I然后在 A 上 ping Bping -c 4 192.168.1.101再检查 B 的 SSH 端口是否可达nc -vz 192.168.1.101 2222如果输出显示 connected说明网络层和应用层的端口都通了可以开始传输。如果端口不通先去 B 上确认 sshd 监听状态ss -lntp | grep 2222以及防火墙规则firewall-cmd --list-ports这个阶段要沉住气把网络问题解决在“传文件”之前。很多用户一上来就执行 scp然后报错再回头排查防火墙不仅浪费时间还容易把问题搞混。3.2 scp 实操推送文件、拉取文件与整个目录场景一把本机的/data/app.tar.gz推到 B 的/backup/目录。scp -P 2222 /data/app.tar.gz ops192.168.1.101:/backup/执行过程中会要求输入 SSH 密码。如果配置了密钥认证并且私钥不在默认路径可以用-i指定scp -P 2222 -i ~/.ssh/id_ed25519 /data/app.tar.gz ops192.168.1.101:/backup/场景二从 B 上拉取一个文件到当前目录。scp -P 2222 ops192.168.1.101:/data/logs/app.log .场景三传输整个目录加-r参数。scp -P 2222 -r /data/config ops192.168.1.101:/backup/注意一个容易踩的坑scp 在复制目录时如果远端目录已存在同名文件它不会主动删除多出来的文件只会覆盖同名文件。所以 scp 适合“复制”不适合“同步”。另外默认 scp 命令遇到主机指纹变化时会直接报Host key verification failed。这个错误经常出现在重装系统后解决方法是手动更新 known_hostsssh-keygen -R 192.168.1.101如果你不想每台机器都提示确认可以在 scp 命令前加一个选项scp -o StrictHostKeyCheckingno -P 2222 /data/app.tar.gz ops192.168.1.101:/backup/注意这种方式会降低安全性不建议在不可信网络下使用。3.3 rsync 实操目录同步、断点续传和限速先看最基本的目录同步。在 A 上执行rsync -avz --progress /data/webroot/ ops192.168.1.101:/data/webroot/由于 SSH 端口不是默认的 22需要加-ersync -avz --progress -e ssh -p 2222 /data/webroot/ ops192.168.1.101:/data/webroot/命令里的源路径末尾带不带斜杠是有讲究的。/data/webroot/带斜杠表示同步目录里面的内容/data/webroot不带斜杠表示把目录本身作为一个整体放过去。这个细节很容易记错我建议用以下方式记忆带斜杠代表“内容”不带斜杠代表“文件夹”。第一次执行时因为没有历史数据会全量传输。执行完以后在本地新增一个文件然后再次执行同样的 rsync 命令。你会发现输出里只显示新文件其他文件都跳过了。这就是 rsync 增量同步的实际效果。模拟断点续传可以这样验证先复制一个大文件到目标目录在传输过程中用 CtrlC 中断。等网络恢复后再执行带有--partial --append-verify的 rsyncrsync -avz --progress --partial --append-verify -e ssh -p 2222 /data/large.iso ops192.168.1.101:/data/large.iso--append-verify的意思是如果远端已经有一部分数据就在尾部追加剩余数据追加完成后对整个文件做一次校验防止中间数据块损坏。这个参数比单纯的--partial更可靠推荐优先使用。如果希望限制传输带宽避免影响线上业务可以用--bwlimitrsync -avz --bwlimit4096 -e ssh -p 2222 /data/webroot/ ops192.168.1.101:/data/webroot/这里的单位是 KB/s所以4096代表 4MB/s。粗算一下如果网络带宽是 1000Mbps理论峰值约 125MB/s用--bwlimit10240就是限到 10MB/s留出足够余量。--delete参数要慎用。比如本地目录里只有 3 个文件远端目录里有 5 个文件执行rsync -avz --delete /data/webroot/ ops192.168.1.101:/data/webroot/那么远端多余的那 2 个文件会被删除。这个参数非常适合发布版本时需要“远端必须与本地完全一致”的场景但在备份场景下我建议不要随手加--delete很容易误删历史文件。3.4 netcat 实操免 SSH 的直连裸传假设两台机器之间并没有配置 SSH 密钥甚至 sshd 都没起来那我们用 netcat 完成同一个文件的传输。先在接收方 B 上启动监听nc -l -p 12345 /data/app.tar.gz然后在发送方 A 上推送数据nc -v 192.168.1.101 12345 /data/app.tar.gz传输完成后在 B 上检查文件大小和 A 上是否一致ls -l /data/app.tar.gz md5sum /data/app.tar.gz同时在 A 上也跑一次 md5sum对比两边哈希值完全一致才说明传输成功。如果是目录用 tar 管道接收端nc -l -p 12345 | tar xzf - -C /data/发送端tar czf - /data/app/ | nc -v 192.168.1.101 12345如果希望看到实时传输速度可以借助pv工具发送端pv /data/app.tar.gz | nc 192.168.1.101 12345接收端保持不变。pv会显示当前速度、总流量和预估剩余时间内网传大文件的时候体验比“无输出干等”好得多。这里要特别强调一下netcat 传输没有任何加密文件内容对局域网内的其他机器完全透明。如果你传输的是账号密码、私钥、数据库明文备份强烈不建议用 nc。它只适合在受信内网中搬运“丢了也不至于出大事”的文件。4. 一个可以直接“抄作业”的 bash 脚本4.1 脚本设计什么状态下我需要这个脚本工具熟了以后你会发现每次传输都需要重复输入一长串参数端口、用户名、远端路径、是否压缩。传一两次还好每天传七八次就显得很琐碎。于是我在实际工作中维护了一个 bash 脚本把常见逻辑封装起来。脚本第一版只做了三件事统一接收参数本地路径、目标 IP、远端目录、用户名、端口。自动选择工具如果安装了 rsync优先用 rsync否则退化为 scp。执行完后可选做 md5 校验确保文件一致。后来我加了一些细节默认连接超时、网络连通性预检、日志输出、帮助信息。这些看起来不复杂但在线上环境操作时每一条都能减少一次“传完才发现文件坏了”的痛苦。4.2 完整脚本与逐段讲解下面是脚本完整内容文件名我习惯叫transfer.sh放在/usr/local/bin/下方便直接调用。#!/usr/bin/env bash # # transfer.sh - 两台 Linux 之间的直连传输脚本 # # 用法: # ./transfer.sh [--toolscp|rsync] [--verify] 本地路径 目标IP [远程目录] [用户名] [端口] # # 示例: # ./transfer.sh /data/app.tar.gz 192.168.1.101 /backup ops 2222 # ./transfer.sh --toolscp --verify /data/app.tar.gz 192.168.1.101 /backup ops 2222 # set -euo pipefail TOOLauto VERIFYfalse LOCAL_PATH REMOTE_IP REMOTE_DIR/root REMOTE_USERroot PORT22 TIMEOUT15 usage() { cat EOF 用法: $0 [选项] 本地路径 目标IP [远程目录] [用户名] [端口] 选项: --toolscp|rsync 指定传输工具默认自动选择: 优先 rsync --verify 传输完成后进行 md5 校验仅适用于单文件 -h, --help 显示帮助信息 示例: $0 /data/app.tar.gz 192.168.1.101 /backup ops 2222 $0 --toolscp --verify /data/backup.sql 192.168.1.101 /backup ops 2222 EOF exit 0 } # 解析参数 while [[ $# -gt 0 ]]; do case $1 in --tool*) TOOL${1#--tool} shift ;; --verify) VERIFYtrue shift ;; -h|--help) usage ;; *) if [[ -z $LOCAL_PATH ]]; then LOCAL_PATH$1 elif [[ -z $REMOTE_IP ]]; then REMOTE_IP$1 elif [[ -z $REMOTE_DIR ]]; then REMOTE_DIR$1 elif [[ -z $REMOTE_USER ]]; then REMOTE_USER$1 elif [[ -z $PORT ]]; then PORT$1 else echo 未知参数: $1 usage fi shift ;; esac done if [[ -z $LOCAL_PATH || -z $REMOTE_IP ]]; then echo 错误: 必须指定本地路径和目标 IP usage fi # 自动选择工具 if [[ $TOOL auto ]]; then if command -v rsync /dev/null; then TOOLrsync else TOOLscp fi fi # 检查本地路径是否存在 if [[ ! -e $LOCAL_PATH ]]; then echo 错误: 本地路径不存在: $LOCAL_PATH exit 1 fi # 网络连通性预检 echo 检查网络连通性: ping $REMOTE_IP if ! ping -c 1 -W 2 $REMOTE_IP /dev/null 21; then echo 警告: ping 不通继续尝试端口连接... fi echo 检查端口连通性: $REMOTE_IP:$PORT if ! timeout 3 bash -c echo /dev/tcp/$REMOTE_IP/$PORT 2/dev/null; then echo 警告: 无法连接到 $REMOTE_IP:$PORT请检查防火墙和 sshd 状态 fi # 执行传输 case $TOOL in rsync) echo 使用 rsync 传输 rsync -avz --partial --append-verify --progress \ -e ssh -p $PORT -o ConnectTimeout$TIMEOUT \ $LOCAL_PATH \ $REMOTE_USER$REMOTE_IP:$REMOTE_DIR ;; scp) echo 使用 scp 传输 if [[ -d $LOCAL_PATH ]]; then scp -r -P $PORT -o ConnectTimeout$TIMEOUT \ $LOCAL_PATH \ $REMOTE_USER$REMOTE_IP:$REMOTE_DIR else scp -P $PORT -o ConnectTimeout$TIMEOUT \ $LOCAL_PATH \ $REMOTE_USER$REMOTE_IP:$REMOTE_DIR fi ;; *) echo 错误: 不支持的传输工具: $TOOL exit 1 ;; esac # 单文件传输后校验 if [[ $VERIFY true -f $LOCAL_PATH ]]; then echo 开始校验文件一致性 BASENAME$(basename $LOCAL_PATH) LOCAL_MD5$(md5sum $LOCAL_PATH | awk {print $1}) REMOTE_MD5$(ssh -p $PORT $REMOTE_USER$REMOTE_IP \ md5sum $REMOTE_DIR/$BASENAME 2/dev/null | awk {print $1}) if [[ -n $REMOTE_MD5 $LOCAL_MD5 $REMOTE_MD5 ]]; then echo 校验通过: $LOCAL_MD5 else echo 校验失败! echo 本地 md5: $LOCAL_MD5 echo 远端 md5: $REMOTE_MD5 exit 1 fi fi echo 传输完成逐段讲几个关键点。参数解析部分我用了简单的while循环加case没有依赖 getopt 等外部命令兼容性更好。对于不认识的参数统一按位置参数处理这样用户不写端口、用户名时也能用默认值。网络预检部分用了一个/dev/tcp技巧这是 bash 内置能力不依赖 nc 或 telnet。它的逻辑是尝试向IP:端口建立一个 TCP 连接能连上就返回成功。这样在 SSH 端口不通时能提前告警而不是等 scp/rsync 跑起来以后才报错。选择工具的逻辑是默认“auto”如果系统里存在 rsync 就用 rsync否则退回 scp。因为脚本运行环境不一定装 rsync这种降级策略能让脚本在最小化的系统里也能跑。校验部分只针对单文件因为目录的 md5 校验需要递归遍历远端文件脚本会复杂不少。实际使用时如果传的是单文件建议加上--verify传的是目录我更建议在另一端跑一次du -sb对比总字节数或者用 rsync 自带的-c参数做 checksum 校验。4.3 运行效果与文件一致性校验脚本保存后先给执行权限chmod x transfer.sh然后执行一个单文件传输示例./transfer.sh --toolscp --verify /data/app.tar.gz 192.168.1.101 /backup ops 2222预期输出大致如下 检查网络连通性: ping 192.168.1.101 检查端口连通性: 192.168.1.101:2222 使用 scp 传输 app.tar.gz 100% 245MB 81.7MB/s 00:03 开始校验文件一致性 校验通过: 5a3a4e7f08e1a1a1a9b8c09a0d1f6e2c 传输完成每次传输完成后我都会习惯性看一遍 md5 是否通过。文件传完不等于传输成功字节数可能一样但损坏的数据块也可能恰好保持相同大小。所以“字节数一致”只能作为参考想要更稳妥就做 md5 或 sha256 校验。脚本后续还可以扩展很多功能比如传输后自动发通知、把日志写入文件、支持多文件列表传输。对我个人来说目前这个版本已经覆盖了日常 80% 的直连传输需求胜在简单和稳定。5. 常见问题与排查技巧实录5.1 连接失败端口、防火墙、密钥到底谁在捣乱连接失败是直连传输里最常遇到的问题。我见过不少同事一上来就怀疑 scp 命令写错了其实大部分情况出在 SSH 服务状态、防火墙策略或密钥权限上。先看服务端。执行ss -lntp | grep 22如果没有任何输出说明 sshd 没有监听端口。再检查服务状态systemctl status sshd如果服务没启动启动一下systemctl start sshd systemctl enable sshd再看防火墙。如果服务监听正常但外部连不上大概率是防火墙拦截。先在服务端查规则firewall-cmd --list-all如果在端口列表里看不到 22/tcp加上firewall-cmd --permanent --add-servicessh firewall-cmd --reload还有一类非常隐蔽的问题私钥权限不对。rsync 或 scp 使用非默认私钥时如果私钥文件权限是 644SSH 会直接拒绝使用。Permissions 0644 for /home/ops/.ssh/id_ed25519 are too open.解决办法是把私钥权限收紧chmod 600 ~/.ssh/id_ed25519另一个老生常谈的报错是Host key verification failed。当你重装过目标系统或者两台机器之间的 IP 被重新分配后known_hosts 里记录的指纹和目标机器当前指纹不一致SSH 会认为存在中间人攻击风险直接拒绝连接。处理方法ssh-keygen -R 192.168.1.101然后重新连接即可。5.2 传输中断网络抖动和断点续传的正确姿势网络抖动造成传输中断是所有大文件传输方式里最容易碰到的“尴尬时刻”。scp 传了一半断掉那这个文件基本就废了因为 scp 的设计里没有“从断点继续”的概念。rsync 则天然支持续传关键参数是--partial和--append-verify。有人会问这两个参数是不是加一个就行实际使用下来建议一起加。--partial让 rsync 在中断时保留已经传了一部分的临时文件不自动删除--append-verify则告诉 rsync如果确认已有数据块匹配就接着追加剩余数据传输完以后再整体校验一次。两者配合既能断点续传又能防数据错位。比如我经常在大带宽内网里搬运数据库备份偶尔会碰上核心交换机闪断。恢复后的操作非常简单重新执行带续传参数的 rsyncrsync -avz --partial --append-verify -e ssh -p 2222 /data/backup.sql.gz ops192.168.1.101:/data/注意rsync 判断“远端已有数据”依赖文件大小和校验信息所以如果远端文件已经因为中断变成一个半截文件不要手动删除直接让 rsync 续传就行。5.3 中文文件名乱码不是传输问题是编码问题很多人在 Linux 之间传文件时遇到过压缩包解压后文件名乱码的情况。注意这不是 scp、rsync 本身传错了而是文件名的字符编码在打包和解包两端不一致导致的。典型的场景是这样的Windows 机器或者某台 locale 为中文 GBK 的 Linux 机器往压缩包里添加了一个中文名文件文件名用的是 GBK 编码。压缩包传到另一台 UTF-8 编码的 Linux 系统后解压工具按 UTF-8 去解释文件名自然就乱码了。解决办法分两步。第一步传输前确认双方 localelocale重点看LANG和LC_ALL是不是带UTF-8。如果目标是中文环境但显示的是zh_CN.GBK最好统一改成 UTF-8export LANGen_US.UTF-8第二步解压时指定正确的字符集。如果压缩包是在 GBK 环境下生成的 zip可以用 unzip 的-O参数unzip -O CP936 files.zip对于 7z可以这样解压7z x files.zip然后用convmv做文件名编码转换convmv -f GBK -t UTF-8 --notest -r ./extracted_folder/如果手头没有 convmv可以先通过ls看乱码文件名的十六进制编码再手动改名。不过这种做法效率太低建议直接把目标机器 locale 统一为 UTF-8从根源上避免问题。5.4 传输速度慢瓶颈在哪用几个命令快速定位两台机器明明都是千兆网卡传文件却只有 20MB/s问题很可能不在传输工具本身而在链路中的某个环节。我排查速度问题的顺序是这样的先看基础网络带宽。用 iperf3 测一下两台机器之间的 TCP 吞吐# 服务端 iperf3 -s # 客户端 iperf3 -c 192.168.1.101如果 iperf3 测出来速度很高但 rsync 很慢那就是工具参数的问题。比如 rsync 开启了-z压缩而文件本身已经是压缩过的 tar.gz 或视频文件压缩反而增加 CPU 开销速度更慢。此时去掉-z参数会更快。如果 iperf3 测出来的带宽也低那就是链路或网卡的问题。重点检查网卡协商速率ethtool eth0看Speed字段是不是1000Mb/s。如果只有100Mb/s检查网线、交换机电口或者网卡驱动。还有一类常见原因是 MTU 不匹配大包被分片后导致吞吐大幅下降可以通过ping -M do -s 1472来测试如果丢包就尝试把 MTU 调整到 1400 或 1450。如果网络和参数都没问题但速度还是上不去就要看磁盘 IO 了。大文件传输非常依赖读盘、写盘的能力尤其是并发传输多个文件时机械磁盘很容易成为瓶颈。用iostat -x 1看磁盘使用率如果%util长期接近 100%那瓶颈基本就在磁盘工具再怎么调参也没用。6. 个人实操中的几个体会把这些年用下来的经验浓缩成几句实话。第一生产环境里的文件同步我几乎不用 scp哪怕它最简单。理由不是 scp 不好而是 rsync 的断点续传和增量机制能救我太多次了。文件传输失败不可怕可怕的是失败后没有办法低成本地恢复。第二写传输脚本时一定要加超时和校验。ConnectTimeout这个参数看起来不起眼但它能避免因为网络不通导致 SSH 进程长时间卡死。校验也不是为了每一次传输都证明自己没错而是为了在出问题时能明确地知道是网络问题、数据问题还是工具问题。第三netcat 这种裸传工具平时也许用不上但一定要会。有些应急环境里系统被精简到连 sshd 都没有netcat 可能是唯一能快速把文件搬过去的手段。它就像一把瑞士军刀不需要它的时候觉得多余真需要的时候你会发现没有它还真不知道该怎么办。最后再分享一个小技巧无论用哪种方式传输传完以后都养成跑一次md5sum或sha256sum的习惯。这一条操作成本很低却能让很多“传完就坏了”的疑难问题原地消失。数据不出错后面的工作才谈得上稳定。
