FTP 登录正常但目录列表卡住：原因何在

用户名正常，密码正常，客户端也说已连接。随后它在文件夹列表或第一次文件传输上一直等待，凭据里没有任何东西能解释这一点。FTP 为每次列表和每个文件另开一条连接，出问题的正是这条第二条连接。登录只证明第一次对话是通的。

按顺序逐项检查。每一项排除一层原因，因此一出现异常就停下来。

先把两条连接分开

控制连接在服务器的监听端口上传输命令和应答。数据连接传输目录列表或文件内容，在被动模式下由服务器选择自己的端点，并在 PASV 或 EPSV 应答中公布。放行端口 21 并不能说明数据端口是否可达，这正是登录成功而每次列表都超时的原因。WinSCP 的 FTP 模式指南 说明了这种分工及其网络要求。

如果客户端位于 VPN 后面，数据路径走同一条隧道，但不一定走同一条策略。

读懂 PASV 应答里的地址

运行详细模式的客户端，直接读应答而不是猜。 curl -v ftp://user@host/ 会打印 PASV 行，给出服务器想要的地址和端口，客户端接下来就连向那个地址。如果它是隧道客户端一侧毫无意义的私有地址，那么控制通道虽然健康，数据连接却无处可去。

把这个地址与客户端实际到达的地址进行比较。不一致就是答案，它通常来自 NAT，或者来自配置了内部地址的服务器。

检查端口范围和隧道策略

被动服务器从配置好的范围中分配数据端口，该范围必须通过 VPN 和路径上的任何防火墙。只放行 21 的策略是仅限登录的策略。向服务器管理员确认范围，然后从中测试一个端口，而不是假定整个范围表现一致。

加密的控制通道让这更难，因为中间设备无法再在传输途中改写公布的地址。

知道何时该用 EPSV 或回退方案

EPSV 返回端口而不附带单独地址，当两端都支持时，这消除了地址错误导致的失败。有些客户端还可以被要求忽略公布的地址，改用控制连接的目的地。两者都是针对特定拓扑的正当工具，而不是万能修复。

不要为了让辅助工具检查会话就关闭 TLS。那是用可用的协议去换一个残缺的威胁模型。

用一次列表和一次传输来确认

地址或端口策略改动后，通过同一条 VPN 路径打开新会话并列出目录。然后传输一个小文件，因为某些服务器上列表和传输走的是不同的代码路径。检查客户端日志中是否出现连向预期地址和端口的数据连接，并 确认字节已经到达。

做这些时，要把 FTP、FTPS 和 SFTP 分开考虑。被动端口改动不是 SFTP 设置，这个修复也不会跨协议通用。