Nginx 的配置指令

我们已经了解了 Nginx 的基本命令和架构原理，下面该到最让人头疼也是最不容易理解的部分了，那就是 nginx.conf 这个配置文件，下面从 Nginx 的指令开始，一步步来讲解 Nginx 的配置。

Nginx 指令

先来看一个典型的 Nginx 配置文件示例。

main
http {
	upstream { … }
	split_clients {…}
	map {…}
	geo {…}
	server {
		if () {…}
		location {
			limit_except {…}
		}
		location {
			location {
			}
		}
	}
	server {
	}
}

从上面可以看到，这个配置文件中包含了多个指令块，有些指令块还是重复的，那么这在 Nginx 中是一个什么样的规则？接下来会慢慢介绍。

指令块的嵌套

在 Nginx 配置文件中，指令块是可以互相嵌套的，例如上面的示例，http 块中可以包含多个 server 块，server 块中还会包含多个 location 块，每一个块中都有相应的指令。

而每一个指令都有 Context 上下文，也就是生效的环境，这在 Nginx 的官方文档中说的很清楚，例如下面的两条指令，Context 中都表明了各自可以生效的环境，access_log 指令可以在多个上下文中生效：

Syntax:  access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
		     access_log off;
Default: access_log logs/access.log combined;
Context: http, server, location, if in location, limit_except

Syntax:  log_format name [escape=default|json|none] string ...;
Default: log_format combined "...";
Context: http

指令的合并

在 Nginx 中，指令分为两种，一种是值指令，一种是动作类指令：

  • 值指令：存储配置项的值，是用来配置某一个配置项的

    • 可以合并
    • 示例
      • root
      • access_log
      • gzip
  • 动作类指令：指定行为动作，往往表示接下来要做一件事情
    • 不可以合并
    • 示例
      • rewrit
      • proxy_pass
    • 生效阶段
      • server_rewrite 阶段
      • rewrite 阶段
      • content 阶段

这里面的示例以及生效阶段，后面都还会详细讲，这里可以不用过多关注，既然指令分为两种，那么就有不同的继承规则，下面就来说一下。

值指令的继承规则

例如下面的配置文件，这里面在 server 块和 location 块中都配置了 root 指令，Nginx 的继承规则如下：

  • 子配置不存在时，直接使用父配置块的指令
  • 子配置存在时，覆盖父配置块
