服务器传文件全攻略：scp、rsync、sftp等常用工具与避坑指南

平时接触服务器的人，不管你是运维、后端开发、测试，还是偶尔碰一次云服务器的新手，大概率都被“传文件”这件事折磨过。项目上线前差一个配置文件、日志要拉回本地排查、虚拟机里做环境要同步一份安装包、备份要拷到另一台机器……这些场景看起来只是敲几条命令的事，但真到上手的时候，连接超时、权限拒绝、传一半断开、文件名乱码，各种问题能把人逼疯。这篇东西就是专门讲透“服务器传文件”这件事的，把常用工具、实操步骤、踩坑经验一次性说清楚，尽量让看完的人能直接照着做。

我日常接触比较多的是 Linux 服务器，也经常要跟 Windows 虚拟机、云服务器、NAS 这些设备打交道。前后踩过的坑不算少，所以这篇文章不打算写成工具文档的堆砌，而是按“场景—选型—实操—排错”这条线来走。文章重点覆盖 Linux 服务器之间、Windows 与虚拟机/服务器之间、以及如何把服务器文件变成浏览器可以直接下载的链接，这些是搜热度最高的几类问题，也是实际工作里最常被问到的。

1. 先想清楚：你这次“传文件”属于哪种场景

很多人在网上搜“服务器传文件”，其实是带着具体问题的，但搜索引擎不一定能理解你脑子里的上下文。所以我先帮大家把场景做一个拆解，搞清楚自己属于哪一类，后面再选工具就顺理成章了。

1.1 按两端系统来分，场景差异非常大

• Linux 服务器到 Linux 服务器：这是最常规的运维场景，两个服务器之间同步配置、拷贝备份、分发程序包。首选命令就是 scp、rsync，效率高、可控性强。
• Windows 本机到 Linux 服务器：开发同学从本地把代码包、压缩包传到远程服务器跑起来，或者反过来把远程日志拉到 Windows 看。这类场景用 WinSCP、Xftp 这种图形化工具最友好，也可以用 scp 命令。
• Windows 与虚拟机之间：装了 VMware、VirtualBox 之后，宿主机和虚拟机之间传文件，优先用 VM Tools 共享文件夹；没装工具的用 FTP 或者网络共享都能解决。
• 云服务器和本机之间：本质还是 Linux/Windows 的远程传输，只是服务器可能没有公网 IP，需要走防火墙规则。免费云服务器、阿里云服务器这些都适用，不要因为上云就把基础命令丢了。
• 同机房多台服务器集群：如果要做几十台的批量分发，scp 逐个拷效率太低，这个时候要用 rsync + 循环脚本，或者上批量运维工具。

1.2 按文件性质来分，决定要不要压缩和校验

文件大小、文件数量、是否需要保留权限，这三个因素直接影响你用哪个工具、要不要先打包。

小文件单个传没问题，但几千个碎文件一个个走 scp 非常慢，因为每次传输都有握手和确认的固定开销。最好的做法是先在源端打包压缩成 tar.gz，再传整个包过去，过去之后再解包。而大文件单独传没什么问题，但要注意网络稳定性，断点续传能力就很重要。scp 本身不支持断点续传，rsync 支持，这个差异后面还会详细讲。

我用一个表把这些情况整理一下，选型的时候直接对号入座。

我记得有一次帮朋友处理一个服务器迁移任务，源服务器上有几万个图片文件，一开始他用 scp -r 直接拷，跑了快两个小时还没完。后来我让他先 tar 打包压缩，再传压缩包，到目标端解压，总耗时不到二十分钟。这就是场景判断和工具选择的价值。

2. 主流传文件手段的原理与选型逻辑

市面上的传文件手段看起来很多，核心不外乎三类：基于 SSH 的传输（scp、sftp、rsync over ssh）、传统的 FTP 协议传输、以及基于 HTTP/对象存储的分享式下载。它们的原理和安全模型完全不同，搞清楚原理，遇到问题才知道往哪个方向排查。

2.1 scp：最直接、最稳妥的基础款

scp 全称是 secure copy，基于 SSH 协议进行加密传输。只要服务器开了 SSH 服务（通常监听 22 端口），并且你有登录权限，就可以直接传文件。它的最大优点就是简单，不需要额外装任何服务端组件，目标机器上的 sshd 就是传输通道。

