⑴ 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 知識
「 關注 前端開發社區 ，回復 ' 領取資源 '，免費領取Vue，小程序，Node Js，前端開發用的插件以及面試視頻等學習資料，讓我們一起學習，一起進步
<figcaption style="margin-top: 5px; text-align: center; color: #888; font-size: 14px;">作者:樹醬 來源: 掘金</figcaption>
當有一台伺服器宕機時，負載均衡器就分配其他的伺服器給用戶，極大的增加的網站的穩定性 當用戶訪問web時候，首先訪問到的是 負載均衡器 ，再通過負載均衡器將請求轉發給後台伺服器
如果檢測出其中某台伺服器異常,那麼在通過客戶端請求 nginx 反向代理進來的都不會被發送到該伺服器上（直至下次輪訓健康檢查正常）
基本例子如下👇
涉及兩個配置：
反向代理的優勢主要有以下兩點:
當你的應用不想直接暴露給客戶端（也就是客戶端無法直接通過請求訪問真正的伺服器，只能通過 Nginx ），通過 nginx 過濾掉沒有許可權或者非法的請求，來保障內部伺服器的安全
也就上一章提到負載均衡，本質上負載均衡就是反向代理的一種應用場景，可以通過 nginx 將接收到的客戶端請求" 均勻地 "分配到這個集群中所有的伺服器上(具體看負載均衡方式),從而實現伺服器壓力的 負載均衡
我們通過模擬內部伺服器的埠啟動的 nodejs 項目設置反向代理到80埠訪問
在 Nginx 反向代理是，會通過 location 功能匹配指定的 URI ，然後把接收到的符合匹配 URI的請求通過 proxy_pass 轉移給之前定義好的 upstream 節點池
建立白名單
修改nginx配置(nginx.conf)
為匹配項做白名單設置
假如我們在程序文件夾下有一個 ngxin 配置文件： /home/app/app.nginx.conf 我們需要給這個文件創建一個軟鏈接到 /etc/nginx/conf.d/ 下：
這樣操作之後，當我們改應用配置文件， /etc/nginx/conf.d/ 下與之對應的配置文件也會被修改，修改後重啟 nginx 就能夠使新的 ngxin 配置生效了。
往期
安利幾個JS開發的小技巧
請各位帥哥美女多多支持帥編，回復「 加群 」即可領取 前端干貨
⑶ 前端工程師怎麼充分利用nginx，更有效的進行web開發
前端工程師，也叫Web前端開發工程師。他是隨著web發展，細分出來的行業。
Web前端開發技術主要包括三個要素：HTML、CSS和JavaScript！
它要求前端開發工程師不僅要掌握基本的Web前端開發技術，網站性能優化、SEO和伺服器端的基礎知識，而且要學會運用各種工具進行輔助開發以及理論層面的知識，包括代碼的可維護性、組件的易用性、分層語義模板和瀏覽器分級支持等。
隨著近兩三年來RIA（Rich Internet Applications的縮寫，中文含義為：豐富的網際網路應用程序）的流行和普及帶來的諸如：Flash/Flex，Silverlight、XML和伺服器端語言（PHP、ASP.NET，JSP、Python）等語言，前端開發工程師也需要掌握。
前端開發的入門門檻其實很低，與伺服器端語言先慢後快的學習曲線相比，前端開發的學習曲線是先快後慢。
HTML 甚至不是一門語言，他僅僅是簡單的標記語言！
CSS 只是無類型的樣式修飾語言。當然可以勉強算作弱類型語言。
Javascript 的基礎部分相對來說不難，入手還算快。
也正因為如此，前端開發領域有很多自學成「才」的同行，但大多數人都停留在會用的階段，因為後面的學習曲線越來越陡峭，每前進一步都很難。
Web前端技術有一些江湖氣，知識點過於瑣碎，技術價值觀的博弈也難分伯仲，即全局的系統的知識結構並未成體系，這些因素也客觀上影響了「正統「前端技術的沉澱！而且各種「奇技淫巧」被濫用，前端技術知識的傳承也過於泛泛，新人難看清時局把握主次。因此，前端技術領域，為自己覓得一個靠譜的師兄，重要性要蓋過項目、團隊、公司、甚至薪水。
另一方面，正如前面所說，前端開發是個非常新的職業，對一些規范和最佳實踐的研究都處於探索階段。
總有新的靈感和技術不時閃現出來，例如CSS sprite、負邊距布局、柵格布局等；
各種JavaScript框架層出不窮，為整個前端開發領域注入了巨大的活力；
瀏覽器大戰也越來越白熱化，跨瀏覽器兼容方案依然是五花八門。
為了滿足「高可維護性」的需要，需要更深入、更系統地去掌握前端知識，這樣才可能創建一個好的前端架構，保證代碼的質量。
隨著手持設備的迅猛發展，帶動了HTML5行業標準的快速發展。web領域的技術，大概有10年都沒有大的更新了！
⑷ 我是做前端的，請教下nginx apache什麼意思，在web上有具體應用是什麼，
nginx和apache都是靜態HTTP伺服器，用於提供HTTP服務，主要展示靜態的html頁面。
⑸ 如何搞定前端資源服務跨域問題之nginx篇
通過add_header命令為響應增加跨域頭：
add_header "Access-Control-Allow-Origin" "*";
⑹ 前端必須用nginx部署嗎
是的。根據查詢相關資料顯示：前後端分別部署，前端使用Nginx部署，後端直接運行jar.
⑺ nginx 在前端中的簡單應用
Web 服務實際上又稱靜態資源服務，自從前後端分離後，前端的輸出趨向於靜態資源的形式，什麼是靜態資源：就是我們通常用webpack構建輸出的結果，比如：
而為了提供文件在互聯網中的可訪問性，前端還是需要依賴 靜態資源服務 ；最常用的做法就是Node服務和Nginx服務。
Node服務最常見的，就是WebpackServer, 在前端開發聯調時經常用到, 啟動後我們就可以通過 http://localhost:8907/bundle.05a01f6e.js 的形式來訪問構建資源；除此之外，我給大家安利另一款Node服務庫： serve , 它也能快速啟動一個靜態資源服務。
但在生產環境，我們一般用Nginx來處理，不是Node不好，而是Nginx已經夠好了。通常整個大前端會有很多前端項目，我們都將構建結果放在一台伺服器上（一般有備份機器）的某個文件夾下,然後通過安裝Nginx來創建一個靜態資源服務供所有前端資源的訪問；比如文件夾static下有A，B，C，D四個前端項目資源, 我們通過nginx配置:
我們即可通過 http://static.closertb.site/A 訪問A項目，通過 http://static.closertb.site/C 訪問C項目, 從而做到一雞多吃，這種玩法在HTTPS與HTTP2的時代特別常見。
以上就是Nginx作為Web服務的簡單用法，接下來我們了解一下反向代理服務
作為一個開發者，可能經常聽到 代理 兩字，但很多人區分不清楚正向和反向的區別：
如上圖左側所示，正向代理是用戶的主動行為，如我們fq時訪問goggle所做的；右側反向代理是我們訪問的伺服器行為，作為用戶的我們是不能控制也無需關注的。
反向代理在服務部署中，是一種非常常見的技術，比如負載均衡、容災、緩存。
而對於前端開發來說，反向代理多用於請求轉發，來處理 跨域 問題。當我們把前端靜態資源服務都指向一個域名（static.closertb.site）時，與服務端請求域名（server.closertb.site）不一致，就會造成跨域。如果服務端不配合的話，那通過nginx，前端也是可以輕松做到的，在前面的配置上，我們添加：
所以當網頁發出一個請求： http://static.closertb.site/a 時，實際請求地址是： http://server.closertb.site/a ，這就簡單實現了一個服務代理。其原理與WebpackServer的proxy相似.
以上就是Nginx的web服務和代理服務在前端開發中的兩個典型使用場景, 接下來我們說點零碎又有用的
當請求 http://static.closertb.site/site/a/logo.png )時，將會返回伺服器上的/home/static/static/a/logo.png文件，即'/home/static'+'/static/a/logo.png',其 拼接的地址是匹配字元串及其以後的
而對於alias：
當請求 http://static.closertb.site/static/a/logo.png )時，將會返回伺服器上的/home/static/a/logo.png文件，即'/home/static'+'/a/logo.png',其 拼接的地址是除了匹配字元串以後的地址
你可能見過A這種：
也可能見過B這種
有什麼區別？
兩者與root 和 alias有相似之處，只不過這種差別，只適用於：
所以當收到一個請求： http://static.closertb.site/api/user/get ) 時，配置A將會把請求代理到： http://server.closertb.site/api/user/get ); 配置B將會把請求代理到： http://server.closertb.site/user/get )
這個知識，在代理配置中真的相當重要
當我們下架一個前端服務，或者用戶訪問了某個根本不存在的頁面，我們不希望用戶看到的是404，而是將其引導到一個模糊正確的頁面，這時候我可以用rewrite服務；反手一個配置，直接就將流量打到了網站首頁;
另一個比較常用的，就是網站開啟https，我們需要將所有http請求重定向到https：
上面同是rewrite，但還是有不一樣的 ，一個是redirect（302）, 另一個是permanent（301），這兩個還是有很大區別的；
web 性能優化是前端的一門學問，好的靜態資源載入速度，會顯著提升用戶體驗，而nginx作為最常用的靜態資源伺服器，也是有諸多渠道來幫助我們來提升靜態資源載入速度，簡單來講，可以三個方面，直接上配置：
``if ( ) {
expires 365d;
add_header Cache-Control max-age=31536000;
}</pre>
expires與max-age兩種配置方式都可以達到告訴瀏覽器資源一年以後過期的目的，更多關於http緩存的可以 看這一篇文章 ；
⑻ 如何搞定前端資源服務跨域問題之nginx篇
我們可以很清楚的看到當http請求的站點訪問https的資源的時候會報出「Cross-Origin」跨域的問題。為什麼會出現這樣的錯誤，這是因為涉及到「同源策略」的問題。。。blablabla……
3、下面依次說如何解決這個問題
問題解決
1、我們再來看一下報錯信息，報錯信息中有一段寫明「Access-Control-Allow-Origin」header的字樣，我們可以由此看出會不會在服務端add header即可呢？
2、順著這個思路，在nginx配置中加入了這樣一句：
add_header 'Access-Control-Allow-Origin' '*';
如圖所示：
3、重啟之後，其他內容好了（例如，css文件等）發現字體（font）文件還是有問題的，如圖所示：
這是為什麼……！字體文件的Context-Type卻是」text/html"！！！而且還沒有像別的東東那樣的 Access-Control-Allow-Origin:*
4、於是乎，繼續增加了這樣一句（如圖所示），指定eot、ttf、woff字體文件 強制加入header信息
5、覺得這樣萬事大吉 就錯了、錯了、錯了……重要的事情說三遍（這個地方是個巨坑、當時就是在下面要說的地方浪費了好長時間，不過最後還是解決了，不墨跡了，我們繼續……）6、突然發現，哦，是不是因為我沒加mime.types呢？（這個必須要加的，因為它決定文件的Content-Type）這個應該早點想起來的……blablabla…… 趕緊加上 回來再看……
於是乎加了三行：
application/x-font-woff woff woff2;
font/ttf ttf;
font/opentype otf;
【要刪除 application/font-woff woff; 這行刪掉(mime.types 第27行） 否則會報plicate的warning】
7、再次重啟，再看！
Oh，My God 還是如此。。。
8、拿出殺手鐧，查詢log吧。
果然發現一個致命問題
哥，為啥你要去$NGINX_HOME/html目錄去找啊，你不應該是從/www/xinghuo-img去找嗎？(⊙o⊙)…
（旁白：誰告訴你 "location /" 和「location ~"會共用他們其中一個的root了。。。。
好吧……我錯了。
9、於是乎，我在「location ~"也加一個root好了：）
10、「最後」一次重啟，測試、搞定！如圖所示：
後記
1、之前看安全測試的書籍中了解到了「同源策略」，今天是見識並實踐了一下跨域問題的解決。漲姿勢了！受益匪淺！
2、其實最後那個配置文件，可以修改為（如圖所示），我姑且認為可以設置一個root全局變數，嘿嘿。
3、還是得繼續學習、鑽研呀……fighting。
4、它折磨我從兩點到四點……還好順利解決了。記錄下來以便大家以後不用再次踩坑，謝謝！blablabla……
5、遇到問題及時查log非常重要、非常重要、非常重要……