基于Nginx反向代理解決公網(wǎng)上服務(wù)跨域問題的研究

崔娟 王偉民 馮繼虎 李懷堂 王林柱

摘? 要：對軟件開發(fā)人員來說，除了日常在本地的開發(fā)工作之外，最終的目的是要將項目部署到公網(wǎng)上，供用戶使用。但是基于系統(tǒng)安全的考慮，一般不能將內(nèi)網(wǎng)服務(wù)器上所有服務(wù)全部暴露在外網(wǎng)上，這個時候選擇通過Nginx的反向代理來解決這個問題。通過實現(xiàn)前端后分離部署，修改Nginx配置文件，解決了公網(wǎng)上瀏覽、下載內(nèi)網(wǎng)服務(wù)器上圖片等問題。

關(guān)鍵詞：安全；Nginx；docker容器化部署；反向代理；跨域

中圖分類號：TP393? ? 文獻(xiàn)標(biāo)識碼：A? 文章編號：2096-4706（2023）08-0079-05

Abstract： For software developers， in addition to daily local development work， the ultimate goal is to deploy the project to the public network for users to use. However， based on the consideration of system security， it is generally not possible to expose all services on the intranet server to the outer internet. At this time， this paper chooses the nginx reverse proxy to solve this problem. By implementing front end separate deployment and modifying nginx configuration files， the problems of browsing and downloading pictures on the intranet server by public network are solved.

Keywords： security; Nginx; docker container deployment; reverse proxy; cross domain

0? 引? 言

軟件開發(fā)采用前后端分離的模式開發(fā)，前端使用vue框架。根據(jù)業(yè)務(wù)需要，項目中需要有上傳圖片，顯示圖片的功能。我們選擇將圖片上傳到對象存儲服務(wù)minio上，而minio通過docker安裝在內(nèi)網(wǎng)服務(wù)器上。上傳后的圖片我們通過后臺接口返回的圖片URL來訪問。而這個圖片的地址是攜帶了內(nèi)網(wǎng)IP和端口號的地址，同時我們也是存儲到數(shù)據(jù)庫中，這樣下次顯示圖片的時候就直接讀取圖片字段的URL。問題是圖片的URL由內(nèi)網(wǎng)IP+端口號+其他路徑+圖片名稱組成，那么在公網(wǎng)上是直接訪問不到這個內(nèi)網(wǎng)的IP或者這個端口號的地址的，這個時候就會出現(xiàn)圖片打不開的問題。所以我們的解決思路是：外網(wǎng)要能訪問服務(wù)器上的前端項目，我們必須要將一個IP地址+端口號映射在公網(wǎng)上，那么我們可以選擇將前端項目放在一個服務(wù)器上，后端項目放在另一臺服務(wù)器上，映射前端服務(wù)器上的IP到公網(wǎng)上，通過配置Nginx訪問后端內(nèi)網(wǎng)服務(wù)器?；蛘呶覀儗⑶岸隧椖亢秃蠖隧椖坎渴鹪谕粋€臺服務(wù)器的不同端口下。本文按照第二種方式部署，部署到同一臺服務(wù)器上的不同端口下。

1? 部署后端項目到服務(wù)器上

1.1? 部署后端項目

將后端項目部署到linux服務(wù)器上，我們可以選擇傳統(tǒng)的部署方式：上傳jar包到服務(wù)器上，運(yùn)行命令“nohup? Java? -jar? xxx.jar --server.port=8011 ”。這種部署方式的弊端是只要我們代碼有修改，就必須重新打包，然后再上傳jar包到服務(wù)器上，重新運(yùn)行命令，效率低下。所以我們也可以采用docker容器的部署方式。

1.1.1? 第一種方式

