存档

‘nginx’ 分类的存档

推荐一本关于Nginx的书

2011年1月9日 wenhui 没有评论

作者是:Kevin(kevin.zwf#gmail.com) & Mark(kissingwolf@gmail.com)
地址:http://wenku.baidu.com/view/e9763a23482fb4daa58d4b29.html

有比较详细的介绍,以及实例~

分类: nginx, 挨踢 标签:

nginx的二级域名匹配

2010年8月26日 wenhui 1 条评论

整了一个域名,涉及到将二级域名为数字的转到特定的目录下,这里用nginx的匹配$host来实现
下面是一个简单的配置,请看

#绑定域名
server_name *.abcd.com;
#匹配你的二级域名
if ( $host ~* (.*)\.yourdomain\.com)
{
   set $domain $1;
}
#定义目录
root  html/abc/$domain/;
location /
{
    root  html/abcd/$domain;
    index index.html index.php;
}
分类: nginx, 挨踢 标签:

让nginx的expires和防盗链都有效,应对nginx图片防盗链没用的情况!

2010年8月25日 wenhui 没有评论

注:在Nginx下,expires和防盗链(valid_referers)一起用的时候,会出现防盗链失效的情况!其详细状况如下:

expires有效,防盗链失效

location ~* ^.+\.(jpg|jpeg|gif|png|css|js|swf)$ {
access_log off;
root /opt/htdocs/career;
expires 1h;
#break;
}
location ~* ^.+\.(jpg|jpeg|gif|png|swf|rar|zip)$ {
valid_referers none blocked *.c1gstudio.com;
if ($invalid_referer) {
rewrite ^/ http://leech.c1gstudio.com/leech.gif;
return 412;
}
}

只有js和css的expire有效,防盗链有效

location ~* ^.+\.(jpg|jpeg|gif|png|swf|rar|zip)$ {
valid_referers none blocked *.c1gstudio.com;
if ($invalid_referer) {
rewrite ^/ http://leech.c1gstudio.com/leech.gif;
return 412;
}
}
location ~* ^.+\.(jpg|jpeg|gif|png|css|js|swf)$ {
access_log off;
root /opt/htdocs/career;
expires 1h;
#break;
}

让expire和防盗链都有效

location ~* ^.+\.(jpg|jpeg|gif|png|swf|rar|zip|css|js)$ {
valid_referers none blocked *.c1gstudio.com;
if ($invalid_referer) {
rewrite ^/ http://leech.c1gstudio.com/leech.gif;
return 412;
}
access_log off;
root /opt/htdocs/career;
expires 1h;
break;
}

Nginx的Rewrite配置

2010年7月23日 wenhui 没有评论

来源:http://www.ccvita.com/319.html

Nginx的Rewrite
经过网上查阅和测试,发现Nginx的Rewrite规则和Apache的Rewite规则差别不是很大,几乎可以直接使用。比如在Apache中这样写规则
rewrite ^/([0-9]{5}).html$ /viewthread.php?tid=$1 last;
而在Nginx中写成这样写是无法启动的,解决的办法是加上两个双引号:
rewrite “^/([0-9]{5}).html$” /viewthread.php?tid=$1 last;
同时将RewriteRule为Rewrite,基本就实现了Nginx的Rewrite规则到Apache的Rewite规则的转换。

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

官方文档请点击这里,另外如果对于302,301这些状态有疑问的,可以参考《301 Redirect 永久重定向的实现》:http://www.ccvita.com/85.html
如果需要对Nginx配置防盗链的话,可以参考《Nginx的防盗链配置》:http://www.ccvita.com/312.html

Discuz!在Nginx下的Rewrite
需要说明的是,下网上以前一直流传的Rewrite都是有误的。
下面的Rewrite中百分号前面多了个转移字符“\”,这在Apache中是需要的,而在Nginx中则是不需要的。
rewrite ^/thread-([0-9]+)-([0-9]+)-([0-9]+)\.html$ /viewthread.php?tid=$1&extra=page\%3D$3&page=$2 last;
正确的应该是
rewrite ^/thread-([0-9]+)-([0-9]+)-([0-9]+)\.html$ /viewthread.php?tid=$1&extra=page%3D$3&page=$2 last;
这个错误在基本上目前所有使用Nginx作为服务器,并且开启了Rewrite的网站上存在。包括Discuz!官方,目前已经给cnteacher反馈了。

完整正确的Discuz!在Nginx下的Rewrite如下:
rewrite ^/archiver/((fid|tid)-[\w\-]+\.html)$ /archiver/index.php?$1 last;
rewrite ^/forum-([0-9]+)-([0-9]+)\.html$ /forumdisplay.php?fid=$1&page=$2 last;
rewrite ^/thread-([0-9]+)-([0-9]+)-([0-9]+)\.html$ /viewthread.php?tid=$1&extra=page%3D$3&page=$2 last;
rewrite ^/space-(username|uid)-(.+)\.html$ /space.php?$1=$2 last;
rewrite ^/tag-(.+)\.html$ /tag.php?name=$1 last;
break;

相关文档
Nginx下Discuz!的Rewrite》:http://www.ccvita.com/348.html
Nginx下WordPress的Rewrite》:http://www.ccvita.com/336.html
Nginx的Rewrite配置》:http://www.ccvita.com/319.html
Nginx的防盗链配置》:http://www.ccvita.com/312.html

分类: nginx, 挨踢 标签:

Nginx打开目录浏览功能(autoindex)

2010年7月19日 wenhui 没有评论

来源:http://blog.licess.org/nginx-autoindex/

Nginx默认是不允许列出整个目录的。如需此功能,
打开nginx.conf文件,在location server 或 http段中加入
autoindex on;
另外两个参数最好也加上去:

autoindex_exact_size off;
默认为on,显示出文件的确切大小,单位是bytes。
改为off后,显示出文件的大概大小,单位是kB或者MB或者GB

autoindex_localtime on;
默认为off,显示的文件时间为GMT时间。
改为on后,显示的文件时间为文件的服务器时间

location /images {
root /var/www/nginx-default/ibugaocn;
autoindex on;
}

详细参照:http://wiki.nginx.org/NginxChsHttpAutoindexModule

如果想希望目录列表支持header,footer则可以安装三方插件:

http://wiki.nginx.org/NginxNgxFancyIndex

分类: nginx, 挨踢 标签: ,

nginx负载均衡和lvs负载均衡的比较分析

2010年7月16日 wenhui 4 条评论

来源:http://www.sudone.com/nginx/nginx_vs_lvs.html

一、lvs的优势:
1、抗负载能力强,因为lvs工作方式的逻辑是非常之简单,而且工作在网络4层仅做请求分发之用,没有流量,所以在效率上基本不需要太过考虑。在我手里的lvs,仅仅出过一次问题:在并发最高的一小段时间内均衡器出现丢包现象,据分析为网络问题,即网卡或linux2.4内核的承载能力已到上限,内存和cpu方面基本无消耗。
2、配置性低,这通常是一大劣势,但同时也是一大优势,因为没有太多可配置的选项,所以除了增减服务器,并不需要经常去触碰它,大大减少了人为出错的几率。
3、工作稳定,因为其本身抗负载能力很强,所以稳定性高也是顺理成章,另外各种lvs都有完整的双机热备方案,所以一点不用担心均衡器本身会出什么问题,节点出现故障的话,lvs会自动判别,所以系统整体是非常稳定的。
4、无流量,上面已经有所提及了。lvs仅仅分发请求,而流量并不从它本身出去,所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。
5、基本上能支持所有应用,因为lvs工作在4层,所以它可以对几乎所有应用做负载均衡,包括http、数据库、聊天室等等。
另:lvs也不是完全能判别节点故障的,譬如在wlc分配方式下,集群里有一个节点没有配置VIP,会使整个集群不能使用,这时使用wrr分配方式则会丢掉一台机。目前这个问题还在进一步测试中。所以,用lvs也得多多当心为妙。
二、nginx和lvs作对比的结果
1、nginx工作在网络的7层,所以它可以针对http应用本身来做分流策略,比如针对域名、目录结构等,相比之下lvs并不具备这样的功能,所以nginx单凭这点可利用的场合就远多于lvs了;但nginx有用的这些功能使其可调整度要高于lvs,所以经常要去触碰触碰,由lvs的第2条优点看,触碰多了,人为出问题的几率也就会大。
2、nginx对网络的依赖较小,理论上只要ping得通,网页访问正常,nginx就能连得通,nginx同时还能区分内外网,如果是同时拥有内外网的节点,就相当于单机拥有了备份线路;lvs就比较依赖于网络环境,目前来看服务器在同一网段内并且lvs使用direct方式分流,效果较能得到保证。另外注意,lvs需要向托管商至少申请多一个ip来做Visual IP,貌似是不能用本身的IP来做VIP的。要做好LVS管理员,确实得跟进学习很多有关网络通信方面的知识,就不再是一个HTTP那么简单了。
3、nginx安装和配置比较简单,测试起来也很方便,因为它基本能把错误用日志打印出来。lvs的安装和配置、测试就要花比较长的时间了,因为同上所述,lvs对网络依赖比较大,很多时候不能配置成功都是因为网络问题而不是配置问题,出了问题要解决也相应的会麻烦得多。
4、nginx也同样能承受很高负载且稳定,但负载度和稳定度差lvs还有几个等级:nginx处理所有流量所以受限于机器IO和配置;本身的bug也还是难以避免的;nginx没有现成的双机热备方案,所以跑在单机上还是风险较大,单机上的事情全都很难说。
5、nginx可以检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点。目前lvs中ldirectd也能支持针对服务器内部的情况来监控,但lvs的原理使其不能重发请求。重发请求这点,譬如用户正在上传一个文件,而处理该上传的节点刚好在上传过程中出现故障,nginx会把上传切到另一台服务器重新处理,而lvs就直接断掉了,如果是上传一个很大的文件或者很重要的文件的话,用户可能会因此而恼火。
6、nginx对请求的异步处理可以帮助节点服务器减轻负载,假如使用apache直接对外服务,那么出现很多的窄带链接时apache服务器将会占用大量内存而不能释放,使用多一个nginx做apache代理的话,这些窄带链接会被nginx挡住,apache上就不会堆积过多的请求,这样就减少了相当多的内存占用。这点使用squid也有相同的作用,即使squid本身配置为不缓存,对apache还是有很大帮助的。lvs没有这些功能,也就无法能比较。
7、nginx能支持http和email(email的功能估计比较少人用),lvs所支持的应用在这点上会比nginx更多。在使用上,一般最前端所采取的策略应是lvs,也就是DNS的指向应为lvs均衡器,lvs的优点令它非常适合做这个任务。重要的ip地址,最好交由lvs托管,比如数据库的ip、webservice服务器的ip等等,这些ip地址随着时间推移,使用面会越来越大,如果更换ip则故障会接踵而至。所以将这些重要ip交给lvs托管是最为稳妥的,这样做的唯一缺点是需要的VIP数量会比较多。nginx可作为lvs节点机器使用,一是可以利用nginx的功能,二是可以利用nginx的性能。当然这一层面也可以直接使用squid,squid的功能方面就比nginx弱不少了,性能上也有所逊色于nginx。nginx也可作为中层代理使用,这一层面nginx基本上无对手,唯一可以撼动nginx的就只有lighttpd了,不过lighttpd目前还没有能做到nginx完全的功能,配置也不那么清晰易读。另外,中层代理的IP也是重要的,所以中层代理也拥有一个VIP和lvs是最完美的方案了。具体的应用还得具体分析,如果是比较小的网站(日PV<1000万),用nginx就完全可以了,如果机器也不少,可以用DNS轮询,lvs所耗费的机器还是比较多的;大型网站或者重要的服务,机器不发愁的时候,要多多考虑利用lvs。
分类: nginx, 挨踢 标签: ,

设置nginx expires和access_log提升网站访问速度

2010年7月15日 wenhui 没有评论

在一个网站中往往图片,css文件,js文件会占用掉大量的带宽和载入时间.采用nginx做前端服务器可以设置类似的静态文件客户端的缓存时间.比如:

location ~ \.(gif|jpg|jpeg|png|bmp|ico|swf|css|js)$ {
expires 30d;
access_log off;
}

就可以将类似静态文件的客户端缓存时间设置为30天,意味着客户在30天内重新访问这些文件时只需要在本地缓存中读取,而不用重新从服务器获取.这样页面载入速度就大大提高了.

当然,对于这些静态文件的访问记录计入日志,在一般情况下也是没有意义的,将accss_log设为off,能在一定程度上降低服务器压力.

分类: nginx, 挨踢 标签: ,

Debian Lenny安装nginx+PHP+MySQL傻瓜手记[转]

2010年7月15日 wenhui 没有评论
新搞了个VPS,打算把Blog以及全套行头迁移过来。
以前的那套图省事,用了CentOS5 Kloxo AllinOne BOX。基本上依靠这个CP搞定了全套,主要是人懒不想折腾而已。这次换了个新的VPS提供商,心血来潮想折腾Debian。所以把过程记录下来,避免以后不折腾了却忘记自己当初怎么搭。
总体思路还是采取懒汉办法,有官方源的从官方源安装,没官方源找第三方社区源,再没有的话自己做deb,无论如何,避免从源代码直接编译。
首先把最简单的MySQL装上,用官方源,一句话搞定:
apt-get install mysql-server
MySQL配置文件稍后再搞,对于小Blog来说MySQL的优化意义不大。
其次是nginx,说实话这东西不熟,不过貌似最近挺流行,Debian Lenny也将其收进官方源了,那就简单apt之
apt-get install nginx
简单netstat看一下发现80已经在监听了,访问http://<IP>发现出现欢迎页“Welcome to nginx!”,接下来就是怎么让PHP在nginx上跑起来。
很没技术含量不是,很不幸后面的也没啥技术含量。一破Blog日IP不过300折腾个什么劲啊,不就是一个玩儿么。
PHP稍微麻烦点,因为Nginx没有像Apache那样的SAPI调用PHP的方式,而是使用FastCGI来调。这里就存在一个对PHP的FastCGI进程如何管理的问题。官方源的php5-cgi本身没有进程管理机制。一个比较好的选择是用spawn-fcgi(源自lighttpd的小东东)来起PHP进程,结果查了一下spawn-fcgi到现在还在sid呆着。还有一个选择是使用php-fpm来做FastCGI进程管理,这东西的灵活性比spawn-fcgi还要高不少,但代价是要往PHP源代码里打Patch才能用,也就意味着–要重新编译整个PHP。
简单权衡了一下,我觉得我还是想用php-fpm,但是又想偷懒不编译源代码,于是就求助于第三方二进制源了。随便搜了一下发现还真有正合适的– http://www.dotdeb.org/,这个社区致力于维护Debian下的LAMP类软件的非官方二进制包,恰好它们近期重做了PHP,使用了PHP5.3.1版本,并集成入了Suhosin安全补丁。最让人舒服的是吧php-fpm做成了一个php5-fpm的安装包,并给其加了SysV类的启动脚本,这样PHP的FastCGI方式即可以有自己单独的conf文件,又有单独的init.d控制脚本,可谓完美。
无废话说干就干。
修改/etc/apt/source.list,加入dotdeb的源设置:
deb http://php53.dotdeb.org stable all
deb-src http://php53.dotdeb.org stable all
然后apt之:
apt-get update
apt-get install php5-cgi php5-fpm
这样PHP就算完事了,简单验证一下,运行如下命令,观察phpinfo()输出是否正常:
php-cgi –i
再保险点看一下PHP的FastCGI进程有没有跑起来,ps aux|grep php,应该能看到有进程为”/usr/bin/php5-fpm –fpm-config /etc/php5/fpm/php5-fpm.conf”在跑。
剩下的事就是搞定nginx的配置文件把站点建好,并让其能调用后台的PHP。这个dotdeb社区源做的php5-fpm好心到都提供了一个nginx的example配置文件,放在/etc/php5/fpm/nginx-site-conf.sample,改改拿来用就好了。
我是将其复制到/etc/nginx/sites-enabled/opslife.com.conf,然后简单修改几个参数,改好的配置文件是这样:
#
# nginx-site-conf.sample:
# Php Site configuration for nginx webserver
#
# 1. set server root /path/to/your/website;
# 2. Rename this file. Copy it to /etc/nginx/sites-available, /etc/nginx/sites-enabled
#    or otherwise ensure that this file is included by the nginx.conf
# 3. Restart nginx webserver, and php-fpm service.
#
server {
root  /home/dawnh/opslife.com;
server_name     opslife.com www.opslife.com d9.opslife.com;
listen          80;
access_log  /var/log/nginx/opslife.com.access.log;
location / {
index  index.html index.htm index.php;
}
#error_page  404  /404.html;
# redirect server error pages to the static page /50x.html
#
error_page   500 502 503 504  /50x.html;
location = /50x.html {
root   /var/www/nginx-default;
}
# pass the *.php scripts to php-fpm listening on tcp port 9000
#
location ~ \.php$ {
fastcgi_pass   127.0.0.1:9000;
fastcgi_index  index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SERVER_NAME $http_host;
fastcgi_ignore_client_abort on;
}
}
这样站点配置就算是完成了,/etc/init.d/nginx restart重启后,新站点应该就会跑起来了,使用域名opslife.com、www.opslife.com、 d9.opslife.com都应该访问到新建立的站点。
最后再验证一下,扔一个info.php放到/home/dawnh/opslife.com,内容就一句:
<?php phpinfo();?>
由于主域名还没指过来,先用子域名访问测试,直接访问http://d9.opslife.com/info.php,看到返回正确的phpinfo信息。到此最后一步也算顺利完成。
剩下就是把wordpress的东西从老的VPS迁移过来了,依旧是没什么技术含量。有空再记录。
分类: nginx, 挨踢 标签:

nginx upstream的5种配置方式[转]

2010年7月13日 wenhui 没有评论

来源:未知,如有了解,请告知,谢谢

nginx的upstream目前支持5种方式的分配
1、轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。
2、weight
指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。
例如:
upstream bakend {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}
3、ip_hash
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。
例如:
upstream bakend {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
4、fair(第三方)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。
upstream backend {
server server1;
server server2;
fair;
}
5、url_hash(第三方)
按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。
例:在upstream中加入hash语句,server语句中不能写入weight等其他的参数,hash_method是使用的hash算法
upstream backend {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
tips:
upstream bakend{#定义负载均衡设备的Ip及设备 状态
ip_hash;
server 127.0.0.1:9090 down;
server 127.0.0.1:8080 weight=2;
server 127.0.0.1:6060;
server 127.0.0.1:7070 backup;
}
在需要使用负载均衡的server中增加
proxy_pass http://bakend/;
每个设备的状态设置为:
1.down 表示单前的server暂时不参与负载
2.weight 默认为1.weight越大,负载的权重就越大。
3.max_fails :允许请求失败的次数默认为1.当超过最大次数时,返回proxy_next_upstream 模块定义的错误
4.fail_timeout:max_fails次失败后,暂停的时间。
5.backup: 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。
nginx支持同时设置多组的负载均衡,用来给不用的server来使用。
client_body_in_file_only 设置为On 可以讲client post过来的数据记录到文件中用来做debug
client_body_temp_path 设置记录文件的目录 可以设置最多3层目录
location 对URL进行匹配.可以进行重定向或者进行新的代理 负载均衡
分类: nginx, 挨踢 标签: , , ,

Nginx的WordPress配置[转]

2010年7月12日 wenhui 没有评论

来自:http://shiningray.cn/nginx-de-wordpress-pei-zhi.html

WordPress是一个非常流行的Blog系统,它可以利用Apache的mod_rewrite来实现URL的静态化。安装好的WordPress在配置了持久链接之后,会在网站的根目录下(如果可写)生成一个.htaccess文件,这个文件可以指示Apache如何进行URL重写(如果服务器配置为允许使用htaccess的指令的话),它的内容如下:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

这个文件的意思就是,如果当请求的文件不存在,那么把请求内部重定向到/index.php。WordPress会自己分析请求的URL,来判断显示哪个页面。

在上次配置了Nginx+PHP之后,由于Nginx不支持Apache的.htaccess文件,要实现持久连接静态化,我们必须手工配置Nginx的文件。首先找到Nginx的配置文件,默认编译后的配置文件在/usr/local/nginx/conf/nginx.conf;Ubuntu通过包安装的配置文件位于/etc/nginx/nginx.conf,也可以编辑vhost的配置文件,放在了/etc/nginx/sites-available下。

以下是基本的配置(Ubuntu下的范例):

   location / {
        index index.html index.php;
        if (-f $request_filename/index.html){
            rewrite (.*) $1/index.html break;
        }
        if (-f $request_filename/index.php){
            rewrite (.*) $1/index.php;
        }
        if (!-f $request_filename){
            rewrite (.*) /index.php;
        }
    }
    location ~ .*\.php$ {
        include /etc/nginx/fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
    }

还可以有很多种不同配置方式,例如不改写所有包含wp-的url等。此配置考虑了目录下的索引文件index.html和index.php。-f指令表示测试文件是否存在(不考虑文件和目录的区别),!-f则表示不存在。注意在重写url到index.html后面有个break,而重写到index.php后没有break。因为html文件不需要任何额外工作可以直接发送到客户端,所以重写规则在这里终止,下面就直接让nginx发送文件。而.php文件需要进一步发送到fastcgi进程来运行,Nginx会继续判断该文件符合第二个部分location ~ .*\.php$的规则,并进行FastCGI的转发。

大家可以将以上内容保存为wordpress.conf,然后在自己的vhost配置,即server节中应用该配置文件,例如(以下为Ubuntu进行的配置):

server {
        listen   80;
        server_name  shiningray.cn *.shiningray.cn;

        root /var/www/shiningray.cn;

        include /etc/nginx/wordpress.conf;
}

接下来让Nginx重新载入配置文件,便可使用WordPress的持久链接了。

分类: nginx, wordpress, 应用, 挨踢 标签: