error_log 错误日志
Include 包含进来的文件
Pid 记录进程
User 指定用户,包括日志访问路径的权限等.指定谁来运行nginx
worker_cpu_affinity
Work_connection 每一个进程可以连接的数目。
worker_processes 最大工作进程数
error_log 日志有6个级别:debug|info|notice|warn|error|crit
Nginx支持将不同的虚拟主机的日志记录在不同的地方,如下示例:
http{
error_log logs/http_error.log error;
server{
server_name one;
access_log logs/one_access.log;
error_log logs/one_error.log error;
}
server{
server_name two;
access_log logs/two_access.log;
error_log logs/two_error.log error;
}
}
注意:error_log off不是禁用日志,而是创建一个名为off的日志,要禁用日志,可以这么写:error_log /dev/null crit;
日志格式:
log_format main '$remote_addr - $remote_user [$time_local]"$request" '
# '$status $body_bytes_sent"$http_referer" '
# '"$http_user_agent""$http_x_forwarded_for"';
如上图所示
$remote_addr 访问的ip
$remote_user 请求的用户
$time_local 访问的时间
$request 请求方式
$status 响应码
$body_bytes_sent"$http_referer" 请求源
http_x_forwarded_for:在经过代理时,代理把你的本来IP加在此头信息中,传输你的原始IP
等等,如上是nginx的日志,默认是main格式的日志,放在相对路劲logs文件夹下。
// 全局区
worker_processes 1; // 有1个工作的子进程,可以自行修改,但太大无益,因为要争夺CPU,一般设置为 CPU数*核数
Event {
// 一般是配置nginx连接的特性
// 如1个worker能同时允许多少连接
worker_connections 1024; // 这是指 一个子进程最大允许连1024个连接
}
http {
//这个是协议级别
include mime.types;
default_type application/octet-stream;
keepalive_timeout 65;
gzip on;
server {
//这个是服务器级别
listen 80;
server_name localhost;
location / {
//这个是请求级别
root html;
index index.html index.htm;
}
}
}
server {
listen 80; #监听端口
server_name a.com; #监听域名
location / {
root/var/www/a.com; #根目录定位
indexindex.html;
}
}
server {
listen 80; #监听端口
server_name a.b.com; #监听域名
location / {
root/var/www/a.com; #根目录定位
indexindex.html;
}
}
server {
listen 8080;
server_name 192.168.1.204;
location / {
root /var/www/html8080;
index index.html;
}
}
server {
listen 8081;
server_name 192.168.1.204;
location / {
root /var/www/html8080;
index index.html;
}
}
Location区段,通过指定模式来与客户端请求的URI相匹配,基本语法如下: location [=|~|~*|^~|@] pattern{……}
server {
server_name localhost;
location /abc{
……
}
}
那么,如下是对的:
http://xxxxxx.com/abc
http://xxxxxx.com/abc?p1=11&p2=22
http://xxxxxx.com/abc
http://xxxxxx.com/abcde
server {
server_name localhost;
location = /abc {
……
}
}
那么,如下是对的:
http://xxxxxxx/abc
http://xxxxxxx/abc/?p1=11&p2=22
如下是错的:
http://xxxxxxx/abc
http://xxxxxxx/abcde
server {
server_name localhost;
location ~ ^/abc$ {
……
}
}
那么,如下是对的:
http://xxxxxxx/abc
http://xxxxxxx/abc?p1=11&p2=22
如下是错的:
http://xxxxxxx/ABC
http://xxxxxxx/abc/
http://xxxxxxx/abcde
server {
server_name sishuok.com;
location ~* ^/abc$ {
……
}
}
那么,如下是对的:
http://xxxxxxxxx/abc
http://xxxxxxxxx/ABC
http://xxxxxxxxx/abc?p1=11&p2=22
如下是错的:
http://xxxxxxxxx/abc/
http://xxxxxxxxx/abcde
不同的是,如果模式匹配, 那么就停止搜索其他模式了。
这些区段客户端不能访问,只可以由内部产生的请 求来访问,如try_files或error_page等
1:带有“=“的精确匹配优先
2:没有修饰符的精确匹配
3:正则表达式按照他们在配置文件中定义的顺序
4:带有“^~”修饰符的,开头匹配
5:带有“~”或“~*” 修饰符的,如果正则表达式与URI匹配
6:没有修饰符的,如果指定字符串与URI开头匹配
location = / { # 只匹配 / 的查询. [ configuration A ] }
location / { # 匹配任何以 / 开始的查询,但是正则表达式与一些较长的字符串将被首先匹配。 [ configuration B ] }
location ^~ /images/ { # 匹配任何以 /images/ 开始的查询并且停止搜索,不检查正则表达式。 [ configuration C ] }
location ~* \.(gif|jpg|jpeg)$ { # 匹配任何以gif, jpg, or jpeg结尾的文件,但是所有 /images/ 目录的请求将在Configuration C中处 理。 [ configuration D ] }
各请求的处理如下例:
■/ → configuration A
■/documents/document.html → configuration B
■/images/1.gif → configuration C
■/documents/1.jpg → configuration D
location = / {
root /var/www/html/;
index index.htm index.html;
}
location / {
root /usr/local/nginx/html;
index index.html index.htm;
}
访问 http://xxx.com/
定位流程是
1: 精准匹配中 ”/” ,得到index页为index.htm,是location的
2: 再次访问 /index.htm , 内部转跳uri已经是”/index.htm” ,一般匹配 “/”
根目录为/usr/local/nginx/html
3: 最终结果,访问了 /usr/local/nginx/html/index.htm
4: 返回结果如果linux下/usr/local/nginx/html目录下有index.htm就返回没有报404
location / {//模糊
root /usr/local/nginx/html;
index index.html index.htm;
}
location ~ image {//相对准确
root /var/www/image;
index index.html;
}
访问 http://xx.com/image/logo.png
1此时, “/” 与”/image/logo.png” 都能匹配
2图片真正会访问 /var/www/image/logo.png
3默认正则的优先级高于一般匹配
location / {//模糊
root /usr/local/nginx/html;
index index.html index.htm;
}
location /foo {//相对准确
root /var/www/html;
index index.html;
}
访问 http://xxx.com/foo
1对于uri “/foo”, 两个location的patt,都能匹配他们
2即‘/’能从左前缀匹配‘/foo’, ‘/foo’也能左前缀匹配’/foo’,
3此时, 真正访问 /var/www/html/index.html
4匹配的最高原则是:按目录最精细,准确的来定位,按访问的域来匹配
5取域的最小交集作为访问路径(存在特殊)。
没有代理的时候,客户端访问服务器是直接访问的,为了找到专门过滤请求,或让请求排队的中间人我们找来了代理。比如我们的的软件,抢票的软件,它都是为客户端服务的。这个类型的代理我们就称之为正向代理。
如上图所示,三个小人不直接请求原来的服务器了,而是通过代理服务器请求服务器,这就是正向代理,然而现在的问题是所有的请求都压在了一个服务器上了,那么怎么办呢。此时我们就要增加真实的服务器。
随着用户量的增加,我们需要在后端增加服务器,这时候客户端不知道怎么访问到每台响应的服务器,就需要把服务器的信息告诉代理,让代理服务器代为转发,此时代理服务器主要是为服务端转发服务的就是我们所说的反向代理了。
6.3 反向代理配置
upstream apachephp {
server 192.168.232.131:8080;
}
server {
listen 80;
server_name www.quancha.cn;
access_log logs/quancha.access.log main;
error_log logs/quancha.error.log;
root html;
index index.html index.htm index.php;
## send request back to apache ##
location / {
proxy_pass http://apachephp;
}
}
如上代理配置nginx监听的www.quancha.cn:8080转发到了192.168.232.131:8080端口http://apachephp作为代理的媒介用来做转发的依据这就是反向代理的配置。
Nginx实现动静分离,其实就是在反向代理的时候,如果是静态资源,那么就直 接从Nginx发布的路径去读取,或者从静态资源服务器中读取,而不需要从动态资源服务器获取了,或者甚至不需要访问后台服务器。但是要注意:这种情况下需要保证后端跟前端的程序保持一致,可以使用Rsync 做服务端自动同步或者使用NFS、MFS分布式共享存储。
如上图所示,我们把项目的静态资源放在nginx服务器上直接返回给客户端,而动态解析的jsp则放在了后台服务器上。
upstream statics{
server s101:80 weight=1; #访问配置了静态页面的nginx
server s102:80 weight=1; #访问配置了静态页面的nginx
server s103:80 weight=1; #访问配置了静态页面的nginx
}
upstream tomcats{
server s101:8080 weight=1; #访问tomcat
server s102:8080 weight=1; #访问tomcat
server s103:8080 weight=1; #访问tomcat
}
server{
listen 80;
server_name s100;
access_log off;
location ~* \.(png|html|js|css)$ {
proxy_pass http://statics;
#所有以.png .html .js .css结尾的url进入此路径
}
location / {
proxy_pass http://tomcats;
#其它url进入此路径
}
}
主机s100,s101, s102上分别配置nginx 和 tomcat(略)
server{
listen 80;
server_name s101;
location / {
root html; #存放了静态页面的根目录
index index.html index.htm; #主页
}
}
Nginx通过upstream模块来实现简单的负载均衡
在upstream块内,定义一个服务器列表,默认的方式是轮询,如果要确定同一个 访问者发出的请求总是由同一个后端服务器来处理,可以设置ip_hash,如:
upstream myapp1 {
ip_hash;
server localhost:18080;
server localhost:18081;
server localhost:18082;
}
server {
listen 8000;
location / {
proxy_pass http://myapp1;
}
}
如上所示myapp1映射到upstream以后采用轮询的方式访问另外的三个服务器。
请注意:这个方法本质还是轮询,而且由于客户端的ip可能是不断变化的,比如动 态ip,代理,等等,因此ip_hash并不能完全保证同一个客户端总是由同一 个服务器来处理。
这两个模块主要用于做全局的负载均衡,可以根据不同的客户端ip来访问不同的 服务器,示例如下:
http{
geo $geo{
default default;
202.103.10.1/24 A;
179.9.0.3/24 B;
}
upstream default.server{
server 192.168.0.100;
}
upstream A.server{
server 192.168.0.101;
}
upstream B.server{
server 192.168.0.102;
}
server{
listen 80;
location / {
proxy_passhttp://$geo.server$request_uri;
}
}
}
七 常见功能配置总结
7.1 server配置为监听ip和端口
server{
listen 127.0.0.1:9080;
server_name127.0.0.1;
}
7.2 server配置为监听域名和端口
server{
listen 80;
server_name www.sishuok.com sishuok.com*.sishuok.com;
}
7.3 向后台服务器传递客户端的真实ip
location ~ \.(jsp|action|mvc)$ {
proxy_set_headerHost $host;
proxy_set_headerX-Forwarded-For $remote_addr;
proxy_pass http://sishuok.com;
}
7.4 在负载均衡里面,实现后端服务器故障转移的配置
location ~ \.(jsp|action|mvc)$ {
proxy_next_upstream http_502 http_504 timeout;
proxy_set_headerHost $host;
proxy_set_headerX-Forwarded-For $remote_addr;
proxy_passhttp://server_pool;
}
7.5 简单的防盗链
location / {
……
valid_referersblocked sishuok.com*.sishuok.com;
if($invalid_referer){
rewrite ^/ http://sishuok.com;
}
}
7.6 简单的限制下载速度
location / {
limit_rate 256K;
}