nginx配置文件

来源：互联网发布：mac系统ps怎么装插件编辑：程序博客网时间：2024/05/28 15:59

nginx接收的参数

Usage: nginx [-?hvVt] [-s signal] [-c filename] [-p prefix] [-g directives]

Options:

-?,-h : this help

-v : show version and exit

-V : show version and configure options then exit

-t : test configuration and exit

-s signal : send signal to a master process: stop, quit, reopen, reload

-p prefix : set prefix path (default: /usr/local/nginx/)

-c filename : set configuration file (default: conf/nginx.conf)

-g directives : set global directives out of configuration file

signal process started

新一刚刚在调试Nginx配置文件的时候，发现error.log文件中会有提示signal process started,新一查阅了资料才知道， signal process started是由于新一在每次修改文件重载文件的原因导致的。只是一个提示信息无需紧张。

nginx的location不允许有if嵌套，也不支持and 与 or 或者 && 与 ||。

如何实现and or

location = /test_and/ {

default_type text/html;

set $a 0;

set $b 0;

if ( $remote_addr != '' ){

set $a 1;

}

if ( $http_x_forwarded_for != '' ){

set $a 1$a;

}

if ( $a = 11 ){

set $b 1;

}

echo $b;

}

location = /test_or/ {

default_type text/html;

set $a 0;

set $b 0;

if ( $remote_addr != '' ){

set $a 1;

}

if ( $http_x_forwarded_for != '' ){

set $a 1;

}

if ( $a = 1 ){

set $b 1;

}

echo $b;

}

location匹配命令

~ #波浪线表示执行一个正则匹配，区分大小写
~* #表示执行一个正则匹配，不区分大小写
^~ #^~表示普通字符匹配，如果该选项匹配，只匹配该选项，不匹配别的选项，一般用来匹配目录
= #进行普通字符精确匹配
@ #"@" 定义一个命名的 location，使用在内部定向时，例如 error_page, try_files

location 匹配的优先级(与location在配置文件中的顺序无关)
= 精确匹配会第一个被处理。如果发现精确匹配，nginx停止搜索其他匹配。
普通字符匹配，正则表达式规则和长的块规则将被优先和查询匹配，也就是说如果该项匹配还需去看有没有正则表达式匹配和更长的匹配。
^~ 则只匹配该规则，nginx停止搜索其他匹配，否则nginx会继续处理其他location指令。
最后匹配理带有"~"和"~*"的指令，如果找到相应的匹配，则nginx停止搜索其他匹配；当没有正则表达式或者没有正则表达式被匹配的情况下，那么匹配程度最高的逐字匹配指令会被使用。

nginx变量

$1-$9存放着正则表达式中最近的9个正则表达式的匹配结果，这些结果按照子匹配的出现顺序依次排列。
例子：
    location ~ "^/xxx/test/share/channel[0-9]{2,}/[0-9a-f]{1}/[0-9a-f]{2}/[0-9a-f]{1}/.*.(m3u8|ts|jpg)?$" {
        rewrite "/xxx/test/share/(.*)/[0-9a-f]{1}/[0-9a-f]{2}/[0-9a-f]{1}/(.*)" /otv/test/share/$1/$2;
    }

/xxx/test/share/channel01/3/11f/6/400.m3u8 可以匹配/xxx/test/share/(.*)/[0-9a-f]{1}/[0-9a-f]{3}/[0-9a-f]{1}/(.*)

http request line: "GET /xxx/test/share/channel01/3/1f/6/400.m3u8?start=1487058030&len=30 HTTP/1.1"
"/xxx/test/share/(.*)/[0-9a-f]{1}/[0-9a-f]{2}/[0-9a-f]{1}/(.*)" matches "/xxx/test/share/channel01/3/1f/6/400.m3u8",
rewritten data: "/xxx/test/share/channel01/400.m3u8

$arg_PARAMETER                 功能：如果在请求中设置了查询字符串，那么这个变量包含在查询字符串是GET请求PARAMETER中的值。
$args                                        功能：该变量的值是GET请求在请求行中的参数。
$binary_remote_addr          功能：二进制格式的客户端地址
$body_bytes_sent                 功能：响应体的大小，即使发生了中断或者是放弃，也是一样的准确。
$content_length                    功能：该变量的值等于请求头中的Content-length字段的值
$cookie_COOKIE                    功能：该变量的值是cookie COOKIE的值
$document_root                   功能：该变量的值为当前请求的location（http，server，location，location中的if）中root指令中指定的值。
$document_uri                      功能：同$uri
$host                                        功能：该变量的值等于请求头中Host的值。如果Host无效时，那么就是处理该请求的server的名称。
在下列情况中，$host变量的取值不同于$http_host变量。
    当请求头中的Host字段未指定（使用默认值）或者为空值，那么$host等于server_name指令指定的值。
    当Host字段包含端口是，$host并不包含端口号。另外，从0.8.17之后的nginx中，$host的值总是小写。
