Nginx Web サーバー構成ブロックとは何ですか?

Nginx Web サーバー構成ブロックには次が含まれます: 1. 仮想サーバーのセットアップ; 2. 場所の構成; 3. 変数の使用; 4. 特定のステータス コードを返す; 5. リクエスト内の URI を書き換える; 6. HTTP レスポンスを書き換えます。7. エラーを処理します。

Nginx Web サーバー構成ブロックは次のとおりです:

1. 仮想サーバーのセットアップ

NGINX 構成ファイルには、仮想サーバーを定義するためのサーバー ディレクティブが少なくとも 1 つ含まれている必要があります。 NGINX がリクエストを処理するとき、最初にリクエストを処理する仮想サーバーを選択します。

仮想サーバーは、http コンテキストのサーバー ディレクティブによって定義されます。例:

http {
    server {
        # Server configuration
    }
}

複数のサーバー ディレクティブを http コンテキストに追加して、複数の仮想サーバーを定義できます。

推奨チュートリアル: nginx クイック スタート チュートリアル

server構成ブロックには通常、サーバーを指定する listen ディレクティブが含まれていますリクエストをリッスンする IP アドレスとポート (または Unix ドメインのソケットとパス)。 IPv4 アドレスと IPv6 アドレスの両方が受け入れられます。角括弧 (.

次の例は、IP アドレス 127.0.0.1 およびポート 8080 でリッスンするサーバーの構成を示しています。

server {
    listen 127.0.0.1:8080;
    # The rest of server configuration
}

が省略されている場合は、標準ポートを使用します。同様に、アドレスが省略された場合、サーバーはすべてのアドレスをリッスンします。リッスン ディレクティブが含まれていない場合、「標準」ポートは 80/tcp で、「デフォルト」は" ポートは、スーパーユーザーの権限に応じて 8000 /tcp です。

複数のサーバーが要求された IP アドレスとポートに一致する場合、NGINX は、要求されたホスト ヘッダー フィールドをサーバー内の server_name ディレクティブに対してテストします。 block 。server_name への引数には、完全 (正確な) 名、ワイルドカード、または正規表現を指定できます。

ワイルドカードは、先頭、末尾、またはその両方にアスタリスク (*) を含む文字列です。アスタリスクは任意の文字シーケンスと一致します。NGINX は正規表現に Perl 構文を使用します。正規表現の前にチルダ (~) を使用します。この例は正確な名前を示しています。

server {
    listen      80;
    server_name example.org www.example.org;
    ...
}

ホスト ヘッダーが複数の名前と一致する場合、NGINX は次のようになりますシーケンスは名前を検索し、見つかった最初の一致を使用して 1 つを選択します:

• Exact Name (完全に正確な名前)

• 最長のワイルドカード文字アスタリスクで始まります。例: *.example.org

• アスタリスクで終わる最長のワイルドカード文字。例: mail.*

• 最初に一致する正規表現 (構成ファイルに表示される順序)

ホスト ヘッダー フィールドがサーバー名と一致しない場合、NGINX はリクエストをデフォルトにルーティングします。リクエストが到着するポートのサーバー。デフォルトのサーバーは、listen ディレクティブに listen_server パラメータを含めて明示的にサーバーをデフォルトとして指定しない限り、nginx.conf ファイルにリストされている最初のサーバーです。完全な Nginx 仮想マシン構成例。ここでは 2 つの仮想マシンの構成を示します。対応するドメイン名は vhost1.com と vhost2.com、vhost1.com Web サイトのメイン ディレクトリは

/data/www/ です。 vhost1

、vhost2.com Web サイトのメイン ディレクトリは /data/www/vhost2: <pre class='brush:php;toolbar:false;'>server { listen 80 default_server; ... }</pre>

2 にあります。設定の場所

NGINX は、リクエスト URI に従って構成できます。さまざまなプロキシがトラフィックを送信したり、さまざまなファイルを提供したりします。これらのブロックは、サーバー ディレクティブに配置されたロケーション ディレクティブを使用して定義されます。

たとえば、3 つのロケーション ブロックを定義できます。仮想サーバーに次のことを指示します。サーバーは一部のリクエストを送信し、他のリクエストを別のプロキシ サーバーに送信し、ローカル ファイル システムからファイルを渡すことによって残りを処理します。

NGINX テストは、すべての場所ディレクティブのパラメーターに基づいて URI を要求し、一致する場所で定義されたディレクティブを適用します。各 location ブロック内では、通常 (一部の例外を除いて) 追加の location ディレクティブを配置して、特定のリクエスト グループの処理をさらに調整することができます。

注: このチュートリアル記事では、「場所」という言葉は 1 つの場所のコンテキストを指します。

location ディレクティブには、プレフィックス文字列 (パス名) と正規表現の 2 種類のパラメータがあります。リクエスト URI がプレフィックス文字列と一致するには、プレフィックス文字列で始まる必要があります。

pathname パラメーターを含む次の場所の例は、

/some/path/document.html

など、/some/path/ で始まるリクエスト URI と一致しますが、 とは一致しません。 /my-site/some/path。/some/path が URI の先頭に現れないためです。 <pre class='brush:php;toolbar:false;'>server { listen 80; server_name vhost1.com www.vhost1.com; index index.html index.html; root /data/www/vhost1; access_log /var/log/vhost1.com.log; } server { listen 80; server_name vhost2.com www.vhost2.com; index index.html index.html; root /data/www/vhost2; access_log /var/log/vhost2.com.log; }</pre>正規表現の前には、大文字と小文字を区別する一致の場合はチルダ (~) が付き、大文字と小文字を区別しない一致の場合はチルダ (~*) が付きます。次の例では、文字列 .html または .html を含む URI を任意の場所と照合します。

location /some/path/ {
    ...
}

URI に最も一致する場所を見つけるために、NGINX はまず URI をプレフィックス文字列の場所と比較します。次に、正規表現を使用して場所を検索します。

正規表現に高い優先順位を与えるために ^~ 修飾子が使用されている場合を除きます。 NGINX は、プレフィックス文字列の中で、最も具体的な文字列 (つまり、最も長く、最も完全な文字列) を選択します。リクエストを処理する場所を選択するための正確なロジックを以下に示します。

すべての URI のプレフィックス文字列をテストします。
= (等号) 修飾子は、URI とプレフィックス文字列間の完全一致を定義します。完全に一致するものが見つかった場合、検索は停止します。

• 如果^~(插入符号)修饰符预先添加最长匹配前缀字符串，则不会检查正则表达式。

• 存储最长匹配的前缀字符串。

• 根据正则表达式测试URI。

• 断开第一个匹配的正则表达式并使用相应的位置。

• 如果没有正则表达式匹配，则使用与存储的前缀字符串相对应的位置。

=修饰符的典型用例是/(正斜杠)的请求。 如果请求/是频繁的，则指定=/作为location指令的参数加速处理，因为搜索匹配在第一次比较之后停止。

location = / {
    ...
}

location上下文可以包含定义如何解析请求的指令 - 提供静态文件或将请求传递给代理的服务器。 在以下示例中，匹配第一个location上下文的请求将从/data/images目录中提供文件，并将匹配第二个位置的请求传递给承载 www.example.com 域内容的代理服务器。

server {
    location /images/ {
        root /data;
    }
    location / {
        proxy_pass http://www.example.com;
    }
}

root指令指定要在其中搜索要提供的静态文件的文件系统路径。 与该位置相关联的请求URI将附加到路径，以获取要提供的静态文件的全名。 在上面的示例中，要响应/images/logo.png的请求，NGINX提供服务器本地实际对应文件是：/data/images/logo.png。

proxy_pass指令将请求传递给使用配置的URL访问代理服务器。然后将代理服务器的响应传回客户端。在上面的示例中，所有不以/images/开头的URI的请求都将被传递给代理的服务器(也就是：www.example.com)。

3. 使用变量

可以使用配置文件中的变量，使NGINX进程的请求根据定义的情况而有所不同。 变量是在运行时计算的命名值，用作指令的参数。 一个变量由它的名字开头的$(美元)符号表示。 变量根据NGINX的状态定义信息，例如正在处理的请求的属性。

有许多预定义的变量，如核心HTTP变量，您可以使用set，map和geo指令定义自定义变量。 大多数变量在运行时计算的，并包含与特定请求相关的信息。 例如，$remote_addr包含客户端IP地址，$uri保存当前的URI值。

4. 返回特定状态码

一些网站URI需要立即返回具有特定错误或重定向代码的响应，例如当页面被暂时移动或永久移动时。 最简单的方法是使用return指令。 例如返回未找到的404状态码：

location /wrong/url {
    return 404;
}

返回的第一个参数是响应代码。可选的第二个参数可以是重定向的URL(代码301,302,303和307)或在响应体中返回文本。 例如：

location /permanently/moved/url {
    return 301 http://www.example.com/moved/here;
}

返回指令可以包含在 location 和 server 上下文中。

重写URI请求

可以通过使用rewrite指令在请求处理期间多次修改请求URI，该指令具有一个可选参数和两个必需参数。 第一个(必需)参数是请求URI必须匹配的正则表达式。 第二个参数是用于替换匹配URI的URI。 可选的第三个参数是可以停止进一步重写指令的处理或发送重定向(代码301或302)的标志。例如：

 

location /users/ {
    rewrite ^/users/(.*)$ /show?user=$1 break;
}

如该示例所示，用户通过匹配正则表达式捕获第二个参数。

您可以在location 和 server上下文中包含多个rewrite指令。 NGINX按照它们发生的顺序逐个执行指令。 当选择该上下文时，server上下文中的rewrite指令将被执行一次。

在NGINX处理一组rewrite指令之后，它根据新的URI选择一个location上下文。 如果所选location块包含rewrite指令，则依次执行它们。 如果URI与其中任何一个匹配，则在处理所有定义的rewrite指令之后，将搜索新location块。

以下示例显示了与返回指令相结合的rewrite指令。

server {
    ...
    rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 last;
    rewrite ^(/download/.*)/audio/(.*)\..*$ $1/mp3/$2.ra  last;
    return  403;
    ...
}

此示例配置区分两组URI。 诸如/download/some/media/file之类的URI更改为/download/some/mp3/file.mp3。由于最后一个标志，所以跳过后续指令(第二次rewrite和return指令)，但NGINX继续处理该请求，该请求现在具有不同的URI。类似地，诸如/download/some/audio/file的URI被替换为/download/some/mp3/file.ra。 如果URI与rewrite指令不匹配，则NGINX将403错误代码返回给客户端。

有两个中断处理重写指令的参数：

last - 停止执行当前服务器或位置上下文中的重写指令，但是NGINX会搜索与重写的URI匹配的位置，并且应用新位置中的任何重写指令(URI可以再次更改，往下继续匹配)。

break - 像break指令一样，在当前上下文中停止处理重写指令，并取消搜索与新URI匹配的位置。新位置(location)块中的rewrite指令不执行。

5. 重写HTTP响应

有时您需要重写或更改HTTP响应中的内容，将一个字符串替换为另一个字符串。 您可以使用sub_filter指令来定义要应用的重写。 该指令支持变量和替代链，使更复杂的更改成为可能。

例如，您可以更改引用除代理服务器之外的绝对链接：

location / {
    sub_filter      /blog/ /blog-staging/;
    sub_filter_once off;
}

另一个示例将方法从http://更改为http://，并从请求头域替换本地主机地址到主机名。 sub_filter_once指令告诉NGINX在一个位置(location)内连续应用sub_filter伪指令：

location / {
    sub_filter     'href="http://127.0.0.1:8080/'    'href="http://$host/';
    sub_filter     'img src="http://127.0.0.1:8080/' 'img src="http://$host/';
    sub_filter_once on;
}

请注意，如果发生另一个sub_filter匹配，则使用sub_filter修改的响应部分将不再被替换。

处理错误

使用error_page指令，您可以配置NGINX返回自定义页面以及错误代码，替换响应中的其他错误代码，或将浏览器重定向到其他URI。 在以下示例中，error_page指令指定要返回404页面错误代码的页面(/404.html)。

error_page 404 /404.html;

请注意，此伪指令并不立即返回该错误(返回指令执行该操作)，而仅仅是指定发生时如何处理错误。 错误代码可以来自代理服务器，或者在NGINX处理期间发生(例如，当NGINX找不到客户端请求的文件时，显示404对应的结果)。

在以下示例中，当NGINX找不到页面时，它会将代码301替换为代码404，并将客户端重定向http:/example.com/new/path.html。 当客户端仍尝试访问其旧URI的页面时，此配置非常有用。 301代码通知浏览器页面已经永久移动，并且需要在返回时自动替换旧地址。

location /old/path.html {
    error_page 404 =301 http:/example.com/new/path.html;
}

以下配置是在未找到文件时将请求传递给后端的示例。 因为在error_page指令的等号之后没有指定状态代码，所以对客户机的响应具有代理服务器返回的状态代码(不一定是404)。

server {
    ...
    location /images/ {
        # Set the root directory to search for the file
        root /data/www;
        # Disable logging of errors related to file existence
        open_file_cache_errors off;
        # Make an internal redirect if the file is not found
        error_page 404 = /fetch$uri;
    }
    location /fetch/ {
        proxy_pass http://backend/;
    }
}

当没有找到文件时，error_page指令指示NGINX进行内部重定向。 error_page指令的最终参数中的$uri变量保存当前请求的URI，该URI在重定向中被传递。

例如，如果没有找到/images/some/file，它将被替换为/fetch/images/some/file，并且新的搜索位置(location)开始。最后请求最终在第二个location上下文中，并被代理到http://backend/。

如果没有找到文件，则open_file_cache_errors指令可防止写入错误消息。 因为丢失的文件可被正确地处理，但这不是必需的。

以上がNginx Web サーバー構成ブロックとは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。