详解Nginx如何配置继承模型

要了解nginx的继承模型,首先需要知道nginx使用多个配置块进行操作。 在nginx中,这样的块被称为上下文,例如,放置在服务器上下文中的配置指令驻留在server { }块中,就像放置在http上下文中的指令驻留在http { } 块中一样。

nginx中有6种可能的上下文,这里是从上到下的顺序:

  • Global.
  • Http.
  • Server.
  • If.
  • Location.
    • Nested Location.
    • If in location.
    • limit_except.

默认继承模型是指令仅向下继承。 从来没有侧身,绝对永远不会。 这包括您在内部从一个位置重写请求到另一个位置的情况 - 第一个位置中的每个指令都被遗忘,只有第二个位置指令适用于位置上下文。 在继承行为方面,nginx中有四种类型的配置指令:

  • Normal指令 - 每个上下文一个值,例如:“root”或“index”。
  • Array指令 - 每个上下文有多个值,例如:“access_log”或“fastcgi_param”
  • Action指令 - 不只是配置的东西,例如:“rewrite”或“fastcgi_pass”
  • try_files指令。

Normal指令是迄今为止最常见的指令,它遵循默认的继承模型而没有任何意外。 让我们看一个示例配置,显示行为的情况。

server {
  root /home/user/public_html;

  location /app {
    root /usr/share; # This results in /usr/share/app
             # Full URI is ALWAYS appended.
  }

  location /app2 {
    // Server context root applies here.
  }
}

Array指令很像普通指令,因为它们遵循标准继承模型,它始终向下继承并替换在更高上下文中指定的任何指令。 可能令人困惑的是假设你添加到数组。Array 指令的行为是,如果在同一上下文中定义多个指令,则将添加到值,但如果在不同的上下文中定义多个指令,则较低的上下文将替换较高的上下文。 这意味着如果您希望它在多个上下文中存在,您有时需要双重定义一个值。 这种情况的一个例子。

server {
  access_log /var/log/nginx/access.log;
  include fastcgi.conf;

  location ~ ^/calendar/.+\.php$ {
    access_log /var/log/nginx/php-requests.log; # If this executes then server context one never does.

    fastcgi_param ENV debug; # This *overwrites* the higher context array.
    include fastcgi.conf   # Therefore we include it in *this* context again.
  }
}

Action指令是它开始变得有趣的地方。 它们被限制在一个上下文中并且永远不会向下继承,但是它们可以在多个上下文中指定,并且在某些情况下将针对每个上下文执行。 rewrite指令是一个action指令,允许在服务器和位置上下文中执行两个上下文。

server {
  rewrite ^/booking(.*) /calendar$1 permanent; # Always executes.

  location /calendar {
    rewrite ^ /index.php; # Can execute in addition to and does not replace server context rewrites.
  }
}

当然,它并不那么简单。 在位置内有三种可能的上下文,一个嵌套位置,一个if和limit_except。 指令的行为实际上完全取决于定义它的模块。 如果在该上下文中允许,则所有normal和array指令都将正确继承。 对于行动指令,故事有点不同。 通常它们不会继承到嵌套位置,但最终取决于模块的预期,并且它可以在指令的基础上有所不同。 这里没有使用nginx文档,所以你必须尝试一下,看看nginx是否会抱怨。 为了更好地衡量,让我们举一个最常见的行为示例以及它如何影响重写:

server {
  location /calendar {
    rewrite ^ /static.php; # Executes unless inner location matches.

    location ~ \.php$ {
      fastcgi_pass backend; # Outer location context rewrite is not executed.
    }
  }
}

try_files指令与上面提到的每个其他操作指令大致相同,不同之处在于,如果放置在服务器上下文中,nginx实际上会创建一个伪位置,该位置是可能的最不具体的位置。 这意味着如果请求与定义的位置匹配,则不会执行try_files指令。 这意味着如果您有location / defined,那么您有一个匹配每个可能请求的位置,因此try_files永远不会实际执行。 因此,如果可能的话,始终将try_files放在位置上下文而不是服务器上下文中

