FTP上传下载全解：从原理、服务端搭建到排错与FTPS/SFTP选型

前阵子帮一个老客户迁移服务器数据，对方翻出一张泛黄的纸条，上面写着十几年前的 FTP 账号密码。说实话，现在云盘、对象存储、网盘工具遍地都是，但 FTP 这种老协议在企业内网、嵌入式设备、旧系统维护里依然活得很好。这篇文章我就把 FTP 上传下载从原理到实操、从命令到排错掰开揉碎讲一遍，包括服务端怎么搭、客户端怎么用、报错怎么查，也会聊到 FTPS、SFTP 的选型问题。如果你正在维护一台旧服务器，或者刚接触 FTP 想快速上手，这篇应该能帮上忙。

1. FTP 的底层逻辑：一条控制链路加一条数据链路

1.1 FTP 在 TCP/IP 协议栈里的位置

FTP（File Transfer Protocol）是 TCP/IP 协议族里专门负责文件传输的协议，它和 HTTP、SMTP 是同一辈的协议，早在 1971 年就有了雏形。很多人第一次学网络协议时，老师都会把 TCP/IP、FTP、HTTP 放在一起讲，这是因为它们都建立在 TCP 可靠传输的基础上，区别在于各自的用途和交互方式。

HTTP 设计出来是为了传输网页文档，它默认走 80 端口、TLS 后走 443 端口，一条连接搞定请求和响应。FTP 不一样，它从一开始就被设计成一个"搬文件"的协议，需要处理文件列表、传输进度、断点续传这些场景，因此它用了两条连接：一条控制连接，一条数据连接。

控制连接默认走 21 端口，负责传输命令和应答文字，比如你敲的 USER、PASS、LIST、RETR、STOR 这些指令，以及服务器的 230 Login successful、226 Transfer complete 这类响应。数据连接则动态建立，用来真正传输文件内容和目录列表。

我见过不少刚接触 FTP 的同事，第一反应是"为什么 FTP 还有主动被动模式，HTTP 就没有？"归根结底就是因为这个双连接设计。你在浏览器里下载文件时，浏览器会替你处理这些细节；但你自己用命令行或代码连 FTP 服务器时，主动模式和被动模式的差异就会被放大，搞不清楚就会遇到"能登录但列不出目录""能连上但下载超时"这类经典问题。

1.2 主动模式与被动模式：绝大部分连不上的根源

主动模式（PORT）下，客户端在控制连接上告诉服务器"我用哪个端口接收数据"，然后服务器主动从自己的 20 端口向客户端的那个端口发起数据连接。这里有个致命问题：客户端通常在内网，前面有路由器、防火墙、NAT，服务器主动连过来的时候，客户端侧的防火墙很可能直接把这个陌生连接丢掉。

被动模式（PASV）就是为了解决这个问题而生的。客户端在控制连接上发送 PASV 命令，服务器返回一个 IP 和端口，由客户端主动向那个端口发起数据连接。这样客户端侧防火墙会放行，因为这是由内向外发起的连接，符合常规防火墙策略。但麻烦转移到了服务器侧——你必须确保服务器的被动端口范围对外开放。

我在做 CentOS 7 和 Ubuntu 16 服务器 FTP 配置时，最常见的故障就是"能从 Windows 上登录，但一执行 ls 就卡死"，十有八九是被动模式端口没放行。后面我会在服务端配置里专门讲到端口段的问题。

1.3 现在的环境下，FTP 到底还适合干什么

先说结论：FTP 依然大量存在于企业内网、专用网络、嵌入式设备、老系统对接场景中，这是它的主力市场。

比如路由器、交换机、摄像头、工控机这些设备的固件备份，很多设备只提供 FTP 接口。又比如企业内部的数据交换目录，甲方要求对接的旧接口只支持 FTP。还有一些 NAS 设备，为了兼容老旧应用，默认会开 FTP 服务。

但如果你的需求是"在公网上传几个大文件给朋友"，或者"跨地域多端同步文件"，FTP 不是好选择。第一，它明文传输，包括账号密码，在公网上裸奔风险很大；第二，它没有目录冲突处理机制，增量同步、双向同步这些能力几乎为零；第三，被动模式需要开放一大批端口，这让防火墙策略变得很麻烦。

所以这篇文章讲 FTP，不是劝你在新项目里用它，而是帮你把已经存在的 FTP 系统玩明白、维护好。该迁移的时候我最后也会给出建议。

