當前位置:首頁 » 網頁前端 » nginx映射前端加項目名
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

nginx映射前端加項目名

發布時間: 2023-07-14 21:33:14

❶ Docker 入門 (07) 部署nginx 並且映射本地配置文件

目標:

1. 利用docker部署一個nginx容器

2.為nginx 容器設置配置文件 , 並且映射到宿主機(本機)

操作步驟:

1.拉取nginx鏡像,並嘗試簡單運行(忘記怎麼操作請參考第五節)

2.在本地新增配置文件 , 為了後面映射容器使用 ,我習慣是放到 /etc/docker/nginx-config , 按你個人習慣新增

3.進入config ,我們需要創建一個簡單配置文件 , 這里就來個簡單的吧

4.因為我稍後需要佔用的是8080埠 , 請確認雲伺服器端是否開放

5. 萬事俱備 , 嘗試啟動吧

6. 使用你的 伺服器ip+8080埠訪問測試 , 看到您的寫的 index,html 內容, 代表啟動成功!

7.具體映射位置 可以 使用 docker exec -it [容器ID] /bin/bash 命令去參考對應映射文件 ,原理就應該明白了

結語:

通過本節的 nginx 映射本地配置文件 , 應該掌握對docker映射文件的基本使用了 , 希望大家都把自己的nginx跑起來吧

❷ linux下安裝nginx部署多個前端項目

1.先安裝nginx所需要的環境

yum install gcc-c++

yum install -y pcre pcre-devel

yum install -y zlib zlib-devel

yum install -y openssl openssl-devel

也可按照如下命令一鍵安裝

yum -y install gcc zlib zlib-devel pcre-devel openssl openssl-devel

2.安裝nginx,安裝在/usr/local下

wget -c https://nginx.org/download/nginx-1.10.1.tar.gz

# 解壓縮

tar -zxvf linux-nginx-1.12.2.tar.gz

cd nginx-1.12.2/

# 執行配置

./configure

# 編譯安裝(默認安裝在/usr/local/nginx)

make

make install

安裝完直接訪問 http://121.36.107.248/     默認埠是80

Nginx常用命令

測試配置文件:${Nginx}/sbin/nginx -t

啟動命令:${Nginx}/sbin/nginx

停止命令:${Nginx}/sbin/nginx -s stop/quit

重啟命令:${Nginx}/sbin/nginx -s reload

查看進程命令:ps -ef | grep nginx

平滑重啟:kill -HUP [Nginx主進程號(即ps命令查到的PID)]

喜歡請關注 「蛋皮皮」 微信公眾號!更多干貨等你來學習哦。

❸ nginx前端常用配置

nginx現在幾乎是眾多大型網站的必用技術,大多數情況下,我們不需要親自去配置它,但是了解它在應用程序中所擔任的角色,以及如何解決這些問題是非常必要的。

下面我將從nginx在企業中的真實應用來解釋nginx在應用程序中起到的作用。

為了便於理解,首先先來了解一下一些基礎知識, nginx是一個高性能的反向代理伺服器 那麼什麼是反向代理呢?

代理 是在伺服器和客戶端之間假設的一層伺服器, 代理 將接收客戶端的請求並將它轉發給伺服器,然後將服務端的響應轉發給客戶端。

不管是正向代理還是反向代理,實現的都是上面的功能。

正向代理 是為我們服務的,即為客戶端服務的,客戶端可以根據正向代理訪問到它本身無法訪問到的伺服器資源。

正向代理 對我們是透明的,對服務端是非透明的,即服務端並不知道自己收到的是來自代理的訪問還是來自真實客戶端的訪問。

反向代理 是為服務端服務的,反向代理可以幫助伺服器接收來自客戶端的請求,幫助伺服器做請求轉發,負載均衡等。

反向代理 對服務端是透明的,對我們是非透明的,即我們並不知道自己訪問的是代理伺服器,而伺服器知道反向代理在為他服務。