server {
	listen 8080;
	root /home/geek/nginx/html;
	access_log logs/geek.access.log main;
	location /test {
		root /home/geek/nginx/test;
		access_log logs/access.test.log main;
	}
	location /dlib {
		alias dlib/;
	}
	location / {
	}

根据上面这两条规则，第一个 location 使用自家的 root 指令，后面两个 location 则使用 server 块的 root 指令。这和编程语言中变量的作用域也是类似的，作用域更小的变量优先级往往更高，Nginx 的指令也是一样。

文档中没有的指令如何判断生效范围

对于很多第三方模块，很可能文档并不完善，这时候需要通过源码来查看指令的生效范围。需要明确下面几个问题：

  1. 指令在哪个块下生效？
  2. 指令允许出现在哪些块下？

这两个问题是在源码中定义的，例如：

static ngx_command_t  ngx_http_core_commands[] = {

    { ngx_string("variables_hash_max_size"),
      NGX_HTTP_MAIN_CONF|NGX_CONF_TAKE1,
      ngx_conf_set_num_slot,
      NGX_HTTP_MAIN_CONF_OFFSET,
      offsetof(ngx_http_core_main_conf_t, variables_hash_max_size),
      NULL },
    ......

从上面第三行可以看到，variables_hash_max_size 指令是在 main 块下生效的。

还会有两个回调方法：

  • 在 server 块生效，从 http 向 server 合并

    • char *(*merge_srv_conf)(ngx_conf_t*cf, void *prev, void *conf);
  • 向 location 合并
    • char *(*merge_loc_conf)(ngx_conf_t*cf, void *prev, void *conf);

例如：

static ngx_http_module_t  ngx_http_core_module_ctx = {
    ngx_http_core_preconfiguration,        /* preconfiguration */
    ngx_http_core_postconfiguration,       /* postconfiguration */

    ngx_http_core_create_main_conf,        /* create main configuration */
    ngx_http_core_init_main_conf,          /* init main configuration */

    ngx_http_core_create_srv_conf,         /* create server configuration */
    ngx_http_core_merge_srv_conf,          /* merge server configuration */

    ngx_http_core_create_loc_conf,         /* create location configuration */
    ngx_http_core_merge_loc_conf           /* merge location configuration */
};

ngx_http_module_t 这个结构体里面，定义了很多回调方法，最后一个 ngx_http_core_merge_loc_conf 方法，就是制定合并规则的。这个方法定义了两个参数，一个是父配置，一个是子配置：

static char *ngx_http_core_merge_loc_conf(ngx_conf_t *cf, void *parent, void *child)
{
    ngx_http_core_loc_conf_t *prev = parent;
    ngx_http_core_loc_conf_t *conf = child;

    ngx_uint_t        i;
    ngx_hash_key_t   *type;
    ngx_hash_init_t   types_hash;

    if (conf->root.data == NULL) {
......

这个方法表明了从父配置向子配置合并。

listen 指令的用法

listen 指令在 server 块中生效，用来配置监听哪些端口，由这些端口来处理请求。listen 指令的配置如下：

如示例所示，listen 指令可以监听的类型有多种，可以配置监听地址和端口，也可以是仅地址和仅端口，还可以仅监听 IPv6 等等。

究竟是哪个 server 来处理请求

server_name 指令的用法

一个指令：server_name

server_name 指令是用来配置究竟是哪个 server 来处理我们的请求的。有时候，一个 server_name 中可能会有多个域名，这时候是如何选择的呢？

  1. server_name 指令后可以跟多个域名，第一个是主域名，多个域名之间空格分隔
  2. 泛域名：仅支持在最前或最后加 *，例如：server_name *.taohui.tech
  3. 正则表达式匹配：server_name www.taohui.tech ~^www\d+\.taohui\.tech$;

当 server_name 指令后有多个域名时，会有一个 server_name_in_redirect 的配置，这个配置默认关闭，它使用来控制域名重定向的，也就是这个配置开启之后，请求过来会重定向到主域名访问。

Syntax  server_name_in_redirect on | off;
Default server_name_in_redirect off;
Context http, server, location
  1. 还可以用正则表达式创建变量

    • # 使用 $1/$2 的方式引用变量
server {
	server_name ~^(www\.)?(.+)$;
	location / { root /sites/$2; }
}

    • # 还可以通过加一个 ?<> 的方式来命名变量
server {
	server_name ~^(www\.)?(?<domain>.+)$;
	location / { root /sites/$domain; }
}
  2. 特殊的配置规则
    • .test.tech 可以匹配 test.tech *.test.tech
    • _ 匹配所有域名请求
    • "" 匹配没有传递 host 头部的请求

server 匹配的顺序

  1. 精确匹配（与顺序无关）
  2. * 在前的泛域名（与顺序无关）
  3. * 在后的泛域名（与顺序无关）
  4. 按文件中的顺序匹配正则表达式域名
  5. default server
    • 第 1 个
    • listen 指定 default

这里面 default server 有两种指定方式，假如没有配置 default server，那么第一个 server 块就会成为 default server，如果 listen 中配置了 default，那么就会由配置的块进行处理。

关注公众号回复 Nginx 领取知识图谱

原文地址：https://www.cnblogs.com/iziyang/p/12651234.html

时间： 2024-10-09 16:16:49

Nginx 的配置指令的相关文章

九爷带你了解 nginx 日志配置指令详解

nginx日志配置指令详解 日志对于统计排错来说非常有利的. 本文总结了nginx日志相关的配置如 access_log.log_format.open_log_file_cache.log_not_found.log_subrequest.rewrite_log.error_log. nginx有一个非常灵活的日志记录模式.每个级别的配置可以有各自独立的访问日志.日志格式通过log_format命令来定义.ngx_http_log_module是用来定义请求日志格式的. 1. access_l

Nginx常用配置指令说明

注意:局部作用域的配置指令可覆盖全局作用域的配置指令 1.不在http响应头中显示Nginx的版本 # 可用于http{}配置块和server{}配置块server_tokens off; 2.索引文件 # 可用于http{}配置块和server{}配置块index index.html index.php; 3.是否允许目录浏览 # 可用于http{}配置块和server{}配置块autoindex on; 4.设置网站根目录 # 可用于http{}配置块和server{}配置块root "E

Nginx基础配置

查看nginx配置文件分类 主配置文件: nginx.conf include conf.d/*.conf fascgi uwsgi scgi 等协议相关配置文件 nginx.conf文件结构 主配置文件结构: main block:#全局块配置全局生效 event{ #事件驱动相关配置 } http{ #http/https协议相关配置段 server { ... }:#每个server用于定义一个虚拟主机: server { ... server_name root alias locati

Nginx配置指令try_files

try_files指令是按顺序检测文件的存在性,并且返回第一个找到文件的内容,如果第一个找不到就会自动找第二个,依次查找.其实现的是内部跳转.以下举例说明: 案例1(跳转到变量): server {   listen 8000;   server_name 121.10.143.66;   root html;   index index.html index.php; location /abc { try_files /4.html /5.html @qwe;      --检测文件4.ht

Nginx 配置指令location 匹配符优先级和安全问题【转】

Nginx配置指令location匹配符优先级和安全问题 使用nginx 很久了,它的性能高,稳定性表现也很好,得到了很多人的认可.特别是它的配置,有点像写程序一样,每行命令结尾一个";"号,语句块用"{}"括起来.配制好,直接nginx -t 检查配制情况,配制成功,直接运行:service nginx reload.服务器没有任何宕机情况下,实现平稳修改配置.最近一直在做location 配置,遇到优先级别问题(如果配置不当可能存在安全隐患哦),以下是个人学习一

Nginx 配置指令的执行顺序（十一）

紧跟在 post-access 阶段之后的是 try-files 阶段.这个阶段专门用于实现标准配置指令 try_files 的功能,并不支持 Nginx 模块注册处理程序.由于 try_files 指令在许多 FastCGI 应用的配置中都有用到,所以我们不妨在这里简单介绍一下. try_files 指令接受两个以上任意数量的参数,每个参数都指定了一个 URI. 这里假设配置了 N 个参数,则 Nginx 会在 try-files 阶段,依次把前 N-1 个参数映射为文件系统上的对象(文件或者

Nginx 配置指令的执行顺序（七）

来看一个 ngx_static 模块服务磁盘文件的例子.我们使用下面这个配置片段:     location / {        root /var/www/;    } 同时在本机的 /var/www/ 目录下创建两个文件,一个文件叫做 index.html,内容是一行文本 this is my home:另一个文件叫做 hello.html,内容是一行文本 hello world. 同时注意这两个文件的权限设置,确保它们都对运行 Nginx worker 进程的系统帐户可读. 现在来通过

Nginx 配置指令的执行顺序（八）

前面我们详细讨论了 rewrite.access 和 content 这三个最为常见的 Nginx 请求处理阶段,在此过程中,也顺便介绍了运行在这三个阶段的众多 Nginx 模块及其配置指令.同时可以看到,请求处理阶段的划分直接影响到了配置指令的执行顺序,熟悉这些阶段对于正确配置不同的 Nginx 模块并实现它们彼此之间的协同工作是非常必要的.所以接下来我们接着讨论余下的那些阶段. 前面在 (一) 中提到,Nginx 处理请求的过程一共划分为 11 个阶段,按照执行顺序依次是 post-read

Nginx 配置指令的执行顺序（一）

大多数 Nginx 新手都会频繁遇到这样一个困惑,那就是当同一个 location 配置块使用了多个 Nginx 模块的配置指令时,这些指令的执行顺序很可能会跟它们的书写顺序大相径庭.于是许多人选择了“试错法”,然后他们的配置文件就时常被改得一片狼藉.这个系列的教程就旨在帮助读者逐步地理解这些配置指令背后的执行时间和先后顺序的奥秘. 现在就来看这样一个令人困惑的例子:     ? location /test {    ?     set $a 32;    ?     echo $a;