nginx過濾http請求

① 如何用nginx 規則來屏蔽某個URL刷量

如果看nginx日誌有url來源指向的話，可以用下面的例子：

if ($http_referer ~* "http://xxxxxx.com") { return 444; }

將其放入NGINX配置文件的HTTP段或者SERVER段落內。

當然，這里也有人遇到跟你類似的問題可以看下網頁鏈接

② 怎樣隱藏HTTP請求響應頭里的nginx版本號

1、進入nginx配置文件（如nginx.conf）並增加 server_tokens off;server_tokens作用域是http server location語句塊，server_tokens默認值是on，表示顯示版本信息，設置server_tokens值是off，就可以在所有地方隱藏nginx的版本信息。例如
http {
……省略
sendfile on;
tcp_nopush on;
keepalive_timeout 60;
tcp_nodelay on;
server_tokens off;
…….省略
}
2、編輯php-fpm配置文件，如fastcgi.conf或fcgi.conf（這個配置文件名也可以自定義的，根據具體文件名修改）：
找到：
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;
改為：
fastcgi_param SERVER_SOFTWARE nginx;
3、重啟nginx 重新載入配置文件後，nginx版本號已經隱藏。

③ nginx+lua怎樣實現http請求的響應

來在 ngx_lua 中訪問 NginX 內置變源量 ngx.var.arg_PARAMETER 即可獲得GET參數PARAMETER的內容。

如何獲取POST請求體數據？

要獲得完整的POST請求體數據，可以訪問 NginX 內置變數 ngx.var.request_body（注意：由於 NginX 默認在處理請求前不自動讀取 request body，所以目前必須顯式藉助 form-input-nginx 模塊才能從該變數得到請求體，否則該變數內容始終為空！）。如果想獲取 POST 方式提交的表單參數，還可以藉助 form-input-nginx 模塊省去解析過程

④ 如何做nginx區分http和http請求

//請求頭
4 ngx_buf_t *header_in;
5
6 ngx_http_headers_in_t headers_in;
7 ngx_http_headers_out_t headers_out;
8 //請求體
9 ngx_http_request_body_t *request_body;
10 //請求行
11 ngx_uint_t method;
12 ngx_uint_t http_version;
13
14 ngx_str_t request_line;
15 ngx_str_t uri;
16 ngx_str_t args;
17 ngx_str_t exten;
18 ngx_str_t unparsed_uri;
19
20 ngx_str_t method_name;
21 ngx_str_t http_prot

⑤ Nginx 反向代理可以緩存 HTTP POST 請求頁面嗎

沒配置 DOWN 掉 post請求應用伺服器掛掉請求失敗

⑥ 如何利用nginx

使用的環境是64位 Ubuntu 14.04。nginx依賴以下模塊：

l gzip模塊需要 zlib 庫

l rewrite模塊需要 pcre 庫

l ssl 功能需要openssl庫

1.1.安裝pcre
1. 獲取pcre編譯安裝包，在http://www.pcre.org/上可以獲取當前最新的版本

2. 解壓縮pcre-xx.tar.gz包。

3. 進入解壓縮目錄，執行./configure。

4. make & make install

1.2.安裝openssl
1. 獲取openssl編譯安裝包，在http://www.openssl.org/source/上可以獲取當前最新的版本。

2. 解壓縮openssl-xx.tar.gz包。

3. 進入解壓縮目錄，執行./config。

4. make & make install

1.3.安裝zlib
1. 獲取zlib編譯安裝包，在http://www.zlib.net/上可以獲取當前最新的版本。

2. 解壓縮openssl-xx.tar.gz包。

3. 進入解壓縮目錄，執行./configure。

4. make & make install

1.4.安裝nginx
1. 獲取nginx，在http://nginx.org/en/download.html上可以獲取當前最新的版本。

2. 解壓縮nginx-xx.tar.gz包。

3. 進入解壓縮目錄，執行./configure

4. make & make install

若安裝時找不到上述依賴模塊，使用--with-openssl=<openssl_dir>、--with-pcre=<pcre_dir>、--with-zlib=<zlib_dir>指定依賴的模塊目錄。如已安裝過，此處的路徑為安裝目錄；若未安裝，則此路徑為編譯安裝包路徑，nginx將執行模塊的默認編譯安裝。

啟動nginx之後，瀏覽器中輸入http://localhost可以驗證是否安裝啟動成功。

clip_image002

2.Nginx配置

安裝完成之後，配置目錄conf下有以下配置文件，過濾掉了xx.default配置：

tyler@ubuntu:/opt/nginx-1.7.7/conf$ tree |grep -v default
.
├── fastcgi.conf
├── fastcgi_params
├── koi-utf
├── koi-win
├── mime.types
├── nginx.conf
├── scgi_params
├── uwsgi_params
└── win-utf
除了nginx.conf，其餘配置文件，一般只需要使用默認提供即可。

2.1.nginx.conf
nginx.conf是主配置文件，默認配置去掉注釋之後的內容如下圖所示：

l worker_process表示工作進程的數量，一般設置為cpu的核數

l worker_connections表示每個工作進程的最大連接數

l server{}塊定義了虛擬主機

n listener監聽埠

n server_name監聽域名

n location{}是用來為匹配的 URI 進行配置，URI 即語法中的「/uri/」。location / { }匹配任何查詢，因為所有請求都以 / 開頭。

u root指定對應uri的資源查找路徑，這里html為相對路徑，完整路徑為/opt/ opt/nginx-1.7.7/html/

u index指定首頁index文件的名稱，可以配置多個，以空格分開。如有多個，按配置順序查找。

clip_image004

從配置可以看出，nginx監聽了80埠、域名為localhost、跟路徑為html文件夾（我的安裝路徑為/opt/nginx-1.7.7，所以/opt/nginx-1.7.7/html）、默認index文件為index.html， index.htm、伺服器錯誤重定向到50x.html頁面。

可以看到/opt/nginx-1.7.7/html/有以下文件：

tyler@ubuntu:/opt/nginx-1.7.7/html$ ls
50x.html index.html
這也是上面在瀏覽器中輸入http://localhost，能夠顯示歡迎頁面的原因。實際上訪問的是/opt/nginx-1.7.7/html/index.html文件。

2.2.mime.types
文件擴展名與文件類型映射表，nginx根據映射關系，設置http請求響應頭的Content-Type值。當在映射表找不到時，使用nginx.conf中default-type指定的默認值。例如，默認配置中的指定的default-type為application/octet-stream。

include mime.types;
default_type application/octet-stream;
默認

下面截一段mime.types定義的文件擴展名與文件類型映射關系，完整的請自行查看：

clip_image005

2.3.fastcgi_params
nginx配置Fastcgi解析時會調用fastcgi_params配置文件來傳遞伺服器變數，這樣CGI中可以獲取到這些變數的值。默認傳遞以下變數：

clip_image006

這些變數的作用從其命名可以看出。

2.4.fastcgi.conf
對比下fastcgi.conf與fastcgi_params文件，可以看出只有以下差異：

tyler@ubuntu:/opt/nginx-1.7.7/conf$ diff fastcgi.conf fastcgi_params
2d1
< fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
即fastcgi.conf只比fastcgi_params多了一行「fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;」

原本只有fastcgi_params文件，fastcgi.conf是nginx 0.8.30 (released: 15th of December 2009)才引入的。主要為是解決以下問題（參考：http://www.dwz.cn/x3GIJ）：

原本Nginx只有fastcgi_params，後來發現很多人在定義SCRIPT_FILENAME時使用了硬編碼的方式。例如，fastcgi_param SCRIPT_FILENAME /var/www/foo$fastcgi_script_name。於是為了規范用法便引入了fastcgi.conf。

不過這樣的話就產生一個疑問：為什麼一定要引入一個新的配置文件，而不是修改舊的配置文件？這是因為fastcgi_param指令是數組型的，和普通指令相同的是：內層替換外層；和普通指令不同的是：當在同級多次使用的時候，是新增而不是替換。換句話說，如果在同級定義兩次SCRIPT_FILENAME，那麼它們都會被發送到後端，這可能會導致一些潛在的問題，為了避免此類情況，便引入了一個新的配置文件。

