Nginx的Rewrite设置及示例

出处：http://shunz.net/2008/07/nginx_rewrite.html
Nginx以其良好的并发性能，目前正在逐渐取代Apache成为大家的Web server首选，但是Nginx目前的中文资料很少，需要大家努力贡献。

下面我介绍一下Nginx的Rewrite模块设置及Wordpress和Discuz的示例。Nginx的Rewrite规则比Apache的简单灵活多了，从下面介绍可见一斑。

首先，Nginx可以用if进行条件匹配，语法规则类似C，举例如下：

if ($http_user_agent ~ MSIE) {rewrite  ^(.*)$  /msie/$1  break;}1、正则表达式匹配，其中：

~  为区分大小写匹配
~* 为不区分大小写匹配
!~和!~*分别为区分大小写不匹配及不区分大小写不匹配
2、文件及目录匹配，其中：

-f和!-f用来判断是否存在文件
-d和!-d用来判断是否存在目录
-e和!-e用来判断是否存在文件或目录
-x和!-x用来判断文件是否可执行
如：

if (!-f $request_filename) {proxy_pass  http://127.0.0.1;}其次，Nginx的Rewrite规则与Apache几乎完全一致，所不同的是最后的flag标记，举例如下：

rewrite ^/feed/$ http://feed.shunz.net last;

flag标记有：

last 相当于Apache里的[L]标记，表示完成rewrite，不再匹配后面的规则
break 与last类似
redirect 返回302临时重定向
permanent 返回301永久重定向
Wordpress的重定向规则：

if (!-e $request_filename) {rewrite ^/(index|atom|rsd)\.xml$ http://feed.shunz.net last;rewrite ^([_0-9a-zA-Z-]+)?(/wp-.*) $2 last;rewrite ^([_0-9a-zA-Z-]+)?(/.*\.php)$ $2 last;rewrite ^ /index.php last;}

nginx 访问需要用户验证

1 首先需要安装apache，可以使用yum install 安装
2 生成密码文件，创建用户
htpasswd -c /usr/local/nginx/conf/htpasswd  test // 添加test用户，第一次添加时需要加-c参数，第二次添加时不需要-c参数
3 在nginx的配置文件中添加
location  / {
                      root /data/www/wwwroot/count;
                      auth_basic              "Auth";
                      auth_basic_user_file   /usr/local/nginx/conf/htpasswd;
            }

Nginx出现413 Request Entity Too Large得解决方法

解决方法：打开nginx主配置文件nginx.conf，找到http{}段，添加
client_max_body_size 20m;

nginx 日志切割（按小时）

vim /usr/local/nginx/sbin/log.conf  //写入以下内容

rotate 48
nocompress

/home/logs/access.log {
    sharedscripts
    create 0644 www www
    postrotate
        /bin/kill -USR1 `cat /usr/local/nginx/var/nginx.pid`
        LDATE=`date +%Y%m%d%H --date="-1 hour"`
        /bin/mv /home/logs/access.log.1 /home/logs/${LDATE}-access_log
    endscript
}

nginx整套pdf電子文檔，挺不錯的

不說廢話了 直接上傳了，第一章是介紹Nignx 和Nginx和其他web server性能對比的個人認為實用性不強就不上傳了，第13章是HTTP模塊 因為太大了 就不傳了，其實說白了，大家把前幾章搞懂了 就已經不錯了，如果有朋友需要第一章和第十三章的朋友可以留下email或者向我索取，我的email:[email protected]

nginx禁止某个IP或者IP段访问站点的设置方法

首先建立下面的配置文件放在nginx的conf目录下面,命名为deny.ip   
cat  deny.ip
deny 192.168.1.11;
deny 192.168.1.123;
deny 10.0.1.0/24;

在nginx的配置文件nginx.conf中加入：include deny.ip;

重启一下nginx的服务：/usr/local/nginx/sbin/nginx  reload 就可以生效了。

deny.ip 的格式中也可以用deny all;
如果你想实现这样的应用，除了几个IP外，其他全部拒绝，
那需要你在deny.ip 中这样写
allow 1.1.1.1;
allow 1.1.1.2;
deny all;

禁止某个目录下php解析

location ~ .*abc/.*\.php?$
        {
         deny all;
        }

一个nginx 对多个fastcgi

应用的最前端是一台nginx服务器，所有静态的内容都由nginx来处理，而将所有php的请求都分摊到下游的若干台运行php fastcgi守护进程的服务器中，这样可以以一种廉价的方案来实现对系统负载的分摊，扩展系统的负载能力。

三台php fastcgi服务器的ip地址分别为：
172.16.236.110 , 172.16.236.111, 172.16.236.112

运行php fastcgi进程时，需要让php-cgi监听到服务器的局域网地址（分别如上所示），而不是之前一般都是监听的本地地址（127.0.0.1）。以172.16.236.110这台服务器为例：

/usr/local/php5/bin/php-cgi -b 172.16.236.110:9000

或许你用spawn-fcgi来启动php-fcgi，那么就是这样（供参考，其实也就是修改监听的地址和端口即可）：

/usr/local/lighttpd/bin/spawn-fcgi -f /usr/local/php5/bin/php-cgi -a 172.16.236.110 -p 9000

又或许你是用php-fpm来管理php-fcgi，那么你需要修改php-fpm的配置：

vi /usr/local/php5/etc/php-fpm.conf

找到这个配置项（其中的地址可能需要根据你自己环境来调整）

<value name="listen_address">127.0.0.1:9000</value>

修改为：

<value name="listen_address">172.16.236.110:9000</value>

修改完毕后，重启你的php-fpm进程。

然后按照上面的步骤，依次修改其他php fastcgi服务器。

php方面的工作暂时就是这些，下面修改nginx。

vi /usr/local/nginx/conf/nginx.conf

在配置文件的http段内增加类似如下的配置：

upstream myfastcgi {
        server 172.16.236.110 weight=1;
        server 172.16.236.111 weight=1;
        server 172.16.236.112 weight=1;
}

我这里三台php fastcgi服务器的权重是相同的，所以其中的weight值都是1，如果你的php fastcgi服务器需要分主次，那么可以通过调整其weight值来达到目的。比如以第一台服务器为主，其他两台为辅，则就是这样：

upstream myfastcgi {
        server 172.16.236.110 weight=1;
        server 172.16.236.111 weight=2;
        server 172.16.236.112 weight=2;
}

然后找到原来nginx关于php fastcgi配置的部分，比如：

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;
}

将其中的fastcgi_pass那一段改为：

fastcgi_pass myfastcgi;


转自：http://xuebingnanmm.javaeye.com/blog/686839

nginx 504 Gateway Time-out的一些方法

从错误代码基本可以确定跟nginx本身无关，主要是提交给php-fpm的请求未能正确反馈而导致，一般情况下，提交动态请求的时候，nginx会直接把请求转交给php-fpm，而php-fpm再分配php-cgi进程来处理相关的请求，之后再依次返回，最后由nginx把结果反馈给客户端浏览器，但我这个vps目前跑的是个纯php应用内容，实际上用户所有的请求都是php请求，有的耗费时间比较久，php-cgi进程就一直都被用满，而php-fpm本身的配置文件只打开了10组php-cgi进程，这样的话在线用户稍微多的话就会导致请求无法被正常处理而出错。

大概分析出了原因，下面做就比较容易了，首先是更改php-fpm的几处配置：

把max_children由之前的10改为现在的30，这样就可以保证有充足的php-cgi进程可以被使用；
把request_terminate_timeout由之前的0s改为60s，这样php-cgi进程处理脚本的超时时间就是60秒，可以防止进程都被挂起，提高利用效率。

接着再更改nginx的几个配置项，减少FastCGI的请求次数，尽量维持buffers不变：

fastcgi_buffers由 4 64k 改为 2 256k；
fastcgi_buffer_size由 64k 改为 128K；
fastcgi_busy_buffers_size 由 128K 改为 256K；
fastcgi_temp_file_write_size 由 128K 改为 256K。

Nginx启动脚本的编写

# vi /etc/init.d/nginx 写入
#!/bin/bash
# chkconfig: - 30 21
# description: http service.
# Source Function Library
. /etc/init.d/functions

# Nginx Settings
NGINX_SBIN="/usr/local/nginx/sbin/nginx"
NGINX_CONF="/usr/local/nginx/conf/nginx.conf"
NGINX_PID="/usr/local/nginx/var/nginx.pid"

RETVAL=0
prog="Nginx"

start() {
        echo -n $"Starting $prog: "
        mkdir -p /dev/shm/nginx_temp
        daemon $NGINX_SBIN -c $NGINX_CONF
        RETVAL=$?
        echo
        return $RETVAL
}

stop() {
        echo -n $"Stopping $prog: "
        killproc -p $NGINX_PID $NGINX_SBIN -TERM
        rm -rf /dev/shm/nginx_temp
        RETVAL=$?
        echo
        return $RETVAL
}

reload(){
        echo -n $"Reloading $prog: "
        killproc -p $NGINX_PID $NGINX_SBIN -HUP
        RETVAL=$?
        echo
        return $RETVAL
}

restart(){
        stop
        start
}

configtest(){
    $NGINX_SBIN -c $NGINX_CONF -t
    return 0
}

case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  reload)
        reload
        ;;
  restart)
        restart
        ;;
  configtest)
        configtest
        ;;
  *)
        echo $"Usage: $0 {start|stop|reload|restart|configtest}"
        RETVAL=1
