分类存档: 系统管理 - 第2页

NGINX 502错误排查

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。

VN:F [1.9.14_1148]
Rating: 8.6/10 (7 votes cast)
VN:F [1.9.14_1148]
Rating: 0 (from 0 votes)

Zencart持久链接的Nginx rewrite规则

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

        rewrite "^/(.*)-p-(.*).html$" /index.php?main_page=product_info&products_id=$2&% last;
        rewrite "^/(.*)-c-(.*).html$" /index.php?main_page=index&cPath=$2&% last;
        rewrite "^/(.*)-m-([0-9]+).html$" /index\.php?main_page=index&manufacturers_id=$2&% last;
        rewrite "^/(.*)-pi-([0-9]+).html$" /index\.php?main_page=popup_image&pID=$2&% last;
        rewrite "^/(.*)-pr-([0-9]+).html$" /index\.php?main_page=product_reviews&products_id=$2&% last;
        rewrite "^/(.*)-pri-([0-9]+).html$" /index\.php?main_page=product_reviews_info&products_id=$2&% last;
        # For on zencart by Jeff
        rewrite "^/wp/(.*).html$" /index.php?main_page=wordpress&page_id=$1&% last;

        # For eazy pages
        rewrite "^/(.*)-ezp-([0-9]+).html$" /index\.php?main_page=page&id=$2&% last;

        # For Open Operations Info Manager
        rewrite "^(.*)-i-([0-9]+).html" /index.php?main_page=info_manager&pages_id=$2&% last;

        # For dreamscape¡¯s News & Articles Manager
        rewrite "^news/?" /index.php?main_page=news&% last;
        rewrite "^news/rss.xml" /index.php?main_page=news_rss&% last;
        rewrite "^news/archive/?" /index.php?main_page=news_archive&% last;
        rewrite "^news/([0-9]{4})-([0-9]{2})-([0-9]{2}).html" /index.php?main_page=news&date=$1-$2-$3&% last;
        rewrite "^news/archive/([0-9]{4})-([0-9]{2}).html" /index.php?main_page=news_archive&date=$1-$2&% last;
        rewrite "^news/(.*)-a-([0-9]+)-comments.html" /index.php?main_page=news_comments&article_id=$2&% last;
        rewrite "^news/(.*)-a-([0-9]+).html" /index.php?main_page=news_article&article_id=$2&% last;

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

VN:F [1.9.14_1148]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.14_1148]
Rating: 0 (from 0 votes)

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)。

VN:F [1.9.14_1148]
Rating: 2.0/10 (1 vote cast)
VN:F [1.9.14_1148]
Rating: +1 (from 1 vote)

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

在上传时nginx返回了413错误,查看log文件,显示的错误信息是:”413 Request Entity Too Large”, 于是在网上找了下“ 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

VN:F [1.9.14_1148]
Rating: 9.3/10 (3 votes cast)
VN:F [1.9.14_1148]
Rating: 0 (from 0 votes)

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

VN:F [1.9.14_1148]
Rating: 10.0/10 (2 votes cast)
VN:F [1.9.14_1148]
Rating: 0 (from 0 votes)

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规则设定详细介绍(中文)

VN:F [1.9.14_1148]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.14_1148]
Rating: +1 (from 1 vote)

WordPress持久链接permalink的Nginx rewrite规则

我用wordpress super cache和nginx来加速wp博客网页,由于需要使用wordpress permalink,需要为wordpress建立一个nginx的rewrite规则, 参照了wordpress super cache作者博客中的一篇评论,具体操作方法如下,首先新建一个文件your__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_||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配置即可。

VN:F [1.9.14_1148]
Rating: 10.0/10 (1 vote cast)
VN:F [1.9.14_1148]
Rating: 0 (from 0 votes)

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/-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变量

VN:F [1.9.14_1148]
Rating: 7.4/10 (11 votes cast)
VN:F [1.9.14_1148]
Rating: -1 (from 3 votes)

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

VN:F [1.9.14_1148]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.14_1148]
Rating: 0 (from 0 votes)

设置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

VN:F [1.9.14_1148]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.14_1148]
Rating: 0 (from 0 votes)
Page 2 of 612345...Last »