server {
  try_files $uri /index.php; # This never executes.

  location / {
    # Whatever here, or empty.
  }

  location ~ \.php$ {
    # If this location executes then try_files still does not execute.
    # Even if location / did not exist.
  }
}

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • 详解Nginx如何配置继承模型

    要了解nginx的继承模型,首先需要知道nginx使用多个配置块进行操作. 在nginx中,这样的块被称为上下文,例如,放置在服务器上下文中的配置指令驻留在server { }块中,就像放置在http上下文中的指令驻留在http { } 块中一样. nginx中有6种可能的上下文,这里是从上到下的顺序: Global. Http. Server. If. Location. Nested Location. If in location. limit_except. 默认继承模型是指令仅向下继承

  • 详解Nginx如何配置Web服务器的示例代码

    概述 今天主要分享怎么将NGINX配置作为Web服务器,并包括以下部分: 设置虚拟服务器 配置位置 使用变量 返回特定状态码 重写HTTP响应 在高层次上,将NGINX配置作为Web服务器有一些问题需要了解,定义它处理哪些URL以及如何处理这些URL上的资源的HTTP请求. 在较低层次上,配置定义了一组控制对特定域或IP地址的请求的处理的虚拟服务器. 用于HTTP流量的每个虚拟服务器定义了称为位置的特殊配置实例,它们控制特定URI集合的处理. 每个位置定义了自己的映射到此位置的请求发生的情况.

  • 详解Nginx Location配置

    今天有一位同学问到 Nginx 的站点多路径匹配的问题? 1.www.domain.com/a 需要返回 /var/www/domain.com/a/index.html 2.www.domain.com/b 需要返回 /var/www/domain.com/b/index.html 如何配置 Nginx 使之生效? 解决这个问题,第一的反映是直接使用 Nginx 的 location 指令来解决,不过在给出答案之前,我们先来了解一下 Nginx location 指令的基础. 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_log指令 语法: a

  • 详解nginx如何配置HTTPS

    使用ssl模块配置同时支持http和https并存 一,生成证书 # 1.首先,进入你想创建证书和私钥的目录,例如: cd /etc/nginx/ # 2.创建服务器私钥,命令会让你输入一个口令: openssl genrsa -des3 -out server.key 1024 # 3.创建签名请求的证书(CSR): openssl req -new -key server.key -out server.csr # 4.在加载SSL支持的Nginx并使用上述私钥时除去必须的口令: cp se

  • 详解Nginx的配置函数对于请求体的读取

    nginx核心本身不会主动读取请求体,这个工作是交给请求处理阶段的模块来做,但是nginx核心提供了ngx_http_read_client_request_body()接口来读取请求体,另外还提供了一个丢弃请求体的接口-ngx_http_discard_request_body(),在请求执行的各个阶段中,任何一个阶段的模块如果对请求体感兴趣或者希望丢掉客户端发过来的请求体,可以分别调用这两个接口来完成.这两个接口是nginx核心提供的处理请求体的标准接口,如果希望配置文件中一些请求体相关的指

  • 详解nginx upstream 配置和作用

    配置例子 upstream backend { server backend1.example.com weight=5; server backend2.example.com:8080; server unix:/tmp/backend3; server backup1.example.com:8080 backup; server backup2.example.com:8080 backup; } server { location / { proxy_pass http://backe

  • 详解nginx websocket配置

    一·什么是websocket WebSocket协议相比较于HTTP协议成功握手后可以多次进行通讯,直到连接被关闭.但是WebSocket中的握手和HTTP中的握手兼容,它使用HTTP中的Upgrade协议头将连接从HTTP升级到WebSocket.这使得WebSocket程序可以更容易的使用现已存在的基础设施. WebSocket工作在HTTP的80和443端口并使用前缀ws://或者wss://进行协议标注,在建立连接时使用HTTP/1.1的101状态码进行协议切换,当前标准不支持两个客户端

  • 详解Nginx防盗链和Nginx访问控制与Nginx解析php的配置

    详解Nginx防盗链和Nginx访问控制与Nginx解析php的配置 Nginx防盗链 配置如下,可以和上面的配置结合起来 location ~* ^.+\.(gif|jpg|png|swf|flv|rar|zip|doc|pdf|gz|bz2|jpeg|bmp|xls)$ { expires 7d; valid_referers none blocked server_names *.test.com ; if ($invalid_referer) { return 403; } access

  • 详解 Nginx 301重定向的配置

    详解 Nginx 301重定向的配置 301重定向是很常见的需求,比如访问 nowamagic.net,自动跳到 www.nowamagic.net.或者倒过来,访问 www.nowamagic.net 跳到 nowamagic.net.Nginx 中配置 301 重定向(301 redirect)很容易,下面介绍下方法. 打开 nginx.conf 文件,找到你的 server 配置段: server { listen 80; server_name nowamagic.net www.now

随机推荐