User：
FTP传文件少几百kb导致文件损坏，每次少的还不一样，为什么！
AI：
出现这种情况通常不是“FTP本身随机吞数据”，而是链路、模式或程序配置造成的。你这种“每次少几百 KB、缺的部分还不一样”现象，非常典型地指向以下几类原因：
1. FTP 传输模式不正确（ASCII/文本模式导致）
如果客户端把模式设成了 ASCII 模式，传输过程中会把某些字节（尤其是换行符
\n、\r\n）自动转换，导致：
文件大小变化
每次变化不一致（取决于文件内容在哪些位置触发了“自动转换”）
解决：
把传输模式固定成 Binary（二进制）模式。
所有非纯文本文件都必须用 Binary。2. 传输过程中 TCP 链路不稳定导致包丢失/中断
FTP 数据走 TCP，一旦网络抖动、丢包、NAT 超时被关闭，可能出现：
文件传到一半，连接被服务器强制关闭
客户端以为传输结束了，文件不完整
每次丢失点不同 → 导致缺的大小不一致
更常见于：
WiFi 信号不稳
VPN / 宽带 NAT 超时
长时传输被路由器清理
解决：
改用有线网络或更稳定的网络
或者改用 SFTP/FTPS（更可靠，不容易被中间设备错误干扰）
3. FTP 客户端或服务器超时/断开
部分 FTP 服务端在长时间无数据后会自动断连接，客户端可能误认为成功完成。
解决：
调长服务器 timeout
客户端启用 KeepAlive
4. 使用了主动模式/被动模式错误导致数据通道异常
数据通道没有建立成功或被中间网关拦截，可能中途断线。
解决：
在客户端固定使用 PASV（被动模式）
5. FTP 软件 bug 或设备缓存损坏
少见，但也有出现过：
路由器/交换机做了错误的 MTU/MSS 修改
老旧的 FTP 客户端就是有问题
FTP 服务端磁盘空间不够而未报错（很少）
你可以做一个验证：
为了判断是不是 ASCII 模式或链路问题：
① 用 Binary 模式上传一个 ZIP 文件（或任意二进制文件）
② 上传后立即比较文件大小
如果仍然每次都不一致，那一定是链路断续/被拦截。如果你愿意，我可以帮你从你的实际情况判断是哪一类问题
你可以告诉我：
用的什么 FTP 客户端？
上传模式是 Binary 还是 ASCII？
网络环境是 WiFi / 有线 / 移动热点？
文件一般多大？上传需要几秒？
我可以给你一个更针对性的结论。
User：
ASCII/文本模式，这个怎么更改？我用的是FlieZilla Server
AI：
FileZilla Server 本身不负责“ASCII/Binary 模式切换”，真正决定传输模式的是 客户端（FileZilla Client 或其他 FTP 客户端）。
也就是说：
你需要在 FTP 客户端里把模式改成 Binary，而不是在 FileZilla Server 改。下面我分别讲：
✅ 如果你用的是 FileZilla Client（最常见）
FileZilla Client 默认会自动判断模式，但有时候会误判成 ASCII，你可以强制用 Binary：
步骤：
打开 FileZilla Client
上方菜单点：
转到(Transfer) → 传输类型(Transfer type)选择：
✔ 二进制(Binary)完成！
从这一刻起所有上传/下载都是纯二进制，不会再修改文件内容。🔧 如果你用的不是 FileZilla Client
其他客户端也都能设置传输模式，例如：
WinSCP
传输设置 → 传输模式 → 二进制lftp
set ftp:charset none set ftp:mode binary命令行 FTP
binary❗为什么 FileZilla Server 不能设置 ASCII/Binary？
因为 FTP 协议规定具体模式由客户端决定。
服务器只被动接收数据，不会去猜内容。🧪 建议你测试一下
为了确认模式是否已经正确：
准备一个 ZIP 或 EXE
上传到服务器
对比上传后文件大小
如果大小一致 → OK
如果 Binary 模式还会变化，那问题就不是 ASCII 了，我再帮你排查。
如果你告诉我你用的是什么 FTP 客户端，我可以精确告诉你在哪个位置改。
User：
解决了！我用的是Android手机MT管理器客户端，设置的是被动，刚改成主动后文件就完整了，而且还有意外收获，传输速度拉满了！在此之前我居然一直以为FTP速度就是这样的，也没去了解主动和被动有什么区别😅。
AI：
听起来你这次一下子踩中了两个关键点，难怪一换模式就立刻“满血复活”。
下面简单讲一下你遇到的现象为什么会这样，这样你以后遇到别的网络环境也能一眼看懂原因。
为什么被动模式会导致文件不完整/速度上不去？
在手机上尤其明显，因为：
1. 被动模式依赖服务器开放数据端口
MT 管理器（FTP 客户端）告诉服务器：“你来开端口，我来连你”。
如果：
服务器端的防火墙/NAT 映射不稳定
或者数据端口范围没配置好
或者路由器对返回连接做限制
就可能 数据通道半路断线，表现就是：
文件突然截断
速度卡住或非常慢
每次传的不一样多（取决于断线时机）
为什么主动模式反而能满速？
主动模式是：
客户端（手机）开端口，服务器反连客户端在多数家庭/手机热点环境里：
客户端 NAT 更简单
返回连接路径更直接
不需要服务器那边开放随机端口
所以你会看到：
稳定、不丢包
带宽能拉满
文件不再损坏
这非常常见，特别是在 Android FTP 客户端上。
你之前以为的“FTP 就是这么慢”其实是被动模式兼容性问题
很多人第一次玩 FTP 都遇到同样误解，能跑满速之后才发现：
FTP 本身很快（尤其是同局域网）
传几 GB 都能稳得像本地拷贝
你这次刚好是典型案例。
顺便给你一个判断技巧
以后你可以这样判断是否该用主动：
被动模式：
速度慢
文件不完整
连接时卡住在“Opening data channel”
上传/下载突然中断
只要出现这些 → 尝试主动模式 80% 都能解决。
如果你愿意，我还能告诉你 MT 管理器主动/被动的差异细节，以及在什么网络场景用哪个更稳。