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的傳遞與回寫。這里解釋有點問題,具體內容詳見Nginx反向代理理解誤區之proxy_cookie_domain

如果用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的處理,仔細想想也就容易理解了。

常見誤區

1、無用的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中做協商跨域而配置的,在這里配這個純屬脫褲子放屁多此一舉。
2、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,然后通過加斜杠來替換掉好了~

以上就是本次的全部內容了~今天的《新聞聯播》播送完了,謝謝收看,再見~再見~


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM