正文

h5部署在Nginx（nginx部署h5項(xiàng)目）

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

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

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

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫出的就越詳細(xì)，有微信小程序端、在線網(wǎng)頁(yè)版、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項(xiàng)目）

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

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

當(dāng)時(shí)的解決辦法為放在同一域名下，但是并沒有解決根本問題。

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

所以當(dāng)下問題就來(lái)了，搞了兩天才弄明白真正原因。

第一，亂碼問題

是因?yàn)閚ginx為了節(jié)省資源在返回html的時(shí)候會(huì)自動(dòng)壓縮（不知道記得對(duì)不對(duì)）

在請(qǐng)求的時(shí)候加上 gzip：true 即可。

第二，nginx返回404問題

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

原因是headers

是因?yàn)榇颂巶鹘oAPI的headers直接復(fù)用了頁(yè)面給nodejs的headers（req.headers為頁(yè)面給nodejs的headers）req.headers有個(gè)參數(shù)為host指向的是h5頁(yè)面的地址而不是API的地址

（猜測(cè)，加上host后nginx會(huì)根據(jù)host來(lái)找調(diào)用的API地址，因?yàn)椴辉谕挥蛎拢藭r(shí)host指向的是頁(yè)面部署的域名而不是API部署的域名，自然找不到，這也就解釋了為什么部署在同一域名時(shí)不會(huì)出現(xiàn)問題。

本地運(yùn)行的時(shí)候，訪問IP地址可以正常返回結(jié)果，訪問IP對(duì)應(yīng)的域名時(shí)404，是因?yàn)樵L問IP時(shí)不會(huì)通過nginx，所以也不會(huì)有問題）

二、uniapp h5打包后跨域問題

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

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

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

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

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

-是的，你沒有看錯(cuò)，就這么簡(jiǎn)單的四行

我們的項(xiàng)目大多會(huì)部署在二級(jí)目錄下，而不是根目錄下

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

四、Nginx配置文件詳解

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

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

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

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

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

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

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

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

先來(lái)看下proxy_set_header的語(yǔ)法

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

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

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

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

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

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

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

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