FTP服务器什么时候回复226，是否正常？

FTP服务器在数据传输成功完成、数据连接正常关闭后，才会回复226应答，它标志着这次文件传输操作已经圆满收尾。

226应答到底代表什么

FTP协议中，226是服务器对数据连接成功结束的确认，你可以把它理解成服务器在说：“文件已经传完了，数据通道我这边关好了，一切正常。”它出现在客户端发出数据传输请求（比如STOR上传、RETR下载）之后，服务器先回复一个“准备传输”的应答，比如150或125，然后真正开始传数据,传完之后再补上226。

行业内有一个共识：没有226，传输过程就不算真正完成，很多脚本和自动化工具都依赖这个应答码来判断任务是否成功，所以搞清楚226的触发时机，比单纯知道它代表“成功”要重要得多。

什么时候会收到226

被动模式下的标准流程

以最常见的被动模式（PASV）为例,服务器回复226的时机非常固定：

• 客户端发送PASV命令，服务器回复227,告知监听端口。
• 客户端建立数据连接，发送STOR或RETR命令。
• 服务器回复150，表示“即将开启数据传输”。
• 数据通过数据连接传完,服务器关闭数据连接。
• 紧接着服务器在控制连接上回复226 Transfer complete。

这里的关键点在于：226是数据连接关闭之后才发的，哪怕文件最后一个字节已经到达，只要数据连接没有干净地断开，服务器就不会发226,反而可能发425或426表示连接异常。

主动模式下略有差异

主动模式（PORT）下流程类似，只是数据连接的建立方向不同，服务器同样会在数据传输结束后关闭数据连接，然后发送226，区别在于，主动模式下如果客户端防火墙拦住了服务器回连的数据端口，你可能连150都看不到,更别提226了。

上传和下载都适用

• 上传文件时，客户端发送STOR,服务器接收完文件后回复226。
• 下载文件时，客户端发送RETR,服务器把文件发完后回复226。
• 列目录时，客户端发送LIST或NLST,服务器传输完目录列表后也会回复226。

所以不管你是从服务器拉文件，还是往服务器推文件，只要传输正常完成,都会收到226。

哪些情况收不到226

很多朋友遇到过“明明文件好像传完了，但客户端一直卡住不结束”，这就是因为缺少226,常见原因有这么几类：

• 数据连接提前断开：比如网络超时、防火墙杀掉了空闲连接，服务器还没发完数据，连接就没了,自然不会有226。
• 服务器主动超时：如果数据连接长时间无活动，服务器会在超时后强制断开，并回复421或426,而不是226。
• 传输中途出错：磁盘写满、权限不足、文件被占用，服务器会在传了部分数据后中断，回复450或451,没有226。
• 客户端主动取消：你点了停止按钮，客户端发送ABOR命令，服务器会回复426，然后可能再给一个226表示本地的关闭动作完成，注意，这个226表示“中断处理完毕”，不是传输成功。

这里有个非常容易混淆的点：在主动中止传输的场景下，服务器也可能返回226，它代表的是“数据连接已中止并清理完毕”，而不是“文件传输成功”，要区分这一点，得看之前有没有收到426或225，如果收到426后再收到226，说明传输失败了,只是服务器完成了善后工作。

如何确保拿到226

检查你的FTP客户端日志

用任何一个FTP客户端，比如FileZilla、WinSCP或者命令行ftp，都能在日志里看到完整的应答序列，如果你发现传输后没有226,先看数据连接的断开方式。

举个例子,用命令行ftp上传一个文件：

ftp> put test.txt
200 PORT command successful.
150 Opening data connection for test.txt.
226 Transfer complete.
ftp> 

这里的226 Transfer complete就是成功标志，如果它变成了426 Connection closed; transfer aborted,那就得检查网络或服务器配置。

脚本里怎么判断

写自动化脚本时，很多语言自带的FTP库会在收到226后才认为上传完成，比如Python的ftplib，storbinary方法会等待服务器返回226,如果没等到就抛异常。

from ftplib import FTP
ftp = FTP("192.168.1.100")
ftp.login("user", "pass")
ftp.storbinary("STOR test.bin", open("test.bin", "rb"))
# 如果没收到226，这里会抛异常

ftplib内部会调用getresp()来读取最终应答码，如果返回的不是2xx开头，就会抛出error_reply异常，所以只要你的脚本没报错,就说明服务器已经回复了226。

服务器端如何确认

如果你在管理FTP服务器，比如vsftpd，可以通过日志查看每次传输的完成状态，vsftpd日志里会记录传输的字节数和完成标志，如果看到“transfer complete”或类似字段,就说明服务器发出了226。

抓包是最直接的办法，用Wireshark过滤ftp协议，你能看到完整的命令应答序列，包括226的位置，抓包时注意观察：226通常紧接着数据连接发完最后一个数据包之后出现。

基于226调优传输优化

知道了226的触发机制,就可以用它来排查性能问题。

• 如果每次传输都要等好几秒才收到226，可能是服务器在关闭数据连接时做了额外的同步操作，比如刷盘,这时候可以检查服务器磁盘性能。
• 如果文件很小但传输速率很低，问题可能出在建立数据连接的三次握手延迟上,而不是226本身。
• 如果并发传输多，服务器处理226的线程池如果不够,也会出现延迟。

业内专家指出，在大批量文件传输场景中，把226纳入监控指标比单纯看吞吐量更实用，因为226意味着每一次传输都有明确的结束标志。

常见疑问解答

FTP服务器什么时候回复226错误？

226不是错误，它是成功应答，如果你看到客户端把“226”当错误提示处理，那多半是软件逻辑把它设置成了“警告”级别，真正要警惕的是，收到226之前出现了其他4xx或5xx代码，所以当别人问“ftp 226错误”，实际含义往往是“为什么传输完成后客户端报了个226的提示”,这属于软件对状态码的解读问题。

为什么文件传完了就是走不了下一步？

这种情况常见于某些FTP客户端在收到226后还要继续等服务器发送“额外数据”，但服务器认为传输已经结束，双方状态不同步，解决办法是升级客户端，或者在客户端设置里开启“被动模式”，并关闭“保留数据连接”之类的选项。

如何区分226与250？

250表示刚刚执行的文件操作成功，例如删除、重命名，226则是专门针对数据连接的，两者都代表成功，但作用对象不同，你可以在一次FTP会话中同时见到250和226：用DELE删文件返回250,然后用LIST列目录返回226。

记住一句话：226是数据传输的“完赛确认”，它只在数据连接干净关闭后出现，当你看到226，就可以放心地认为这次传输任务已经真正结束了，如果没收到，别管文件大小看起来对不对,都得重新检查整个传输链路。