SFTP比FTP快的关键在于SSH层的压缩机制和连接复用，而非协议本身；需启用internal-sftp、配置SFTPCompression delayed、正确设置ChrootDirectory权限，并在FileZilla中开启SSH压缩。
为什么SFTP比FTP快？不是因为协议本身，而是因为压缩和复用
很多人以为换SFTP就能提速，其实关键在SSH层的压缩机制。FTP是明文协议，每次传输都要建立新连接、协商参数；SFTP复用同一个SSH连接，且支持SFTPCompression delayed——数据流开始后才启用压缩，避免小文件握手开销。宝塔默认的Pure-FTPd不支持压缩，而OpenSSH自带的SFTP引擎可以开。
必须改/etc/ssh/sshd_config，不能只靠宝塔界面
宝塔面板的“FTP”模块和“外部存储”里的SFTP配置，都只是客户端行为，不影响服务器端的SFTP性能。真正提速要动SSH服务配置：
- 确认已启用
internal-sftp（不是/usr/libexec/openssh/sftp-server）——只有internal-sftp支持SFTPCompression - 在
Match User www块内添加SFTPCompression delayed（注意：该指令仅对internal-sftp生效） - 确保
www用户主目录权限为755，且/www/wwwroot所有者是www，否则ChrootDirectory会失败导致连接降级回普通SSH，压缩失效 - 重启服务必须用
systemctl restart sshd，service sshd restart在较新系统上可能不触发重载
FileZilla连SFTP时，压缩开关藏在高级设置里
即使服务端开了压缩，客户端不配合也没用。FileZilla默认关闭SSH压缩：
- 站点管理器 → 编辑目标站点 → “高级”选项卡 → 勾选
Enable compression (requires SSH2) - 不要勾选
Use UTF-8 for filenames（除非你确认服务端locale是en_US.UTF-8），否则中文路径可能触发额外编码转换，拖慢列表速度 - “传输设置”中把
Maximum number of simultaneous transfers从1调到3——SFTP单连接多通道比FTP多线程更稳，但超过3容易触发internal-sftp的并发限制
上传大文件卡在99%？大概率是ChrootDirectory权限或磁盘IO问题
宝塔常用ChrootDirectory /www/wwwroot，但chroot环境要求根目录严格不可写（除指定子目录外）。常见卡顿原因：
-
/www/wwwroot本身被设为755但属主不是root：执行chown root:root /www/wwwroot - 目标子目录（如
/www/wwwroot/myapp）没给www用户写权限：chown -R www:www /www/wwwroot/myapp - 磁盘使用率超90%，ext4会主动限速：用
df -h检查，清理/www/backup或/www/server/data - 没关SELinux：CentOS/RHEL系必须
setsebool -P ssh_chroot_rw_homedirs on，否则chroot下写入被拦截且无明确错误提示
真正影响速度的从来不是协议名，而是ChrootDirectory的权限链、internal-sftp的压缩开关、以及FileZilla是否真的用了它——三者缺一不可。漏掉任意一个，就退回慢速明文传输状态。
