❶ nginx前端頁面配置(nginx代理前端頁面)
【nginx】前後端代理配置代理單個前端時，以下eg1、eg2代理的是同一個文件，不用的是url
細心地讀者發現還有第三個代理eg3、它的不同在於19行，是以alias開頭的代理。那麼他有什麼不同呢，按照上面代理文件的路徑，test1與test0是一樣的讓敗槐，也就是說eg1和eg3是一樣的代理。
簡單的分析出：
root：root+location為實際文件路徑
alias：鎮告alias為實際文件路徑（ps：必須是以/結尾，因為御搭明代理的東西在此目錄下）
當代理多個靜態文件時，容易發生404問題。
若把單個配置成location/時，又沒有問題，那麼你需要參考以下配置。
ps：一般根路徑用root，其他為alias代理。
有枯陸關^~請看FAQ
12行最後的/api/;分號前面的/問題請看FAQ
因為微信公眾號的回調只能調用https，有些時候可能會用到。
這里需要自己了解一下https，簡而言之需要證書，針對某一個url，這里展示一個代理示例
簡單測試了一下，若是僅僅前枝消端代理，是沒有影響的，無論是root還是alias
那區別是什麼呢，當代理的內容為地址時，
url尾部的/表示目錄，沒有/表示文件，是否需要加，根據情況選擇
使用^~當做前綴，正則匹配然坦友後代理
關於nginx你可能不知道的秘密----nginx地址重寫以及錯誤頁面配置Rewrite對稱URLRewrite，即URL重寫，就是把傳入Web的請求重定向到其他URL的過程。
rewrite**指令根據表達式來重定向URI，或者修改字元串。可以應用於server,location,if環境下每行rewrite指令稿攔最後跟一個flag標記，支持的flag標記有：
redirect和permanent區別則是返回的不同方式的重定向，對於客戶端來說一般狀態下是沒有區別的。余首而對於搜索引擎，相對來說301的重定向更加友好，如果我們把一個地址採用301跳轉方式跳轉的話，搜索引擎會把老地址的相關信息帶到新地址，同時在搜索引擎索引庫中徹底廢棄掉原先的老地址。使用302重定向時，搜索引擎(特別是google)有時會查看跳轉前後哪個網址更直觀，然後決定顯示哪個，如果它覺的跳轉前的URL更好的話，也許地址欄不會更改。
首先我們需要在windows上進行本地解析，打開C:WindowsSystem32driversetc下面的hosts文件並添加
192.168.13.128
訪問
nginx錯誤頁麵包括404403500502503504等頁面，只需鍵毀胡要在server中增加以下配置即可：
注意：
/usr/local/nginx/html/路徑下必須有404.html這個文件！！！
但是404.html上如果引用其他文件的png或css就會有問題，顯示不出來，因為其他文件的訪問也要做配置；為了簡單，可以將css嵌入文件中，圖片用base編碼嵌入；如下：
訪問（ip地址/404.html）
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-sreload命令進行重載一次。
追加一：
如果前端包的構造如下圖
則location配置依然如下圖
但是訪問地址則需要指定到具體的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/才行。）
這樣就部署好了一個埠支持多個頁面蘆返鎮。
nginx配置前端，需要幾台什麼樣的伺服器。什麼樣的系統，什麼樣的配置兩種前端架構：
lvs-nginx前端代理-squid緩存
lvs-squid前端緩存-nginx中層代理
squid在前面的優點：
Squid作純代理比較穩當
前端少一級代理，響應速度會快，出問題的可能性要小
功能有限，不會常被調整
容易為人接受，只是為了擴充功能而增加中層代理
一般的配置簡便，比如增加一個二級域名，只需配置一個指向。
增加的nginx可擴展功能，增加對應用服務的負載均衡告緩等。
squid在前面的缺點：
squid支持的負載均衡配置復雜
容災問題
更新緩存要遍歷所有機器
squid只支持單cpu，所以浪費cpu
nginx在前面的優點：
分流、負載均衡功能強大，可以細致定義
可精細定製access_log
nginx的錯告指誤日誌更詳細
可讓squid只緩存無壓縮版本，由nginx壓縮，這樣可優化squid緩存容量
nginx可分擔襪友模部分無實時性要求的緩存
nginx在前面的優點：
nginx目前還有部分bug。
功能強，所以可能經常被調整
nginx代理用的短鏈接方式
單機上安裝nginx+squid的cpu消耗比純squid和純nginx之和要大一倍，但也不算高
容易遭到質疑，不易被接受。
nginx如何配置靜態頁面
首先nginx安裝好之後的預設配置文件：nginx/conf/nginx.conf
這里定義的root地址是相對於nginx的根路徑的；那麼當用戶通過瀏覽器訪問根地址:;hostname:port時，nginx試圖返回的頁面就是：nginx/html/index.html。
當然這里root也可以寫全路徑，例如/home/username/tools/nginx/html，效果是一樣的。
這里我們要討論如何把一個靜態頁面配置到nginx裡面。
假設靜態頁面內容放在文件夾/app/testapp/www下面(同時假設/app/testapp/www/index.html也存在)，我們如何配置nginx使得;hostname:port/做握亂testapp能夠訪問到這些靜態頁面內容呢。
結果：404NotFound
查看nginx日誌(nginx/logs/error.log)：
原來nginx試圖訪問的文件路徑是：/app/testapp/www/testapp，這個路徑是」root「的內容再拼上location的值組成的；那我們給修改location和root的值：純檔
然後通過地址;hostname:port/www就可以訪問了；但是這里location必須用」www「不能用」皮喊testapp「，這就非常不可接受了，解決的辦法可以是修改靜態頁面的地址，再加一層testapp路徑，例如："/app/testapp/www/testapp"，然後再配置：
這樣是可以的。另一個方法是採用alias取代root。
保留今天頁面的地址"/app/testapp/www"，配置nginx的配置文件：
關於alias和root的區別，請查閱nginx文檔或者自行google，這里不再重復貼了。
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(TimeToFirstByte，首位元組時間，WEB性能優化重要指標)。這樣唯一的問題是，Nginx開始返回響應時，它無法知道將要傳輸的文件最終有多大，也就是無法給出Content-Length這個響應頭部。
所以，在HTTP1.0中如果利用Nginx啟用了GZip，是無法獲得Content-Length的，這導致HTTP1.0中開啟持久鏈接和使用GZip只能二選一，所以在這里gzip_http_version默認設置為1.1。
如上面的圖，前面是眾多的服務窗口，下面有很多用戶需要服務，我們需要一個工具或策略來幫助我們將如此多的用戶分配到每個窗口，來達到資源的充分利用以及更少的排隊時間。
把前面的服務窗口想像成我們的後端伺服器，而後面終端的人則是無數個客戶端正在發起請求。負載均衡就是用來幫助我們將眾多的客戶端請求合理的分配到各個伺服器，以達到服務端資源的充分利用和更少的請求時間。
Upstream指定後端伺服器地址列表
在server中攔截響應請求，並將請求轉發到Upstream中配置的伺服器列表。
上面的配置只是指定了nginx需要轉發的服務端列表，並沒有指定分配策略。
輪詢策略
默認情況下採用的策略，將所有客戶端請求輪詢分配給服務端。這種策略是可以正常工作的，但是如果其中某一台伺服器壓力太大，出現延遲，會影響所有分配在這台伺服器下的用戶。
最小連接數策略
將請求優先分配給壓力較小的伺服器，它可以平衡每個隊列的長度，並避免向壓力大的伺服器添加更多的請求。
最快響應時間策略
依賴於NGINXPlus，優先分配給響應時間最短的伺服器。
客戶端ip綁定
來自同一個ip的請求永遠只分配一台伺服器，有效解決了動態網頁存在的session共享問題。
匹配以png|gif|jpg|jpeg為結尾的請求，並將請求轉發到本地路徑，root中指定的路徑即nginx本地路徑。同時也可以進行一些緩存的設置。
nginx的功能非常強大，還有很多需要探索，上面的一些配置都是公司配置的真實應用（精簡過了），如果您有什麼意見或者建議，歡迎在下方留言...
❷ Nginx部署前端vue後端express項目步驟細節
前端採用Vue構建頁面，後端通過Express編寫介面，部署前需要做好vue項目打包和Nginx安裝准備工作。以下是詳兆棚細的部署步驟：
首先，在Nginx安裝目錄（如：C:/nginx-1.18.0）的conf文件夾找到並打開nginx.conf文件。添加一個serve塊，設置反向代理以監聽5678埠，如：listen 5678。
允散歲許Nginx監聽10.9.26.121的5678埠，以便外部訪問。配置代碼：server_name 10.9.26.121。
當用戶訪問10.9.26.121:5678時，Nginx會將請求轉發到打包後的dist文件夾，其中存放前端頁面代碼。確保root路徑正確，如：D:/nginx-1.18.0/html/personManage/dist，注意使用正斜杠/，避免Windows中的反斜杠問族掘則題。
因為前端使用vue.config.js的devServer處理跨域，Nginx也需要配置相應的location來轉發跨域請求，確保前後端介面路徑一致。
後端Express應用監聽9999埠，使用pm2管理。啟動命令：pm2 start app.js。
全局安裝pm2進行項目管理，提供開機自啟動、進程監控等高級功能。安裝成功後，通過pm2 start app.js啟動Express項目。
以上就是Nginx部署Vue+Express項目的詳細流程。如有興趣深入了解pm2，可訪問其官方網站獲取更多信息。