我在 FileZilla 服务器中设置了自签名证书并启用了 FTP over TLS。当我从客户端 FileZilla 连接时，我能够进行身份验证，每天 1-2 次，我会获得目录列表...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Status: Directory listing of "/" successful
但剩余时间无法获取目录列表
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is current directory.
Command: TYPE I
Response: 200 Type set to I
Command: PORT 192,168,1,119,88,109
Response: 200 Port command successful
Command: MLSD
Response: 150 Opening data channel for directory listing of "/"
Response: 425 Can't open data connection for transfer of "/"
Error: Failed to retrieve directory listing
答案1
FTP作为协议有点奇怪。它使用两个 TCP 连接，而不仅仅是大多数协议使用的端口。您有端口 21（命令和登录连接）和第二个连接（数据连接）。
使用被动 FTP 时，第二个连接是随机分配的 1024 以上的可用 TCP 端口。
您的问题似乎表明您的防火墙没有打开第二个端口。
通常情况下，如果防火墙足够智能，第二个端口会自动打开。由于 FTP 是明文协议，因此防火墙可以扫描端口 21 上的命令连接上的流量。防火墙将识别将要分配的 PASV 端口，并动态打开防火墙，允许该特定客户端与该会话中使用的 PASV 端口之间的流量。
因为你正确地使用了 TLS 加密，但实际上它不起作用。FTPS防火墙无法再监听命令通道。
解决方案：修复 PASV 端口（范围）：
一种解决方案是将 FTP 服务器配置为使用一小段端口范围或仅使用一个端口，并创建防火墙规则以打开这些端口。这在FileZilla 文档：
常规设置 ==> 被动模式设置 ==> 自定义端口范围
然后在防火墙中打开该端口范围。
此外，如果您位于 NAT 路由器后面，您会遇到第二个问题，即 PASV 响应不仅包含端口号，还包括 FTP 服务器的 IP 地址。
如果您仍以明文形式使用 FTP，则 NAT 路由器通常能够使用正确的外部 IP 地址重写该内部 IP 地址响应。
再次，因为您使用 TLS 上的 FTP，它不再起作用。
幸运的是，FileZilla 也有一个解决方案，它可以纠正这个问题，公布外部/公共 IP 地址而不是实际的（内部）IP地址。