nginx 中location和root,你确定真的明白他们关系?

最近公司开发新项目,web server使用nginx,趁周末小小的研究了一下,一不小心踩了个坑吧,一直404 not found!!!!!当时卡在location和root中,但是网上却比较少聊这方面的关系,一般都是聊location匹配命令(这里可以看看http://www.nginx.cn/115.html),花了一下午,彻底搞清楚了location和root到底怎样找到文件的。

 

nginx指定文件路径有两种方式root和alias,这两者的用法区别,使用方法总结了下,方便大家在应用过程中,快速响应。root与alias主要区别在于nginx如何解释location后面的uri,这会使两者分别以不同的方式将请求映射到服务器文件上。

 

 

阅读剩余部分 -

nginx的location root 指令

location /img/ {
    alias /var/www/image/;
}
#若按照上述配置的话,则访问/img/目录里面的文件时,ningx会自动去/var/www/image/目录找文件
location /img/ {
    root /var/www/image;
}
#若按照这种配置的话,则访问/img/目录下的文件时,nginx会去/var/www/image/img/目录下找文件。] 

 

alias是一个目录别名的定义,root则是最上层目录的定义。

一直以为root是指的/var/www/image目录下,应该 是 /var/www/image/img/ 

还有一个重要的区别是alias后面必须要用“/”结束,否则会找不到文件的。。。而root则可有可无~~

 

 在通过域名访问图片时发现404,而ip能访问到,原因是配置域名server的location中的root与访问的图片路径不在一个目录下的原因导致的,解决办法是再配个location匹配自己的图片所在路径。

阅读剩余部分 -

nginx目录设置 alias 和 root

使用nginx设置root时要注意一个问题,就是如果该root设置的前端目录不是根目录,那么在写root的绝对地址时,要把前端目录的部分省略掉。
我们用设置虚拟目录指向的alias来和root比较一下就非常明显了

alias

location /abc/ {
    alias /home/html/abc/;
}

在这段配置下,http://test/abc/a.html就指定的是 /home/html/abc/a.html。这段配置亦可改成

root

location /abc/ {
    root /home/html/;
}

可以看到,使用root设置目录的绝对路径时,少了/abc,也就是说,使用root来设置前端非根目录时,nginx会组合root和location的路径。

另外,使用alias时目录名后面一定要加“/”

阅读剩余部分 -

Nginx proxy_set_header 理解

用户认证接口:根据客户端IP和port,进行IP反查和端口范围确认,如符合则用户认证通过。
当前使用的是Nginx负载均衡,从客户端到Nginx端 ip和port都对,从Nginx到应有服务器上-port端口变成很奇怪的端口号。
疑问:Nginx往应有服务器上 是如何 传递 客户端IP和port 参数的呢?
请看 Nginx proxy_set_header

Nginx proxy_set_header
允许重新定义或添加字段传递给代理服务器的请求头。该值可以包含文本、变量和它们的组合。在没有定义proxy_set_header时会继承之前定义的值。默认情况下,只有两个字段被重定义:

proxy_set_header Host       $proxy_host;
proxy_set_header Connection close;

如果启用缓存,来自之前请求的头字段“If-Modified-Since”, “If-Unmodified-Since”, “If-None-Match”, “If-Match”, “Range”, 和 “If-Range” 将不会被代理服务器传递。
一个不会变化的“Host”头请求字段可通过如下方式被传递:

proxy_set_header Host       $http_host;

然后,当字段不在请求头中就无法传递啦。在这种情况下,可通过设置Host变量,将需传递值赋给Host变量。

proxy_set_header Host       $host;

此外,服务器名称和端口一起通过代理服务器传递。

proxy_set_header Host       $host:$proxy_port;

如果请求头的存在空的字段将不会通过代理服务器传递出去。

proxy_set_header Accept-Encoding "";

总结:proxy_set_header 就是可设置请求头-并将头信息传递到服务器端。不属于请求头的参数中也需要传递时 重定义下就行啦。

阅读剩余部分 -

nginx proxy_set_header设置、自定义header

先来看下proxy_set_header的语法
语法: proxy_set_header field value;
默认值:
proxy_set_header Host $proxy_host;

proxy_set_header Connection close;
上下文: http, server, location

允许重新定义或者添加发往后端服务器的请求头。value可以包含文本、变量或者它们的组合。 当且仅当当前配置级别中没有定义proxy_set_header指令时,会从上面的级别继承配置。 默认情况下,只有两个请求头会被重新定义:

 

proxy_set_header Host       $proxy_host;
proxy_set_header Connection close;
 

proxy_set_header也可以自定义参数,如:proxy_set_header test paroxy_test;

 

如果想要支持下划线的话,需要增加如下配置:

underscores_in_headers on;

 

可以加到http或者server中

语法:underscores_in_headers on|off
默认值:off
使用字段:http, server
是否允许在header的字段中带下划线

Java端,需要获取proxy_set_header的参数时,需要使用request.getHeader(field),一般用来获取真实ip地址

阅读剩余部分 -

nginx配置location总结及rewrite规则写法

1. location正则写法

一个示例:

location = / {

# 精确匹配 / ,主机名后面不能带任何字符串

[ configuration A ]

}

 

location / {

# 因为所有的地址都以 / 开头,所以这条规则将匹配到所有请求

# 但是正则和最长字符串会优先匹配

[ configuration B ]

}

 

location /documents/ {

# 匹配任何以 /documents/ 开头的地址,匹配符合以后,还要继续往下搜索

# 只有后面的正则表达式没有匹配到时,这一条才会采用这一条

[ configuration C ]

}

 

location ~ /documents/Abc {

# 匹配任何以 /documents/Abc 开头的地址,匹配符合以后,还要继续往下搜索

# 只有后面的正则表达式没有匹配到时,这一条才会采用这一条

[ configuration CC ]

}

 

location ^~ /images/ {

# 匹配任何以 /images/ 开头的地址,匹配符合以后,停止往下搜索正则,采用这一条。

[ configuration D ]

}

 

location ~* \.(gif|jpg|jpeg)$ {

# 匹配所有以 gif,jpg或jpeg 结尾的请求

# 然而,所有请求 /images/ 下的图片会被 config D 处理,因为 ^~ 到达不了这一条正则

[ configuration E ]

}

 

location /images/ {

# 字符匹配到 /images/,继续往下,会发现 ^~ 存在

[ configuration F ]

}

 

location /images/abc {

# 最长字符匹配到 /images/abc,继续往下,会发现 ^~ 存在

# F与G的放置顺序是没有关系的

[ configuration G ]

}

 

location ~ /images/abc/ {

# 只有去掉 config D 才有效:先最长匹配 config G 开头的地址,继续往下搜索,匹配到这一条正则,采用

[ configuration H ]

}

 

location ~* /js/.*/\.js
  • 已=开头表示精确匹配
    如 A 中只匹配根目录结尾的请求,后面不能带任何字符串。
  • ^~ 开头表示uri以某个常规字符串开头,不是正则匹配
  • ~ 开头表示区分大小写的正则匹配;
  • ~* 开头表示不区分大小写的正则匹配
  • / 通用匹配, 如果没有其它匹配,任何请求都会匹配到

阅读剩余部分 -

NGINX配置文件NGINX.CONF详解

nginx配置文件详解:

#定义Nginx运行的用户和用户组

user www www; 

#nginx进程数。
worker_processes 8;

#全局错误日志定义类型,[ debug | info | notice | warn | error | crit ]
error_log /var/log/nginx/error.log info;

#进程文件
pid /var/run/nginx.pid;

#一个nginx进程打开的最多文件描述符数目要与ulimit -n的值保持一致。
worker_rlimit_nofile 65535;

#工作模式与连接数上限
events
{
#参考事件模型,use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型是Linux 2.6以上版本内核中的高性能网络I/O模型,如果跑在FreeBSD上面,就用kqueue模型。
use epoll;
#单个进程最大连接数(最大连接数=连接数*进程数)
worker_connections 65535;
}

阅读剩余部分 -

NGINX作为反向代理时传递客户端IP的设置方法

Nginx 是一个高性能的 HTTP 和 反向代理 服务器,也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的,第一个公开版本0.1.0发布于2004年10月4日。其将源代码以类BSD许可证的形式发布,因它的稳定性、丰富的功能集、示例配置文件和 低系统资源的消耗而闻名。
因为nginx的优越性,现在越来越多的用户在生产环境中使用nginx作为前端,不管nginx在前端是做负载均衡还是只做简单的反向代理,都需要把日志转发到后端real server,以方便我们检查程序的各种故障

nginx默认配置文件里面是没有进行日志转发配置的,这个需要我们自己手动来操作了,当然后端的real server不同时操作方法是不一样的,这里我们分别例举几种情况来说明一下。

nginx做前端,转发日志到后端nginx服务器:

因为架构的需要采用多级 Nginx 反向代理,但是后端的程序获取到的客户端 IP 都是前端 Nginx 的 IP,问题的根源在于后端的 Nginx 在 HTTP Header 中取客户端 IP 时没有取对正确的值。
同样适用于前端是 Squid 或者其他反向代理的情况。

阅读剩余部分 -

meiyoutongji