采用dockerFile文件+jar包的方式部署，根據(jù)自己的項目編寫對應(yīng)的dockerFile文件，同時上傳dockerFile文件和jar包在同一個父目錄下。通過運(yùn)行命令“docker build -t? imageName? ?.”構(gòu)建我們的項目鏡像。然后我們就可以通過命令“docker run -d? -P? --name 容器名稱 鏡像名稱 ”運(yùn)行基于這個鏡像的容器，如圖3所示，這樣我們的后端服務(wù)就可以正常啟動了。當(dāng)然這種方式和傳統(tǒng)的部署方式本質(zhì)上并沒有幫我們開發(fā)人員解決運(yùn)維時間，只是使用了當(dāng)下流行的docker容器而已。

1.1.2? 第二種方式

配置pom文件，讓其打包的時候就直接構(gòu)建對應(yīng)的鏡像。首先配置docker的服務(wù)地址和IP例如

http：//192.168.60.192：2375

這樣打包的時候才能找到對應(yīng)的服務(wù)器上的docker，接下來就是配置打包時自動構(gòu)建鏡像的命令：

build-image

package

build

最后配置如何根據(jù)相應(yīng)的jar構(gòu)建什么樣名稱，什么樣版本號的鏡像：

repository/${project.artifactId}：${project.version}

${docker.host}

java：8

["java"， "-jar"，"/${project.build.finalName}.jar"]

/

${project.build.directory}

${project.build.finalName}.jar

打包成功之后我們就可以在Linux服務(wù)器上能看到對應(yīng)的鏡像，如圖1所示。

最后就是通過docker run的命令啟動容器，我們的服務(wù)也就起來了。相對于第一種方式我們少了自己打包jar，然后又上傳到服務(wù)器上的過程，更加節(jié)約時間。但是有一個缺點是我們重新打包，構(gòu)建鏡像的時候要手動刪除原先的容器和鏡像，不然會因為鏡像名沖突的問題而構(gòu)建不知名的鏡像none，如圖2所示。

1.1.3? 第三種方式

基于Jenkins+shell腳本的部署方式，這是一種半自動化的部署，只需要上傳shell腳本到服務(wù)器上，結(jié)合我們的gitee或者其他的版本控制工具，將項目上傳到對應(yīng)的版本控制工具上，再配置我們的Jenkins，就可以完成鏡像、容器一起的構(gòu)建。不需要再手動輸入docker run的命令，當(dāng)然這一步是因為我們在shell腳本提前寫入了運(yùn)行容器的命令。在shell腳本中如果我們寫了構(gòu)建鏡像的命令

“docker build -t ${group_name}/${app_name}：${app_version}? .”我們就可以在配置文件pom文件中不寫自動構(gòu)建鏡像的配置。這種方式我們每次只需要上傳我們修改的代碼到版本控制工具中，然后在Jenkins中點擊構(gòu)建對應(yīng)的項目，我們的后端項目就可以啟動起來了。不需要再手動上傳文件到Linux服務(wù)上。根據(jù)shell腳本，每次構(gòu)建的時候都會刪除原先的容器和鏡像，所以也不會出現(xiàn)第二種方式的問題了。

上述的幾種方式實現(xiàn)原理都是通過構(gòu)建鏡像和運(yùn)行容器的方式來部署項目，部署過程不重要，最終目的是將后端項目部署到內(nèi)網(wǎng)服務(wù)器上，最后的容器運(yùn)行截圖如圖3所示，表示后端項目正式運(yùn)行起來了。部署后的后端訪問地址比如說是：192.168.60.192：8011。（這個地址在Nginx配置反向代理的時候用）

1.2? 測試后端項目正常運(yùn)行

確保通過postman或其他工具測試接口上傳圖片到minio是成功的，如圖4所示。url中的“http：192.168.60.192：9090/”就是minio內(nèi)網(wǎng)ip+端口號，這個地址就是我們返回給前端，前端用來展示圖片的地址，當(dāng)我們在內(nèi)網(wǎng)的瀏覽器上輸入這個url就會顯示圖片了，但是我們外網(wǎng)訪問的時候就打不開這個圖片。

2? 部署前端項目

2.1? 上傳代碼到Linux服務(wù)器

