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的异同