办公室的打印机卡纸了能重启，但FTP传一半断了，员工只能盯着进度条发呆。你大概见过这个场景：合同附件、设计原稿、几百兆的数据库备份，刚跑到70%突然“连接已关闭”，重新来一遍又卡在差不多的位置。很多人第一反应是网速波动、磁盘IO不够，或者干脆吐槽FTP太老。其实问题往往藏在更隐蔽的地方——端口空闲超时和防火墙的会话回收机制。
FTP这东西长得像普通客户端，骨子里却是“双通道”选手。你以为它只占一个端口？控制连接（默认21端口）只负责发指令，真正搬文件的是数据连接。被动模式（PASV）下，服务器会临时开一段端口范围，把端口号写回给客户端，客户端再主动连过去。大文件传输时，数据通道一旦中间有几十秒的静默期，或者NAT设备、安全网关觉得“这条路没人说话了”，就会把这条连接悄悄回收。客户端那边还没传完，服务器已经把端口释放了，断线自然找上门。
要稳住它，得从服务器端先把“耐心值”拉满。以Linux上最常见的vsftpd为例，配置文件一般在/etc/vsftpd/vsftpd.conf。几个关键参数直接对照着改就行：
# 控制连接空闲超时（单位：秒），默认600，大文件场景建议拉到1800~3600
idle_session_timeout=1800
# 数据连接空闲超时，默认300，传大文件至少给到900
data_connection_timeout=900
# 开启TCP KeepAlive，让空闲连接不被中间设备误判为死连接
tcp_keepalive=yes
# 被动模式端口范围，必须和防火墙放行区间完全一致
pasv_min_port=50000
pasv_max_port=50100
pasv_address=你的公网IP或DDNS地址
改完别急着重启，先用vsftpd -o /etc/vsftpd/vsftpd.conf -d跑一遍语法检查，没报错再systemctl restart vsftpd。Windows上的IIS FTP Manager或者FileZilla Server也有类似选项，路径不同但逻辑一样：控制连接别太敏感，数据连接多给缓冲，端口范围提前画好圈。
服务器把耐心调好了，防火墙这边要是还按老规矩办事，照样白搭。很多企业的边界防火墙、云安全组、甚至Linux自带的firewalld，都会对FTP做ALG（应用层网关）检测，自动识别PASV回复里的端口号并动态开孔。但ALG有时候抽风，反而会把连接状态搞乱，尤其是遇到大流量或加密封装时。如果你们用的是现代防火墙，建议优先确认两件事：
第一，放行pasv_min_port到pasv_max_port这段范围，协议选TCP，方向是入站。不要只开21端口，那是控制通道，数据通道必须单独放行。
第二，检查NAT会话超时设置。Linux内核的nf_conntrack对FTP的默认超时大约是30秒，传大文件肯定不够。可以先确认模块是否正常加载：
lsmod | grep nf_conntrack_ftp
cat /proc/sys/net/netfilter/nf_conntrack_ftp_timeout
如果超时值还是默认的30或60，直接拉长：
# 临时生效，单位：秒
echo 300 > /proc/sys/net/netfilter/nf_conntrack_ftp_timeout
echo 600 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
# 持久化写入
mkdir -p /etc/modprobe.d
echo 'options nf_conntrack_ftp timeout=300' > /etc/modprobe.d/nf_conntrack_ftp.conf
echo 'net.netfilter.nf_conntrack_tcp_timeout_established=600' >> /etc/sysctl.conf
sysctl -p
企业级防火墙（深信服、华为、Palo Alto、Fortinet之类）界面里通常有“FTP ALG”或“应用识别”开关。大文件传输密集的场景，我建议把FTP ALG关掉，改成手动放行端口段。ALG虽然方便，但它要深度解析FTP数据包，遇到FTPS加密传输直接失效，还可能因为解析延迟把正常连接判为异常。手动放行反而更透明、更可预测。
光调参数不验证，等于蒙眼开车。下次员工再报断线，别急着问“是不是网不好”，直接在服务器上跑这几步：
# 实时抓FTP数据流，看是不是在某个时间点突然收到RST
tcpdump -i any tcp portrange 50000-50100 -nn -vv
如果你看到大量Flags [R]（RST重置）而不是正常的Flags [.][ACK]或Flags [F]，基本就是中间某台设备主动掐断了连接。这时候回去核对防火墙会话表：conntrack -L | grep ftp，或者在防火墙后台查“活跃会话”和“会话老化记录”。另外，客户端日志一定要留。FileZilla在“编辑→设置→日志记录”里可以开启详细日志，断线那一刻的时间戳和错误码能直接告诉你问题出在哪一端。比如ETIMEDOUT通常是防火墙或NAT回收了会话，ECONNRESET多半是中间设备发了RST，421 Service not available则是服务器主动拒绝，可能是超时配置又没生效。
顺便说一句，别把所有大文件都塞进传统FTP。如果公司内部有NAS、MinIO或者对象存储，SFTP/FTPS配合分块上传会稳得多。FTP本身的设计年代早于现代防火墙普及期，它那种“动态开端口+ALG解析”的通信方式，放在零信任架构里确实有点水土不服。但如果业务暂时离不开FTP，把超时参数和防火墙策略对齐，基本能解决九成的“传一半断线”问题。
调参这事儿没有银弹，但逻辑很直白：服务器别太急躁，防火墙别乱删会话，两端给彼此留够缓冲。下次再遇到进度条卡住，先看看连接是不是被“误杀”，而不是怀疑员工电脑有问题。网络运维的真相往往就藏在这些不起眼的超时数字里，摸清它们，传输自然就顺了。