基本用法是两个方向：

bash复制# 本机文件传到服务器
scp /local/file.txt user@server_ip:/remote/path/

# 服务器文件拉到本机
scp user@server_ip:/remote/file.txt /local/path/

scp 适合一锤子买卖，比如上传一个安装包、下载一个日志文件。它不支持断点续传，如果网络不稳定或者传输量大，建议换 rsync。另外要注意，scp 默认端口是 22，如果 SSH 改过端口，需要用 -P 参数指定。

2.2 rsync：增量同步才是效率担当

rsync 的出现解决了两个核心痛点：一是大文件传输中断后可以从断点继续，二是多次同步时只传变化的部分。

它支持本地模式、远程 Shell 模式，也可以起服务端模式。日常用得最多的是基于 SSH 的远程同步模式，这样既享受 SSH 加密，又具备增量能力。常用命令：

bash复制# 基本同步，-a 表示归档模式，保留权限、属主、时间戳
rsync -avz /local/dir/ user@server_ip:/remote/dir/

# 断点续传，--partial 保留已传部分
rsync -avz --partial /local/dir/ user@server_ip:/remote/dir/

rsync 还有一个非常大的优点：传输前会做文件比对，如果文件在源端没有变化，目标端不会重新拷贝，这对于重复执行的备份任务非常关键。我第一次用 rsync 做日志备份的时候，几 GB 的目录增量同步只需要几十秒，当时挺震惊的。

2.3 sftp、FTP、lrzsz 这些传统方式怎么选

sftp 可以理解成 SSH 协议下的一种文件传输协议，和 scp 一样安全，但交互方式更像 FTP，支持列目录、删除、重命名等操作。命令行可以用 sftp 进入交互模式，图形化工具 WinSCP、Xftp 走的就是 sftp 协议。

传统 FTP 就比较老了，使用 21 端口，数据连接还分主动/被动模式，而且默认使用明文传输，非常容易被抓包。如果一定要用 FTP，必须想清楚三点：是否只在内网使用、是否对传输速度有特殊要求、账号密码权限是否严格管控。现在很多云服务器的安全组里都默认不放行 21 端口，FTP 实际用得越来越少。

lrzsz（rz/sz）是 Linux 终端里很方便的一对命令，配合 Xshell、SecureCRT 这类终端工具，可以直接在会话里弹窗选文件上传下载。它适合临时传点小文件，缺点是文件大小受限（一般 2GB 以内），且传输过程占用终端会话，断线就失败。

2.4 下载链接与对象存储：从“传给你”变成“放上去自己拿”

有时候目标不是把文件放到某台服务器，而是让其他人能从浏览器下载。最朴素的做法是在服务器上放一个 nginx 静态目录，或者用 MinIO 这种对象存储服务生成一个分享链接。

nginx 目录浏览或静态文件的下载，适合小团队内部用，配置简单，只要指定一个根目录，put 文件进去就能通过 URL 访问。

MinIO 则是更工程化的方案，兼容 S3 协议，支持生成带签名的临时下载链接，适合做“前端直接传文件到 MinIO”这种需求。前端拿到一个上传签名链接，浏览器直传对象存储，不占用后端带宽，服务器压力小很多。这个我后面实操部分会写具体步骤。

3. 高频场景实操：从零到文件到位

理论讲再多，不如直接上操作。这一章我挑四个高频场景，把完整步骤和里面的细节拆开来讲。

3.1 Linux 服务器之间传文件完整示例

假设有两台 Linux 服务器，A 服务器（192.168.1.10）上有一个目录 /data/app，需要同步到 B 服务器（192.168.1.20）的 /data/backup 目录。

第一步，在 A 服务器上测试到 B 的 SSH 连接：

bash复制ssh root@192.168.1.20

如果这一步都不通，后面别想了。常见原因包括：B 服务器的 sshd 没启动、防火墙拦了 22 端口、密钥或密码不对。ssh 通了再执行 rsync。

第二步，执行增量同步：

bash复制rsync -avz --partial /data/app/ root@192.168.1.20:/data/backup/

这里 -a 能保留软链接、权限、属主、时间戳，这个很重要，用作程序部署时，属性乱了可能直接导致程序起不来。-z 是传输时压缩，适合文本类文件；如果是已经压缩过的压缩包或图片，-z 基本没效果，反而增加 CPU 开销。-v 是显示传输过程，方便观察哪些文件被传输了。