esac

exit $RETVAL

# chmod 755 /etc/init.d/nginx

nginx限制只让某个ip访问

server
{
    listen       80;
    server_name  www.aldjflas.cn;
    access_log   /home/logs/bbs/access.log combined buffer=32k;
    error_log    /home/logs/bbs/error.log warn;
    index           index.html index.htm index.php;
    root            /data/www/wwwroot/bbs;
    allow          219.232.244.234;
    deny           all;
}

nginx 禁止通过ip访问站点

在server部分加如下代码：

server {
             listen 80 default;
             server_name  suibian.com;  #这里的域名可以乱填一个
             return 444;
     }

基于thinkphp框架开发的代码，nginx需要的配置

开发的人跟我说基于thinkphp框架开发的代码在apache下能用，在nginx下为什么用不了呢，总是提示404的错误，原来apache默认就支持thinkphp等所需的PATH_INFO，而nginx不可以，那么接下来，我们就配置一下nginx，让他支持PATH_INFO，我是这么做的：
        1，更改php.ini

           首先php.ini的配置中把

       ;cgi.fix_pathinfo=0   改为


      cgi.fix_pathinfo=1
        
         2，改nginx配置文件中php的location如下：
  
           location ~ \.php {
                fastcgi_pass unix:/dev/shm/php-fcgi.sock;
                fastcgi_index index.php;
                set $path_info "";
                set $real_script_name $fastcgi_script_name;
                if ($fastcgi_script_name ~ "^(.+?\.php)(/.+)$") {
                set $real_script_name $1;
                set $path_info $2;
                }
               fastcgi_param SCRIPT_FILENAME /data/www/wwwroot$real_script_name;
               fastcgi_param SCRIPT_NAME $real_script_name;
               fastcgi_param PATH_INFO $path_info;
               include  /usr/local/nginx/conf/fastcgi_params;
               }
      以前是这样的：
         location ~ \.php$ {
             include fastcgi_params;
             fastcgi_pass  unix:/tmp/php-fcgi.sock;
             fastcgi_index index.php;
             fastcgi_param SCRIPT_FILENAME /data/www/wwwroot$fastcgi_script_name;

nginx实现动静态负载均衡

具体请看帖子
http://mylinux.5d6d.com/viewthre ... mp;fromuid=1#pid526

nginx文件类型错误解析漏洞

漏洞介绍：nginx是一款高性能的web服务器，使用非常广泛，其不仅经常被用作反向代理，也可以非常好的支持PHP的运行。80sec发现其中存在一个较为严重的安全问题，默认情况下可能导致服务器错误的将任何类型的文件以PHP的方式进行解析，这将导致严重的安全问题，使得恶意的攻击者可能攻陷支持php的nginx服务器。


漏洞分析：nginx默认以cgi的方式支持php的运行，譬如在配置文件当中可以以


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

的方式支持对php的解析，location对请求进行选择的时候会使用URI环境变量进行选择，其中传递到后端Fastcgi的关键变量SCRIPT_FILENAME由nginx生成的$fastcgi_script_name决定，而通过分析可以看到$fastcgi_script_name是直接由URI环境变量控制的，这里就是产生问题的点。而为了较好的支持PATH_INFO的提取，在PHP的配置选项里存在cgi.fix_pathinfo选项，其目的是为了从SCRIPT_FILENAME里取出真正的脚本名。
那么假设存在一个http://www.80sec.com/80sec.jpg我们以如下的方式去访问

http://www.80sec.com/80sec.jpg/80sec.php

将会得到一个URI

/80sec.jpg/80sec.php

经过location指令，该请求将会交给后端的fastcgi处理，nginx为其设置环境变量SCRIPT_FILENAME，内容为

/scripts/80sec.jpg/80sec.php

而在其他的webserver如lighttpd当中，我们发现其中的SCRIPT_FILENAME被正确的设置为

/scripts/80sec.jpg

所以不存在此问题。
后端的fastcgi在接受到该选项时，会根据fix_pathinfo配置决定是否对SCRIPT_FILENAME进行额外的处理，一般情况下如果不对fix_pathinfo进行设置将影响使用PATH_INFO进行路由选择的应用，所以该选项一般配置开启。Php通过该选项之后将查找其中真正的脚本文件名字，查找的方式也是查看文件是否存在，这个时候将分离出SCRIPT_FILENAME和PATH_INFO分别为

/scripts/80sec.jpg和80sec.php

最后，以/scripts/80sec.jpg作为此次请求需要执行的脚本，攻击者就可以实现让nginx以php来解析任何类型的文件了。

POC： 访问一个nginx来支持php的站点，在一个任何资源的文件如robots.txt后面加上/80sec.php，这个时候你可以看到如下的区别：

访问http://www.80sec.com/robots.txt

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:05:30 GMT
Content-Type: text/plain
Content-Length: 18
Last-Modified: Thu, 20 May 2010 06:26:34 GMT
Connection: keep-alive
Keep-Alive: timeout=20
Accept-Ranges: bytes

访问访问http://www.80sec.com/robots.txt/80sec.php

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:06:49 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
X-Powered-By: PHP/5.2.6

其中的Content-Type的变化说明了后端负责解析的变化，该站点就可能存在漏洞。

漏洞厂商：http://www.nginx.org

解决方案：

我们已经尝试联系官方，但是此前你可以通过以下的方式来减少损失

关闭cgi.fix_pathinfo为0

或者

if ( $fastcgi_script_name ~ \..*\/.*php ) {
return 403;
}

转载至:http://www.80sec.com/nginx-securit.html