2. 服务端搭建：Linux 和 Windows 两条路都要会

2.1 Linux 下用 vsftpd 搭建的完整配置

Linux 上主流的 FTP 服务端是 vsftpd，名字是 Very Secure FTP Daemon 的缩写。它在 CentOS 7、Ubuntu 16 这些老系统上都还在维护，配置也不复杂。

先装包：

bash复制# CentOS 7 / RHEL
yum install -y vsftpd

# Ubuntu / Debian
apt-get update && apt-get install -y vsftpd

然后编辑 /etc/vsftpd.conf。下面是我在实测中比较常用的一套基础配置，我把注释也给你标好：

bash复制anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_std_format=YES

chroot_local_user=YES
allow_writeable_chroot=YES

pasv_enable=YES
pasv_min_port=40000
pasv_max_port=41000

这套配置的意思是：不允许匿名登录，允许本地系统用户登录并写入，用户登录后限制在自己的家目录（chroot），同时开启被动模式并指定数据端口范围为 40000–41000。

你可能会问，为什么要把被动端口限定一个小范围而不是不限制？因为 vsftpd 默认的行为会为每次数据传输动态绑定任意高端口，为了在防火墙上放行，你必须固定一个范围。40000–41000 是 1000 个端口，够普通并发用；如果你有大量并发用户，可以再调大。

改完配置后，重启服务并设置开机启动：

bash复制systemctl restart vsftpd
systemctl enable vsftpd

如果跑的是 Ubuntu 16，可能没有 systemd，用 service vsftpd restart 也一样。

有个细节必须提醒：chroot 开启后，如果用户的家目录对用户自己是可写的，vsftpd 在较新版本里会直接拒绝登录，报 500 OOPS: vsftpd: refusing to run with writable root inside chroot()。解决方式有两个，要么让家目录不能写（把可写目录拆分到子目录），要么在配置里加 allow_writeable_chroot=YES 释放限制。我建议测试环境用后者图省事，生产环境还是把目录权限设计好更安全。

2.2 Windows 下 IIS FTP 和第三方 Server 的陷阱

Windows 上的方案更杂，有人用 IIS 自带的 FTP 服务，有人装 FileZilla Server、Serv-U 这类第三方工具。IIS FTP 的坑主要在版本和管理工具上。

如果你用的是 Windows Server 2012 之后的版本，IIS 里默认不自带 FTP 服务，需要到"服务器管理器 -> 添加角色和功能"里勾选 FTP 服务器。装好之后在 IIS 管理器里新建 FTP 站点，设置绑定 IP 和端口。注意 Windows Server 2008 R2 的 IIS 7.5 和 Windows Server 2016 之后的 IIS 10，FTP 配置界面完全不同，网上很多教程截图是旧的，别照抄。

还有一个很容易忽略的点是"FTP 防火墙支持"。IIS 的 FTP 服务在被动模式下，需要你在 IIS 管理器的"FTP 防火墙支持"里配置外部 IP 地址和端口范围，否则客户端从外网访问时，服务器返回的 PASV 地址可能是内网 IP，客户端根本连不上。这个配置藏在功能视图里，不在站点设置里，很多新手找不到。

如果你不想用 IIS，我自己的经验是 FileZilla Server 更省心。它的安装包里自带了服务端和管理界面，配置项很直观，尤其是不太熟悉 Windows 网络管理的人。FileZilla Server 可以在设置里指定被动端口范围，比如 50000–50100，然后到防火墙放行就好。

无论哪种方案，装完之后一定要在 Windows 防火墙里放行对应端口。Windows 的防火墙策略和 Linux 的 iptables 一样，都是默认阻断，服务起得再欢，端口没开等于白搭。

2.3 防火墙、SELinux、端口策略——服务起来不等于能用

Linux 下服务起不来通常是配置文件问题，但服务起来了却连不上的情况，大概率是防火墙和 SELinux 在作怪。

CentOS 7 默认用的是 firewalld，要放行 FTP 服务和被动端口：

bash复制firewall-cmd --permanent --add-service=ftp
firewall-cmd --permanent --add-port=40000-41000/tcp
firewall-cmd --reload

Ubuntu 16 默认通常是 ufw，命令类似：

bash复制ufw allow 21/tcp
ufw allow 40000:41000/tcp

