快捷導(dǎo)航

詳解Nginx如何配置繼承模型

更新時(shí)間：2018年07月13日 16:34:13 作者：夢(mèng)想_行人

這篇文章主要介紹了詳解Nginx如何配置繼承模型，小編覺(jué)得挺不錯(cuò)的，現(xiàn)在分享給大家，也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧

要了解nginx的繼承模型，首先需要知道nginx使用多個(gè)配置塊進(jìn)行操作。在nginx中，這樣的塊被稱為上下文，例如，放置在服務(wù)器上下文中的配置指令駐留在server { }塊中，就像放置在http上下文中的指令駐留在http { } 塊中一樣。

nginx中有6種可能的上下文，這里是從上到下的順序：

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

默認(rèn)繼承模型是指令僅向下繼承。從來(lái)沒(méi)有側(cè)身，絕對(duì)永遠(yuǎn)不會(huì)。這包括您在內(nèi)部從一個(gè)位置重寫(xiě)請(qǐng)求到另一個(gè)位置的情況 - 第一個(gè)位置中的每個(gè)指令都被遺忘，只有第二個(gè)位置指令適用于位置上下文。在繼承行為方面，nginx中有四種類型的配置指令：

Normal指令 - 每個(gè)上下文一個(gè)值，例如：“root”或“index”。
Array指令 - 每個(gè)上下文有多個(gè)值，例如：“access_log”或“fastcgi_param”
Action指令 - 不只是配置的東西，例如：“rewrite”或“fastcgi_pass”
try_files指令。

Normal指令是迄今為止最常見(jiàn)的指令，它遵循默認(rèn)的繼承模型而沒(méi)有任何意外。讓我們看一個(gè)示例配置，顯示行為的情況。

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指令很像普通指令，因?yàn)樗鼈冏裱瓨?biāo)準(zhǔn)繼承模型，它始終向下繼承并替換在更高上下文中指定的任何指令。可能令人困惑的是假設(shè)你添加到數(shù)組。Array 指令的行為是，如果在同一上下文中定義多個(gè)指令，則將添加到值，但如果在不同的上下文中定義多個(gè)指令，則較低的上下文將替換較高的上下文。這意味著如果您希望它在多個(gè)上下文中存在，您有時(shí)需要雙重定義一個(gè)值。這種情況的一個(gè)例子。

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指令是它開(kāi)始變得有趣的地方。它們被限制在一個(gè)上下文中并且永遠(yuǎn)不會(huì)向下繼承，但是它們可以在多個(gè)上下文中指定，并且在某些情況下將針對(duì)每個(gè)上下文執(zhí)行。 rewrite指令是一個(gè)action指令，允許在服務(wù)器和位置上下文中執(zhí)行兩個(gè)上下文。

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.
  }
}

當(dāng)然，它并不那么簡(jiǎn)單。在位置內(nèi)有三種可能的上下文，一個(gè)嵌套位置，一個(gè)if和limit_except。指令的行為實(shí)際上完全取決于定義它的模塊。如果在該上下文中允許，則所有normal和array指令都將正確繼承。對(duì)于行動(dòng)指令，故事有點(diǎn)不同。通常它們不會(huì)繼承到嵌套位置，但最終取決于模塊的預(yù)期，并且它可以在指令的基礎(chǔ)上有所不同。這里沒(méi)有使用nginx文檔，所以你必須嘗試一下，看看nginx是否會(huì)抱怨。為了更好地衡量，讓我們舉一個(gè)最常見(jiàn)的行為示例以及它如何影響重寫(xiě)：

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指令與上面提到的每個(gè)其他操作指令大致相同，不同之處在于，如果放置在服務(wù)器上下文中，nginx實(shí)際上會(huì)創(chuàng)建一個(gè)偽位置，該位置是可能的最不具體的位置。這意味著如果請(qǐng)求與定義的位置匹配，則不會(huì)執(zhí)行try_files指令。這意味著如果您有l(wèi)ocation / defined，那么您有一個(gè)匹配每個(gè)可能請(qǐng)求的位置，因此try_files永遠(yuǎn)不會(huì)實(shí)際執(zhí)行。因此，如果可能的話，始終將try_files放在位置上下文而不是服務(wù)器上下文中

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.
  }
}

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。