第三步，如果目标目录之前已经存在同名文件，rsync 会默认比对大小和 mtime，不一致才重新传输。如果想要强制比对内容，可以加 -c 参数，但会多消耗 IO，日常同步用默认就行。

如果只是临时传一个文件，用 scp 更省事：

bash复制scp /data/app/installer.tar.gz root@192.168.1.20:/opt/

3.2 Windows 与虚拟机/服务器互传文件实战

Windows 这边场景非常多：宿主机与虚拟机互传、本机与远程 Linux 服务器互传、Windows 服务器之间传文件。很多小白问“windows与虚拟机传文件”怎么办，其实就是三种思路。

第一种思路是共享文件夹。在 VMware 或 VirtualBox 中装好增强工具（VMware Tools / Guest Additions），然后设置共享文件夹，宿主机和虚拟机都能访问同一个物理目录。这种方法适合日常开发调试，改代码、看日志都方便，甚至可以双向实时同步，但依赖虚拟化环境，不是所有场景都适用。

第二种思路是直接用 WinSCP 或 Xftp。它们通过 sftp 协议连接 Linux 服务器，图形化界面上拖拽文件即可，连接参数就是 IP、端口、用户名、密码。WinSCP 还有一个同步目录的功能，可以选择镜像、双向或增量同步，比敲rsync更直观。实测下来，本地 Windows 到云服务器传文件，WinSCP 是最稳的，也支持断点续传。

第三种思路是 Windows 之间用 FTP 或 SMB 共享。Windows 自带的 IIS FTP 可以挂成 FTP 站点，但配置起来相对啰嗦，而且 FTP 明文不安全。SMB 共享对于内网 Windows 文件交换是原生支持，直接 \192.168.x.x\share 访问即可，虚拟机里如果和宿主机同一内网段，这也是可选方案。不过一旦跨公网，SMB 基本别想了，延迟和端口问题会让人崩溃。

3.3 把服务器文件变成浏览器可下载的链接

这个需求最近被问得很多：有一台云服务器，文件在上面，想发给客户或同事下载，对方既不希望装客户端，也不想注册账号。最实用的做法是用 nginx 搭一个目录浏览，或者用 MinIO 生成分享链接。

nginx 静态文件下载的方案，假设文件放在 /data/share 目录，配置文件大致如下：

nginx复制server {
    listen 8080;
    server_name _;

    location /download/ {
        alias /data/share/;
        autoindex on;
        autoindex_exact_size off;
        autoindex_localtime on;
    }
}

这样用户访问 http://server_ip:8080/download/ 就能看到共享目录里的文件列表，点击即可下载。autoindex on 是开启目录索引，autoindex_exact_size off 让文件大小显示得更友好，autoindex_localtime on 让文件时间使用服务器本地时区。注意 8080 端口要在云服务器安全组里放行，否则外部访问不了。

MinIO 的方向更现代一些，适合把文件传到对象存储。MinIO 服务启动后，通过自带的 mc 客户端或者 SDK 上传文件，然后可以生成带有效期的签名下载链接：对方不需要知道你的 MinIO 账号，只要拿到链接，在有效期内就能下载。签名链接适合“临时分享，过期自动失效”的业务场景，在给外部人员发文件时非常实用。

关于“服务器文件怎么弄成下载链接”，我补充一个很容易踩的坑：服务器上文件的权限必须让 nginx 进程有读取权限。如果文件属主是 root 且权限是 600，nginx 以 www-data 身份运行，访问的时候会 403。最简单的处理是调整属主和权限：

bash复制chown -R www-data:www-data /data/share/
chmod -R 644 /data/share/

3.4 借助 VSCode Remote-SSH 传文件的小技巧

现在不少开发同学用 VSCode 的 Remote-SSH 插件连接远程服务器，把整个项目目录挂到一个 VSCode 窗口里直接编辑。传文件这种需求，在这个环境下其实被很多人忽略了。

VSCode Remote-SSH 连接上之后，左侧资源管理器显示的是远程目录，但你只需要把本地的文件直接拖拽到远程目录树里，它就自动帮你完成上传。反过来，远程文件往本地拖，也会直接下载。这个功能是基于 SFTP 协议的，传输时走的是 SSH 通道，安全性和 scp 一样。

