正文

h5部署在Nginx（nginx部署h5項目）

發(fā)布時間：2023-03-19 07:15:31 稿源：創(chuàng)意嶺閱讀： 130 問大家

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于h5部署在Nginx的問題，以下是小編對此問題的歸納整理，讓我們一起來看看吧。

開始之前先推薦一個非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計劃、工作報告、論文、代碼、作文、做題和對話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準，寫出的就越詳細，有微信小程序端、在線網(wǎng)頁版、PC客戶端

官網(wǎng)：https://ai.de1919.com

本文目錄:

1、nodejs的轉(zhuǎn)發(fā)接口遇到的問題
2、uniapp h5打包后跨域問題
3、uniapp打包h5部署服務(wù)器，apache，uniapp配置history模式
4、Nginx配置文件詳解

h5部署在Nginx（nginx部署h5項目）

一、nodejs的轉(zhuǎn)發(fā)接口遇到的問題

之前在預(yù)生產(chǎn)環(huán)境遇到過這個問題，h5頁面和API部署在不同域名下，訪問接口返回值為亂碼。

當時的解決辦法為放在同一域名下，但是并沒有解決根本問題。

現(xiàn)在生產(chǎn)環(huán)境公司要求絕對不能放在同一域名下，（一個小伙伴給的解釋是搶占資源，我覺得合理）

所以當下問題就來了，搞了兩天才弄明白真正原因。

第一，亂碼問題

是因為nginx為了節(jié)省資源在返回html的時候會自動壓縮（不知道記得對不對）

在請求的時候加上 gzip：true 即可。

第二，nginx返回404問題

亂碼問題解決了以后，發(fā)現(xiàn)nginx返回的結(jié)果為404。

原因是headers

是因為此處傳給API的headers直接復(fù)用了頁面給nodejs的headers（req.headers為頁面給nodejs的headers）req.headers有個參數(shù)為host指向的是h5頁面的地址而不是API的地址

（猜測，加上host后nginx會根據(jù)host來找調(diào)用的API地址，因為不在同一域名下，此時host指向的是頁面部署的域名而不是API部署的域名，自然找不到，這也就解釋了為什么部署在同一域名時不會出現(xiàn)問題。

本地運行的時候，訪問IP地址可以正常返回結(jié)果，訪問IP對應(yīng)的域名時404，是因為訪問IP時不會通過nginx，所以也不會有問題）

二、uniapp h5打包后跨域問題

開發(fā)環(huán)境中設(shè)置瀏覽器跨域只要設(shè)置 vue.config.js 的devServer的proxy代理即可；

此時就要配置服務(wù)器（這邊用的nginx代理服務(wù)器）的代理配置；

proxy_pass的匹配規(guī)則如下：

三、uniapp打包h5部署服務(wù)器，apache，uniapp配置history模式

文件內(nèi)容如下：

-是的，你沒有看錯，就這么簡單的四行

我們的項目大多會部署在二級目錄下，而不是根目錄下

網(wǎng)上大多教程讓人不明覺厲

四、Nginx配置文件詳解

說到該指令，首先得闡述一下什么是所謂的 “驚群問題”，可以參考 WIKI百科的解釋。就Nginx的場景來解釋的話大致的意思就是：當一個新網(wǎng)絡(luò)連接來到時，多個worker進程會被同時喚醒，但僅僅只有一個進程可以真正獲得連接并處理之。如果每次喚醒的進程數(shù)目過多的話，其實是會影響一部分性能的。

所以在這里，如果accept_mutex on，那么多個worker將是以串行方式來處理，其中有一個worker會被喚醒；反之若accept_mutex off，那么所有的worker都會被喚醒，不過只有一個worker能獲取新連接，其它的worker會重新進入休眠狀態(tài)。

用rewrite轉(zhuǎn)發(fā)的話，url會發(fā)生變化的，那就用proxy_pass吧，于是添加了如下的配置：

在現(xiàn)有環(huán)境的nginx里添加這段配置之后，訪問卻始終轉(zhuǎn)不過去，查看nginx日志也只能看到是404信息，并沒有更多定位問題的信息。檢查了許久也沒找到原因，于是重新裝了一臺新nginx，里面只加上面這段配置，結(jié)果nginx是能夠轉(zhuǎn)發(fā)成功的，這說明單獨來看這條location的配置是沒有問題的，很有可能是現(xiàn)有環(huán)境nginx里的某些配置影響到了這個轉(zhuǎn)發(fā)。

為了定位問題原因，我將aaa.example.com虛擬主機下的其他配置注意注釋掉來調(diào)試，最后發(fā)現(xiàn)當注釋掉proxy_set_header Host $http_host ;這條配置之后，就能成功轉(zhuǎn)發(fā)了。這才注意到是反向代理配置的問題?，F(xiàn)有環(huán)境中原有的配置也不能隨便刪掉，上網(wǎng)查了下原因，找到下面這種解決方案：

即，在location里面添加一條proxy_set_header Host http_host時，則不改變請求頭的值，所以當要轉(zhuǎn)發(fā)到bbb.example.com的時候，請求頭還是aaa.example.com的Host信息，就會有問題；當Host設(shè)置為$proxy_host時，則會重新設(shè)置請求頭為bbb.example.com的Host信息。

另外，關(guān)于proxy_pass轉(zhuǎn)發(fā)url的參數(shù)，可以通過在location中用rewrite來做，所以完善后的配置如下：

在location用rewrite改變了URI之后，proxy_pass將使用改變后的URI。上面例子(.*)是將所有參數(shù)傳給 1會拼接在 http://bbb.example.com 后面。

先來看下proxy_set_header的語法

允許重新定義或者添加發(fā)往后端服務(wù)器的請求頭。value可以包含文本、變量或者它們的組合。當且僅當當前配置級別中沒有定義proxy_set_header指令時，會從上面的級別繼承配置。默認情況下，只有兩個請求頭會被重新定義：

當匹配到/customer/straightcustomer/download時，使用crmtest處理，到upstream就匹配到crmtest.aty.sohuno.com，這里直接轉(zhuǎn)換成IP進行轉(zhuǎn)發(fā)了。假如crmtest.aty.sohuno.com是在另一臺nginx下配置的，ip為10.22.10.116，則$proxy_host則對應(yīng)為10.22.10.116。此時相當于設(shè)置了Host為10.22.10.116。如果想讓Host是crmtest.aty.sohuno.com，則進行如下設(shè)置：

如果不想改變請求頭“Host”的值，可以這樣來設(shè)置：

但是，如果客戶端請求頭中沒有攜帶這個頭部，那么傳遞到后端服務(wù)器的請求也不含這個頭部。這種情況下，更好的方式是使用$host變量——它的值在請求包含“Host”請求頭時為“Host”字段的值，在請求未攜帶“Host”請求頭時為虛擬主機的主域名：

此外，服務(wù)器名可以和后端服務(wù)器的端口一起傳送：

如果某個請求頭的值為空，那么這個請求頭將不會傳送給后端服務(wù)器：

nginx配置項，里面的配置項有代理https，http，代理靜態(tài)文件，H5分發(fā)，代理TCP連接，能滿足大多數(shù)搭建測試環(huán)境所要用的nginx的情況，大家碰到要使用nginx的時候可以參考下

以上就是關(guān)于h5部署在Nginx相關(guān)問題的回答。希望能幫到你，如有更多相關(guān)問題，您也可以聯(lián)系我們的客服進行咨詢，客服也會為您講解更多精彩的知識和內(nèi)容。