用Nginx代理请求，处理先后端跨域

　　自从前端spa框架出现后，都是先后端分离开发了。咱们在开发的时候不免会遇到跨域的问题。跨域这种问题解决的方法基本都是在服务端实现的。以java为例，我知道的有3种方法处理跨域：

　　1.使用 @CrossOrigin 注解对每个接口进行跨域处理,缺点是比较麻烦

@CrossOrigin(origins ="*")
@RequestMapping(value = "/test", method = RequestMethod.GET)
public String test() {
    return "test";
}

　　2.使用 @CrossOrigin 在入口类对全部接口进行跨域处理

@CrossOrigin(origins = "*")
@RestController
@SpringBootApplication
public class SpringBootCorsTestApplication {
    // ***
}

　　3.还能够添加一个配置类，对全部的接口进行跨域处理

@Configuration
public class WebMvcConfig extends WebMvcConfigurerAdapter {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("*")
                .allowedMethods("POST", "GET", "PUT", "OPTIONS", "DELETE")
                .maxAge(3600)
                .allowCredentials(true);
    }
}

　　可是...咱们项目组的后端他们不在代码中处理跨域，经过线上的nginx统一配置跨域处理...咱们前端用的vue，vue配置中是有对于开发跨域的处理，因为咱们项目的特殊性，并不适合咱们（咱们一套代码会运行会部署在不一样的服务器，至少3套，先后端代码有差别，咱们经过gitlab分支解决代理管理，咱们将差别抽离出来成为不一样版本代码的配置，例如不一样的后台api接口地址，刚开始咱们前端代码在构建的时候将配置打进去，发现这样仍是代码和配置傻傻分不清楚，这样子处理的不是很好，咱们为了前端代码和配置的完全分离，将代码和配置分别创建两个gitlab仓库，前端项目构建的时候只是构建代码，配置会在部署的时候经过脚本对特定环境进行替换，我感受跟猴子补丁有点相似，以此来达到跟后台java同样一套代码，运行时用不一样命令读取不一样的配置运行）本着本身散装的nignx配置了解，能够经过本地nginx作一个请求代理转发，而后在nginx中处理跨域

server {
    listen 9090;
    server_name localhost;

    location /{
        add_header 'Access-Control-Allow-Origin' $http_origin;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        add_header 'Access-Control-Allow-Headers' '*';


        if ($request_method = "OPTIONS") {
            add_header 'Access-Control-Allow-Origin' $http_origin;
            add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
            add_header 'Access-Control-Allow-Headers' '*';
            add_header 'Content-Length' 0;
            add_header 'Content-Type' 'text/plain, charset=utf-8';
            return 204;
        }

        proxy_pass http://192.168.0.3:9999;
    }
    
    #location /aepreservation {
    #
    #    add_header 'Access-Control-Allow-Origin' $http_origin;
    #    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
    #    add_header 'Access-Control-Allow-Headers' '*';

    #    if ($request_method = "OPTIONS") {
    #        add_header 'Access-Control-Allow-Origin' $http_origin;
    #        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
    #        add_header 'Access-Control-Allow-Headers' '*';
    #        add_header 'Content-Length' 0;
    #        add_header 'Content-Type' 'text/plain, charset=utf-8';
    #        return 204;
    #    }
    
    #   proxy_http_version 1.1;
    #   proxy_set_header Upgrade $http_upgrade;
    #   proxy_set_header Connection "upgrade";
    #    proxy_pass http://192.168.0.3:9999;
   #}
}

　　nginx监听本地端口9090的全部端口，并转发到对应的后端服务(假如大家后台服务的地址为 http://192.168.0.3:9999/api/*，咱们的前端代理只要访问 http:localhost:9090/api/*就能够了，注意下方我注释的地方是代理websocket的方法，路径是/aepreservation，我当时为了偷懒（正则看着头疼），抄了一份上边的配置，ningx是能够经过正则判断的，只对肯定的websocket路径进行处理，不用向我同样写的这么啰嗦