下面是一個nginx配置文件的基本結構:

下面是 nginx 一些配置中常用的內置全局變數,你可以在配置的任何位置使用它們。

| 變數名 | 功能 | | ------ | ------ | | $host | 請求信息中的 Host ,如果請求中沒有 Host 行,則等於設置的伺服器名 | | $request_method | 客戶端請求類型,如 GET 、 POST | $remote_addr | 客戶端的 IP 地址 | | $args | 請求中的參數 | | $content_length | 請求頭中的 Content-length 欄位 | | $http_user_agent | 客戶端agent信息 | | $http_cookie | 客戶端cookie信息 | | $remote_addr | 客戶端的IP地址 | | $remote_port | 客戶端的埠 | | $server_protocol | 請求使用的協議,如 HTTP/1.0 、·HTTP/1.1 | | server_name | 伺服器名稱| | $server_port`|伺服器的埠號|

先追本溯源以下,跨域究竟是怎麼回事。

同源策略限制了從同一個源載入的文檔或腳本如何與來自另一個源的資源進行交互。這是一個用於隔離潛在惡意文件的重要安全機制。通常不允許不同源間的讀操作。

如果兩個頁面的協議,埠(如果有指定)和域名都相同,則兩個頁面具有相同的源。

例如:

現在我在 fe.server.com 對 dev.server.com 發起請求一定會出現跨域。

現在我們只需要啟動一個nginx伺服器,將 server_name 設置為 fe.server.com ,然後設置相應的location以攔截前端需要跨域的請求,最後將請求代理回 dev.server.com 。如下面的配置:

這樣可以完美繞過瀏覽器的同源策略: fe.server.com 訪問 nginx 的 fe.server.com 屬於同源訪問,而 nginx 對服務端轉發的請求不會觸發瀏覽器的同源策略。

根據狀態碼過濾

根據URL名稱過濾,精準匹配URL,不匹配的URL全部重定向到主頁。

根據請求類型過濾。

GZIP 是規定的三種標准HTTP壓縮格式之一。目前絕大多數的網站都在使用 GZIP 傳輸 HTML 、 CSS 、 JavaScript 等資源文件。

對於文本文件, GZip 的效果非常明顯,開啟後傳輸所需流量大約會降至 1/4 ~ 1/3 。

並不是每個瀏覽器都支持 gzip 的,如何知道客戶端是否支持 gzip 呢,請求頭中的 Accept-Encoding 來標識對壓縮的支持。

啟用 gzip 同時需要客戶端和服務端的支持,如果客戶端支持 gzip 的解析,那麼只要服務端能夠返回 gzip 的文件就可以啟用 gzip 了,我們可以通過 nginx 的配置來讓服務端支持 gzip 。下面的 respone 中 content-encoding:gzip ,指服務端開啟了 gzip 的壓縮方式。

這里為什麼默認版本不是 1.0 呢?

HTTP 運行在 TCP 連接之上,自然也有著跟 TCP 一樣的三次握手、慢啟動等特性。

啟用持久連接情況下,伺服器發出響應後讓 TCP 連接繼續打開著。同一對客戶/伺服器之間的後續請求和響應可以通過這個連接發送。

為了盡可能的提高 HTTP 性能,使用持久連接就顯得尤為重要了。

HTTP/1.1 默認支持 TCP 持久連接, HTTP/1.0 也可以通過顯式指定 Connection: keep-alive 來啟用持久連接。對於 TCP 持久連接上的 HTTP 報文,客戶端需要一種機制來准確判斷結束位置,而在 HTTP/1.0 中,這種機制只有 Content-Length 。而在 HTTP/1.1 中新增的 Transfer-Encoding: chunked 所對應的分塊傳輸機制可以完美解決這類問題。

nginx 同樣有著配置 chunked的 屬性 chunked_transfer_encoding ,這個屬性是默認開啟的。

Nginx 在啟用了 GZip 的情況下,不會等文件 GZip 完成再返回響應,而是邊壓縮邊響應,這樣可以顯著提高 TTFB ( Time To First Byte ,首位元組時間,WEB 性能優化重要指標)。這樣唯一的問題是, Nginx 開始返回響應時,它無法知道將要傳輸的文件最終有多大,也就是無法給出 Content-Length 這個響應頭部。

所以,在 HTTP1.0 中如果利用 Nginx 啟用了 GZip ,是無法獲得 Content-Length 的,這導致HTTP1.0中開啟持久鏈接和使用 GZip 只能二選一,所以在這里 gzip_http_version 默認設置為 1.1 。

如上面的圖,前面是眾多的服務窗口,下面有很多用戶需要服務,我們需要一個工具或策略來幫助我們將如此多的用戶分配到每個窗口,來達到資源的充分利用以及更少的排隊時間。

把前面的服務窗口想像成我們的後端伺服器,而後面終端的人則是無數個客戶端正在發起請求。負載均衡就是用來幫助我們將眾多的客戶端請求合理的分配到各個伺服器,以達到服務端資源的充分利用和更少的請求時間。

Upstream指定後端伺服器地址列表

在server中攔截響應請求,並將請求轉發到Upstream中配置的伺服器列表。

上面的配置只是指定了nginx需要轉發的服務端列表,並沒有指定分配策略。

輪詢策略

默認情況下採用的策略,將所有客戶端請求輪詢分配給服務端。這種策略是可以正常工作的,但是如果其中某一台伺服器壓力太大,出現延遲,會影響所有分配在這台伺服器下的用戶。

最小連接數策略

將請求優先分配給壓力較小的伺服器,它可以平衡每個隊列的長度,並避免向壓力大的伺服器添加更多的請求。

最快響應時間策略

依賴於NGINX Plus,優先分配給響應時間最短的伺服器。

客戶端ip綁定

來自同一個ip的請求永遠只分配一台伺服器,有效解決了動態網頁存在的session共享問題。

匹配以 png|gif|jpg|jpeg 為結尾的請求,並將請求轉發到本地路徑, root 中指定的路徑即nginx本地路徑。同時也可以進行一些緩存的設置。

nginx的功能非常強大,還有很多需要探索,上面的一些配置都是公司配置的真實應用(精簡過了),如果您有什麼意見或者建議,歡迎在下方留言...

❹ 利用nginx部署站點,前端資源默認放在

部署springboot+vue項目的時候,我們一般是將打包好的前端項目放在我們後端的resources目錄下,然後前後端一起打包成jar包或者war包部署上伺服器的。也就是說,如果前端項目發生修改的話,那麼即使後端不用修改,前後端項目也要重新放在一起重新打包、重新部署。但是,前端項目打包往往是幾mb大小,而後端項目打包卻要幾十mb。因此,為了方便,我們可以使用Nginx獨立部署前端項目。

一、 Nginx安裝步驟

1、安裝GCC、automake、pcre、zlib和openssl

用rpm -qa 命令查看是否安裝

如果沒有安裝,執行以下命令

yum -y install gcc gcc-c++ automake pcre pcre-devel zlib zlib-devel openssl openssl-devel
1
2、下載Nginx

我是安裝在 /www/server目錄的

cd /www/server
1
weget命令下載

wget http://nginx.org/download/nginx-1.16.1.tar.gz
1
tar zxvf 解壓

tar zxvf nginx-1.16.1.tar.gz
1
重命名 nginx-1.16.1文件夾

mv nginx-1.16.1 nginx
1

3、安裝Nginx,默認安裝目錄:/usr/local/nginx

進入nginx文件夾,運行configure腳本

cd nginx
./configure
1
2
編譯、安裝

make
make install
1
2
切換到安裝目錄

cd /usr/local/nginx
1

注意:html:存放了兩個後綴名為.html的靜態文件,前端項目打包後的文件放在此處,編輯好配置文件,啟動Nginx伺服器即可成功部署前端項目。

4、修改配置文件、開放埠

vim /usr/local/nginx/conf/nginx.conf
1
埠改為 8051

5、啟動Nginx

cd /usr/local/nginx
./sbin/nginx
1
2
6、其他命令

查看進程

ps -ef|grep nginx
1
重啟Nginx

/usr/local/nginx/sbin/nginx -s reopen
1
停止Nginx

/usr/local/nginx/sbin/nginx -s stop
1
重載Nginx配置文件

/usr/local/nginx/sbin/nginx -s reload
1
7、訪問

curl 127.0.0.1:8051
1

如果訪問不了,伺服器安全組開放埠以及防火牆放行埠

firewall-cmd --zone=public --add-port=8051/tcp --permanent
1
firewall-cmd --reload
1
二、前端項目獨立部署

1、將打包的前端項目上傳到/usr/local/nginx/html目錄

2、 重新啟動即可成功訪問到前端項目

/usr/local/nginx/sbin/nginx -s reopen
1
可能遇到的問題

1、刷新頁面查詢404的情況,也就是頁面找不到

修改Nginx配置文件

try_files $uri $uri/ /index.html;
1

重新載入配置文件重啟Nginx

❺ 使用Tomcat和Nginx部署前端項目

第一種方式,將我們的前端項目放置在webapps目錄下

進入tomcat安裝路徑下的conf目錄,在server.xml文件中<Host>標簽內配置虛擬路徑

簡單的解釋一下參數
path 對應用戶請求過來的url路徑, /static 匹配所有以 /static 開頭的請求
docBase 表示實際匹配到的路徑,這里可以使用絕對路徑,也可以使用相對路徑
reloadable 如果為true,則tomcat會自動檢測應用程序的/WEB-INF/lib 和/WEB-INF/classes目錄的變化。(對於靜態資源來說,個人覺得這個配置用處不大)
總結起來就是,對於ip:8080/static的資源請求,會通過虛擬路徑匹配到我們實際的資源路徑music_client/static。
配置好後重啟,我們可以發現已經能夠看到我們的前端項目了

對於ROOT目錄下的資源,tomcat可以直接在根目錄下進行訪問。通過這種方式,我們可以讓項目的路徑去適配tomcat訪問的路徑。
但是這種方式不是特別推薦,當有多個項目在同一個tomcat伺服器上的時候,會不方便管理。

Nginx是當下熱門的伺服器,使用起來只需要進行簡單的配置即可。對於Nginx的安裝大家可以自行網路解決。
我們先進入到usr/local/nginx(具體以實際nginx安裝目錄為准)下的conf目錄,vim編輯nginx.xml。主要進行下面的配置

簡單的解釋一下
listen 表示nginx監聽的埠號,也就是你希望暴露哪個埠給用戶進行訪問
server_name 表示nginx接受請求的域名,一般默認localhost就行
location 模塊用於響應請求,這里的 / 表示匹配8082埠的所有請求
root 表示靜態資源/項目的路徑
index 表示默認的訪問資源
配置完成後,進入 sbin 目錄下,通過 ./nginx -t 檢查配置文件的格式是否正確
如正確 ./nginx 進行啟動或者 ./nginx -s reload 進行重啟
啟動完,我們就可以直接ip:8082直接訪問我們的前端項目啦

開啟nginx的反向代理也比較簡單,只需要加上proxy_pass 配置即可

出現這個問題的原因是: 在history模式下,只是動態的通過js操作window.history來改變瀏覽器地址欄里的路徑,並沒有發起http請求,但是當我們直接在瀏覽器輸入這個地址的時候,就會對伺服器發起http請求,但是這個目標在伺服器上又不存在,所以會返回404。
我們可以通過把所有請求都轉發到首頁上來解決這個問題。只需要在 Nignx 中的配置文件加入如下配置:

事實上,上面的解決方式也是Vue-Router官方推薦的解決方式( https://router.vuejs.org/zh/guide/essentials/history-mode.html#nginx )。
那上面的 try_files 為什麼能幫助我們解決這個問題呢?我們可以看一下這個屬性的作用

try_files :按選項所指定的順序去檢查用戶請求的文件是否存在,如果本地存在的話則返回該請求;不存在的話將該請求轉發到指定的其它路徑。也就是說,比如我們當前的前端項目部署在 /usr/myproj 目錄下,現在我們在瀏覽器發起 ip:port/testApi 請求,那麼此時 uri 為testApi,nginx會先去 $root/testApi (即/usr/local/myproj/testApi)找是否存在該靜態資源,若不存在,則繼續尋找 $root/testApi/index (即/usr/local/myproj/testApi/index)文件是否存在,如果還是不存在,則會把請求轉發到首頁。

而我們的項目本事就是由Vue-Cli創建的 單頁面應用 ,當index頁面接收到請求的時候,對應的history模式路由就可以發揮作用了,根據瀏覽器的路由跳轉到對應的頁面,這也就保證了我們的路由請求都能夠轉發給index頁面來進行處理。

這種問題一般是出現在伺服器一開始安裝Nginx的時候,沒有安裝SSL模塊。在不重裝Nignx的情況下,可以安裝如下方式進行操作:

執行如下命令

這一步只是以防萬一,可以省略

也可以直接執行 ./usr/local/nginx/sbin/nginx -t 看還會不會報錯就行

nginx報錯: [emerg] https protocol requires SSL support in /usr/local/nginx/conf/nginx.conf:50

❻ nginx 部署多個前端vue項目的3種方式,一篇文章搞定

首先我們看一下nginx.conf配置文件

為了方便管理,在/usr/local/nginx/conf.d/ 創建自己的*.conf配置文件。沒有conf.d目錄,直接mkdir 創建conf.d
*.conf 詳細可參考:

這種方式只需要開放80埠,然後訪問二級域名。

這種方式的好處是只有一個server ,而且不需要二級域名、用路徑location就能實現。

但是這種方式的一個缺點,就是vue項目前端需要改配置。修改地方如下:

react 配置請參考: https://blog.csdn.net/mollerlala/article/details/96427751?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBai-2&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBai-2

vue 配置請參考: https://blog.csdn.net/weixin_33868027/article/details/92139392

❼ nginx部署前端純頁面

1.進入nginx配置文件vim .../nginx-1.9.12/conf/nginx.conf。

如上圖所示:第一個紅框中的內容就是應用伺服器的地址;第二個紅框中的內容就是前端包的位置。

此時,配置文件已經准備完畢。這個包和埠可以存在多個。

2.進入.../nginx-1.9.12/sbin 找到nginx的啟動程序。

nginx -c ../nginx-1.9.12/conf/nginx.conf    啟動nginx程序,並指定配置文件。

3.如果要替換包,則直接替換就行,nginx為熱載入自動更新的。但是以防有緩存之類的存在,可以使用nginx -s reload命令進行重載一次。

追加 一 :

如果前端包的構造如下圖

則location配置依然如下圖

但是訪問地址則需要指定到具體的html文件上。。

綁定: http://127.0.0.1:48110/binding.html

成功: http://127.0.0.1:48110/success.html

失敗: http://127.0.0.1:48110/error.html

追加 二:

同一個埠部署多個頁面:

一個server下,多個 location。

location的作用就是是否有後綴,並且這個後綴會去拼接root後的地址。

比如第二個location /sis/。

則在訪問127.0.0.1:8080/sis時,會去自動尋找/apps/svr/nginx-1.9.12/pagefile/0921/sis這個包。   (Ps:location後的地址一定要用 / 關閉,比如 location /sis/,不然訪問127.0.0.1:8080/sis時,會報錯,只有用127.0.0.1:8080/sis/才行。)

這樣就部署好了一個 埠支持多個頁面。