NGINX 502错误排查

NGINX 502 Bad Gateway错误是FastCGI有问题，造成NGINX 502错误的可能性比较多。将网上找到的一些和502 Bad Gateway错误有关的问题和排查方法列一下，先从FastCGI配置入手：

1.查看FastCGI进程是否已经启动
NGINX 502错误的含义是sock、端口没被监听造成的。我们先检查fastcgi是否在运行

2.检查系统Fastcgi进程运行情况
除了第一种情况，fastcgi进程数不够用、php执行时间长、或者是php-cgi进程死掉也可能造成nginx的502错误
运行以下命令判断是否接近FastCGI进程，如果fastcgi进程数接近配置文件中设置的数值，表明worker进程数设置太少
netstat -anpo | grep "php-cgi" | wc -l

3.FastCGI执行时间过长
根据实际情况调高以下参数值
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

4.头部太大
nginx和apache一样，有前端缓冲限制，可以调整缓冲参数
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
如果你使用的是nginx的负载均衡Proxying，调整
proxy_buffer_size  16k;
proxy_buffers      4 16k;
参见：http://www.ruby-forum.com/topic/169040

5.https转发配置错误
正确的配置方法
server_name www.mydomain.com;
location /myproj/repos {
set $fixed_destination $http_destination;
if ( $http_destination ~* ^https(.*)$ )
{
set $fixed_destination http$1;
}
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Destination $fixed_destination;
proxy_pass http://subversion_hosts;
}
参见：http://www.ruby-forum.com/topic/169040

当然，还要看你后端用的是哪种类型的FastCGI，我用过的有php-fpm，流量约为单台机器40万PV(动态页面), 现在基本上没有碰到502。

Zencart持久链接的Nginx rewrite规则

前几天介绍了如何在nginx下作wordpress的伪静态化和Joomla的SEF模块设置。今天顺便介绍下如何在nginx下来做zencart的url伪静态化呢? 这里我们对这个过程做个假单的介绍，首先我们假设你使用的是zencart的Ultimate SEO URLs模块，并且已经安装和设置好了该插件。那么现在我们需要做的就是为zencart建立一个nginx的rewrite规则,具体操作方法如下，首先新建一个文件your_nginx_path/conf/zencart_rewrite.conf, 建立如下：
        # if the requested file exists, return it immediately
        if (-f $request_filename) {
                break;
        }

        # All other pages
        # Don‘t rewrite real files or directories
        rewrite "^(.*).html" /index.php?main_page=$1&% last;

Nginx 400错误排查：HTTP头/Cookie过大

今天有人汇报nginx的HTTP400错误，而且这个HTTP400错误并不是每次都会出现的，查了一下发现nginx 400错误是由于request header过大，通常是由于cookie中写入了较长的字符串所引起的。

解决方法是不要在cookie里记录过多数据，如果实在需要的话可以考虑调整在nginx.conf中的client_header_buffer_size(默认1k)
若cookie太大，可能还需要调整large_client_header_buffers(默认4k)，该参数说明如下：
请求行如果超过buffer，就会报HTTP 414错误(URI Too Long)
nginx接受最长的HTTP头部大小必须比其中一个buffer大，否则就会报400的HTTP错误(Bad Request)。

Nginx 413错误的排查:修改上传文件大小限制

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

在nginx.conf增加 client_max_body_size的相关设置, 这个值默认是1m，可以增加到8m以增加提高文件大小限制；
如果运行的是php，那么还要检查php.ini，这个大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大，这样就不会因为提交数据大小不一致出现的错误。

post_max_size = 8M
upload_max_filesize = 2M

nginx的301重定向规则

今天对博客进行了301重定向，把www.jefflei.com和jefflei.com合并，并把之前的域名也一并合并. 有两种实现方法,第一种方法是判断nginx核心变量host(老版本是http_host)：
server {
server_name www.jefflei.com jefflei.com ;
if ($host != 'www.jefflei.com' ) {
rewrite ^/(.*)$ http://www.jefflei.com/$1 permanent;
}
...
}
第二种方法：
server {
server_name jefflei.com;
rewrite ^/(.*) http://www.jefflei.com/$1 permanent;
}
我用的是第一种方法，这两种方法中， permanent是关键，详细说明见nginx重定向规则说明。

last – 基本上都用这个Flag。
break – 中止Rewirte，不在继续匹配
redirect – 返回临时重定向的HTTP状态302
permanent – 返回永久重定向的HTTP状态301

好了,现在可以检查结果，这里可以看返回的HTTP头信息：http://www.seoconsultants.com/tools/headers.asp

Joomla！SEF模块的nginx rewrite 配置

#如果要设置nginx下joomla下的seo静态化插件以下这段设置是必须的

