基于Nginx反向代理解決公網上服務跨域問題的研究

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

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

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

中圖分類號：TP393? ? 文獻標識碼：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? 引? 言

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

1? 部署后端項目到服務器上

1.1? 部署后端項目

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

1.1.1? 第一種方式

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

1.1.2? 第二種方式

配置pom文件，讓其打包的時候就直接構建對應的鏡像。首先配置docker的服務地址和IP例如

http：//192.168.60.192：2375

這樣打包的時候才能找到對應的服務器上的docker，接下來就是配置打包時自動構建鏡像的命令：

build-image

package

build

最后配置如何根據相應的jar構建什么樣名稱，什么樣版本號的鏡像：

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

${docker.host}

java：8

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

/

${project.build.directory}

${project.build.finalName}.jar

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

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

1.1.3? 第三種方式

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

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

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

1.2? 測試后端項目正常運行

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

2? 部署前端項目

2.1? 上傳代碼到Linux服務器

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

2.2? 配置Nginx啟動前端項目

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

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

2.3? 配置Nginx連接后端項目

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

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

2.4? 配置nginx訪問內網服務器minio上的圖片

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

如果監聽到了這個端口號下的/pic路徑下的請求時，就進行轉發。轉發到圖片真正所在的服務器地址上。實現邏輯同上一個過程，這樣公網上就能訪問到內網的圖片了。具體實現有以下兩種方式。

2.4.1? 第一種方式

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

2.4.2? 第二種方式

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

3? 結? 論

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

參考文獻：

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

[2] 伍春生.Nginx負載均衡技術在高速公路視頻云聯網平臺中的應用 [J].上海船舶運輸科學研究所學報，2021，44（1）：60-64.

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

[4] 郝淑惠.基于Nginx的Web服務器負載均衡策略改進與實現 [J].電子技術與軟件工程，2019（2）：23.

[5] 黎宇.Nginx在不同網絡域名訪問中的應用 [J].通訊世界，2019，26（2）：88-89.

[6] 張文新.基于Linux的“數據保護+備份”架構——文件防篡改 [J].內蒙古科技與經濟，2021（20）：90-91+122.

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