记一次FTP下载踩坑的故(shi)事(gu)

下班前领导忽然要求我将客户的日志服务器上一些日志拷贝到测试服务器中，不过领导只提供给我ftp的连接方式，很明显就是要我用ftp方式去做啦

一般来说ftp批量下载也就上网随便找个脚本的事，但是却成了我疯狂踩坑的开始

1、mget命令完全不能用

首先，为了保证命令是可以正常执行的，我们先连接ftp服务器，并跳转到某个文件夹下，执行以下命令：

mget *

一般来说，这时候弹出下载提示只需要回车即可下载，然而我这次却深深的感觉到了这个命令的恶意

1 mget -rwxr-xr-x 1 user group         154519 jan 02 07:30 20190101180001.txt? 
2 227 entering passive mode(192,168,24,158,7,170).
3 550 "/log/2019/01/-rwxr-xr-x 1 user group         154519 jan 02 07:30 20190101180001.txt": directory not found.

excuse me?

为什么你的文件路径会在文件名前出现文件属性？？？

我就不信邪了，既然都是txt格式保存的日志那我就只取.txt的，我就不信还有问题

ftp> mget *.txt        
"/log/2019/01/*.txt": directory not found.

卧槽，别这么打脸好吧！难道是ftp服务器挂了？于是用get命令试了一下，然而...

ftp> get 20190131160001.txt
local: 20190131160001.txt remote: 20190131160001.txt
227 entering passive mode(192,168,24,158,18,227).
150 opening binary mode data connection for file transfer.
226 transfer complete.
1540 bytes received in 2.39 secs (0.65 kbytes/sec)

很明显，ftp服务器没有任何问题，get命令可以执行，mget出错是什么鬼

行行行，你赢了，mget不行我换个方式可以了吧。

2.wget下载失败

既然mget有问题，那我们就换一个方法，但是curl不支持递归下载，那我们就选择常见的wget来吧

[root@localhost ~]# wget ftp://user:password@192.168.24.158/log/2019/02/20190201180001.txt
--2019-02-27 15:37:42--  ftp://user:*password*@192.168.24.158/log/2019/02/20190201180001.txt
connecting to 192.168.1.1:8080... connected.
proxy request sent, awaiting response... 

看起来好像没问题了，响应可能需要一点时间吧，等等就好了（于是等到了地老天荒）

还等啥啊！局域网响应哪有这么久的！

 

3.虚拟机执行以上命令，找到原因

以上两个常用方法都失败了，那会不会是网络问题呢？于是我到我自己的虚拟机上执行这这几条命令，结果mget得到的结果是一样的，但wget却可以成功下载。

那么问题就很明显了，mget获取文件名的时候，十有八九是ftp服务器将文件属性和文件名合并成一个字符串发送到客户端，所以会出现前面的问题，要是有哪个大佬知道这个问题的原因或者解决方法的话麻烦留个言。

那么wegt失败的原因是什么呢？

仔细观察响应信息之后，我才忽然注意到怎么wget的时候把192.168.1.1作为代理服务器了，让我一度以为是被网关给拦截了，于是加上了参数--no-proxy

wget -r -nh --proxy=none ftp://user:password@192.168.24.158/log/2019/02/* 

哇，终于下载成功了，是哪个混蛋设置了默认代理，还代理到网关去了！