前端也要懂的Nginx反向代理跨域

最近公司先後端分離，前端獨立提供頁面和靜態服務很天然的就想到了用nginx去作靜態服務器。同時因爲跨域了，就想利用nginx的反向代理去處理一下跨域，可是在解決問題的同時，發現網上有些方案的確是存在一些問題，在這裏總結一下基本配置，也聊一下常見的配置問題。～～文末有驚喜～～

---

Nginx接口服務反向代理基本配置

server {
    listen 8443; # 監聽的端口號
    server_name a.test.com; # 服務器名稱
    client_max_body_size 100m;   # 定義讀取客戶端請求頭的超時時間
    ssl on;
    ssl_certificate test.pem;
    ssl_certificate_key test.key;
    ssl_session_timeout 5m;
    ssl_protocols SSLv3 TLSv1.2;
    ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM;
    ssl_prefer_server_ciphers on;
    location / {
        root /test-static-app; # 靜態資源目錄
        index index.html index.htm;
        try_files $uri $uri/ /index.html; # 動態解析目錄，配合vue的history模式
    }
}
複製代碼

基本配置實現了頁面及靜態服務器的基本功能，並能夠實現使用vue的history模式時的路由解析。進一步的，爲了實現向接口服務器的統一轉發，咱們須要和後端開發人員規定接口名的前綴，好比全部接口的相對路徑都以api開頭，此時咱們能夠添加以下配置(和上一個location平級)，

...
location /api {
   proxy_pass https://b.test.com; # 設置代理服務器的協議和地址
   proxy_cookie_domain b.test.com  a.test.com; # 修改cookie，針對request和response互相寫入cookie
}       
...
複製代碼

其中主要依賴proxy_pass，實現將a.test.com下的/api/x接口轉發到了b.test.com下面，這個過程大體以下

cookie的交互主要就是proxy_cookie_domain，加上下面這段

proxy_cookie_domain b.test.com  a.test.com; 
複製代碼

這個實現了，a.test.com和b.test.com域名之間cookie的傳遞與回寫。這裏的理解有點小誤區，晚點補充一篇詳細解釋上來。補上了，看這裏：juejin.im/post/5d4567…

若是用node來模擬一下的話，大體以下

module.exports =  (router) => {
  router.get('/api/index/getCmsInfo', async function (ctx, next) {
    // 接口轉發
    let result = await superagent.post('https://b.test.com/api/card/home').set(browserMsg)
    // 獲取返回的set-cookie，並設置header
    let setCookie = result.headers['set-cookie']
    if (setCookie) {
        ctx.response.header['set-cookie'] = setCookie
    }
    // 返回
    ctx.response.body={
        success: true,
        result: result.body 
    }
  })
}
複製代碼

綜上nginx反向代理的本質其實就是接口服務的轉發與header的處理，仔細想一想也就容易理解了。

常見誤區

一、無用的ACA-Header ？ 網上不少的nginx跨域設置裏面都加了跨域header設置相關的內容，好比

add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Credentials' "true"; 
add_header Access-Control-Allow-Headers X-Requested-With;
複製代碼

想一想上面的原理，各位看官以爲這個還有用麼？ACA(Access-Control-Allow-)系列的header自己是爲了cors中作協商跨域而配置的，在這裏配這個純屬脫褲子放屁畫蛇添足。

二、proxy_pass 域名帶不帶‘斜槓/’ ？ 一樣的，在網上看到了有的網友在配置proxy_pass的時候，會在後面加一個斜槓，以下，而後說報錯啦，找不到接口啦～咋整啊～

...
location /api {
   #proxy_pass https://b.test.com;
   proxy_pass https://b.test.com/;
}       
...
複製代碼

看到這個咱們來想想哈，proxy_pass的做用是抓發，加了斜槓意味着全部的**/api請求都會轉發到根目錄下，也就是說 /api 會被 / 替代，這個時候接口路徑就變了，少了一層/api**。而不加斜槓的時候呢？這表明着轉發到b.test.com 的域名下，/api的路徑不會丟失。 針對這種狀況，若是後端接口統一有了規定前綴，好比**/api**，那你這裏就不要配置斜槓了。另外一種狀況，後端接口shit同樣，沒有統一前綴，這邊又要區分，那就在前端全部接口都加一個統一前綴，好比**/api**，而後經過加斜槓來替換掉好了～

---

插播一條晚間新聞：最近入職螞蟻了，emmm最近咱們又要招人了，螞蟻金服-芝麻信用招前端P6/7，大廠你懂的，感興趣的快來試試吧，評論留言每晚回覆哈

---

以上就是本次的所有內容了～今天的《新聞聯播》播送完了，謝謝收看，(男)再見～(女)再見～