使用Nginx过滤OPTIONS请求，避免后台大量204响应

使用Nginx过滤OPTIONS请求（204）

在前后端分离项目中，由于跨域，导致前端每次请求后台都会发送一个options请求去检查目标站点是否可达，这样后台就会收到很多响应码为204的OPTIONS请求，虽然每次请求都耗时极少，但是一旦请求量大了，还是会占用部分连接资源，并且日志中也会存在很多没用的数据，导致日志文件体积增加。下面就来讲讲如何利用Nginx拦截这些OPTIONS请求

拦截请求之前

浏览器的请求信息

可以看到每个200响应之前都有一个204响应，耗时也就几毫秒，但是就是看它不爽。

同样服务器端的日志是一个204响应一个200响应

Nginx配置

location /{
    if ($request_method = 'OPTIONS') {
        # 对于OPTIONS，不保存请求日志到日志文件
        access_log off;

        # 这里配置允许跨域的域名，* 代表所有，也可以写域名：http://www.xxx.com 或者IP+端口 http://192.168.1.10
        add_header 'Access-Control-Allow-Origin' '*';
        # 允许的请求类型
        add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';
        add_header 'Access-Control-Allow-Credentials' true;
        add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
        # 允许跨域的最大时间，超过这个时间又会重发一次OPTIONS请求获取新的认证
        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Content-Type' 'text/plain charset=UTF-8';
        add_header 'Content-Length' 0;
        # 直接在这里返回204响应，不转发到后台服务程序
        return 204;
    }
    # 原来怎么写这里还怎么写
    ...
}

层级如下图

最后的效果

前端依然会发送OPTIONS请求，因为要判断请求是否可达

但是后台的日志中没有OPTIONS请求了，因为请求到Nginx那被拦截了，直接就返回浏览器了，没有到达后台服务程序

大功告成！！！