指定了以下信息：
使用协议、请求方法、域名、URI作为cache key
cache文件保存在目录/tmp/Nginx/下，采取两层目录，keys_zone名称为my_zone，大小为10M
对于返回状态值为200的内容，cache有效时间为10分钟
现在，我们配置好了名为my_zone的cache，接下来选择对目录下的图片做缓存。首先，仍然是设置反向代理：
接下来，我们使用下列命令对img目录下的文件进行缓存：
配置命令解释如下：
proxy_cache指定使用的keys_zone名称，就是之前的my_zone
add_header在Nginx返回的HTTP头中，增加一项X-Proxy-Cache，如果缓存命中其值为HIT，未命中则为MISS
proxy_ignore_headers由于百度对图片的请求也会Set-Cookie设置，而Nginx不会缓存带有Set-Cookie的返回，因此我们这里设置忽略该HTTP头
现在，对图片的缓存配置就完成了，完整的配置内容如下
我们使用curl命令进行实验，访问。由于是第一次访问，可以看到返回内容中X-Proxy-Cache的值为MISS：
再次访问时，此时缓存命中，X-Proxy-Cache的值为HIT了
那么现在的Cache文件是什么样的呢？我们检查设置的缓存目录/tmp/Nginx，发现存在以下Cache文件：
可见，确实使用了2层目录保存了Cache文件。Cache文件保存了Nginx请求得到的返回内容：
可以看到，cache key的内容保存在了Cache文件的头部，此外还有Nginx请求后端返回的HTTP头，如后端（这里是）的服务器为Apache。正常情况下，这些信息是不会返回给客户端的。而本次的的漏洞，就是由于负数偏移量，导致Cache文件的头部信息也被返回，从而造成信息泄漏。
4 、漏洞原理首先，我们看这次漏洞修复的commit:
可以看到，在ngx_http_range_filter_module.c的ngx_http_range_parse函数中做了两处修复：
进一步检测了size的溢出情况，防止size溢出后造成小于content-length这条判断的绕过
则直接限定了使用后缀的情况下，start不能为负的，最小只能是0，也就是说使用“-xxx”的方式对Cache文件的读取只能从0开始到结束。
根据漏洞修复commit的注释，我们知道这次漏洞的主要成因就是bytes-range读取的起始范围可能为负数，从而读取缓存文件头部。
首先，如果传入完整的range参数，如start-end，则在ngx_http_range_parse()中会检查start，确保其不会溢出为负值：
因此，如果需要将start解析为负数，只能通过-end这类后缀型range参数实现:
此时的start等于content-length减去读入的end值，所以如果传入的end比实际长度还要长，就可以使start变为负数，而这就是第二处修复所处理的情形：
同时注意到，在这类情况下，最终end的值会被设定为content-length-1。所以这块range的总长度就超过了content-length。而Nginx对range总长度会有检查：