不过拖拽上传有一个隐藏问题：如果文件名包含中文或特殊字符，某些版本下会出现文件名乱码。解决方法是右键选择“在终端中显示”，用 rz 命令或者 scp 来传，或者干脆先把文件重命名成简单的 ASCII 名字再传。

此外，VSCode 内置终端里可以直接执行 scp、rsync 命令，所以即使不用图形化拖拽，在 VSCode 里开一个终端，操作习惯和在 Linux 本地敲命令完全一致。

4. 传文件最常踩的坑，我帮你提前排掉

传文件出问题时，一半以上是环境问题而不是命令问题。这里把我自己和身边同事踩过的高频问题整理成速查表，方便大家直接对照。

4.1 连接不上的三板斧排查

不管用 scp、rsync 还是 WinSCP，连不上的排查思路是一致的。第一板斧，先在源服务器上测试端口通不通：

bash复制telnet 192.168.1.20 22

telnet 不通，说明网络层被卡住了。常见原因是目标服务器防火墙、云厂商安全组、或者本机出网限制。云服务器的安全组尤其重要，很多人在阿里云、亚马逊免费服务器的控制台里忘记放行 22 端口，本地怎么连都连不上，SSH 也白搭。

第二板斧，确认 sshd 服务本身在运行：

bash复制systemctl status sshd

有些精简系统默认没有装 sshd，或者安全加固时把 SSH 端口改了，这时候参数、工具怎么换都没用，先把 SSHD 拉起来再说。

第三板斧，检查登录凭据和权限。如果是密码登录报 Permission denied，留意目标服务器的 /etc/ssh/sshd_config 里的 PasswordAuthentication 是否设置成了 no。我见过很多次，系统加固时把密码登录关了，结果传文件也一起被挡住，这种情况只能先在控制台用密钥验证一次，或者临时开启密码登录。

4.2 传到一半断掉，scp 怎么办

scp 不支持断点续传，传到 80% 断掉就只能重来。如果文件不大倒还好，几个 GB 的备份文件就很痛苦。遇到这种情况，我的建议是立刻放弃 scp，改用 rsync：

bash复制rsync -avz --partial --progress user@server_ip:/remote/file.sql /local/

--partial 让 rsync 保留传输中断时已经下载的部分文件，下次重跑会自动判断从哪个位置继续，而不是从头开始。--progress 显示进度条，方便观察。这个参数组合在传大文件时是救命稻草，建议直接记下来。

补充一个场景：如果源端是 Windows 目标端是 Linux，Windows 上不能用原生命令跑 rsync，可以借助 Git Bash 或者 Cygwin，或者在 Windows 侧用软件 cwRsync，一样支持断点续传。

4.3 权限、属主与编码的隐性坑

传文件过去之后，发现目标目录的文件属主成了 root，或者执行权限丢了，这种情况在部署程序时非常致命。根源在于普通 scp 不保留原有属主，只按当前用户身份落盘。要保留权限和属主，用 -p 或 -a 参数。

scp 保留时间戳和权限：

bash复制scp -p /local/file.txt user@server_ip:/remote/

rsync 的 -a 参数是更完整的选择，它会递归传输并保留权限、属主、时间戳、软链接和特殊文件，基本是搬迁目录的首选。

另外很容易被忽略的是编码问题。从 Windows 传一个 zip 压缩包到 Linux，解压出来中文文件名乱码，Windows 的 zip 文件名默认用 GBK/GB18030 编码，而 Linux 的 unzip 默认按 UTF-8 解压。解决办法是用 unzip 配合指定编码：

bash复制unzip -O gbk archive.zip

如果系统 unzip 版本比较老不支持 -O 选项，要么用 7z 替代，要么在 Windows 侧用支持 UTF-8 的压缩工具重新打包。这个坑在传中文文件名的业务资料时特别常见。

4.4 端口与安全的平衡点

传文件用到的端口其实很固定：SSH 相关的是 22，FTP 是 21 和数据端口，rsync 自带 daemon 是 873，HTTP 下载是 80/8080。安全起见，很多服务器的防火墙都把这些端口限制得很严格，导致文件传不上去。

