为什么先怀疑数据连接
文件传输的登录与传输走两套连接：能登录只证明控制通道与认证没问题，真正的卡点通常发生在数据连接的方向、端口与模式上。按控制连接可用、数据端口可达、权限与传输模式正确这三步推进，比在客户端反复改设置快得多。
基本信息
| 排查顺序 | 连通性 → 认证 → 数据通道 → 权限 → 传输模式 |
|---|---|
| 证据来源 | 客户端报错文本、服务端日志、两端抓包 |
| 关键命令 | nc、lftp、sftp、rsync 对照测试 |
| 常见协议 | FTP/FTPS（20/21、被动端口范围）、SFTP/SCP（22）、TFTP（69/UDP） |
| 注意 | FTP 被动端口范围由服务端配置，不是固定值 |
典型使用场景
- 登录成功但目录列不出来，判断是否为被动端口未放行
- 上传后文件变大或损坏，确认是否误用 ASCII 模式
- 断点续传失效，核查是否缺少续传指令或版本条件
- 跨网段传输慢或中断，区分丢包、MTU 与中间设备超时
现象与快速验证
| 现象 | 可能原因 | 快速验证 |
|---|---|---|
| 登录成功，LIST/RETR 卡死 | 被动端口未放行或 NAT 改写 | 抓包看客户端连的目标端口是否可达 |
| 227 里的地址连不上 | PASV 返回私网地址 | 服务端配置对外通告地址后重试 |
| 主动模式失败 | 服务端出站 20 被防火墙拦截 | 切换被动模式对照验证 |
| 认证通过但 550 拒绝 | 路径不存在或文件权限不足 | 比对服务端日志中的实际路径 |
| 上传后文件损坏变大 | ASCII 模式做了换行转换 | 改用 TYPE I 重传并比对校验和 |
| SFTP 连不上 | 端口或协议搞混，误当 FTPS | 先用 ssh 连同一端口验证 |
分层定位
分层定位
nc -zv host 21 # ① 控制端口是否可达
lftp -u u,p host -e 'ls; bye' # ② 认证与数据通道是否可用
lftp -u u,p host -e 'set ftp:passive-mode off; ls; bye' # ③ 换主动模式对照
sftp user@host <<< 'ls' # ④ 用 SFTP 排除 FTP 专属问题
rsync -av --partial ./dir/ user@host:/data/dir/ # ⑤ 大批量同步改用 rsyncFTP 排障黄金法则：能用被动就用被动；两端同时抓包，控制连接与数据连接一起看，连接建立方向一目了然，比猜快十倍。
只测了 21 端口就宣布网络没问题是最常见的误判：FTP 数据连接走完全不同的端口与方向，TFTP 更是全程 UDP。