虚拟机创建FTP服务后用户无法访问，多数情况下问题出在防火墙规则、被动模式端口未放行或虚拟机的网络适配器设置上，按顺序排查即可解决。
先看访问路径：FTP客户端发起连接，先经过物理机网卡、宿主防火墙、虚拟网络交换机、虚拟机防火墙，最后才到达vsftpd进程，这四个环节随便哪一环拦截，都会表现为“用户无法访问”，我用虚拟机搭FTP也踩过同样的坑，后来发现相当一部分故障都能通过下面三件事定位：检查监听地址、放行防火墙端口、确认网络模式。
虚拟机FTP服务无法访问？先确认这个“无法访问”的具体位置
不同位置的访问失败，原因完全不同，先别急着改配置，打开命令行确认一下：在虚拟机本机执行 ftp 127.0.0.1，如果这里都连不上，说明vsftpd服务本身没启动或配置语法错误,检查服务状态：
- Ubuntu/Debian：
systemctl status vsftpd - CentOS/RHEL：
systemctl status vsftpd
如果本机能连，但同一台虚拟机的另一个SSH会话里用虚拟机的IP访问也失败，问题多半在监听地址，执行 ss -tlnp | grep 21，看到 0.0.1:21 就说明服务只监听了回环接口，外部请求根本进不来，此时编辑 /etc/vsftpd.conf 中的 listen_address=0.0.0.0,并注释掉仅监听本机的行。
接着从宿主机访问虚拟机，如果失败，检查Windows防火墙，行业共识认为，FTP这类老协议在Windows防火墙下需要额外放行，尤其开着远程桌面、在线代理共存的环境里，误拦截概率更高，你可以临时关掉Windows防火墙做一次测试，通了就给vsftpd或端口加允许规则,别一关了之。
从局域网其他电脑访问失败，问题往往出在虚拟机的网络模式,这是下一节重点。
虚拟机搭建FTP服务时，网络模式选NAT还是桥接？
这是虚拟机创建FTP服务初期最容易留坑的地方，默认情况下VMware和VirtualBox都推荐使用NAT模式，但NAT模式对外部访问者来说，虚拟机就像躲在一扇门后面，如果用户只想自己本机调试，NAT完全可以；如果要求同网段的其他电脑都能访问FTP，
桥接模式更省心,两类模式对比如下：
- NAT模式：虚拟机通过宿主机共享IP上网，外部用户无法直接触达虚拟机的21端口,需要配置端口转发。
- 桥接模式：虚拟机直接接入物理网络，有自己的局域网IP，外部用户可以直接访问,但容易遇到IP地址冲突或需要管理员分配固定IP。
- Host-Only模式：只允许宿主机访问，用户想从外部连FTP，基本等于死路一条,除非再加路由。
NAT模式下，端口转发这样填才不漏
打开VMware：编辑 -> 虚拟网络编辑器 -> 选中VMnet8 -> NAT设置 -> 添加端口转发，把宿主机的21端口转发到虚拟机的21端口，协议选TCP，然后还要为被动模式准备一个端口范围，比如40000-40100，同样做转发，否则用户登录成功后列目录会卡死，VirtualBox的操作路径不同：设置 -> 网络 -> 高级 -> 端口转发,添加规则即可。
桥接模式下，IP地址和网关不要随手乱填
桥接模式下虚拟机应当和宿主机处于同一网段，不改IP时，虚拟机可能自动拿到一个新IP，但用户记的是老IP，依然访问不了，建议在虚拟机里设置静态IP，和宿主机网卡同一网段，网关指向家里的路由器或公司核心交换机，改完用 ping 宿主机IP 验证链路,通了再测FTP。
虚拟机防火墙设置不当，FTP用户权限再高也没用
不少人在vsftpd里配好了用户、密码、目录权限，满心以为能登录，结果外部用户连21端口都会被拒绝,防火墙就是隐藏的拦路虎。
Ubuntu/Debian 上用 ufw 放行FTP服务
执行以下命令,注意别只开21端口：
sudo ufw allow 21/tcp
sudo ufw allow 40000:40100/tcp
sudo ufw reload如果之前启用了默认拒绝，还得确认 sudo ufw status verbose 里能看到以上规则。
CentOS/RHEL 上用 firewalld 放行FTP服务
执行：
sudo firewall-cmd --permanent --add-service=ftp sudo firewall-cmd --permanent --add-port=40000-40100/tcp sudo firewall-cmd --reload
用 firewall-cmd --list-all 检查，看到 ftp 和 40000-40100/tcp 才算完。
SELinux不放手，FTP用户登录了也写不进文件
CentOS里除了firewalld，还有个SELinux，执行 getenforce，如果是Enforcing，即使FTP服务正常，用户也可能在登录后读取目录时收到500错误，业内专家指出，这种情况在RHEL系虚拟机中相当常见,处理办法是：
setsebool -P ftpd_full_access on或更保守一点，只开启针对用户主目录的 ftp_home_dir，改完后用 getsebool -a | grep ftp 确认状态。
被动模式没配好，虚拟机FTP服务连得上却卡在列目录
这是“用户无法访问”中最让人抓狂的一种表现：客户端提示连接成功，输入账号密码后，进度条卡在“正在读取目录列表”，最后报错“连接超时”或“无法打开数据连接”，原因在于FTP主动模式与被动模式的差异：当客户端在NAT之后，或虚拟机在NAT之后，被动模式要求FTP服务端打开一组高位端口，这组端口没有被防火墙放行,数据连接就建立不起来。
vsftpd.conf里这几个参数必须出现
打开 /etc/vsftpd.conf,确认以下内容：
pasv_enable=YES
pasv_min_port=40000
pasv_max_port=40100保存后重启服务，不要用默认的随机高位端口，随机端口很难在防火墙和NAT转发里逐个放行,统一规划成连续区间是行业共识。
物理机和虚拟机的四层网络都要放行这100个端口
从内到外检查：虚拟机防火墙放行了40000-40100；宿主机防火墙同样放行；VMware的NAT端口转发规则里添加40000-40100；如果FTP用户来自公网，家用路由器的端口转发层也要做对应映射，每个环节漏一个，被动模式都必挂，通完以后，用FileZilla连接，把日志级别调到“调试信息”，能看到客户端请求了哪个端口,立刻就能对上号。
账号权限和无响应别混为一谈，三个典型报错一眼看清
用户无法访问FTP时，报错信息能直接帮你定位问题,下面这些常见情况值得记一下：
- 530 Login incorrect：用户名或密码错误，或者该账号被vsftpd的userlist拒绝，检查 /etc/vsftpd.user_list 和 /etc/vsftpd.chroot_list。
- 500 OOPS: cannot change directory：多数和SELinux、目录权限或chroot目录配置有关,按上面SELinux部分处理即可。
- 550 Permission denied：账号能登录但没写权限，检查目录属主和写权限，
chown -R ftpuser /srv/ftp/share，目录权限建议755,上传目录建议775。
如果你用的是Windows自带的FTP客户端，老旧的IE/资源管理器模式还会强制主动模式，连接被动模式服务端时会失败,换成FileZilla或WinSCP就好。
关于虚拟机FTP服务无法访问的常见问题解答
为什么虚拟机里FTP服务已经启动，外部用户还是无法访问？
先确认vsftpd监听在0.0.0.0，而不是127.0.0.1；再检查虚拟机防火墙和宿主机防火墙是否放行21端口；最后确认虚拟机的网络模式，NAT模式下没有端口转发时外部用户根本找不到虚拟机，按这个顺序排查,绝大多数无响应问题能解决。
桥接模式的虚拟机FTP服务，在办公室网段能通，换个Wi-Fi就访问失败，怎么回事？
Wi-Fi路由器如果开启了AP隔离，会阻断同一无线网络下设备之间的互通；另外用户设备如果连接的是访客网络，与虚拟机所在网络不在同一VLAN，FTP数据包自然送不到，这种情况下要么关闭AP隔离,要么让FTP用户改用网线连接同一局域网。
FTP用户登录时验证通过，但列目录时卡住一分钟后才报错，该调整哪里？
这是典型的被动模式数据端口不通，检查vsftpd是否配置了pasv_min_port和pasv_max_port，然后逐层放行虚拟机防火墙、宿主机防火墙和NAT端口转发中的相同端口段，端口范围越大，被防火墙漏掉的概率越小，但建议别超过一百个,不然规则太多反而难维护。
最后再提醒一句：虚拟机创建FTP服务，用户无法访问时，不要总想着加深密码或改目录权限，把链路、端口、模式这三件套理顺,大多数故障当场就能解决。