因此不再建議大家使用以下方式（搜了一下，網上大量的文章，並且nginx.conf的默認配置也是使用這種方式）：

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

include fastcgi_params;

而使用最新的方式：

include fastcgi.conf;

2.5.uwsgi_params
與fastcgi_params一樣，傳遞哪些伺服器變數，只有前綴不一樣，以uwsgi_param開始而非fastcgi_param。

2.6.scgi_params
與fastcgi_params一樣，傳遞哪些伺服器變數，只有前綴不一樣，以uwsgi_param開始而非fastcgi_param。

2.7.koi-utf、koi-win、win-utf
這三個文件都是與編碼轉換映射文件，用於在輸出內容到客戶端時，將一種編碼轉換到另一種編碼。

koi-win： charset_map koi8-r < -- > windows-1251

koi-utf： charset_map koi8-r < -- > utf-8

win-utf： charset_map windows-1251 < -- > utf-8

koi8-r是斯拉夫文字8位元編碼，供俄語及保加利亞語使用。在Unicode未流行之前，KOI8-R 是最為廣泛使用的俄語編碼，使用率甚至起ISO/IEC 8859-5還高。這3個文件存在是因為作者是俄國人的原因。

⑦ 如何去掉nginx 的http 方法delete，put

一般來說，Web伺服器默認的只支持Post和Get這兩種「只讀」的請求方法。但是隨著Ajax XMLHttpRequest 和 REST風格應用的深入，我們發現Http 1.1協議還支持如下請求方法（Request Method）：

OPTIONS

HEAD

DELETE

PUT

TRACE

CONNECT

Get是最常用的，就是向Web Server發請求「獲取」資源；那麼Post就是向Web Server「郵寄」一些封裝的數據包獲取資源，這兩者方法嚴格的說都是「索取」行為。

顧名思義，Delete方法就是通過http請求刪除指定的URL上的資源啦，Delete請求一般會返回3種狀態碼：

200 (OK) - 刪除成功，同時返回已經刪除的資源

202 (Accepted) - 刪除請求已經接受，但沒有被立即執行（資源也許已經被轉移到了待刪除區域）

204 (No Content) - 刪除請求已經被執行，但是沒有返回資源（也許是請求刪除不存在的資源造成的）

Put方法就不多廢話了，就是往Web Server上直接扔資源（上傳資源）嘛，不過實際操作起來可能會讓諸位看官喝一壺，E文定義如下：

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI,

it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server.

HTTP/1.1 does not define how a PUT method affects the state of an origin server.

PUT requests MUST obey the message transmission requirements set out in section 8.2.

Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT.

上面說的都是虛的，實戰才是硬道理！

（本文始發於CSDN，作者胡奇的博客：http://blog.csdn.net/kthq ）

首先，我們要讓Web Server支持Delete 和 Put請求方法，以大家熟悉的Tomcat為例：

在Tomcat的web.xml 文件中配置 org.apache.catalina.servlets.DefaultServlet 的初始化參數

[xhtml] view plain

<init-param>

<param-name>readonly</param-name>

<param-value>false</param-value>

</init-param>

readonly參數默認是true，即不允許delete和put操作，所以默認的通過XMLHttpRequest對象的put或者delete方法訪問就會報告 http 403 forbidden 錯誤。

接下來，從客戶端通過 Ajax XMLHTTPRequest 發起 DELETE/PUT 請求：

⑧ nginx 過濾非法請求 有access日誌嗎

nginx的log日誌分為access log 和 error log

其中access log 記錄了哪些用戶，哪些頁面以及用戶瀏覽器、ip和其他的訪問信息

error log 則是記錄伺服器錯誤日誌

錯誤日誌的形式如下：

201.158.69.116 - - [03/Jan/2013:21:17:20 -0600] fwf[-] tip[-] 127.0.0.1:9000 0.007 0.007 MX pythontab.com GET /html/test.html HTTP/1.1 "200" 2426 "http://a.com" "es-ES,es;q=0.8" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11"
187.171.69.177 - - [03/Jan/2013:21:17:20 -0600] fwf[-] tip[-] 127.0.0.1:9000 0.006 0.006 MX pythontab.com GET /html/test2.html HTTP/1.1 "200" 2426 "http://a.com" "es-ES,es;q=0.8" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11"