$hostname                              功能：有gethostname返回值设置机器名。
$http_HEADER                       功能：该变量的值为HTTP 请求头HEADER，具体使用时会转换为小写，并且将“——”（破折号）转换为"_"(下划线)。
$is_args                                    功能：如果设置了$args，那么值为“？”，否则为“”
$limit_rate                              功能：该变量允许限制连接速率。
$nginx_version                       功能：当前运行的nginx的版本号
$query_string                         功能：同$args
$remote_addr                        功能：客户端的IP地址
$remote_user                        功能：该变量等于用户的名字，基本身份验证模块使用。
$remote_port                        功能：客户端连接端口
$request_filename               功能：该变量等于当前请求文件的路径，有指令root或者alias和URI构成。
$request_body                     功能：该变量包含了请求体的主要信息。该变量与proxy_pass或者fastcgi_pass相关。
$request_body_file              功能：客户端请求体的临时文件。
$request_completion          功能：如果请求成功完成，那么显示“OK”。如果请求没有完成或者请求不是该请求系列的最后一部分，那么它的值为空。
$request_method                功能：该变量的值通常是GET或者POST。
$request_uri                          功能：该变量的值等于原始的URI请求，就是说从客户端收到的参数包括了原始请求的URI，该值是不可以被修改的，不包含主机名，例如“/foo/bar.php?arg=baz”。
$scheme                                 功能：该变量表示HTTP scheme（例如HTTP，HTTPS），根据实际使用情况来决定，
例如：rewrite ^ $scheme://example.com$uri redirect;
$server_addr                         功能：该变量的值等于服务器的地址。通常来说，在完成一次系统调用之后就会获取变量的值，为了避开系统钓鱼，那么必须在listen指令中使用bind参数。
$server_name                       功能：该变量为server的名字。
$server)port                          功能：该变量等于接收请求的端口。
$server_protocol                 功能：该变量的值为请求协议的值，通常是HTTP/1.0或者HTTP/1.1
$uri                                        功能：该变量的值等于当前请求中的URI（没有参数，不包括$args）的值。它的值不同于request_uri，由浏览器客户端发送的request_uri的值。例如，可能会被内部重定向或者使用index。
另外需要注意：$uri不包含主机名，例如 "/foo/bar.html"

指令上下文

nginx.conf中的配置信息，根据其逻辑上的意义，对它们进行了分类，也就是分成了多个作用域，或者称之为配置指令上下文。不同的作用域含有一个或者多个配置项。
当前nginx支持的几个指令上下文：
main:   nginx在运行时与具体业务功能（比如http服务或者email服务代理）无关的一些参数，比如工作进程数，运行的身份等。
http:   与提供http服务相关的一些配置参数。例如：是否使用keepalive啊，是否使用gzip进行压缩等。
server:   http服务上支持若干虚拟主机。每个虚拟主机一个对应的server配置项，配置项里面包含该虚拟主机相关的配置。在提供mail服务的代理时，也可以建立若干server.每个server通过监听的地址来区分。
location:   http服务中，某些特定的URL对应的一系列配置项。
mail:   实现email相关的SMTP/IMAP/POP3代理时，共享的一些配置项（因为可能实现多个代理，工作在多个监听地址上）。
指令上下文，可能有包含的情况出现。例如：通常http上下文和mail上下文一定是出现在main上下文里的。在一个上下文里，可能包含另外一种类型的上下文多次。例如：如果http服务，支持了多个虚拟主机，那么在http上下文里，就会出现多个server上下文。

我们来看一个示例配置：

以“#”开始的是注释行。

nginx的配置介绍
nginx的配置可以分为简单配置和复杂配置(块配置)
其中简单配置包括配置名和配置值，如daemon on
而复杂配置则由一个配置名一对大括号组成和括号里面的内容组成，括号里面的内容可以是简单配置也可以继续嵌套复杂配置
如 upstream backend{
server backend1.example.com weight=5;
server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
}

简单配置项和复杂配置项的区分在于简单配置可以直接解析和赋值，而复杂配置项nginx一般只是申请对应的内存空间，切换解析状态，然后递归调用解析函数
nginx的配置存在继承关系，内层的配置可以继承外层的配置，当内外层中的配置发生冲突是，以内层为主还是以外层为主取决于解析这个配置项的模块
include命令可以用在nginx配置文件的任何地方，来载入其他的配置文件，以增强配置文件的可读性，并且include支持通配符，inlucde文件的路径默认是nginx.conf文件的所作目录

一些全局配置介绍：

user root 不配置会出现权限错误。

daemon on | off   默认on
是否以守护进程的方式运行nginx，守护进程是指脱离终端并且在后头运行的进程，关闭守护进程执行的方式可以让我们方便调试nginx

