Apache和Nginx下禁止访问特定的目录或文件
大家是否测试Apache做了目录禁止浏览后,目录下面的txt文件还是可以显示里面的内容的。
RewriteCond (重写规则执行条件)
RewriteCond 重写规则执行条件
W3Techs报告:使用web服务器分析进行排名
Release date: in 2012, August 25
Usage of web servers broken down by ranking
This diagram shows the percentages of websites using various web servers broken down by ranking. Cross-technology reports only include technologies with more than 1% usage to ensure statistical significance of the results. See technologies overview for explanations on the methodologies used in the surveys.
How to read the diagram:
Apache is used by 64.9% of all the websites whose web server we know.
Apache is used by 55.2% of all the websites whose web server we know and that rank in the top 100.000.
原文地址:http://w3techs.com/technologies/cross/web_server/ranking
apche for linux(索引列表) 中文目录及文件名乱码问题
由WINDOWS XP 下新建TXT文件,编码默认为WIN下:ANSI 文件名称为中文,PUT 上传至linux 下,并且打开apache列表索引,英文正常,中文目录及其文件夹名称显示乱码。
分析:linux 下文件系统默认编码默认为UTF-8 而WIN下默认为GB2312/GBK 初始状态apache生成的列表索引并无指定任何编码,导致出现乱码。
解决方法:设置apache 目录列表索引模式,并设置字符集为utf-8
Options Indexes
IndexOptions Charset=UTF-8
参数"Options Indexes"表示启用目录浏览,"IndexOptions Charset=UTF-8"设置字符集,以消除中文乱码!
============================================================================
假设是WIN XP 下上传:说明.txt -->到apache for linux 下,在目录索引点击查看TXT内文本内容显示乱码,则要转变文件本身保存字符集所需用的编码格式。即文件自身编码于linux文件系统编码不一至@
解决方法可使用iconv转换文件编码:http://liuxinxiu.com/iconv/
【转载】Nginx中文手册(技术指南第二版)
Nginx 常见应用技术指南[Nginx Tips] 第二版
目 录
一、 Nginx 基础知识
二、 Nginx 安装及调试
三、 Nginx Rewrite
四、 Nginx Redirect
五、 Nginx 目录自动加斜线:
六、 Nginx Location
七、 Nginx expires
八、 Nginx 防盗链
九、 Nginx 访问控制
十、 Nginx日志处理
十一、 Nginx Cache
十二、 Nginx 负载均衡
十三、 Nginx简单优化
十四、 如何构建高性能的LEMP环境
十五、 Nginx服务监控
十六、 常见问题与错误处理.
十七、 相关资源下载
【前言】:
编写此技术指南在于推广普及NGINX在国内的使用,更方便的帮助大家了解和掌握NGINX
的一些使用技巧。本指南很多技巧来自于网络和工作中或网络上朋友们问我的问题.在此对
网络上愿意分享的朋友们表示感谢和致意!欢迎大家和我一起丰富本技术指南提出更好的建
议!请朋友们关注: http://www.linuxtone.org 技术分享社区! 互想学习共同进步!
一、 Nginx 基础知识
1、简介
Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器,也是一个 IMAP/POP3/SMTP 代理服
务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的,它已经在该站点运行超
过两年半了。Igor 将源代码以类BSD许可证的形式发布。尽管还是测试版,但是,Nginx 已经因为它的稳
定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名了。
更多的请见官方wiki: http://wiki.codemongers.com/
2、 Nginx的优点
nginx做为HTTP服务器,有以下几项基本特性:
1) 处理静态文件,索引文件以及自动索引;打开文件描述符缓冲.
2) 无缓存的反向代理加速,简单的负载均衡和容错.
3) FastCGI,简单的负载均衡和容错.
4) 模块化的结构。包括gzipping, byte ranges, chunked responses, 以及 SSI-filter等filter。
如果由FastCGI或其它代理服务器处理单页中存在的多个SSI,则这项处理可以并行运行,而不
需要相互等待。
5) 支持SSL 和 TLS SNI.
Nginx专为性能优化而开发,性能是其最重要的考量, 实现上非常注重效率 。它支持内核Poll模型,
能经受高负载的考验, 有报告表明能支持高达 50,000 个并发连接数。
Nginx具有很高的稳定性。其它HTTP服务器,当遇到访问的峰值,或者有人恶意发起慢速连接时,
也很可能会导致服务器物理内存耗尽频繁交换,失去响应,只能重启服务器。例如当前apache一旦上到
200个以上进程,web响应速度就明显非常缓慢了。而Nginx采取了分阶段资源分配技术,使得它的CPU与
内存占用率非常低。nginx官方表示保持10,000个没有活动的连接,它只占2.5M内存,所以类似DOS这
样的攻击对nginx来说基本上是毫无用处的。就稳定性而言, nginx比lighthttpd更胜一筹。
Nginx支持热部署。它的启动特别容易, 并且几乎可以做到7*24不间断运行,即使运行数个月也不
需要重新启动。你还能够在不间断服务的情况下,对软件版本进行进行升级。
Nginx采用master-slave模型, 能够充分利用SMP的优势,且能够减少工作进程在磁盘I/O的阻
塞延迟。当采用select()/poll()调用时,还可以限制每个进程的连接数。
Nginx代码质量非常高,代码很规范, 手法成熟, 模块扩展也很容易。特别值得一提的是强大
的Upstream与Filter链。 Upstream为诸如reverse proxy, 与其他服务器通信模块的编写奠定了很好的
基础。而Filter链最酷的部分就是各个filter不必等待前一个filter执行完毕。它可以把前一个filter
的输出做为当前filter的输入,这有点像Unix的管线。这意味着,一个模块可以开始压缩从后端服务器
发送过来的请求,且可以在模块接收完后端服务器的整个请求之前把压缩流转向客户端。
Nginx采用了一些os提供的最新特性如对sendfile (Linux 2.2+),accept-filter (FreeBSD
4.1+),TCP_DEFER_ACCEPT (Linux 2.4+) 的支持,从而大大提高了性能
二、 Nginx 安装及调试
1、Pcre 安装
make && make install
cd ../
2. nginx 编译安装
--with-openssl=/usr/local/openssl
make && make install
更详细的模块定制与安装请参照官方wiki.
3、Nginx 配置文件测试:
2008/12/16 09:08:35 [info] 28412#0: the configuration file /usr/local/nginx/conf/nginx.conf
syntax is ok
2008/12/16 09:08:35 [info] 28412#0: the configuration file /usr/local/nginx/conf/nginx.conf was
tested successfully
3、 Nginx 启动:
4、 Nginx 配置文件修改重新加载:
三、 Nginx Rewrite
1. Nginx Rewrite 基本标记(flags)
last - 基本上都用这个Flag。
※相当于Apache里的[L]标记,表示完成rewrite,不再匹配后面的规则
break - 中止Rewirte,不再继续匹配
redirect - 返回临时重定向的HTTP状态302
permanent - 返回永久重定向的HTTP状态301
※原有的url支持正则 重写的url不支持正则
2. 正则表达式匹配,其中:
~ 为区分大小写匹配
~* 为不区分大小写匹配
!~ 和 !~* 分别为区分大小写不匹配及不区分大小写不匹配
3. 文件及目录匹配,其中:
-f 和 !-f 用来判断是否存在文件
-d 和 !-d 用来判断是否存在目录
-e 和 !-e 用来判断是否存在文件或目录
-x 和 !-x 用来判断文件是否可执行
3. Nginx 的一些可用的全局变量,可用做条件判断:
$content_length
$content_type
$document_root
$document_uri
$host
$http_user_agent
$http_cookie
$limit_rate
$request_body_file
$request_method
$remote_addr
$remote_port
$remote_user
$request_filename
$request_uri
$query_string
$scheme
$server_protocol
$server_addr
$server_name
$server_port
$uri
四、 Nginx Redirect
将所有linuxtone.org与netseek.linuxtone.org域名全部自跳转到http://www.linuxtone.org
listen 80;
server_name linuxtone.org netseek.linuxtone.org;
index index.html index.php;
root /data/www/wwwroot;
if ($host !~ "^www\.linxtone\.org$") {
rewrite ^(.*) http://www.linuxtone.org$1 redirect;
}
.....................
}
五、 Nginx 目录自动加斜线:
rewrite ^/(.*)([^/])$ http://$host/$1$2/ permanent;
}
六、 Nginx Location
1.基本语法:[和上面rewrite正则匹配语法基本一致]
location [=|~|~*|^~] /uri/ { … }
~ 为区分大小写匹配
~* 为不区分大小写匹配
!~ 和 !~* 分别为区分大小写不匹配及不区分大小写不匹配
示例1:
# matches the query / only.
# 只匹配 / 查询。
}
匹配任何查询,因为所有请求都已 / 开头。但是正则表达式规则和长的块规则将被优先和查询匹配
示例2:
# matches any query beginning with /images/ and halts searching,
# so regular expressions will not be checked.
# 匹配任何以 /images/ 开头的任何查询并且停止搜索。任何正则表达式将不会被测试。
}
示例3:
# matches any request ending in gif, jpg, or jpeg. However, all
# requests to the /images/ directory will be handled by
# 匹配任何以 gif、jpg 或 jpeg 结尾的请求。
}
七、 Nginx expires
1.根据文件类型判断,添加expires
location ~* \.(js|css|jpg|jpeg|gif|png|swf)$ {
if (-f $request_filename) {
root /data/www/wwwroot/bbs;
expires 1d;
break;
}
}
2、根据某个目录判断,添加expires
location ~ ^/(images|javascript|js|css|flash|media|static)/ {
root /data/www/wwwroot/down;
expires 30d;
}
八、 Nginx 防盗链
1. 针对不同的文件类型
location ~* ^.+\.(gif|jpg|png|swf|flv|rar|zip)$ {
valid_referers none blocked server_names *.linuxtone.org linuxtone.org http://localhost baidu.com;
if ($invalid_referer) {
rewrite ^/ http://www.linuxtone.org/images/default/logo.gif;
# return 403;
}
}
2. 针对不同的目录
root /data/www/wwwroot/bbs/img/;
valid_referers none blocked server_names *.linuxtone.org http://localhost baidu.com;
if ($invalid_referer) {
rewrite ^/ http://www.linuxtone.org/images/default/logo.gif;
#return 403;
}
}
3. 同实现防盗链和expires的方法
location ~* ^.+\.(gif|jpg|png|swf|flv|rar|zip)$ {
valid_referers none blocked server_names *.linuxtone.org linuxtone.org http://localhost ;
if ($invalid_referer) {
rewrite ^/ http://www.linuxtone.org/images/default/logo.gif;
}
access_log off;
root /data/www/wwwroot/bbs;
expires 1d;
break;
}
九、 Nginx 访问控制
1. Nginx 身份证验证
#mkdir htpasswd
/usr/local/apache2/bin/htpasswd -c /usr/local/nginx/conf/htpasswd/tongji linuxtone
#添加用户名为linuxtone
New password: (此处输入你的密码)
Re-type new password: (再次输入你的密码)
Adding password for user
http://count.linuxtone.org/tongji/data/index.html(目录存在/data/www/wwwroot/tongji/data/目录
下)
将下段配置放到虚拟主机目录,当访问http://count.linuxtone/tongji/即提示要密验证:
root /data/www/wwwroot/count;
auth_basic "LT-COUNT-TongJi";
auth_basic_user_file /usr/local/nginx/conf/htpasswd/tongji;
}
2. Nginx 禁止访问某类型的文件.
如,Nginx下禁止访问*.txt文件,配置方法如下.
if (-f $request_filename) {
root /data/www/wwwroot/linuxtone/test;
#rewrite …..可以重定向到某个URL
break;
}
}
方法2:
root /data/www/wwwroot/linuxtone/test;
deny all;
}
实例:
禁止访问某个目录
deny all;
}
3. 使用ngx_http_access_module限制ip访问
deny 192.168.1.1;
allow 192.168.1.0/24;
allow 10.1.1.0/16;
deny all;
}
详细参见wiki: http://wiki.codemongers.com/NginxHttpAccessModule#allow
4. Nginx 下载限制并发和速率
server {
listen 80;
server_name down.linuxotne.org;
index index.html index.htm index.php;
root /data/www/wwwroot/down;
#Zone limit
location / {
limit_conn linuxtone 1;
limit_rate 20k;
}
..........
}
只允许客房端一个线程,每个线程20k.
【注】limit_zone linuxtone $binary_remote_addr 10m; 这个可以定义在主的
5. Nginx 实现Apache一样目录列表
autoindex on;
}
6. 上文件大小限制
主配置文件里加入如下,具体大小根据你自己的业务做调整。
十、 Nginx 日志处理
1.Nginx 日志切割
59 23 * * * /usr/local/sbin/logcron.sh /dev/null 2>&1
# cat /usr/local/sbin/logcron.sh
log_dir="/data/logs"
time=`date +%Y%m%d`
/bin/mv ${log_dir}/access_linuxtone.org.log ${log_dir}/access_count.linuxtone.org.$time.log
更多的日志分析与处理就关注(同时欢迎你参加讨论):http://bbs.linuxtone.org/forum-8-1.html
2.利用AWSTATS分析NGINX日志
设置好Nginx日志格式,仍后利用awstats进行分析.
请参考: http://bbs.linuxtone.org/thread-56-1-1.html
3. Nginx 如何不记录部分日志
日志太多,每天好几个G,少记录一些,下面的配置写到server{}段中就可以了
access_log off;
}
十一、Nginx Cache服务配置
如果需要将文件缓存到本地,则需要增加如下几个子参数:
proxy_store_access user:rw group:rw all:rw;
proxy_temp_path 缓存目录;
其中,
proxy_store on 用来启用缓存到本地的功能,
proxy_temp_path 用来指定缓存在哪个目录下,如:proxy_temp_path html;
在经过上一步配置之后,虽然文件被缓存到了本地磁盘上,但每次请求仍会向远端拉取
文件,为了避免去远端拉取文件,必须修改proxy_pass:
proxy_pass http://mysvr;
}
即改成有条件地去执行proxy_pass,这个条件就是当请求的文件在本地的
proxy_temp_path指定的目录下不存在时,再向后端拉取。
更多更高级的应用可以研究ncache,官方网站: http://code.google.com/p/ncache/
详细安装请参照http://bbs.linuxtone.org 应用加速版ncache相关的贴子.
十二、Nginx 负载均衡
1. Nginx 负载均衡基础知识
nginx的upstream目前支持4种方式的分配
1)、轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。
2)、weight
指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。
2)、ip_hash
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。
3)、fair(第三方)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。
4)、url_hash(第三方)
2. Nginx 负载均衡实例1
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中增加
每个设备的状态设置为:
a) down 表示单前的server暂时不参与负载
b) weight 默认为1.weight越大,负载的权重就越大。
c) max_fails :允许请求失败的次数默认为1.当超过最大次数时,返回proxy_next_upstream 模块定义的错误
d) fail_timeout:max_fails次失败后,暂停的时间。
e) backup: 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。
nginx支持同时设置多组的负载均衡,用来给不用的server来使用。
client_body_in_file_only 设置为On 可以讲client post过来的数据记录到文件中用来做debug
client_body_temp_path 设置记录文件的目录 可以设置最多3层目录
location 对URL进行匹配.可以进行重定向或者进行新的代理 负载均衡
3. Nginx 负载均衡实例 2
按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓
存时比较有效,也可以用作提高Squid缓存命中率.
简单的负载均等实例:
#vi nginx.conf //nginx主配置文件核心配置
.........
upstream my.linuxtone.org {
ip_hash;
server 127.0.0.1:8080;
server 192.168.169.136:8080;
server 219.101.75.138:8080;
server 192.168.169.117;
server 192.168.169.118;
server 192.168.169.119;
}
.........
include vhosts/linuxtone_lb.conf;
.........
# vi proxy.conf
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 50m;
client_body_buffer_size 256k;
proxy_connect_timeout 30;
proxy_send_timeout 30;
proxy_read_timeout 60;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
proxy_max_temp_file_size 128m;
proxy_store on;
proxy_store_access user:rw group:rw all:r;
#nginx cache
#client_body_temp_path /data/nginx_cache/client_body 1 2;
proxy_temp_path /data/nginx_cache/proxy_temp 1 2;
#vi linuxtone_lb.conf
listen 80;
server_name my.linuxtone.org;
index index.php;
root /data/www/wwwroot/mylinuxtone;
if (-f $request_filename) {
break;
}
if (-f $request_filename/index.php) {
rewrite (.*) $1/index.php break;
}
error_page 403 http://my.linuxtone.org/member.php?m=user&a=login;
location / {
if ( !-e $request_filename) {
proxy_pass http://my.linuxtone.org;
break;
}
include /usr/local/nginx/conf/proxy.conf;
}
}
十三、Nginx简单优化
1. 减小nginx编译后的文件大小 (Reduce file size of nginx)
默认的nginx编译选项里居然是用debug模式(-g)的(debug模式会插入很多跟踪和
ASSERT之类),编译以后一个nginx有好几兆。去掉nginx的debug模式编译,编译以
后只有几百K
在 auto/cc/gcc,最后几行有:
CFLAGS=”$CFLAGS -g”
注释掉或删掉这几行,重新编译即可。
2. 修改Nginx的header伪装服务器
1) 修改nginx.h
#define NGINX_VERSION "1.8"
#define NGINX_VER "LTWS/" NGINX_VERSION
#define NGINX_VAR "NGINX"
#define NGX_OLDPID_EXT ".oldbin"
2) 修改nginx_http_header_filter_module
#vi nginx-0.7.30/src/http/ngx_http_header_filter_module.c
将如下
修改为
a) 修改nginx_http_header_filter_module
#vi nginx-0.7.30/src/http/ngx_http_special_response.c
将如下:
"<hr><center>" NGINX_VER "</center>" CRLF
"</body>" CRLF
"</html>" CRLF
;
static u_char ngx_http_error_tail[] =
"<hr><center>nginx</center>" CRLF
"</body>" CRLF
"</html>" CRLF
;
修改为:
"<center> "NGINX_VER" </center>" CRLF
"<hr><center>http://www.linuxtone.org</center>" CRLF
"</body>" CRLF
"</html>" CRLF
;
static u_char ngx_http_error_tail[] =
"<hr><center>LTWS</center>" CRLF
"</body>" CRLF
"</html>" CRLF
;
修改后重新编译一下环境,
404错误的时候显示效果图(如果没有指定错误页的话):
利用curl命令查看服务器header
3. 为特定的CPU指定CPU类型编译优化.
默认nginx使用的GCC编译参数是-O
需要更加优化可以使用以下两个参数
--with-cpu-opt=opteron \
使得编译针对特定CPU以及增加GCC的优化.
此方法仅对性能有所改善并不会有很大的性能提升,供朋友们参考.
CPUD类型确定:
编译优化参数参考:http://en.gentoo-wiki.com/wiki/Safe_Cflags
4. Tcmalloc优化Nginx 性能
# tar zxvf libunwind-0.99-alpha.tar.gz
# cd libunwind-0.99-alpha/
# CFLAGS=-fPIC ./configure
# make CFLAGS=-fPIC
# make CFLAGS=-fPIC install
# wget http://google-perftools.googlecode.com/files/google-perftools-0.98.tar.gz
# tar zxvf google-perftools-0.98.tar.gz
# cd google-perftools-0.98/
# ./configure
# make && make install
# echo "/usr/local/lib" > /etc/ld.so.conf.d/usr_local_lib.conf
# ldconfig
# lsof -n | grep tcmalloc
编译nginx 加载google_perftools_module:
在主配置文件加入nginx.conf 添加:
5. 内核参数优化
# vi /etc/sysctl.conf
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 5000 65000
#使配置立即生效
/sbin/sysctl -p
十四、如何构建高性的LEMP
请参见: http://www.linuxtone.org/lemp/lemp.pdf
1、 提供完整的配置脚本下载:http://www.linuxtone.org/lemp/scripts.tar.gz
2、 提供NGINX常见配置范例含(虚拟主机,防盗链,Rewrite,访问控制,负载均衡Discuz相关程序静态化及等等),你只要稍稍修改即可线上应用。
3、将原版的xcache替换成EA,并提供相关简单调优脚本及配置文件。
更多的及更新资料请关注: http://www.linuxtone.org
十五、Nginx监控
1、 RRDTOOL+Perl脚本画图监控
先安装好rrdtool ,关于rrdtool本文不作介绍,具体安装请参照linuxtone监控版块.
#wget http://blog.kovyrin.net/files/mrtg/rrd_nginx.pl.txt
#mv rrd_nginx.pl.txt rrd_nginx.pl
#chmod a+x rrd_nginx.pl
#vi rrd_nginx.pl //配置脚本文件设置好路径
use RRDs;
use LWP::UserAgent;
# define location of rrdtool databases
my $rrd = '/data/www/wwwroot/nginx/rrd';
# define location of images
my $img = '/data/www/wwwroot/nginx/html';
# define your nginx stats URL
my $URL = "http:// 219.32.205.13/nginx_status";
…………
【注】根据自己具体的状况修改相应的路径.
#crontab –e //加入如下
重启crond后,通过配置nginx虚拟主机指到/data/www/wwwroot/nginx/html目录,通过crond
自动执行perl脚本会生成很多图片.
http://xxx/connections-day.png即可看到服务器状态图。
2、 官方Nginx-rrd 监控服务(多虚拟主机)(推荐)
网址:http://www.nginx.eu/nginx-rrd.html
此解决方案其实是基于上述监控方案的一个改进和增强,同样先安装好rrdtool这个画图工
具和相应的perl模块再做如下操作:
先建立好生成的库存和图片存放录
#cd /usr/local/sbin
#wget http://www.nginx.eu/nginx-rrd/nginx-rrd-0.1.4.tgz
#tar zxvf nginx-rrd-0.1.4.tgz
#cd nginx-rrd-0.1.4
#cd etc/
#cp nginx-rrd.conf /etc
#cd etc/cron.d
#cp nginx-rrd.cron /etc/cron.d
#cd /usr/local/src/nginx-rrd-0.1.4/html
# cp index.php /data/www/wwwroot/nginx/html/
#cd /usr/local/src/nginx-rrd-0.1.4/usr/sbin
#cp * /usr/sbin/
#vi /etc/nginx-rrd.conf
#
# dir where rrd databases are stored
RRD_DIR="/data/www/wwwroot/nginx/rrd";
# dir where png images are presented
WWW_DIR="/data/www/wwwroot/nginx/html";
# process nice level
NICE_LEVEL="-19";
# bin dir
BIN_DIR="/usr/sbin";
# servers to test
# server_utl;server_name
SERVERS_URL="http://219.32.205.13/nginx_status;219.32.205.13
http://www.linuxtone.org/nginx_status;www.linuxtone.org"" //根据你的具体情况做调整.
SEVERS_URL 格式 http://domain1/nginx_status;domain1 http://domain2/nginx_status;domain2
这种格式监控多虚拟主机连接状态:
重点启crond服务,仍后通过http://219.32.205.13/nginx/html/ 即可访问。配置过程很简单!
3、 CACTI模板监控Nginx
利用Nginx_status状态来画图实现CACTI监控
nginx编译时允许http_stub_status_module
# vi /usr/local/nginx/conf/nginx.conf
stub_status on;
access_log off;
allow 192.168.1.37;
deny all;
}
# wget http://forums.cacti.net/download.php?id=12676
# tar xvfz cacti-nginx.tar.gz
# cp cacti-nginx/get_nginx_socket_status.pl /data/cacti/scripts/
# cp cacti-nginx/get_nginx_clients_status.pl /data/cacti/scripts/
# chmod 755 /data/cacti/scripts/get_nginx*
检测插件
# /data/cacti/scripts/get_nginx_clients_status.pl http://192.168.1.37/nginx_status
在cacti管理面板导入
cacti_graph_template_nginx_sockets_stat.xml
十六、常见问题与错误处理
1、 400 bad request错误的原因和解决办法
配置nginx.conf相关设置如下.
large_client_header_buffers 4 64k;
根据具体情况调整,一般适当调整值就可以。
2、 Nginx 502 Bad Gateway错误
或者尝试设置:
3、 Nginx出现的413 Request Entity Too Large错误
这个错误一般在上传文件的时候会出现,
编辑Nginx主配置文件Nginx.conf,找到http{}段,添加
如果运行php的话这个大小client_max_body_size要和php.ini中的如下值的最大值
一致或者稍大,这样就不会因为提交数据大小不一致出现的错误。
upload_max_filesize = 2M
4、 解决504 Gateway Time-out(nginx)
遇到这个问题是在升级discuz论坛的时候遇到的
一般看来, 这种情况可能是由于nginx默认的fastcgi进程响应的缓冲区太小造成的,
这将导致fastcgi进程被挂起, 如果你的fastcgi服务对这个挂起处理的不好, 那么最后就
极有可能导致504 Gateway Time-out
现在的网站, 尤其某些论坛有大量的回复和很多内容的, 一个页面甚至有几百K。
默认的fastcgi进程响应的缓冲区是8K, 我们可以设置大点
在nginx.conf里, 加入:
这表示设置fastcgi缓冲区为8×128k
当然如果您在进行某一项即时的操作, 可能需要nginx的超时参数调大点,例如设置成60秒:
只是调整了这两个参数, 结果就是没有再显示那个超时, 可以说效果不错, 但是也
可能是由于其他的原因, 目前关于nginx的资料不是很多, 很多事情都需要长期的经验
累计才有结果, 期待您的发现哈!
5、 如何使用Nginx Proxy
朋友一台服务器运行tomcat 为8080端口,IP:192.168.1.2:8080,另一台机器
IP:192.168.1.8. 朋友想通过访问http://192.168.1.8即可访问tomcat服务.配置如下:
在192.168.1.8的nginx.conf上配置如下:
listen 80;
server_name java.linuxtone.org
location / {
proxy_pass http://192.168.1.2:8080;
include /usr/local/nginx/conf/proxy.conf;
}
}
6、 如何关闭Nginx的LOG
error_log /dev/null;
十七、相关资源下载
1. nginx配置示例及脚本下载:
# wget http://www.linuxtone.org/lemp/scripts.tar.gz #此脚本范例定期更新.
php不能加载mysql Fatal error: Call to undefined function mysql_connect()
首先看下:
调用了没有定义的函数
你看看你的php.ini的配置
找到
extension=php_mysql.dll
extension=php_mysqli.dll
把前面的分号去掉
如以上没有问题再检查:
先用phpinfo();看一下是否支持mysql。
要是没有,还是配置有问题。
Loaded Configuration File 看看php.ini是读哪个路径下的
php.ini 里extension = php_mysql.dll前的分号已经去掉了,extension_dir = "X:/php/ext"也改为了自己ext文件夹的路径,libmysql.dll和php5ts.dll也复制到Windows目录下的system32文件夹下
请参考
Nginx简单的防盗链和带宽限制
很多时候,服务不是被用户流量击垮,而是被大量的对你没有任何贡献的盗链击倒,所以作为一个web站点防盗链是首先要考虑的问题,目前来说,对于各个web服务器,简单的防盗链方法多数是做rewrite,判断referer是否有效,当然高端的伪造referer的情况不在这里讨论。
在apache下,防盗链的方法有很多,你可以看看apache的日志,有多少是外部直接referer过来的,有可能比内部引用还多,尤其是图片和下载类站点更加明显。在apache下,最简单的防盗链使用类似这个形式:
SetEnvIfNoCase Referer "^http://www.google.com" local_ref=1
SetEnvIfNoCase Referer "^http://google.com" local_ref=1
<filesmatch "\.(txt|doc|mp3|zip|rar|jpg|gif)">
Order Allow,Deny
Allow from env=local_ref
或者在apache下使用RewriteEngine on,然后使用RewriteCond {HTTP_REFERER} 来定义,这些都是防止比较低级的盗链,如果是面对迅雷或者其他的话,这个远远不够,但是不是这里讨论的范围。
对于nginx而言,本身也有简单的防盗链模块ngx_http_referer_module,配置比较简单,定义文件类型:
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
valid_referers none blocked server_names *.163.com 163.com baidu.com;
if ($invalid_referer) {return 403;}
expires 30d;
}
具体的可以参考这里:http://wiki.nginx.org//NginxHttpLimitZoneModule,同时还有一个第三的防盗链相关模块,ngx_http_accesskey_module:
location /download {
accesskey on;
accesskey_hashmethod md5;
accesskey_arg "key";
accesskey_signature "mypass$remote_addr";
}
具体的使用方法:http://wiki.nginx.org//NginxHttpAccessKeyModule
对于带宽限制,apache可以动态编译一些模块进去,mod_evasive20.so和mod_bw.so都是对防止简单的dos和带宽限制而存在的,而对于nginx,可以使用nginx的标准模块ngx_http_limit_zone_module,进行会话的并发连接数控制:
http {
limit_zone one $binary_remote_addr 10m;
#定义一个叫“one”的记录区,总容量为 10M,以变量 $binary_remote_addr 作为会话的判断基准(即一个地址一个会话)
...
server {
...
location /icons_rar/ {
limit_conn one 2;
limit_rate 2k;
}
limit_conn 一个会话只能进行两个连接。超过一个,则返回503。
imit_rate 来控制该目录的下载速度为2KB/S
# 如果限制当前server内域名下所有目录下载显示则写 / 如:
server {
...
location / {
limit_conn one 2;
limit_rate 2k;
}
之后用迅雷下载文件测试:
这是简单的nginx的方案,更高级的应用应该是在客户端类型或者根据日志分析后,针对具体问题做文章,例如对$http_user_agent的特殊内容进行匹配,然后返回503。
为什么要返回503?如果直接返回403,有可能被下载工具发现,403的状态被认为被禁止了,然后进行调整继续作案。而返回一个503,对服务器来说影响不大,只占用一个nginx的线程而已。
先说到这里,以后再继续补充。
【原创】nginx负载均衡实例,亲测
nginx不单可以作为强大的web服务器,也可以作为一个七层的反向代理服务器,而且nginx还可以按照调度规则实现动态、静态页面的分离,可以按照轮询、ip哈希、URL哈希、权重等多种方式对后端服务器做负载均衡,同时还支持后端服务器的健康检查。
如果将web服务器集群当做一个城池,那么负载均衡服务器就相当于城门,重要性不言而喻,如果“城门”关闭了,与外界的通道也就掐断了,如果只有一台nginx负载均衡服务器,当该服务器发生故障时,则会整个网站无法访问,因此,就需要两台以上的nginx负载均衡服务器,实现故障转移与高可用,双机高可用暂不详细介绍。
下面就是一个生产实例。
aaa.liuxinxiu.com 和 bbb.liuxinxiu.com 域名均指向 Nginx 所在的服务器IP。
用户访问http://aaa.liuxinxiu.com/,将其负载均衡到120.9.123.121:80、202.108.22.142:80 这两台服务器。
用户访问http://bbb.liuxinxiu.com/,将其负载均衡到60.5.185.59:80、120.9.123.121:80、202.108.22.142:80 这三台服务器。
============================================================================
注意:
ip_hash来代替默认的rr方式,即可以将某客户端IP的请求通过哈希算法定位到同一台后端web服务器上,这样避免了session丢失,解决了session问题。但ip_hash指令无法保证后端服务器的负载均衡,可能有些后端服务器接收的请求多,有些后端服务器接收的请求少;这样失去了负载均衡的意义,所以,如果后端的动态应用服务器做到session共享,还是建议采用后端服务器的session共享方式来代替nginx的ip_hash方式。
===================================================================】】
以下是AAA组分配的2组负载均衡服务器,规则更加反应速度,快者NGINX优先选择,ip_hash; 这种形式只能使用IP分配!
BBB组分配的三组负载均衡服务器,采用默认顺序规则,由上至下依次选择,如果最上边60.5.185.59这组服务器DOWN掉选择中间120.9.123.121这组,如果中间这组挂掉则NGINX自动202.108.22.142最下边这组IP主机!
BBB虚拟主机SERVER中的配置内容:
注,选择中的部分:
#root /ftp/101;
index index.html index.htm index.php;
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
expires 30d;
}
location ~ .*\.(htm|html|js|css)$ {
expires 1h;
}
可以忽略不添加,或者注释掉也可以!!!!!!
AAA在SERVER中的添加内容和BBB类似!
Nginx Location 语法,与简单配置
一、介绍Nginx是俄罗斯人编写的十分轻量级的HTTP服务器,Nginx,它的发音为“engine X”, 是一个高性能的HTTP和反向代理服务器,同时也是一个IMAP/POP3/SMTP 代理服务器.
二、Location语法语法:location [=|~|~*|^~] /uri/ { … }
注:
1、~ 为区分大小写匹配
2、~* 为不区分大小写匹配
3、!~和!~*分别为区分大小写不匹配及不区分大小写不匹配
示例一:
location / { }
匹配任何查询,因为所有请求都以 / 开头。但是正则表达式规则将被优先和查询匹配。
示例二:
location =/ {}
仅仅匹配/
示例三:
location ~* \.(gif|jpg|jpeg)$ {
rewrite \.(gif|jpg)$ /logo.png;
}
注:不区分大小写匹配任何以gif,jpg,jpeg结尾的文件
三、ReWrite语法
last - 基本上都用这个Flag。
break - 中止Rewirte,不在继续匹配
redirect - 返回临时重定向的HTTP状态302
permanent - 返回永久重定向的HTTP状态301
1、下面是可以用来判断的表达式:
-f和!-f用来判断是否存在文件
-d和!-d用来判断是否存在目录
-e和!-e用来判断是否存在文件或目录
-x和!-x用来判断文件是否可执行
2、下面是可以用作判断的全局变量
例:http://localhost:88/test1/test2/test.php
$host:localhost
$server_port:88
$request_uri:http://localhost:88/test1/test2/test.php
$document_uri:/test1/test2/test.php
$document_root:D:\nginx/html
$request_filename:D:\nginx/html/test1/test2/test.php
四、Redirect语法
server {
listen 80;
server_name start.igrow.cn;
index index.html index.php;
root html;
if ($http_host !~ "^www\.itlearner\.com$ {
rewrite ^(.*) http://www.itlearner.com$1 redirect;
}
}
五、防盗链location ~* \.(gif|jpg|swf)$ {
valid_referers none blocked start.igrow.cn sta.igrow.cn;
if ($invalid_referer) {
rewrite ^/ http://$host/logo.png;
}
}
六、根据文件类型设置过期时间
location ~* \.(js|css|jpg|jpeg|gif|png|swf)$ {
if (-f $request_filename) {
expires 1h;
break;
}
}
七、禁止访问某个目录
location ~* \.(txt|doc)${
root /data/www/wwwroot/linuxtone/test;
deny all;
}
++ 一些可用的全局变量
$args
$content_length
$content_type
$document_root
$document_uri
$host
$http_user_agent
$http_cookie
$limit_rate
$request_body_file
$request_method
$remote_addr
$remote_port
$remote_user
$request_filename
$request_uri
$query_string
$scheme
$server_protocol
$server_addr
$server_name
$server_port
$uri
nginx负载均衡和lvs负载均衡的比较分析【转载】
lvs和nginx都可以用作多机负载的方案,它们各有优缺,在生产环境中需要好好分析实际情况并加以利用。
首先提醒,做技术切不可人云亦云,我云即你云;同时也不可太趋向保守,过于相信旧有方式而等别人来帮你做垫被测试。把所有即时听说到的好东西加以钻研,从而提高自己对技术的认知和水平,乃是一个好习惯。
下面来分析一下两者:
一、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是最完美的方案了。
nginx也可作为网页静态服务器,不过超出了本文讨论的范畴,简单提一下。
具体的应用还得具体分析,如果是比较小的网站(日PV<1000万),用nginx就完全可以了,如果机器也不少,可以用DNS轮询,lvs所耗费的机器还是比较多的;大型网站或者重要的服务,机器不发愁的时候,要多多考虑利用lvs。