詳解Nginx反向代理跨域基本配置與常見誤區(qū)
跨域是指a頁面想獲取b頁面資源,如果a、b頁面的協(xié)議、域名、端口、子域名不同,所進(jìn)行的訪問行動(dòng)都是跨域的,而瀏覽器為了安全問題一般都限制了跨域訪問,也就是不允許跨域請(qǐng)求資源。注意:跨域限制訪問,其實(shí)是瀏覽器的限制。理解這一點(diǎn)很重要?。?!
最近公司前后端分離,前端獨(dú)立提供頁面和靜態(tài)服務(wù)很自然的就想到了用nginx去做靜態(tài)服務(wù)器。同時(shí)由于跨域了,就想利用nginx的反向代理去處理一下跨域,但是在解決問題的同時(shí),發(fā)現(xiàn)網(wǎng)上有些方案的確是存在一些問題,在這里總結(jié)一下基本配置,也聊一下常見的配置問題。
Nginx接口服務(wù)反向代理基本配置
server { listen 8443; # 監(jiān)聽的端口號(hào) server_name a.test.com; # 服務(wù)器名稱 client_max_body_size 100m; # 定義讀取客戶端請(qǐng)求頭的超時(shí)時(shí)間 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; # 靜態(tài)資源目錄 index index.html index.htm; try_files $uri $uri/ /index.html; # 動(dòng)態(tài)解析目錄,配合vue的history模式 } }
基本配置實(shí)現(xiàn)了頁面及靜態(tài)服務(wù)器的基本功能,并可以實(shí)現(xiàn)使用vue的history模式時(shí)的路由解析。進(jìn)一步的,為了實(shí)現(xiàn)向接口服務(wù)器的統(tǒng)一轉(zhuǎn)發(fā),我們需要和后端開發(fā)人員規(guī)定接口名的前綴,比如所有接口的相對(duì)路徑都以api開頭,此時(shí)我們可以添加如下配置(和上一個(gè)location平級(jí)),
... location /api { proxy_pass https://b.test.com; # 設(shè)置代理服務(wù)器的協(xié)議和地址 proxy_cookie_domain b.test.com a.test.com; # 修改cookie,針對(duì)request和response互相寫入cookie } ...
其中主要依賴proxy_pass,實(shí)現(xiàn)將a.test.com下的/api/x接口轉(zhuǎn)發(fā)到了b.test.com下面,這個(gè)過程大致如下
cookie的交互主要就是proxy_cookie_domain,加上下面這段
proxy_cookie_domain b.test.com a.test.com;
這個(gè)實(shí)現(xiàn)了,a.test.com和b.test.com域名之間cookie的傳遞與回寫。
如果用node來模擬一下的話,大致如下
module.exports = (router) => { router.get('/api/index/getCmsInfo', async function (ctx, next) { // 接口轉(zhuǎn)發(fā) let result = await superagent.post('https://b.test.com/api/card/home').set(browserMsg) // 獲取返回的set-cookie,并設(shè)置header let setCookie = result.headers['set-cookie'] if (setCookie) { ctx.response.header['set-cookie'] = setCookie } // 返回 ctx.response.body={ success: true, result: result.body } }) }
綜上nginx反向代理的本質(zhì)其實(shí)就是接口服務(wù)的轉(zhuǎn)發(fā)與header的處理,仔細(xì)想想也就容易理解了。
常見誤區(qū)
1、無用的ACA-Header ?
網(wǎng)上很多的nginx跨域設(shè)置里面都加了跨域header設(shè)置相關(guān)的內(nèi)容,比如
add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Credentials' "true"; add_header Access-Control-Allow-Headers X-Requested-With;
想想上面的原理,各位看官覺得這個(gè)還有用么?ACA(Access-Control-Allow-)系列的header本身是為了cors中做協(xié)商跨域而配置的,在這里配這個(gè)純屬脫褲子放屁多此一舉。
2、proxy_pass 域名帶不帶‘斜杠/' ?
同樣的,在網(wǎng)上看到了有的網(wǎng)友在配置proxy_pass的時(shí)候,會(huì)在后面加一個(gè)斜杠,如下,然后說報(bào)錯(cuò)啦,找不到接口啦~咋整啊~
... location /api { #proxy_pass https://b.test.com; proxy_pass https://b.test.com/; } ...
看到這個(gè)我們來想一想哈,proxy_pass的作用是抓發(fā),加了斜杠意味著所有的/api請(qǐng)求都會(huì)轉(zhuǎn)發(fā)到根目錄下,也就是說 /api 會(huì)被 / 替代,這個(gè)時(shí)候接口路徑就變了,少了一層/api。而不加斜杠的時(shí)候呢?這代表著轉(zhuǎn)發(fā)到b.test.com 的域名下,/api的路徑不會(huì)丟失。
針對(duì)這種情況,如果后端接口統(tǒng)一有了規(guī)定前綴,比如/api,那你這里就不要配置斜杠了。另一種情況,后端接口shit一樣,沒有統(tǒng)一前綴,這邊又要區(qū)分,那就在前端所有接口都加一個(gè)統(tǒng)一前綴,比如/api,然后通過加斜杠來替換掉好了~
以上就是本文的全部內(nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
相關(guān)文章
nginx:413 Request Entity Too Large的處理辦法--修改 PHP上傳文件大小
在用 phpMyAdmin 進(jìn)行 sql 數(shù)據(jù)庫導(dǎo)入的時(shí)候,經(jīng)常需要上傳比較大的 sql 數(shù)據(jù)文件,而這時(shí)會(huì)常碰見 nginx報(bào)錯(cuò):413 Request Entity Too Large。解決此問題,根據(jù)上傳數(shù)據(jù)文件的大小進(jìn)行修改處理2014-06-06Nginx 配置反向代理使用 Google fonts 字體并開啟 HTTP2/SSL 支持
nginx作為web服務(wù)器一個(gè)重要的功能就是反向代理。當(dāng)然你也可以使用nginx配置正向代理,本是介紹如何配置nginx的反向代理。nginx反向代理的指令不需要新增額外的模塊,默認(rèn)自帶proxy_pass指令,只需要修改配置文件就可以實(shí)現(xiàn)反向代理。2017-04-04nginx配置多個(gè)站點(diǎn)共用80端口的解決方法
這篇文章主要介紹了nginx配置多個(gè)站點(diǎn)共用80端口的解決方法,本文給大家介紹的非常詳細(xì),具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2018-06-06Nginx域名轉(zhuǎn)發(fā)使用場(chǎng)景代碼實(shí)例
這篇文章主要介紹了Nginx域名轉(zhuǎn)發(fā)使用場(chǎng)景代碼實(shí)例,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-09-09