1. nginx代理常用配置
1. 最簡反向代理配置
在http節點下，使用upstream配置服務地址，使用server的location配置代理映射。
upstream my_server {
server 10.0.0.2:8080;
keepalive 2000;
}
server {
listen 80;
server_name 10.0.0.1;
client_max_body_size 1024M;
location /my/ {
proxy_pass http://my_server/;
proxy_set_header Host $host:$server_port;
}
}
通過該配置，訪問nginx地址http://10.0.0.1:80/my的請求會被轉發到my_server服務地址http://10.0.0.2:8080/。
需要注意的是，如果按照如下配置：
upstream my_server {
server 10.0.0.2:8080;
keepalive 2000;
}
server {
listen 80;
server_name 10.0.0.1;
client_max_body_size 1024M;
location /my/ {
proxy_pass http://my_server;
proxy_set_header Host $host:$server_port;
}
}
那麼，訪問nginx地址http://10.0.0.1:80/my的請求會被轉發到my_server服務地址http://10.0.0.2:8080/my。這是因為proxy_pass參數中如果不包含url的路徑，則會將location的pattern識別的路徑作為絕對路徑。
2. 重定向報文代理
即便配置了nginx代理，當服務返回重定向報文時（http code為301或302），會將重定向的目標url地址放入http response報文的header的location欄位內。用戶瀏覽器收到重定向報文時，大讓段會解析出該欄位並作跳轉。此時新的請求報文將直接發送給服務地址，而非nginx地址。為了能讓nginx攔截此類請求，必須修改重定向報文的location信息。
location /my/ {
proxy_pass http://my_server;
proxy_set_header Host $host:$server_port;
proxy_redirect / /my/;
}
使用proxy_redirect可以修改重定向報文的滾譽location欄位，例子中會將所有的根路徑下的url代理到nginx的/my/路徑下返回給用戶。比如服務返回的重定向報文的location原始值為/login，那麼經過nginx代理後，用戶收到的報文的location欄位為/my/login。此時，瀏覽器將會跳轉到nginx的/my/login地址進行訪問。
需要注意的是，服務滑毀返回的重定向報文的location欄位有時會填寫絕對路徑（包含服務的ip/域名和埠），有時候會填寫相對路徑，此時需要根據實際情況進行甄別。
location /my/ {
proxy_pass http://my_server;
proxy_set_header Host $host:$server_port;
proxy_redirect http://my_server/ http://$host:$server_port/my/;
}
上述配置便是將my_server服務的根路徑下的所有路徑代理到nginx地址的/my/路徑下。當nginx配置只有一個server時，http://$host:$server_port前綴可以省略。
3. 報文數據替換
使用nginx代理最牛（dan）逼（sui）的情況就是http響應報文內寫死了服務地址或web絕對路徑。寫死服務地址的情況比較少見，但也偶爾存在。最棘手的是寫死了web絕對路徑，尤其是絕對路徑都沒有公共前綴。舉個例子來說：
一般的web頁面會包含如下類似路徑：
/public：用於靜態頁面資源，如js腳本/public/js，樣式表/public/css，圖片/public/img等。
/static：和/public類似。
/api：用於後台服務API介面。
/login：用於登錄驗證。
其他。
對於這樣的服務，可能的代理配置如下：
location /my/ {
proxy_pass http://my_server/;
proxy_set_header Host $host:$server_port;
proxy_redirect / /my/;
}
location /login/ {
proxy_pass http://my_server/public;
proxy_set_header Host $host:$server_port;
}
location /public/ {
proxy_pass http://my_server/public;
proxy_set_header Host $host:$server_port;
}
location /api/ {
proxy_pass http://my_server/api;
proxy_set_header Host $host:$server_port;
}
由於web頁面或靜態資源內寫死了類似的絕對路徑，那麼對於用戶來說，通過頁面內的鏈接進行跳轉時，都會請求到nginx服務對應的路徑上。一旦存在另一個服務也包含類似的路徑，也需要nginx進行代理，那麼矛盾就出現了：訪問nginx的同一個路徑下的請求究竟轉發給哪一個服務？
要解決這個問題，必須在用戶收到報文前，將報文的數據中包含的絕對路徑都添加統一的前綴，如/my/public，/my/api，/my/login，這樣nginx代理配置則可以簡化為：
location /my/ {
proxy_pass http://my_server/;
proxy_set_header Host $host:$server_port;
proxy_redirect / /my/;
}
location /other/ {
proxy_pass http://other_server/;
proxy_set_header Host $host:$server_port;
proxy_redirect / /other/;
}
nginx的ngx_http_sub_mole模塊提供了類似的報文數據替換功能，該模塊默認不會安裝，需要在編譯nginx時添加--with-http_sub_mole參數，或者直接下載nginx的rpm包。
使用sub_filter對數據包進行替換的語法如下：
location /my/ {
proxy_pass http://my_server/;
proxy_set_header Host $host:$server_port;
sub_filter 'href="/' 'href="/my/';
sub_filter 'src="/' 'src="/my/';
sub_filter_types text/html;
sub_filter_once off;
}
上述配置會將/my/下的所有響應報文內容的href="/替換為href="/my，以及src="/替換為src="/my，即為所有的絕對路徑添加公共前綴。
注意，如果需要配置多個sub_filter，必須保證nginx是1.9.4版本之上的。
2. nginx 配置靜態資源
修改枯余 nginx/conf\nginx.conf
在納肢 http 模塊下，沒茄滾新增一個server虛擬服務配置，如下
3. 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緩存的可以 看這一篇文章 ；
4. 【NGINX入門】2.Nginx搭建靜態資源web伺服器
本文講解Nginx安裝後，nginx搭建鍵侍靜態資源web伺服器需要的配置內容包括location，gzip，帶寬限速等配置。
添野舉加上圖中的配稿脊吵置後, 客戶端訪問 http://172.16.204.5:90/ 時, 會以樹的格式展示mine_html中的所有文件. 使用這種方式可以很好的共享靜態資源.
（1）Nginx系列教程(2)nginx搭建靜態資源web伺服器
https://yq.aliyun.com/articles/752950
5. 向nginx請求靜態資源的時候，nginx還會提交給php-fpm來處理嗎
不會的，如果都交給php-fpm來處理的話，效率肯定低。
這個其實有nginx 配置文件來決定，所以你就看你怎麼配置了，打開nginx.conf 看到裡面有這么一段
location~.php${
fastcgi_pass127.0.0.1:9000;
fastcgi_indexindex.php;
fastcgi_paramSCRIPT_FILENAME$document_root$fastcgi_script_name;
includefastcgi_params;
}可以看出 當請求地址 匹配.php時 nginx就轉發到php-fpm,
你可以研究下nginx.conf這個配置文件，自然就明白了。
希望可以幫助到你，有問題可以隨時私信交流。
6. 不容錯過的Nginx配置詳解，一文帶你搞懂Nginx
Nginx是一個高性能的HTTP和反向代理伺服器，特點是佔用內存少，並發能力強，事實上Nginx的並發能力確實在同類型的網頁伺服器中表現好。Nginx專為性能優化而開發，性能是其最重要的考量，實現上非常注重效率，能經受高負載的考驗，有報告表明能支持高達50000個並發連接數。
需要客戶自己在瀏覽器配置代理伺服器地址。
例如：在大陸訪問www.google.com，我們需要一個代理伺服器，我們通過代理伺服器去訪問谷歌，這個過程就是正向代理。
反向代理，客戶端對代理是無感知的，因為客戶端不需要任何配置就可以訪問，我們只需要將請求發送到反向代理伺服器，由反向代理伺服器去選擇目標伺服器獲取數據後，在返回給客戶端，此時反向代理伺服器和目標伺服器對外就是一個伺服器，暴露的是代理伺服器地址，隱藏了真實伺服器IP地址。
單個伺服器解決不了，我們增加伺服器的數量，然後將請求分發到各個伺服器上，將原先請求集中到單個伺服器上的情況改為將請求分發到多個伺服器上，將負載分發到不同的伺服器，也就是我們說的負載均衡。
為了加快網站的解析速度，可以把動態頁面和靜態頁面由不同的伺服器來解析，加快解析速度。降低原來單個伺服器的壓力。
進入到下面的目錄，然後使用命令
配置文件所在位置：/usr/local/nginx/conf/nginx.conf
由全局塊+events塊+http塊組成
從配置文件開始到events之間的內容，主要會設置一些影響Nginx伺服器整體運行的配置指令，主要包括配置運行Nginx伺服器的用戶（組）、允許生成的worker process數，進程pid存放路徑、日誌存放路徑和類型以及配置文件的引入等。
events塊設計的指令主要影響Nginx伺服器與用戶的網路連接，常用的設置包括是否開啟對多work process下的網路連接進行序列化，是否允許同時接收多個網路連接，選取哪種事件驅動模型來處理連接請求，每個work process可以同時支持的最大連接數等。下面的例子表示每個work process支持的最大連接數為1024。這部分配置對Nginx的性能影響較大，在實際中應該靈活配置。
Nginx伺服器配置中最頻繁的部分，代理、緩存和日誌定義等絕大多數功能和第三方模塊的配置都在這里，http塊又包括http全局塊和server塊。
http全局塊配置的指令包括文件引入、MIME-TYPE定義、日誌自定義、連接超時時間、單鏈接請求數上限等。
這塊和虛擬主機有密切關系，虛擬主機從用戶角度看，和一台獨立的硬體主機是完全一樣的，該技術的產生是為了節省互聯網伺服器硬體成本。
每個http塊可以包括多個server塊，而每個server塊就相當於一個虛擬主機。
每個server塊也可以分為全局server塊，以及可以同時包含多個location塊。
最常見的配置時本虛擬主機的監聽配置和本虛擬主機的名稱或IP配置。
一個server塊可以配置多個location塊。
這塊的主要作用是基於Nginx伺服器接收到的請求字元串（例如server_name/uri-string），對虛擬主機名稱（也可以是IP別名）之外的字元串（例如前面的/uri-string）進行匹配，對特定的請求進行處理。地址定向、數據緩存和應答控制等功能，還有許多第三方模塊的配置也在這里進行。
訪問http://ip，訪問到的是Tomcat的主頁面http://ip:8080。
Nginx+JDK8+Tomcat
訪問：http://192.168.71.167/，看到的是Tomcat的首頁。
根據訪問的路徑跳轉到不同的伺服器中去。
訪問http://ip:9001/e 直接跳到http://127.0.0.1:8080/e
訪問http://ip:9001/vod 直接跳到http://127.0.0.1:9090/vod
Nginx+JDK8+配置兩個Tomcat，Tomcat的配置不再講述。
訪問http://192.168.71.167:9001/e/a.html跳到了http://127.0.0.1:8080/e/a.html頁面。
訪問http://192.168.71.167:9001/vod/a.html跳到了http://127.0.0.1:9090/vod/a.html頁面。
假如Nginx代理伺服器Server的配置為：192.168.71.167:9001，跳到：127.0.0.1:8080，訪問者的IP為：192.168.71.200:20604。
通過訪問http://192.168.71.167/e/a.html，實現負載均衡的效果，平均分攤到8080和8081埠中。
Nginx+JDK8+2台Tomcat，一台8080，一台8081。
訪問：http://192.168.71.167/e/a.html，8080和8081交替訪問。
1 輪詢（默認）
每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。
2 weight
weight代表權重，默認為1，權重越高被分配的客戶端越多。
指定輪詢幾率，weight和訪問比率成正比，用於後端伺服器性能不均的情況。
3 ip_hash
每個請求按訪問IP的hash結果分配，這樣每個訪客固定訪問一個後端伺服器，可以解決session的問題，示例如下：
4 fair（第三方）
按後端伺服器的響應時間來分配請求，響應時間短的優先分配。
訪問圖片：http://192.168.71.167/image/1.jpg
訪問頁面：http://192.168.71.167/www/a.html
訪問目錄：http://192.168.71.167/image/（因為設置了autoindex on;）
兩台機器，每台機器都裝有keepalived+Nginx+Tomcat。
主備keepalived伺服器中只有master一台機器會出現VIP地址，否則會出現腦裂問題。
【提示】腳本要加+x的執行許可權：chmod +x chk_nginx.sh
在Nginx里把虛擬IP配置進去即可。
一個Nginx是由一個master進程和多個worker進程組成的。
客戶端發送請求到Master，然後給worker，再由這些work爭搶處理這個請求。
1 可以使用nginx -s reload進行熱部署方式；
2 每個worker是獨立的進程，如果有其中的一個worker出現了問題，其他worker獨立的繼續進行爭搶，實現請求的過程，不會造成服務的中斷；
Nginx和Redis類似，都採用了io多路復用機制。每個worker進程都可以把CPU發揮到極致，一般來說worker數和伺服器的CPU數相等是最為適宜的。
發送請求：訪問靜態資源佔用2個連接，反向代理佔用4個連接。
【溫馨提示】
7. 詳解nginx如何代理靜態資源(長搜索路徑優先)
web伺服器重要的的任務之一就是服務靜態資源文件，比如網站的圖片，還有一些靜態的HTML頁面，本文的例子還是來自於Nginx官網。在這個用例中我旁肢們要配置兩個靜態資源路徑，來處理外部的靜態資源請求。我們會更改配置文件中，server塊下http下的location。
首先需要創建/data/www目錄，然後將index.html文件，文件的內容並不重要，本例只是指引我們觀察nginx如何找到和發送靜態資源。然後唯談在創建一個/data/images目錄，並放置一些圖片文件。
下一步打開配置文件，默認的配置文件中已經包含了一些server塊，大多數已經注釋掉了，官網讓我們把server塊都注釋掉，重寫寫一個新的空的server塊，但注意，一定不要將http注釋掉，nginx通過識別它才能知道我們需要處理的是http請求。
通常，配置文件可能會包含多個server塊，這些server塊可以由埠號區分，也可以由server names來區分。當nginx決定由哪一個server去處理請求指啟碰的時候，nginx會根據server塊中location參數去測試請求頭中指定的URI
現在在server塊中添加location塊
該location塊指定了URI請求的根目錄前綴，"/"。對於請求來講，URI被添加在root路徑具體指向的目標路徑，如果存在的多個匹配的位置塊，nginx將選擇前綴最長的位置塊（可能是因為更加具體）。上方的location塊提供的已經是最短前綴了，也就是說，server塊中所有的location塊如果都沒有匹配到，則該location塊將會被採用。
官網的說法真的非常繞，我覺得思路就是， nginx首先會優先去具體的location塊匹配資源（規則是參數越長，越優先查找），如果都查不到就去根路徑查。
我們再加一個location塊
這個location塊會匹配以/images/開始的請求，但上一個(location塊 location / 也會匹配該內容，記得嗎，Nginx會先匹配長路徑location塊)
現在為了看的更加清楚，在加過這兩部分內容之後的配置文件應該長這樣
重新載入nginx之後，配置會更新，使用：
現在該配置文件已經生效了，配置在監聽80埠的本地伺服器上，我們可以在本地訪問 http://localhost/ ，在此之後例如 http://localhost/images/example.png 這樣的請求， Nginx會映射到location /images/去，如果請求的資源不存在，Nginx將返回404頁面，404頁面是可以定製的，一般企業也會定製屬於自己的404頁面。
後續的內容我還打算針對一些常見場景，記錄以下nginx的配置文件針對不同場景和需求該如何去寫，以及為什麼這么寫。Nginx一些模塊的詳細介紹不打算專門寫，大家如果有需求可以看官方文檔。
http://nginx.org/en/docs/beginners_guide.html#conf_structure
8. node靜態資源nginx部署部署後無法訪問
1、首先確認靜態資源文件夾是否已經放在與 nginx.exe 同級的目錄中。
2、確認 conf 文件夾中 nginx.conf 文件里 location 中 root 後面是否填寫正確的靜態資源文件名襪橡。
3、Nginx 伺服器的目錄路徑不能有中文，檢查路徑中是否有中文，有的話，需神好銷游游要移出來。
4、確認以上修改沒有問題後，進入任務管理器，點擊詳細信息，找到所有的 nginx.exe 停止運行，並清理瀏覽器上的緩存，重啟 nginx 伺服器。
5.若以上操作均沒有問題，那麼最後可能導致的原因是防火牆，檢查防火牆是否關閉。
9. 安全開發運維必備的Nginx代理Web伺服器性能優化與安全加固配置
為了更好的指導部署與測試藝術升系統nginx網站伺服器高性能同時下安全穩定運行,需要對nginx服務進行調優與加固;
本次進行Nginx服務調優加固主要從以下幾個部分：
本文檔僅供內部使用，禁止外傳，幫助研發人員，運維人員對系統長期穩定的運行提供技術文檔參考。
Nginx是一個高性能的HTTP和反向代理伺服器，也是一個IMAP/POP3/SMTP伺服器。Nginx作為負載均衡伺服器, Nginx 既可以在內部直接支持 Rails 和 PHP 程序對外進行服務，也可以支持作為 HTTP代理伺服器對外進行服務。
Nginx版本選擇:
項目結構:
Nginx文檔幫助: http://nginx.org/en/docs/
Nginx首頁地址目錄: /usr/share/nginx/html
Nginx配置文件:
localtion 請求匹配的url實是一個正則表達式:
Nginx 匹配判斷表達式:
例如,匹配末尾為如下後綴的靜態並判斷是否存在該文件, 如不存在則404。
查看可用模塊編譯參數：http://nginx.org/en/docs/configure.html
http_gzip模塊
開啟gzip壓縮輸出(常常是大於1kb的靜態文件)，減少網路傳輸;
http_fastcgi_mole模塊
nginx可以用來請求路由到FastCGI伺服器運行應用程序由各種框架和PHP編程語言等。可以開啟FastCGI的緩存功能以及將靜態資源進行剝離，從而提高性能。
keepalive模塊
長連接對性能有很大的影響，通過減少CPU和網路開銷需要開啟或關閉連接;
http_ssl_mole模塊
Nginx開啟支持Https協議的SSL模塊
Linux內核參數部分默認值不適合高並發,Linux內核調優，主要涉及到網路和文件系統、內存等的優化，
下面是我常用的內核調優配置：
文件描述符
文件描述符是操作系統資源，用於表示連接、打開的文件，以及其他信息。NGINX 每個連接可以使用兩個文件描述符。
例如如果NGINX充當代理時，通常一個文件描述符表示客戶端連接，另一個連接到代理伺服器，如果開啟了HTTP 保持連接，這個比例會更低（譯註：為什麼更低呢）。
對於有大量連接服務的系統，下面的設置可能需要調整一下：
精簡模塊:Nginx由於不斷添加新的功能，附帶的模塊也越來越多,建議一般常用的伺服器軟體使用源碼編譯安裝管理;
(1) 減小Nginx編譯後的文件大小
(2) 指定GCC編譯參數
修改GCC編譯參數提高編譯優化級別穩妥起見採用 -O2 這也是大多數軟體編譯推薦的優化級別。
GCC編譯參數優化 [可選項] 總共提供了5級編譯優化級別：
常用編譯參數:
緩存和壓縮與限制可以提高性能
NGINX的一些額外功能可用於提高Web應用的性能，調優的時候web應用不需要關掉但值得一提，因為它們的影響可能很重要。
簡單示例:
1) 永久重定向
例如，配置 http 向 https 跳轉 (永久)
nginx配置文件指令優化一覽表
描述:Nginx因為安全配置不合適導致的安全問題,Nginx的默認配置中存在一些安全問題,例如版本號信息泄露、未配置使用SSL協議等。
對Nginx進行安全配置可以有效的防範一些常見安全問題，按照基線標准做好安全配置能夠減少安全事件的發生,保證採用Nginx伺服器系統應用安全運行;
Nginx安全配置項：
溫馨提示: 在修改相應的源代碼文件後需重新編譯。
設置成功後驗證:
應配置非root低許可權用戶來運行nginx服務,設置如下建立Nginx用戶組和用戶，採用user指令指運行用戶
加固方法:
我們應該為提供的站點配置Secure Sockets Layer Protocol (SSL協議)，配置其是為了數據傳輸的安全，SSL依靠證書來驗證伺服器的身份，並為瀏覽器和伺服器之間的通信加密。
不應使用不安全SSLv2、SSLv3協議即以下和存在脆弱性的加密套件(ciphers), 我們應該使用較新的TLS協議也應該優於舊的,並使用安全的加密套件。
HTTP Referrer Spam是垃圾信息發送者用來提高他們正在嘗試推廣的網站的互聯網搜索引擎排名一種技術，如果他們的垃圾信息鏈接顯示在訪問日誌中，並且這些日誌被搜索引擎掃描，則會對網站排名產生不利影響
加固方法:
當惡意攻擊者採用掃描器進行掃描時候利用use-agent判斷是否是常用的工具掃描以及特定的版本,是則返回錯誤或者重定向;
Nginx支持webdav，雖然默認情況下不會編譯。如果使用webdav，則應該在Nginx策略中禁用此規則。
加固方法: dav_methods 應設置為off
當訪問一個特製的URL時，如"../nginx.status"，stub_status模塊提供一個簡短的Nginx伺服器狀態摘要,大多數情況下不應啟用此模塊。
加固方法：nginx.conf文件中stub_status不應設置為：on
如果在瀏覽器中出現Nginx自動生成的錯誤消息，默認情況下會包含Nginx的版本號,這些信息可以被攻擊者用來幫助他們發現伺服器的潛在漏洞
加固方法: 關閉"Server"響應頭中輸出的Nginx版本號將server_tokens應設置為：off
client_body_timeout設置請求體（request body）的讀超時時間。僅當在一次readstep中，沒有得到請求體，就會設為超時。超時後Nginx返回HTTP狀態碼408(Request timed out)。
加固方法：nginx.conf文件中client_body_timeout應設置為：10
client_header_timeout設置等待client發送一個請求頭的超時時間（例如：GET / HTTP/1.1）。僅當在一次read中沒有收到請求頭，才會設為超時。超時後Nginx返回HTTP狀態碼408(Request timed out)。
加固方法：nginx.conf文件中client_header_timeout應設置為：10
keepalive_timeout設置與client的keep-alive連接超時時間。伺服器將會在這個時間後關閉連接。
加固方法：nginx.conf文件中keepalive_timeout應設置為：55
send_timeout設置客戶端的響應超時時間。這個設置不會用於整個轉發器，而是在兩次客戶端讀取操作之間。如果在這段時間內，客戶端沒有讀取任何數據，Nginx就會關閉連接。
加固方法：nginx.conf文件中send_timeout應設置為：10
GET和POST是Internet上最常用的方法。Web伺服器方法在RFC 2616中定義禁用不需要實現的可用方法。
加固方法:
limit_zone 配置項限制來自客戶端的同時連接數。通過此模塊可以從一個地址限制分配會話的同時連接數量或特殊情況。
加固方法：nginx.conf文件中limit_zone應設置為：slimits $binary_remote_addr 5m
該配置項控制一個會話同時連接的最大數量，即限制來自單個IP地址的連接數量。
加固方法：nginx.conf 文件中 limit_conn 應設置為: slimits 5
加固方法：
加固方法:
解決辦法:
描述後端獲取Proxy後的真實Client的IP獲取需要安裝--with-http_realip_mole，然後後端程序採用JAVA(request.getAttribute("X-Real-IP"))進行獲取;
描述: 如果要使用geoip地區選擇,我們需要再nginx編譯時加入 --with-http_geoip_mole 編譯參數。
描述: 為了防止外部站點引用我們的靜態資源，我們需要設置那些域名可以訪問我們的靜態資源。
描述: 下面收集了Web服務中常規的安全響應頭, 它可以保證不受到某些攻擊,建議在指定的 server{} 代碼塊進行配置。
描述: 為了防止某些未備案的域名或者惡意鏡像站域名綁定到我們伺服器上, 導致伺服器被警告關停，將會對業務或者SEO排名以及企業形象造成影響，我們可以通過如下方式進行防範。
執行結果:
描述: 有時你的網站可能只需要被某一IP或者IP段的地址請求訪問，那麼非白名單中的地址訪問將被阻止訪問, 我們可以如下配置;
常用nginx配置文件解釋：
(1) 阿里巴巴提供的Concat或者Google的PageSpeed模塊實現這個合並文件的功能。
(2) PHP-FPM的優化
如果您高負載網站使用PHP-FPM管理FastCGI對於PHP-FPM的優化非常重要
(3) 配置Resin on Linux或者Windows為我們可以打開 resin-3.1.9/bin/httpd.sh 在不影響其他代碼的地方加入:-Dhttps.protocols=TLSv1.2, 例如
原文地址: https://blog.weiyigeek.top/2019/9-2-122.html