出于某种原因，无论我尝试多少次，在客户端发送 PASV 命令（服务器正确接收）后，服务器的回复（227 进入被动模式）都不会返回到客户端。我甚至使用 Wireshark 分析了客户端和服务器流量以找出原因。特别奇怪的是，服务器发送的最后一个数据包与它迄今为止成功发送的每个其他数据包的 TCP 设置完全相同。它们都发往同一个客户端，在同一个端口，但出于某种原因，这个 227 响应从未通过。我完全不明白为什么。
以下是客户端和服务端交互的截图：
客户端捕获
如您所见，它从未收到 PASV 命令的 ACK。它再次尝试，然后放弃。
服务器捕获
如您所见，它接收了 PASV 命令并发送了响应，但始终无法到达客户端。它稍后重新发送并再次发送响应 3 次，但仍然无法到达。然后它断开了连接。
我无法想象所有其他 TCP 数据包都能毫无问题地从服务器传输到客户端，而这个特定的 TCP 数据包却不行。所有发往和来自服务器的数据包的 TCP 报头都是相同的，因此根据我的理解，所有路由器、防火墙、ISP 等都应该平等对待它们，除非它们是数据包嗅探。
答案1
我刚刚也遇到了同样的问题，在谷歌搜索解决方案时发现了这个问题。就我而言，问题是由防火墙 (Sonic Wall) 引起的，防火墙将服务器答案检测为可能的 FTP 反弹攻击并断开连接。解决方案是更改 FTP 服务器中的被动设置并输入内部 IP 地址作为对 PASV 的响应。然后防火墙将其检测为合法答案，并将答案转换为外部地址，然后再将其传输到客户端。这样设置感觉很不对，但它可以与此防火墙配合使用。
答案2
明显的解决方案：我一直在弄乱路由器上的任何内容，我认为这些内容可能会破坏传出的数据包。我禁用了名为“NAT ALG”的东西（应用级网关)，FTP 客户端和服务器又开始以被动模式正常通信。显然，这种协议监听给很多人带来了麻烦。
对于未来的读者，我的调制解调器/路由器是 Motorola SBG6580 SurfBoard。这是我的 ISP EastLink 的标准配置。它预配置了许多此类“功能”，其中一些似乎在以太网 II 帧级别破坏了传出的数据包。
答案3
我认为这是 FileZilla 版本 <3.6.0.2 的一个已知问题，您是否使用了旧版本？
答案4
我在 Windows 7 服务器上也遇到了同样的问题。客户端无法接收“227 进入被动模式”包。问题肯定出在服务器端。我关闭了所有防火墙，但结果还是一样。最后我找到了原因。在网络和共享中心，您无法将网络位置设置为“公共网络”。因为 Windows 将公共网络视为不受信任。任何连接您计算机的尝试都将被视为风险并被阻止。只需将其设置为“工作网络”，服务器就可以正常工作。