將我們的前端項目通過命令npm? build打包到dist目錄下，上傳dist文件夾到linux服務(wù)器上，如圖5所示，dist文件夾所在的目錄是“/usr/local/sti/minjian”如果我們的前端代碼在本地啟動的時候加上了前綴/admin，例如：http：//localhost：8022/admin/，如圖6所示，那么我們配置Nginx的時候記得也是要多寫這個/admin。

2.2? 配置Nginx啟動前端項目

Nginx代理監(jiān)聽的時候是根據(jù)配置文件中Nginx所在服務(wù)器的IP地址和端口號來的，當(dāng)它監(jiān)聽到這個端口號之后，依據(jù)請求的路徑，根據(jù)配置文件轉(zhuǎn)發(fā)不同的代理。在服務(wù)器上啟動的項目的端口號和前端代碼啟動時本地寫的端口號沒有關(guān)系，比如2.1中本地項目前端地址的端口號是8022，但是我們Nginx中配置的可以是其他端口號如8024。這兒修改Nginx的配置文件如圖7所示，代表我們的前端項目在公網(wǎng)上就會是8024的端口號。

因為本地前端項目的啟動地址里端口號后面加入了/admin，如圖6所示。所以我們在這兒配置location的時候需要加上/admin，server_name可以寫成localhost或者這臺服務(wù)器的IP地址，當(dāng)然后續(xù)我們的IP地址有相應(yīng)的域名，就可以寫成域名了，如baidu.com。此時我們訪問http：//192.168.60.192：8024/admin/，就可以正常啟動我們的前端項目，如圖8所示。如果我們訪問的路徑是“http：//192.168.60.192：8024”，那么在這個端口下就匹配不到轉(zhuǎn)發(fā)規(guī)則，就默認(rèn)走Nginx的默認(rèn)80端口的路徑，如圖9所示。

2.3? 配置Nginx連接后端項目

基于前面的步驟，我們只是將前端項目和后端項目分別部署到了服務(wù)器上，各自都能啟動起來，但是前端項目訪問不到后端的接口。獲取驗證碼的時候，提示系統(tǒng)接口異常404，如圖8所示。原因是我們本地項目本來就是前后端分離的，跨越進(jìn)行訪問的。所以本地訪問后端接口的時候需要進(jìn)行代理，我們在前端中配置的請求的地址如圖10所示。加上路徑/dev-api就說明要去請求后端接口了。

所以Nginx還需要再配置個location，當(dāng)在服務(wù)器上訪問到路徑/prod-api時就去轉(zhuǎn)發(fā)，去訪問后端8011端口上的請求，配置文件如圖11所示，這樣前端就能正常訪問到后端的接口了，如圖12所示，就不會報跟圖8一樣的錯誤。同時后端的IP和端口也沒有暴露在外網(wǎng)上，增加被攻擊的危險性。

2.4? 配置nginx訪問內(nèi)網(wǎng)服務(wù)器minio上的圖片

圖片上傳到內(nèi)網(wǎng)服務(wù)器上的minio中，接口返回給前端的是一個內(nèi)網(wǎng)圖片地址例如“http：//192.168.60.192：9090/minjian/20200405/re34.png”，外網(wǎng)訪問不到，此時我們需要將前端拿到的圖片地址進(jìn)行轉(zhuǎn)化，將內(nèi)網(wǎng)的IP和端口號修改為nginx所在服務(wù)器的IP和端口號，再根據(jù)業(yè)務(wù)需求加上一個前綴。比如/pic，再加圖片本來的地址。轉(zhuǎn)化后的地址是：http：//ngnix服務(wù)器的IP：端口號/pic/minjian/20200405/re34.png，然后配置nginx中的localtion，如圖13所示。

如果監(jiān)聽到了這個端口號下的/pic路徑下的請求時，就進(jìn)行轉(zhuǎn)發(fā)。轉(zhuǎn)發(fā)到圖片真正所在的服務(wù)器地址上。實現(xiàn)邏輯同上一個過程，這樣公網(wǎng)上就能訪問到內(nèi)網(wǎng)的圖片了。具體實現(xiàn)有以下兩種方式。

2.4.1? 第一種方式

