用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路徑進行處理，不用向我同樣寫的這麼囉嗦