摘要:背景早些時候我們做了一個項目,用的是前后端分離,前端后端提供功能接口,然后兩個部署在不同的域名下后端接口開放了跨域,方便前端本地開發調試。前端項目域名為后端的接口域名為,上線后也沒問題,一切都美滋滋的。
背景
早些時候我們做了一個項目,用的是前后端分離,前端vue,后端提供功能接口,然后兩個部署在不同的域名下,后端接口開放了跨域,方便前端本地開發調試。前端項目域名為www.a.com,后端的接口域名為 www.b.com,上線后也沒問題,一切都美滋滋的。直到有一天,用戶反饋過來有一個頁面一些數據出現的太慢了。。
然后我們各種優化,前端緩存、數據庫索引等等,快了那么一點,最后想能不能再快點,因為一開始用了開放跨域,且接口的請求方法為post,所以是復雜請求,會先發送一個options請求探探路,每個接口都會發這個,消耗的時間都有幾百毫秒,這樣時間就捉急了,那么如何解決這個問題呢~
為什么會跨域、復雜請求、nginx的使用不在本文范圍~
想到的解決方案 不跨域的方向方案1:放到同一個項目中,同一個域名(pass,(前后端各自管理,不好合并了,需要考慮接口地址已經使用,不能改了的情況)
方案2:nginx反響代理api接口,對于前端項目來說看起來不跨域(采用)
方案3:jsonp和其他(限制比較多)
options請求的速度更快點的方向方案:原來的跨域響應頭是應用中加的,能不能放在更前面一點的步驟,比如請求到nginx就返回(快了一丟丟。pass)
解決方案(方案2模擬) 場景前端項目域名為www.a.com,文件夾為html/a,
接口項目為www.b.com,文件夾為html/b
現在有一個接口,www.b.com/login.json,大意為登錄接口,現在用json數據進行模擬
www.a.com會發送一個登錄請求獲取數據
目錄結構圖如下
html ├── 50x.html ├── a │?? └── index.html ├── b │?? ├── apis │?? │?? └── login.json │?? └── login.json └── index.html
b/login.json的內容為`{
"location": "我是b站點/login"
}`
b/apis/login.json的內容為`{
"location":"我是b站點/apis/login"
}`
b/apis/login.json存在的意義是驗錯,沒有的的話訪問是404,但是需要知道訪問到哪啦
修改前端項目www.a.com中的請求接口為www.a.com/apis/login,真正的接口地址為www.b.com/login,如果請求www.a.com/apis/login能獲取json數據,則不會進行跨域(前端項目和接口在同一域名下),也不會發options請求
修改前端項目www.a.com的nginx配置所有/apis/打頭的接口,全部去請求www.b.com
nginx配置如下圖
server { listen 80; server_name www.a.com; access_log logs/test.access.log; # 匹配以/apis/開頭的請求 location ^~ /apis/ { proxy_pass http://www.b.com; } location / { root html/a; index index.html index.htm; } # error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }
proxy_pass 常用在反向代理,比如nginx代理node服務,java服務
重啟nginx 效果curl www.a.com/apis/login.json結果為
{ "location":"我是b站點/apis/login" }
結果是不對的(觀察下上文給出的文件夾下,還有個apis/login.json),心理的預期www.a.com/apis/login.json是要訪問到www.b.com/login.json,應該是b文件夾下的login.json,內容為
`{
"location": "我是b站點/login"
}`
修改a站點的nginx配置文件并重啟nginxserver { listen 80; server_name www.a.com; access_log logs/test.access.log; # 匹配以/apis/開頭的請求 location ^~ /apis/ { proxy_pass http://www.b.com/; #注意域名后有一個/ } location / { root html/a; index index.html index.htm; } # error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }
沒錯就是proxy_pass后面的地址加一個/
加/的情況,訪問www.a.com/apis/login.json會得到www.b.com/login.json(符合預期的),使用b文件夾作為/目錄來訪問
不加/的情況,訪問www.b.com/apis/login.json會得到www.b.com/apis/login.json(不符合預期),使用b文件下的apis作為根目錄進行訪問
最終的效果為
{ "location": "我是b站點/login" }參考資料
用nginx的反向代理機制解決前端跨域問題
Nginx反向代理解決跨域問題
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/39767.html
摘要:反向代理服務器對于客戶端而言它就像是原始服務器,并且客戶端不需要進行任何特別的設置。使用反向代理可能訪問網頁相對于之前響應會比較慢 標簽: Nginx,跨域 問題 在之前的分享的跨域資源共享的文章中,有提到要注意跨域時,如果要發送Cookie,Access-Control-Allow-Origin就不能設為*,必須指定明確的、與請求網頁一致的域名。在此次項目開發中與他人協作中就遇到...
摘要:反向代理服務器對于客戶端而言它就像是原始服務器,并且客戶端不需要進行任何特別的設置。使用反向代理可能訪問網頁相對于之前響應會比較慢 標簽: Nginx,跨域 問題 在之前的分享的跨域資源共享的文章中,有提到要注意跨域時,如果要發送Cookie,Access-Control-Allow-Origin就不能設為*,必須指定明確的、與請求網頁一致的域名。在此次項目開發中與他人協作中就遇到...
摘要:反向代理服務器對于客戶端而言它就像是原始服務器,并且客戶端不需要進行任何特別的設置。使用反向代理可能訪問網頁相對于之前響應會比較慢 問題 在之前的分享的跨域資源共享的文章中,有提到要注意跨域時,如果要發送Cookie,Access-Control-Allow-Origin就不能設為*,必須指定明確的、與請求網頁一致的域名。在此次項目開發中與他人協作中就遇到此類問題。 showImg(h...
摘要:三反向代理解決的原理將安裝在本地,然后將項目部署于下,這樣訪問本地項目時用本地項目即可訪問。這樣瀏覽器之間的請求完全滿足瀏覽器域名協議端口相同的同源策略,可在不改變后臺接口的情況下避免跨域問題。 一、問題背景說明: 編寫移動前端頁面時需要訪問后臺系統接口。前端項目在本地(個人辦公電腦)開發,后臺接口存放后生產的后臺服務器,本地的ajax請求無法直接訪問后臺接口,也就是遇到了跨域問題...
閱讀 1191·2021-11-23 10:10
閱讀 1523·2021-09-30 09:47
閱讀 907·2021-09-27 14:02
閱讀 2983·2019-08-30 15:45
閱讀 3028·2019-08-30 14:11
閱讀 3623·2019-08-29 14:05
閱讀 1829·2019-08-29 13:51
閱讀 2213·2019-08-29 11:33