FTP上传失败报错227 Entering Passive Model (222,111,8,111,10,40)
昨天为了一个ftp问题折腾了一天。问题背景：原来有个接口涉及到上传文件，服务端更换了ftp服务器，我们这边需要刷新连接服务端的ip和端口配置，代码没动。联调环境和验收环境都测试通过，一到生产环境就歇菜了。我们手工连接ftp并上传文件正常，就是跑接口由程序上传不行。根据日志信息定位发现在登录ftp后程序做了两个事情，一个是把传输模式设置为二进制，一个是设置被动模式，用apache的Ftpclient实现：
ftpClient.enterLocalPassiveMode();
从代码层面看不出问题，因为我们根本就没动，因此开始怀疑服务端配置问题，找他们确认后，他们的ftp服务器设置的就是被动模式。这里需要区别下主被动模式：主动模式下客户端通过命令端口（通常是21）连服务端后，服务端通过数据端口（通常是20）“主动”连接客户端；被动模式下客户端通过命令端口连接服务端后，服务端还是通过命令端口告诉客户端“我的XX数据端口可以连接，你过来吧”，于是客户端按该指定数据端口连接过去，服务端“被动”连接。命令端口就是传输ftp命令用的，数据端口就是上传下载文件用的。XX端口一般不固定且大于1024。既然服务端是被动模式，那么它会告知我们一个随机端口给我们去上传文件。服务端的命令端口是10000，开通了10001-10100作为数据端口。但现在不通，两边都说没问题，没办法，只能抓包:
220 "welcome to FOOBAR FTP service."
USER wlf
331 Please specify the password.
PASS 123
230 Login successful.
TYPE I
200 Switching to Binary mode.
PASV
227 Entering Passive Mode (222,111,8,111,10,40)
500 OOPS:
vsf_sysutil_recv_peek: no data
让服务端改为主动模式重试，抓包结果一样。这说明只要我们程序里设置了客户端为被动模式，服务端无论初始设置是主动还是被动，都会按被动模式来进行，而问题很可能就出现在服务端再次发送过来的连接通道上，如果该通道对客户端不可达，那么必将导致客户端再次连接服务端上传文件失败。经确认，我们跟服务端之间是用内网连接的，登录时也是根据内网ip来的，从抓包看登录成功。而从报错的信息看，客户端设置了被动模式后服务端新建到客户端的连接使用的是经过NAT映射后的外网ip，就是上面那个222.111.8.111。客户端内网跟服务端外网网络是不通的，导致客户端到服务端新建的数据传输管道无法连通。
综上所述，问题的解决方案有三个：要么服务端把外网ip改为内网ip，要么客户端使用主动模式上传文件，要么开通客户端内网到服务端外网的网络策略。第一个方案服务端不同意，理由是他们还有其他客户端，需要统一提供外网；第二个方案我不知道能否开通内网到内网映射的外网的网络策略，有待确认；所以最终只能我们改代码，客户端不再设置被动模式，把上面那一行设置被动模式的代码注释掉就可以了，默认就是按主动模式来的。