Nginx中的Location指令基础-在nginx上处理一次小型的ddos事...-nginx配置url重写及自定义404错误页面等

当前位置: 操作系统/服务器>linux

本页文章导读:

▪Nginx中的Location指令基础介绍： Nginx 中的 Location 指令是NginxHttpCoreModule中重要指令。Location 指令比较简单，但却是配置 Nginx 过程中不得不去了解的。 Location 指令，是用来为匹配的 URI 进行配置，URI 即语法中的"/uri/".........

▪在nginx上处理一次小型的ddos事件 nginx的负载能力超强，一般小的ddos是无法击垮一台nginx代理的，所以用nginx来过滤掉一些小型的ddos是完全没有问题。早上同事负责的一台服务器当机，重起之后又挂掉，他检查过后发现是有一.........

▪nginx配置url重写及自定义404错误页面等一、nginx禁止与允许IP访问服务代码如下: location / { allow 122.234.54.116; deny all; index index.html index.htm index.php; if (!-e $request_filename){ rewrite ^(.*)$ /index.php?s=$1 last; .........

[1]Nginx中的Location指令基础

来源: 互联网发布时间: 2013-12-24

介绍：
Nginx 中的 Location 指令是NginxHttpCoreModule中重要指令。Location 指令比较简单，但却是配置 Nginx 过程中不得不去了解的。
Location 指令，是用来为匹配的 URI 进行配置，URI 即语法中的"/uri/"，可以是字符串或正则表达式。但如果要使用正则表达式，则必须指定前缀。

一、基本语法

location [=|~|~*|^~|@] /uri/ { … }

〖=〗表示精确匹配，如果找到，立即停止搜索并立即处理此请求。
〖~ 〗表示区分大小写匹配
〖~*〗表示不区分大小写匹配
〖^~ 〗表示只匹配字符串,不查询正则表达式。
〖@〗指定一个命名的location，一般只用于内部重定向请求。

二、匹配过程

首先对字符串进行匹配查询，最确切的匹配将被使用。然后，正则表达式的匹配查询开始，匹配第一个结果后会停止搜索，如果没有找到正则表达式，将使用字符串的搜索结果，如果字符串和正则都匹配，那么正则优先级较高。

三、配置实例

代码如下:

location = / {
# 只匹配对 / 目录的查询.
[ config A ]
}
location / {
# 匹配以 / 开始的查询，即所有查询都匹配。
[ config B ]
}
location ^~ /images/ {
# 匹配以 /images/ 开始的查询，不再检查正则表达式。
[ config C ]
}
location ~* \.(gif|jpg|jpeg)$ {
# 匹配以gif, jpg, or jpeg结尾的文件，但优先级低于config C。
[ config D ]
}

四、全局变量

$args #这个变量等于请求行中的参数。
$content_length #请求头中的Content-length字段。
$content_type #请求头中的Content-Type字段。
$document_root #当前请求在root指令中指定的值。
$host #请求主机头字段，否则为服务器名称。
$http_user_agent #客户端agent信息
$http_cookie #客户端cookie信息
$limit_rate #这个变量可以限制连接速率。
$request_body_file #客户端请求主体信息的临时文件名。
$request_method #客户端请求的动作，通常为GET或POST。
$remote_addr #客户端的IP地址。
$remote_port #客户端的端口。
$remote_user #已经经过Auth Basic Module验证的用户名。
$request_filename #当前请求的文件路径，由root或alias指令与URI请求生成。
$query_string #与$args相同。
$scheme #HTTP方法（如http，https）。
$server_protocol #请求使用的协议，通常是HTTP/1.0或HTTP/1.1。
$server_addr #服务器地址，在完成一次系统调用后可以确定这个值。
$server_name #服务器名称。
$server_port #请求到达服务器的端口号。
$request_uri #包含请求参数的原始URI，不包含主机名，如：”/foo/bar.php?arg=baz”。
$uri #不带请求参数的当前URI，$uri不包含主机名，如”/foo/bar.html”。
$document_uri #与$uri相同。

[2]在nginx上处理一次小型的ddos事件

来源: 互联网发布时间: 2013-12-24

nginx的负载能力超强，一般小的ddos是无法击垮一台nginx代理的，所以用nginx来过滤掉一些小型的ddos是完全没有问题。

早上同事负责的一台服务器当机，重起之后又挂掉，他检查过后发现是有一个链接的访问量很大。

看了一下，因为这个项目不是公司的项目，所以应用服务器是Windows+IIS，架构采用的是app_squid架构。因为那个访问量大的链接业务上必须加上no-cache头，所以全部透入后台应用服务器，应用服务器招架不住所以频频出问题。

对IIS根本不熟，况且那台应用服务器已经基本没法正常服务，所以我就在cache上把受攻击的域名指向中层代理，中层代理再转发到应用服务器。这样架构变成了app_nginx_squid架构，然后我就好正常地开始分析。

先打开日志，看看到底是怎么回事，看过之后发现确实是有一个链接访问量很大，用命令行统计一下，发现这个链接是正常的所有访问请求100倍之多。由上可知，确实就是这个链接访问量超大引起问题，但是这些访问量是不是正常的呢？从它的ip看，并不是同一个ip，这就比较难判断了，如果确实是真实流量，我把它毙掉，那就会有人要追杀我了。

具体原因的干脆先不查，我把它的no-cache头先干掉好了，这样至少不会死机。作为维护人员，那肯定先要想办法让网站正常服务，然后才能去找原因的。

proxy_hide_header Cache-Control;

嗯，这下这个链接就缓存到前端squid了，应用服务器不会死机了，不过这只是临时方法，不是长久之计，因为这样做影响了业务功能。

所以继续分析日志，多加了几项参数到日志中，这时看到这些大量的请求有一个共同点，那就是user-agent都是一样的，都是MSIE 5.01，而IE5并不是主流浏览器。这样看来，这些请求都是同一个客户端恶意发起的，不知道是用了什么垃圾软件。

找到了原因和特征，当然就可以配置把它干掉了，判断一下user-agent，如果是MSIE 5.01就把它丢到另外一个地方去就可以了，比如指向sudone.com，看看能不能抗得住？

代码如下:

location = /v2/index.php {
include proxy.conf;
if ( $http_user_agent ~* "MSIE 5.01" ) {
proxy_pass http://www.;
#access_log /home/logs/1.log main;
}
proxy_pass http://iis.xxx.com;
}

最后开回Cache-Control，访问一下页面，嗯，这回一切正常，业务也没有被修改。

[3]nginx配置url重写及自定义404错误页面等

来源: 互联网发布时间: 2013-12-24

一、nginx禁止与允许IP访问服务

代码如下:

location / {
   allow 122.234.54.116;
   deny   all;
   index index.html index.htm index.php;
   if (!-e $request_filename){
      rewrite ^(.*)$ /index.php?s=$1 last;
       break;
}
}

二、装了NGINX1.0.8 不能访问PHP文件
原因：这个主要是PHP的解析脚本路径找不到

代码如下:

location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}

三、nginx下自定义404页面

IIS和APACHE下自定义404页面的经验介绍文章已经非常多了，NGINX的目前还比较少，为了解决自家的问题特地对此作了深入的研究。研究结果表明，NGINX下配置自定义的404页面是可行的，而且很简单，只需如下几步：
1. 创建自己的404.php页面
2. 更改nginx.conf在http定义区域加入： fastcgi_intercept_errors on;
3. 更改nginx.conf（或单独网站配置文件，例如在nginx -> sites -enabled下的站点配置文件）中在server 区域加入： error_page 404 = /404.php; 或者 error_page 404 = http://www.xxx.com/404.html ;

四、让Nginx支持shtml格式
发现包括IIS在内的大多数处理服务器，都是默认不支持shtml的，nginx支持shtml的方法为：
在nginx.conf配置文件，添加：

代码如下:

ssi on;
ssi_silent_errors on;
ssi_types text/shtml;

保存，重启nginx。

在上传时nginx返回了413错误，查看log文件，显示的错误信息是:”413 Request Entity Too Large”, 于是在网上找了下“nginx 413错误”发现需要做以下设置：

在nginx.conf增加 client_max_body_size的相关设置, 这个值默认是1m，可以增加到8m以增加提高文件大小限制；

client_max_body_size 设置在 location ~ .*\.(php|php5)?$ 这个标签里，不管对配置文件做了什么改动，重启前要测试配置文件是否正确

如果运行的是php，那么还要检查php.ini，这个大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大，这样就不会因为提交数据大小不一致出现的错误。post_max_size = 8M
upload_max_filesize = 2M

五、nginx下配置 thinkphp URL重写此配置是vhost中的

代码如下:

server
{
listen       80;
server_name my.ai9475.com;
index index.html index.htm index.php;
root /home/renshi/;

error_page 404 = /404.php;

location / {
         index index.html index.htm index.php;
         if (!-e $request_filename){
rewrite ^(.*)$ /index.php?s=$1 last;
break;
         }
         }

location ~ .*\.(php|php5)?$
     {
         fastcgi_pass unix:/tmp/php-cgi.sock;
         fastcgi_index index.php;
         include fcgi.conf;
     }

location /status {
     stub_status on;
     access_log   off;
}

location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
     {
         expires      30d;
     }

location ~ .*\.(js|css)?$
     {
         expires      12h;
     }

error_log logs/nginx_error_renshi.log error;
}

您可能感兴趣的文章：

nginx rewrite(nginx url地址重写)的配置示例
nginx实现url重写-rewrite实例参考
nginx中一些常用的 URL 重写方法
Nginx常用的 URL 重写方法
超详细的 NGINX URL重写实例讲解