master_process on | of 默认on
是否以master/worker方式进行工作，在实际的环境中 nginx是以一个master进程管理多个worker进程的方式运行的，关闭后 nginx就不会fork出worker子进程来处理请求，而是用master进程自身来处理请求

worker_processes number; 默认1
在master/worker运行方式下 worker进程的数目，一般情况下用户要配置与CPU内核数相等的worker进程

worker_cpu_affinity cpumask[cpumask…]
示例：worker_cpu_affinity 1000 0100 0010 0001;
绑定worker进程到指定的cpu内核,每一个worker进程都独享一个CPU，可以在内核的调度策略上实现完全的并发

worker_limit_nofile，默认为操作系统的限制
该值为worker进程可以打开的最大文件描述符的数量

events模块
events模块包含了nginx了有关连接处理的配置
worker_connections
设置一个worker能够同时打开的最大连接数，该值最大为worker_rlimit_nofile的值
在nginx作为http服务器的时候，最大连接数为worker_processes * worker_connctions
在nginx作为反向代理服务器的时候，最大连接数为worker_processes * worker_connections / 2

use
示例 use epoll
设置用于客户端线程的轮询方式，默认nginx会选择一个最适合你操作系统的
http模块
http模块下配置有server location upstream等不同的内容
log_format
log_format指令用于设置日志的记录格式
当nginx位于负载均衡设备，反向代理服务器之后的时候，无法直接获得客户端真实的ip，但是反向代理服务器转发的http头信息中，可以增加X-Forwarded-For信息，记录原有的客户端ip地址和原来客户端请求的服务器地址，这个时候可以通过log_format指令来设置日志格式，将X-Forwarded-For信息打入日志中

server_name
由于IP地址的数量有限，因此经常存在多个主机域名对应同一个ip的情况，这个时候可以按照server_name通过server块来定义虚拟主机，每个server块是一个虚拟主机，处理满足相应listen端口和server_name的请求
server_name与host的匹配优先级如下
首先选中所有字符串完全匹配的server_name，如www.nginx.org
其次选中通配符在前面的server_name，如*.nginx.org
再次选择通配符在后面的server_name，如www.nginx.*
最后选择使用正则表达式才匹配的server_name，如~^\.testweb\.com$

location
location会尝试根据用户请求中的URI来匹配设置的表达式并选中最终结果中的配置来处理用户的请求
location [=|~|~*|^~|@] / uri / { … }
=表示把uri作为字符串，与参数中的URI作完全匹配
~进行正则表达式匹配的时候，区分大小写
~*进行正则表达式匹配的时候，不区分大小写
^~表示匹配URI的时候，如果该location是最佳匹配，那么对于匹配这个location的字符串不在进行正则表达式的匹配检测
@表示仅用于nginx服务内部请求之间的重定向，带有@的location不直接处理用户请求

匹配的优先级如下
1、如果查询精确的命中了一个使用=前缀的location，那个它将被使用，并结束匹配
2、在剩下普通字符串中，将按照最大前缀匹配的原则进行匹配，将结果最后候选结果，如果最终命中的结果使用了^~前缀表示或者它是一个完全匹配，那么它将被使用，并结束匹配
3、正则表达式匹配时，按照正则表达式在配置文件中出现的顺序，并且只有匹配到了一条正则local，就不在匹配下面的local了
4、如果步骤3命中了一个匹配，那个它将被使用，否则将使用步骤2的候选结果
（普通字符串和正则字符串的区别 ~和~*前缀表示location是正则字符串，其他前缀和无前缀表示location是普通字符串）

upstream
Upstream模块是与反向代理，负载均衡相关的模块
示例: upstream backend{
    server backend1.example.com weight=5;
    server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
}
指定了一个叫backend的代理服务器，可以在proxy_pass和fastcgi_pass中使用，默认的负载均衡方式为加权轮询，可以在配置项使用使用ip_hash来使用ip哈希
weight指定了每个server的权重默认是1

max_fails指定了在fail_timeout(默认是60s)内对后端服务器请求失败的次数,达到次数后会在fail_timeout时间内不再去查询它

adobe flash player

需要crossdomain.xml文件。在根目录下建立crossdomain.xml，如下内容。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>

proxy_pass

不带/
location /test/
{
proxy_pass http://t6:8300;
}

带/
location /test/
{
proxy_pass http://t6:8300/;
}

上面两种配置，区别只在于proxy_pass转发的路径后是否带 “/”
如果是不带/的情况，如果访问url = http://server/test/test.jsp，则被nginx代理后，请求路径会便问http://proxy_pass/test/test.jsp，将test/ 作为根路径，请求test/路径下的资源。
如果是带/的情况，如果访问url = http://server/test/test.jsp，则被nginx代理后，请求路径会变为 http://proxy_pass/test.jsp，直接访问server的根资源。

if (!-e $request_filename) { // 如果找不到

0 0