如果是 CentOS 7，还有一个大坑是 SELinux。SELinux 默认会阻止 vsftpd 访问某些目录和网络端口。你可以用 getsebool -a | grep ftp 查看相关布尔值，最省事的做法是：

bash复制setsebool -P ftpd_full_access on

这个开关会放开 vsftpd 的绝大多数限制，适合测试环境。生产环境更稳妥的做法是按需开启，比如 setsebool -P ftpd_use_passive_mode on、setsebool -P httpd_can_connect_ftp on 之类的具体项。但说实话，大部分人不会细抠 SELinux 的类型策略，用 ftpd_full_access 先跑通业务，再逐步收紧是更现实的路径。

我整理了一张简化排查表，服务端配置完后可以从上往下对照：

3. 客户端上传下载实操：从敲命令到脚本自动化

3.1 命令行 ftp：简单场景下的够用方案

Windows、Linux、macOS 都自带命令行 ftp 客户端。虽然它难用，但在最小化安装的 Linux 服务器上这是最可靠的随时可用方案。登录并下载上传的基本流程是：

bash复制ftp 192.168.1.230
# 输入用户名和密码
# 登录后先切二进制模式，否则图片、压缩包会被转坏
bin
# 查看目录
ls
# 下载文件
get remote_file.txt
# 上传文件
put local_file.txt
# 批量下载/上传
prompt off
mget *.zip
mput *.tar.gz

这里必须强调 bin 这个命令。FTP 默认是 ASCII 模式，在文本模式下传输时会做换行符转换，Windows 和 Linux 之间传文本经常出现 \r\n 和 \n 互相转换的乱码问题。传 .txt、.csv 这类纯文本还能接受，但如果传 .zip、.exe、.xlsx，哪怕是二进制文件中间有一个字节被改写，整个文件就损坏了。所以我一直以来的习惯是：登录后第一件事就是敲 bin，不管传什么文件都按二进制处理。

Windows 自带的命令行 ftp 不支持 SFTP，也不支持断点续传，批量下载时 mget 一次匹配一堆文件这个能用，但如果中途断了，它会从前一个文件重新开始，而不是从断点继续。这也是为什么我平时更倾向于用 curl 或 lftp 做自动化。

3.2 curl 和 lftp：自动化运维的主力

curl 在 Linux 和 Windows 10 自带的系统里基本都有，它不只支持 HTTP，也支持 FTP 上传下载。优点是命令干净、容易写进脚本。

bash复制# 下载单个文件并保持远程文件名
curl -u user:pass -O ftp://192.168.1.230/pub/readme.txt

# 下载并重命名为本地文件名
curl -u user:pass -o myreadme.txt ftp://192.168.1.230/pub/readme.txt

# 上传文件
curl -u user:pass -T backup.tar.gz ftp://192.168.1.230/backup/

curl 默认走被动模式，这对多数内网环境很友好。需要控制主动模式时用 --ftp-port 或 --ftp-method 调整，不过大部分场景不需要。

lftp 则是更强大的交互式工具，尤其擅长批量镜像目录。例如要把远端 /data 目录完整同步到本地 /local-backup，并支持断点续传：

bash复制lftp -u user,pass 192.168.1.230 -e "mirror -c /data /local-backup; quit"

这里的 -c 参数表示继续之前的传输（续传），比较适合大目录的增量同步。lftp 在 CentOS 上用 yum install -y lftp 装，Ubuntu 上用 apt-get install -y lftp。

我在脚本化上传时会做一个更稳妥的"两步走"：先把文件传到临时文件名，传完再 rename 成正式文件名。这样如果有其他脚本在监视目录，就不会读到半截文件。lftp 里可以这样串联：

bash复制lftp -u user,pass 192.168.1.230 -e "put /local/file.zip -o /remote/file.zip.tmp; mv /remote/file.zip.tmp /remote/file.zip; quit"

这个模式在对接业务系统时特别实用，很多程序扫描目录发现新文件就开始处理，如果文件还没传完它就启动处理，就会出现读到半个文件的问题。

3.3 图形客户端选择与断点续传

图形界面的 FTP 客户端里，我见过最多的是 FileZilla 和 WinSCP。FileZilla 跨平台，WinSCP 只有 Windows，但它可以直接和 Windows 资源管理器整合，双击就能打开远程目录。