if ( !-e $request_filename ) {
rewrite (/|\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$ /index.php last;
break;
}
#下面这段是joomla 1.5防止攻击的url rewrite转译

if ( $args ~ “mosConfig_[a-zA-Z_]{1,21}(=|\%3d)” ) {
set $args “”;
rewrite ^.*$ http://$host/index.php last;
return 403;
}
if ( $args ~ “base64_encode.*\(.*\)” ) {
set $args “”;
rewrite ^.*$ http://$host/index.php last;
return 403;
}
if ( $args ~ “(\<|%3C).*script.*(\>|%3E)” ) {
set $args “”;
rewrite ^.*$ http://$host/index.php last;
return 403;
}
if ( $args ~ “GLOBALS(=|\[|\%[0-9A-Z]{0,2})” ) {
set $args “”;
rewrite ^.*$ http://$host/index.php last;
return 403;
}
if ( $args ~ “_REQUEST(=|\[|\%[0-9A-Z]{0,2})” ) {
set $args “”;
rewrite ^.*$ http://$host/index.php last;
return 403;
}
然后将上面的文件命名为vi joomla-sef.conf，然后include到nginx的configure文件中就可以了。

nginx重定向的相关用法可以参照nginx rewrite规则设定详细介绍(中文)

WordPress持久链接permalink的Nginx rewrite规则

我用wordpress super cache和nginx来加速wp博客网页，由于需要使用wordpress permalink，需要为wordpress建立一个nginx的rewrite规则, 参照了wordpress super cache作者博客中的一篇评论，具体操作方法如下，首先新建一个文件your_nginx_path/conf/wp_rewrite.conf, 建立如下：

if (-f $request_filename) {
expires 7d;
 break;
 }
 
 set $supercache_file ”;
 set $supercache_uri $request_uri;
 
 if ($request_method = POST) {
 set $supercache_uri ”;
 }
 
 # Using pretty permalinks, so bypass the cache for any query string
 if ($query_string) {
 set $supercache_uri ”;
 }
 
 if ($http_cookie ~* “comment_author_|wordpress|wp-postpass_” ) {
 set $supercache_uri ”;
 }
 
 # if we haven’t bypassed the cache, specify our supercache file
 if ($supercache_uri ~ ^(.+)$) {
 set $supercache_file /wp-content/cache/supercache/$http_host/$1index.html;
 }
 
 # only rewrite to the supercache file if it actually exists
 if (-f $document_root$supercache_file) {
 rewrite ^(.*)$ $supercache_file break;
 }
 
 # all other requests go to WordPress
if (!-e $request_filename) {
rewrite . /index.php last;
}
然后在你的nginx配置文件中include这个文件,重新load配置即可。

nginx重定向规则详细介绍(原创)

Nginx的重定向用到了Nginx的HttpRewriteModule，下面简单解释以下如何使用的方法：

rewrite命令

nginx的rewrite相当于apache的rewriterule(大多数情况下可以把原有apache的rewrite规则加上引号就可以直接使用)，它可以用在server,location 和IF条件判断块中,命令格式如下：
rewrite 正则表达式 替换目标 flag标记
flag标记可以用以下几种格式：
last – 基本上都用这个Flag。
break – 中止Rewirte，不在继续匹配
redirect – 返回临时重定向的HTTP状态302
permanent – 返回永久重定向的HTTP状态301
例如下面这段设定nginx将某个目录下面的文件重定向到另一个目录,$2对应第二个括号(.*)中对应的字符串：
location /download/ {
rewrite ^(/download/.*)/m/(.*)\..*$ $1/nginx-rewrite/$2.gz break;
}

nginx重定向的IF条件判断

在server和location两种情况下可以使用nginx的IF条件判断，条件可以为以下几种：
正则表达式

如：
匹配判断
~  为区分大小写匹配; !~为区分大小写不匹配
 ~* 为不区分大小写匹配；!~为不区分大小写不匹配
例如下面设定nginx在用户使用ie的使用重定向到/nginx-ie目录下：
if ($http_user_agent ~ MSIE) {
rewrite ^(.*)$ /nginx-ie/$1 break;
}
文件和目录判断
  -f和!-f判断是否存在文件
 -d和!-d判断是否存在目录
 -e和!-e判断是否存在文件或目录
 -x和!-x判断文件是否可执行
例如下面设定nginx在文件和目录不存在的时候重定向：
if (!-e $request_filename) {
proxy_pass http://127.0.0.1;
}

return

返回http代码，例如设置nginx防盗链：
location ~* \.(gif|jpg|png|swf|flv)$ {
valid_referers none blocked www.jefflei.com www.leizhenfang.com;
if ($invalid_referer) {
return 404;
}
}

set

设置nginx变量

SosoSpider及恶意蜘蛛屏蔽

最近从网络日志看到有很多陕西电信IDC的访问，占我们www总访问数的一半,ip都是124.115.0.X和124.115.4.X，总共约有60多个IP。网上搜索了一下，发现这是sosospider，文章参见：

http://www.wangzhongyuan.com/archives/522.html
http://www.cnzzr.cn/2008/02/sosospider-124-115.html

由于这个sosospider不遵守行规，不读取robots.txt，并且User-agents中没有spider信息，而且还带有referer，伪装成普通用户，封闭的办法只有禁止IP：

Order Allow,Deny
Allow from all
Deny from 124.115.4. env=bad_bot
Deny from 124.115.0. env=bad_bot

注意这里deny和allow的顺序，对于其他恶意搜索引擎，可以用：

SetEnvIfNoCase User-Agent “Indy Library” bad_bot
…
Order Allow,Deny
Allow from all
Deny from env=bad_bot

nginx配置如下：

location / {
    deny   124.115.4.0/24;
deny 124.115.0.0/24;
    allow    all;
}

设置rsync用SSH自动传输

为了使SSH能够自动传输，我们需要

1）客户端配置

在需要授权的用户目录下，此处为root:
ssh-keygen -t rsa -b 2048 -f /root/.ssh/hostkey
若没有.ssh目录，手动创建一个；此时会在该目录下生成2个文件，hostkey  hostkey.pub;
将生成的hustkey.pub传输给server，由于此处是要用于身份验证的：
scp -P 1818 /root/.ssh/hostkey.pub jeff@192.168.1.98:/.ssh/

2. 服务器端设置

a，在/etc/hosts.allow里，添加：sshd:192.168.1.100，允许客户端可以登陆；
b，在/.ssh目录下手动创建：touch authorized_keys；chomd 600 authorized_keys;再将由客户端scp过来的hostkey.pub导进去：cat hostkey.pub >> authorized_keys

c，vi /etc/ssh/sshd_config,修改如下几行：

RhostsAuthentication yes
RhostsRSAAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

ssh -p 1818 -i /root/.ssh/hostkey