上周三下午，传失我往服务器传一个200MB的传失数据库备份文件，FileZilla的传失进度条卡在87%不动了。等了五分钟，传失弹出“传输超时”的传失红色报错。重试三次，传失每次都在差不多同一个位置断掉。传失这不是传失我第一次遇到FTP上传失败，但那次特别典型——网络看起来正常，传失账号密码也没错，传失可文件就是传失传不上去。

先说最常见的传失坑：被动模式没开对。很多家用路由器后面的传失FTP客户端默认走主动模式，服务器试图回连你的传失机器时被防火墙挡掉。表现就是传失能登录、能列目录，一传文件就挂。FileZilla里在“传输设置”把模式改成被动，或者勾上“使用服务器外部IP”，往往立刻见效。我那次就是这个问题，改完重传，一次过。

另一个高频原因是磁盘配额或权限。你看着上传进度条在走，服务器端却悄悄写不进去。有回帮朋友传网站素材，FTP账号对/var/www/uploads只有读权限，上传报“550 Permission denied”。这种报错还算直白。更阴的是磁盘满了——服务器不报错，客户端显示100%完成，上去一看文件0字节。用df -h查一下剩余空间，或者让运维看看inode是不是爆了，能省很多瞎折腾的时间。

文件本身也会捣乱。文件名带中文、空格、特殊符号，在某些老旧的FTP服务端上直接乱码或截断。我习惯上传前把文件名改成纯英文加下划线，比如db_backup_20240612.sql。还有一次传一个3GB的压缩包，FTP客户端默认二进制模式没勾，传上去解压报错——ASCII模式会偷偷转换换行符，把二进制文件毁掉。这个坑现在少了，但用命令行ftp的时候仍然要手动敲binary。

网络层面的问题更隐蔽。MTU不匹配会导致小文件正常、大文件传到一半卡死。判断方法很简单：ping -f -l 1472 服务器IP，如果提示需要拆分数据包，就把MTU调低到1400左右再试。还有公司网络里的深度包检测设备，会识别FTP控制连接但放行数据连接不稳定，表现就是时好时坏。换个网络环境，比如用手机热点传一次，能快速定位是不是本地网络的问题。

服务端配置也值得看一眼。vsftpd默认local_umask是077，上传的文件权限变成600，Web服务器读不了。改local_umask=022，或者上传后手动chmod。Pure-FTPd有个MaxClientsNumber限制，并发一多就拒绝新连接，报“421 Too many connections”。这些在日志里都有记录，/var/log/vsftpd.log或者/var/log/messages翻一翻，比瞎猜强。

实在搞不定的时候，我直接换SFTP。OpenSSH自带的sftp命令走SSH通道，加密、单端口、不用折腾被动模式。命令行sftp user@host，然后put 文件名，简单粗暴。WinSCP也支持SFTP协议，图形界面操作跟FTP没区别。现在新配的服务器，我基本只开SFTP，FTP留着给那些老旧的嵌入式设备用——它们没得选。

那次87%卡死的备份文件，最后是用rsync传完的。断点续传、压缩传输、校验和验证，比FTP可靠太多。FTP诞生于1971年，那会儿网络环境跟现在完全两码事。它没坏，只是不太适合今天的网络了。遇到上传失败，别急着骂服务器，先看看被动模式、权限、磁盘、文件名、MTU这几个地方，大部分问题都出在那儿。