FileZilla 连接时的两个关键设置：一个是"传输模式"，建议设成被动；另一个是"字符集"，老 Linux 服务器上如果中文文件名乱码，可以用强制 UTF-8，如果对方是 Windows 编码的 GBK 文件名，可能需要把字符集改成 "Custom" 并填 cp936。很多教程只讲连接，不讲编码，但中文文件名乱码在对接老系统时非常常见。

断点续传这块，FileZilla 和 WinSCP 都支持，传输中断后重连，右键文件选择"继续传输"。命令行 ftp 不支持，所以传大文件时不要用 Windows 自带的 ftp，确实是个坑。

另外要提醒一下，FileZilla 客户端连接某些旧版 vsftpd 服务器时，后台会提示 "FTP over TLS is not enabled"。这个警告的意思是服务器没有启用 TLS 加密，用户密码会明文传输。如果你只是内网测试环境，可以忽略；如果是生产环境，建议把服务端升级为支持 FTPS 的配置，或者改用 SFTP，这部分后面专门讲。

3.4 大文件上传的几种思路（含前端 Worker 和 Django）

FTP 传大文件最大的痛点不是速度，而是中断。几 GB 的文件传一半断线，如果客户端不支持续传，就要从头再来。所以大文件场景我一般分几种处理：

1. 使用支持断点续传的客户端：lftp mirror -c、FileZilla 的续传、curl -C - 都能续传。curl 的上传续传不总是可靠，但对多数服务器可用。
2. 上传前先压缩分片：把大文件 split 成多个小文件，再逐个传，传完后在服务器端合并。这样单个文件失败重传的成本低。
3. 如果是在 Web 应用里做上传，比如 Django 接收视频文件，FTP 不是唯一选项，但设计思路上和 FTP 一样要处理"分片和续传"。

关于第三点，很多热词搜索里会出现"vue 上传视频和封面图""前端使用 worker 上传大文件""django实现视频上传"这类问题。它们的核心思路是：浏览器端用 File 对象 slice 方法把大文件切成多个分片，然后丢给 Web Worker 并行上传分片，后端（Django 或其它的 Web 框架）接收分片后按顺序保存，最后再调用合并接口把分片拼成完整文件。这个过程其实和 FTP 的分片续传思路一模一样，只是传输层从 FTP 换成了 HTTP。

再提一个老梗：浏览器里上传大文件时遇到"不能装载 NTKO 大文件上传控件，请确保使用 IE 浏览器"这种提示。这个问题的根源是旧系统用了 ActiveX 控件实现分片上传，现在 Win10 自带 Edge 默认不再支持 ActiveX，IE 模式又默认关闭了相关安全选项。这种系统的正确出路是换成现代浏览器分片上传方案，而不是去"设置安全级别"，因为 ActiveX 本身就是个安全黑洞。如果你正好碰到这种平台，我的建议是直接推动技术组改造，别在 IE 兼容上花太多时间。

4. 高频问题排查：从登录失败到列不出目录

4.1 Windows 找不到 ftp:// 地址：先分清是访问方式还是网络问题

热词里有一条很典型："Windows 找不到 ftp:192.168.1.230。请检查拼写并重试。"

这个提示我见过无数次。大多数情况下不是网络不通，而是你把地址输入到了浏览器或者资源管理器，系统把它当成网页搜索或应用名了。正确做法是在地址栏里完整输入，包括协议头：

text复制ftp://192.168.1.230

如果资源管理器弹出一个窗口，提示"登录身份"，说明地址本身没问题；如果依然是"找不到"，那就是网络级别的问题。先用 ping 测一下 192.168.1.230 是否通，再用 telnet 测端口：

bash复制telnet 192.168.1.230 21

如果 21 端口能连上，说明基本网络通畅；连不上就看服务器防火墙、FTP 服务状态。

Win10 无法访问 FTP 文件夹，还有另一个隐蔽设置：Internet 选项 -> 高级 -> 勾选"使用被动 FTP（用于防火墙和 DSL 调制解调器兼容）"。Win10 默认被动模式，但某些企业网络里的防火墙策略和这个模式有冲突。这个设置我改过不止一次，改完后需要重启浏览器或资源管理器才生效。

4.2 能连上但证书警告、TLS 警告怎么处理

非常多的 FTP 客户端在连接时会弹出一条警告：warning: ftp over tls is not enabled, users cannot securely log in。