前端拿到后端返回的圖片地址時，需要給圖片屬性src賦值，可以不寫IP和端口號，直接加前綴/pic，src的屬性值就是“/pic/minjian/20200405/re34.png“，如圖14所示，因為沒有對應(yīng)的IP和端口號，所以一般情況下Nginx時間聽不到的，這里可以正常訪問的，原因是image標(biāo)簽的src屬性問題，本地代碼里面寫的是相對路徑，實際點擊訪問的時候會自動補(bǔ)充當(dāng)前服務(wù)器的IP和端口號，如圖15所示，這樣nginx代理服務(wù)器才能監(jiān)聽到請求了該端口下的/pic路徑，然后根據(jù)轉(zhuǎn)發(fā)邏輯請求真正的圖片所在的地址。

2.4.2? 第二種方式

第二種方式就是將圖片地址中的IP和端口號改為nginx所在的服務(wù)器的端口號，然后再加入請求路徑/pic，賦值給image標(biāo)簽的src 屬性，如src屬性值等于“http：//192.168.60.192：8024/pic/minjian/20200405/re34.png ”。但是這種方式的壞處是寫死了IP和端口號，將來若是將前端項目部署在其他服務(wù)器上，需要重新修改前端代碼。而第一種方式就不會出現(xiàn)這種問題。

3? 結(jié)? 論

至此，我們的系統(tǒng)就能正式運(yùn)行。我們選擇將前后端分離開發(fā)的項目分別部署到Linux服務(wù)器上，相對window系統(tǒng)而言，具有穩(wěn)定性好，不易受到攻擊，硬件維護(hù)成本低的特點。同時使用nginx的反向代理，我們很好的保護(hù)了我們內(nèi)網(wǎng)服務(wù)器的安全性，暴露在公網(wǎng)上的IP和端口越少，我們的系統(tǒng)更加的安全，更好的解決了公網(wǎng)IP或者端口號如何跨域訪問我們的內(nèi)網(wǎng)服務(wù)器上的服務(wù)，同時使用docker容器化的部署，也大大提升了部署的效率。

參考文獻(xiàn)：

[1] 李彬，朱亞興.Nginx在實現(xiàn)網(wǎng)站負(fù)載均衡方面的研究 [J].信息與電腦：理論版，2013（22）：49-50.

[2] 伍春生.Nginx負(fù)載均衡技術(shù)在高速公路視頻云聯(lián)網(wǎng)平臺中的應(yīng)用 [J].上海船舶運(yùn)輸科學(xué)研究所學(xué)報，2021，44（1）：60-64.

[3] 譚暢，譚歆，胡磊，等.云中心基于Nginx的動態(tài)權(quán)重負(fù)載均衡算法 [J].重慶郵電大學(xué)學(xué)報：自然科學(xué)版，2021，33（6）：991-998.

[4] 郝淑惠.基于Nginx的Web服務(wù)器負(fù)載均衡策略改進(jìn)與實現(xiàn) [J].電子技術(shù)與軟件工程，2019（2）：23.

[5] 黎宇.Nginx在不同網(wǎng)絡(luò)域名訪問中的應(yīng)用 [J].通訊世界，2019，26（2）：88-89.

[6] 張文新.基于Linux的“數(shù)據(jù)保護(hù)+備份”架構(gòu)——文件防篡改 [J].內(nèi)蒙古科技與經(jīng)濟(jì)，2021（20）：90-91+122.

作者簡介：崔娟（1995—），女，漢族，甘肅白銀人，研究實習(xí)員，本科，研究方向：大數(shù)據(jù)、軟件工程；王偉民（1970—），男，漢族，甘肅蘭州人，高級工程師，本科，研究方向：信息化、農(nóng)業(yè)工程；馮繼虎（1982—），男，漢族，甘肅隴南人，工程師，本科，研究方向：科技管理與服務(wù)；李懷堂（2000—），男，漢族，甘肅民勤人，本科，研究實習(xí)員，研究方向：數(shù)據(jù)庫加密；王林柱（1997—），男，漢族，甘肅靜寧人，研究實習(xí)員，本科，研究方向：高性能計算。