这是一个奇怪的问题。
我有一个基于 centOS 7 的服务器，运行 vsftpd 作为 FTP 服务器。
如果我使用 filezilla 将文件从 centOS 盒子复制到本地客户端，则在传输大约 128MB 的几 MB（有时会更少）后，传输会失败。
如果我随后通过 SSH 连接到 CentOS 服务器并登录，然后尝试重复 FTP 下载，就像使用 filezilla 之前一样，文件传输会完全且快速。
我一生都无法弄清楚为什么通过 SSH 连接到服务器会影响 FTP 传输，有人能想到这种行为的任何原因吗？
答案1
如果您的 FTP 传输仅在您打开与服务器的 SSH 会话时才起作用，可能是由于以下几个原因造成的：
防火墙或安全设置：您的服务器的防火墙或安全设置可能允许 SSH 连接，但不允许 FTP。您应该检查服务器的配置以确保允许 FTP 流量。
转发端口：FTP 使用不同的端口进行数据和控制连接。如果您的服务器位于 NAT 路由器后面，您可能需要设置端口转发以允许 FTP 连接。
被动 FTP：如果您使用被动 FTP，则可能需要将 FTP 客户端配置为使用特定范围的端口。检查服务器的被动 FTP 设置并确保您的客户端已进行相应设置。
服务器配置：您计算机上的 FTP 服务器可能具有导致问题的特定配置设置。检查 FTP 服务器的设置和日志以识别任何潜在的问题。
用户权限：确保您用于 FTP 的用户帐户具有访问和传输文件所需的权限。默认情况下，SSH 会话可能会授予不同的权限。
必须检查这些方面，以确定在没有打开 SSH 会话的情况下 FTP 传输失败的原因，并相应地调整服务器或客户端配置。
答案2
最有可能的是，防火墙由于不活动而断开了您的连接。
在文件传输期间，您的 FTP 客户端不需要向服务器发送任何内容。当然，客户端会针对收到的每个数据块发送 TCP ACK，但问题是 FTP 使用两个通道，一个用于数据，另一个用于命令。后者将在转移期间保持沉默。
因此，如果文件非常大，其传输将花费很长时间，并且过度热心（且愚蠢）的防火墙可能会认为命令通道已死，将“关闭”它（可能不是以正统方式 = 有时只是停止对其进行 NAT，而不让任何一方意识到），从而阻止数据传输最终完成。
解决方案？使用保活。 TCP 保持活动或应用层保持活动（无操作命令）。
我看到 FileZilla 有一个保持活动选项设置->连接->FTP->发送FTP保持活动命令。尝试一下（但是我没有看到任何有关其频率的设置，并且可能会变得太短）。
至于为什么 ssh 连接会阻止连接被断开，这是一个谜，您应该首先询问断开连接的人（即根据什么标准？）。
最后，正如 Chris Davies 的评论所建议的：使用 scp、sftp、ssh+tar 或 ssh+rsync 可能会让您免于这些头痛，因为它们仅使用一个通道并集成了灵活的保持活动机制。