这条消息不是连接失败，而是服务器没有启用显式 FTPS（FTP over TLS）时，客户端给出的提示。如果你用的是 FileZilla，这个提示可能出现在消息日志里；如果你用 WinSCP，则可能弹窗提示"服务器不支持加密，是否继续"。继续连接是可以的，只是密码会明文传输。

要消除这个警告，需要在服务端启用 TLS。vsftpd 里需要修改配置：

bash复制ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_ciphers=HIGH
rsa_cert_file=/etc/ssl/certs/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.key

然后生成自签名证书：

bash复制openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout /etc/ssl/private/vsftpd.key \
  -out /etc/ssl/certs/vsftpd.pem

重启 vsftpd 后，客户端再连接时就会进入显式 TLS 协商流程，警告消失。要注意的是，有些很老的 FTP 客户端不支持 TLS，开启后反而连不上，所以这个改动要在可控的维护窗口里做。

4.3 中文乱码、被动模式端口不通、rz 上传丢文件的细节

中文乱码的原因，几乎都是客户端和服务端字符集不一致。老 Linux 服务器（比如 CentOS 6/7 早期环境）默认 locale 是 POSIX 或 en_US.UTF-8，但文件系统里存的中文文件名可能是 GBK 编码。FTP 传输目录列表时，服务器把这些字节原样发给客户端，客户端用 UTF-8 去解码，自然就乱码了。

解决办法：在 FileZilla 站点管理器里把服务器字符集设置为"强制 UTF-8"或者"自定义，cp936"，多试一次就能解决。WinSCP 则在"高级 -> 环境 -> 文件名"里设置 UTF-8 编码。如果是 lftp 命令行，可以敲 set ftp:charset "UTF-8" 和 set file:charset "GBK" 之类的命令。

被动模式端口不通的情况，症状是 ls 命令卡住，或者下载时进度条一直不动。排查链路分两步：

1. 在客户端抓包或看日志，确认服务器 PASV 响应返回的 IP 和端口是什么。如果返回的 IP 是 192.168.x.x 而客户端不在同一网段，那就是服务器配置里 pasv_address 没设置外网 IP。
2. 检查服务器防火墙是否放行了 pasv_min_port 到 pasv_max_port 的端口范围。很多情况下 21 端口通了，但 40000-41000 端口没通，就会造成这种半通状态。

"rz 上传的文件在哪去了"这个问题，其实不是 FTP 的锅。rz/sz 是 ZMODEM 协议，通常通过 SSH 终端使用，很多人输入 rz 后选择文件上传，然后去某个目录找半天找不到。rz 默认会把文件保存到当前终端所在目录，不是你自己想象的"服务器根目录"。所以上传之前先在终端敲 pwd 看当前目录，或者用 cd 切换到目标目录再 rz。

4.4 上传被拒绝的完整检查顺序

上传时遇到 "553 Could not create file" 或 "550 Permission denied" 这类拒绝提示，不要慌，按顺序排查：

1. 服务端 write_enable=YES 是否正确设置且服务已重启。
2. 用户对目标目录是否有写权限。用 chmod 检查目录权限：FTP 用户一般需要目录的写权限和执行权限。如果目录属于 root，用户没有写权限，上传自然失败。
3. chroot 之后用户是否能访问目录。如果 chroot_local_user=YES，用户只能在自己的根目录内活动，你让他上传到 /home/otheruser 肯定不行。
4. 磁盘空间是否满了。df -h 看一眼，FTP 上传失败很容被忽略的原因就是磁盘满。
5. 是否存在配额限制。XFS 文件系统的项目配额、/etc/vsftpd/vsftpd.conf 里如果配了 quota 相关的模块，也可能导致上传失败。
6. 被动模式下，目标端口段是否可达。

还有一种情况是服务器端做了文件类型过滤，比如某些平台会检测"pdf 内容包含不安全脚本或自动执行特征，已拒绝上传"。这属于应用层安全策略，FTP 本身不做这种过滤，但如果你对接的是二次开发过的 FTP 网关，就可能有这种规则。遇到这种问题只能找平台方确认拦截规则，不是 Ftp 配置的问题。

5. 明文传输风险与 FTPS/SFTP 的取舍

5.1 抓包看到 FTP 密码之后发生了什么