從上面我們可以看出幾部分信息：

1.客戶端（用戶）IP地址。如：上例中的 201.158.69.116
2.訪問時間。如：上例中的 [03/Jan/2013:21:17:20 -0600]
3.訪問埠。如：上例中的 127.0.0.1:9000
4.響應時間。如：上例中的 0.007
5.請求時間。如：上例中的 0.007
6.用戶地理位置代碼（國家代碼）。如：上例中的 MX（墨西哥）
7.請求的url地址（目標url地址）的host。如：上例中的 pythontab.com
8.請求方式（GET或者POST等）。如：上例中的 GET
9.請求url地址（去除host部分）。如：上例中的 /html/test.html
10.請求狀態（狀態碼，200表示成功，404表示頁面不存在，301表示永久重定向等，具體狀態碼可以在網上找相關文章，不再贅述）。如：上例中的 "200"
11.請求頁面大小，默認為B（byte）。如：上例中的 2426
12.來源頁面，即從哪個頁面轉到本頁，專業名稱叫做「referer」。如：上例中的 "http://a.com"
13.用戶瀏覽器語言。如：上例中的 "es-ES,es;q=0.8"
14.用戶瀏覽器其他信息，瀏覽器版本、瀏覽器類型等。如：上例中的 "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11"

其實nginx access日誌的格式不是一成不變的，是可以自定義的。

在nginx的nginx.conf配置文件找到：log_format 這里就是日誌的格式

看一下和上述日誌匹配的log格式設置：

#access日誌格式配置，具體參數不再細說，上面都已經說過了，自己對應一下即可
log_format main '$remote_addr - $remote_user [$time_local] '
'fwf[$http_x_forwarded_for] tip[$http_true_client_ip] '
'$upstream_addr $upstream_response_time $request_time '
'$geoip_country_code '
'$http_host $request '
'"$status" $body_bytes_sent "$http_referer" '
'"$http_accept_language" "$http_user_agent" ';

#配置access log日誌的存儲位置及文件，注意：access.log文件是可以按日期進行分割的，方便查看及處理
access_log /home/serversoft/nginx/log/access.log main;

⑨ nginx正則過濾$http_cookie欄位。將其 非test_cookie鍵值對的 所有cookie值都匹配到$my_cookie變數中

|代碼原本是這樣的吧：newRegExp("(^|)"+name+"=([^;]*)(;|$)")，name前後有+"(^|)"這個匹配開頭和空格cookie的保存方式：name=value，有多個cookie時用分內號空格隔開：容cookieaa=aaaa;cookiebb=bbbb如果name值為cookieaa，完整的正則為(^|)cookieaa=([^;]*)(;|$)匹配結果：cookieaa=aaaa;

⑩ nginx負載剔除後http連接會關閉嗎

本章主要介紹Nginx的配置管理和使用。作為一個輕量級的HTTP伺服器
，Nginx與Apache相比有以下優勢：在性能上，它佔用很少的系統資源，能支持更多的並發連接，達到更高的訪問效率：在功能上，Nginx是優秀的代理伺服器和負載均衡伺服器：在安裝配置上，Nginx安裝簡單、配置靈活。下面就詳細介紹Nginx的配置與使用。
相信很多讀者都對Apache非常熟悉，Nginx與Apache類似，也是一款高性能的HTTP和反向代理伺服器軟體，還是一個IMAP/POP3/SMTP代理伺服器。Nginx(發音是enginex)由俄羅斯的程序設計師Igor Sysoev開發（Igor將源代碼以類BSD許可證的形式發布）．可以運行在UNIX、GNU/Linux、BSD、Mac OS X、Solaris以及Microsoft Windows等操作系統中。隨著Nginx在很多大型網站的廣泛使用，其穩定、高效的特性逐漸被越來越多的用戶認可。
Nginx與Apache的異同