通用的解决思路是：能走 SSH 通道的就别额外开端口。scp、sftp、rsync over ssh 都只依赖 22 端口，只要放行 22 就够了。不要图省事开启大范围端口范围，比如 FTP 被动模式的 30000-40000 端口，从安全审计的角度看非常不推荐。在云服务器上配置安全组时，建议配置源地址白名单，只允许办公网 IP 访问 22 端口，这样既保证传输，又降低暴力破解风险。

如果确实需要对外开放下载链接，优先走 443 端口配 HTTPS，把下载服务挂在 nginx 后面，不要直接用裸 FTP 对公网开放。公网明文传输的 FTP 账号密码，几乎等于裸奔，抓包一抓一个准，这个风险没必要去冒。

4.5 传输速度上不去，怎么定位瓶颈

传大文件时速度很慢，很多人第一反应是带宽不够。但实际排查下来，瓶颈可能出在加密算法、磁盘 IO、或者是小文件太多导致的握手开销。

先在两端分别测磁盘写入速度，用 dd 命令或者直接看 iotop。如果磁盘本身写不满，瓶颈可能在 CPU 加解密。SSH 默认的加密算法对老 CPU 有压力，可以考虑在 sshd_config 里换更快的算法，但这条需要对安全性有把握才建议折腾。

其次要看是不是海量小文件的问题。几万个 1KB 的碎文件，逐个传输的握手时间远超数据时间，这种场景先 tar 再传往往是质的飞跃。我做过一次完整对比，同样 1 万个文件，直接 scp -r 要 15 分钟，tar 后传输加解压总共不到 2 分钟。

最后是带宽本身。可以先用 iperf 测两端之间的裸网络带宽：

bash复制# 服务端
iperf3 -s
# 客户端
iperf3 -c server_ip

如果 iperf 的数值远低于购买带宽，说明网络链路有问题，该找运营商或云服务商工单了；如果 iperf 正常，但 scp 很慢，那就是传输层自身的问题，按前面的思路去排查。

5. 文件传输之外的自动化思路

传文件本质上是个一次性动作，但工作中真正省力的方向是把它变成自动化任务。定时备份、多机分发、日志归档，这些如果靠人工一次次执行命令，迟早出错。

一个很通用的备份脚本思路是这样：把关键目录用 rsync 同步到另一台服务器，同时保留最近 7 天的备份。

bash复制#!/bin/bash
DATE=$(date +%Y%m%d)
rsync -avz --link-dest=/backup/current /data/app/ backup@192.168.1.20:/backup/$DATE/

--link-dest 是 rsync 一个非常强大的参数，它能基于上一次备份做硬链接复用，效果是“每天看起来都有一个完整备份，但实际占用空间只增加变化的部分”。我接触过不少运维项目，这个参数帮团队省了大量存储成本。

如果是备份到 NAS，思路也是一样的。群晖 NAS 备份 Linux 服务器，可以在群晖上开启 rsync 服务，然后在 Linux 端用 rsync 推数据过去，或者反过来在群晖的任务计划里定期拉取。这种模式不依赖图形界面，稳定性很高，跑一两年都不会出问题。

如果是多台服务器集群分发同一个文件，可以写一个简单的循环：

bash复制for host in server1 server2 server3; do
    rsync -avz /package/app.tar.gz root@$host:/opt/
done

再配合密钥登录，整批分发几十台服务器就是一条命令的事。这种“脚本 + 定时任务 + 日志”的组合，才是服务器文件传输真正该有的常态。

我把这个做成一个建议的传输方案速查，方便平时直接对标：

最后说一点个人体会。服务器传文件这件事，表面上是一堆命令的组合，但真正决定顺不顺手的，是你对两端系统、网络环境、文件特征的判断能力。同样传一个大文件，有人被中断折磨半天，有人用 rsync 一条命令搞定；同样给外部人员发文件，有人用 FTP 暴露账号密码，有人用 MinIO 签名链接优雅解决。差别不在于背了多少命令，而在于有没有把场景和工具的匹配关系弄明白。

从实用主义的角度出发，我建议你重点把 rsync、scp、WinSCP 这三个东西用熟，再掌握 nginx 目录下载和 MinIO 的基本用法，已经能覆盖 90% 以上的服务器传文件需求。剩下的就是遇到问题别慌，按连接、权限、编码、带宽这几个方向去排查，大多数坑都能很快定位出来。希望这篇文章能帮你在下次被文件传输折磨的时候，少走一些弯路。