我在教团队排查网络问题时，做过一个测试：在客户端一台机器上运行 tcpdump 抓包，然后另一台机器用传统 FTP 登录，密码是什么在抓包结果里清清楚楚。

bash复制tcpdump -i eth0 port 21 -A

输出里能看到 USER 后面的用户名，PASS 后面的密码明文。这个冲击力很强。很多老工程师觉得 FTP 用了十几年没什么问题，是因为在内网没有抓包意识。但在公网上，明文密码就等于把大门钥匙交给路过的人。

所以我的建议很明确：凡是经过公网的 FTP 连接，必须启用 TLS，或者直接改用 SFTP。内网如果审计要求高，也应该考虑收敛。

5.2 FTPS、SFTP、FTP 三者对比与选型建议

很多人把 FTPS 和 SFTP 混为一谈，其实完全是两回事。FTPS 是 FTP 协议加 TLS 加密，端口还是 21，只是多了一次加密协商；SFTP 是基于 SSH 协议的文件传输子系统，默认端口 22，不走 FTP 控制连接和数据连接。

如果你在维护一个老系统，必须保留 FTP 协议兼容性，那就升级成 FTPS 至少把密码和数据的明文暴露挡住。如果要新建文件传输通道，我建议直接 SFTP，客户端基本都是现成的：WinSCP、FileZilla、lftp、curl 7.x 以上都支持 sftp:// 协议。Windows 自带的 OpenSSH 客户端也直接支持 sftp 命令。

这里也顺带解释一下"tcp/ip、ftp、http 等主流网络协议机制"这类搜索词背后的疑问：FTP、HTTP 都是 TCP/IP 之上的应用层协议，HTTP 因为 Web 大发展，已经衍生出 HTTP/2、HTTP/3，而 FTP 则一直停留在 1.0 时代。但两者并不冲突，HTTP 适合做请求响应式的资源访问，FTP 适合做批量目录交换。Web 表单上传文件本质上走的是 HTTP POST，不是 FTP，只不过在浏览器世界里，用户只关心"上传"这个动作，底层协议对使用者透明。

5.3 对象存储、网盘兴起后，FTP 的退出策略

对象存储出现后，很多新项目直接使用 S3、OSS、COS 这些产品，通过 HTTPS API 上传下载，既能用云厂商的鉴权和加速能力，又能避免维护 FTP 服务器的安全补丁。如果你的系统已经可以改，迁移到对象存储是更省心的方向。当时我在帮客户把老文件服务从 FTP 迁到对象存储时，保留了一个"FTP 兼容层"：在内网放一台跳板机，用 s3fs 或 rclone 把对象存储桶挂载成目录，再跑一个 vsftpd 指向这个目录，这样老客户端不改变习惯也能继续使用。这种桥接方案的好处是平滑过渡，坏处是引入一层额外故障点，需要监控。

但我也要说，不是所有场景都适合迁走。嵌入式设备、部分硬件网卡固件升级、专用网络设备的管理，它们的固件和文档只写了 FTP 配置，你压根没法改协议。这种情况下，尽量把 FTP 服务限制在隔离的内网网段，启用 FTPS，做好访问控制，也比裸奔强得多。

我自己实际维护这类老服务时，会在 vsftpd 上再叠加一层 tcp_wrappers 或类似的白名单机制，限制可连接来源 IP。虽然 vsftpd 本身有 hosts_deny / hosts_allow 配置，但很多人根本没开，这等于断了一条重要的防线。

最后再分享一点我个人的维护习惯

FTP 这个东西，单看每个功能点都不难，难的是把服务端、客户端、防火墙、SELinux、用户权限、编码、TLS 这些因素拼在一起后还能稳定运行。我平时在处理 FTP 问题时，从不先改配置，而是先用 tcpdump 或 Wireshark 抓一次包，看清楚客户端和服务端之间到底在哪个环节断的。很多时候包一看完，问题就定位了，根本不用瞎猜。

另外我会在服务器上写一个最简单的连通性检查脚本，定时探活 21 端口和被动端口范围，一旦发现异常就告警。这样能在用户报障之前提前发现问题。别看 FTP 是老技术，把这些运维习惯沉淀下来，它依然可以很可靠。

如果你正被某台 FTP 服务器折腾得头疼，建议你按这篇文章的顺序走一遍：先看链路通不通，再看主动被动模式，再看防火墙，再看 TLS，最后看目录权限。大部分问题都逃不出这几个环节。