>  기사  >  운영 및 유지보수  >  Nginx 웹 서버 구성 블록이란 무엇입니까?

Nginx 웹 서버 구성 블록이란 무엇입니까?

coldplay.xixi
coldplay.xixi원래의
2020-06-29 16:44:022466검색

Nginx 웹 서버 구성 블록에는 다음이 포함됩니다. 1. 가상 서버 설정 3. 변수 사용 4. 요청에서 URI 다시 작성 7. 오류를 처리합니다.

Nginx 웹 서버 구성 블록이란 무엇입니까?

Nginx 웹 서버 구성 블록은 다음과 같습니다.

1 가상 서버 설정

NGINX 구성 파일에는 가상 서버를 정의하기 위한 서버 지시어가 하나 이상 포함되어야 합니다. NGINX는 요청을 처리할 때 먼저 요청을 처리하는 가상 서버를 선택합니다.

가상 서버는 http 컨텍스트의 서버 지시어로 정의됩니다. 예:

http {
    server {
        # Server configuration
    }
}

여러 서버 지시어를 http 컨텍스트에 추가하여 여러 가상 서버를 정의할 수 있습니다.

권장 튜토리얼: nginx 빠른 시작 튜토리얼

server 구성 블록에는 일반적으로 서버가 요청을 수신하는 IP 주소와 포트(또는 Unix 도메인 소켓)를 지정하는 Listen 지시문이 포함되어 있습니다. 및 경로). IPv4 및 IPv6 주소 모두 허용됩니다. 대괄호로 묶습니다. server配置块通常包括一个listen指令,用于指定服务器侦听请求的IP地址和端口(或Unix域套接字和路径)。IPv4和IPv6地址均被接受; 将方括号(。

下面的示例显示了监听IP地址127.0.0.1和端口8080的服务器的配置:

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

如果省略端口,则使用标准端口。 同样地,如果省略一个地址,服务器将侦听所有地址。 如果没有包含listen指令,则“标准”端口为80/tcp,“default”端口为8000/tcp,具体取决于超级用户权限。

如果有多个服务器与请求的IP地址和端口相匹配,则NGINX将根据服务器块中的server_name指令测试请求的主机头域。 server_name的参数可以是完整(精确)名称,通配符或正则表达式。 

通配符是一个字符串,其开头,结尾或两者都包含星号(*); 星号匹配任何字符序列。 NGINX将Perl语法用于正则表达式; 在它们之前使用波浪号(〜)。 此示例说明了一个确切的名称。

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

如果匹配主机头几个名称,则NGINX通过按以下顺序搜索名称并使用其找到的第一个匹配来选择一个:

  • 确切的名字(完整准确的名称)

  • 以星号开头的最长通配符,例如:*.example.org

  • 以星号结尾的最长通配符,如:mail.*

  • 第一个匹配正则表达式(按照出现在配置文件中的顺序)

如果主机头字段与服务器名称不匹配,则NGINX会将请求路由到请求到达端口的默认服务器。 默认服务器是nginx.conf文件中列出的第一个服务器,除非您将listen_server参数包含在listen指令中以明确指定服务器为默认值。

server {
    listen    80    default_server;
    ...
}

一个完整的Nginx虚拟机配置示例,这里我们演示配置两个虚拟机,对应域名分别为:vhost1.com 和 vhost2.com,vhost1.com网站的主目录在/data/www/vhost1,vhost2.com网站的主目录在/data/www/vhost2

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

2. 配置位置

NGINX可以根据请求URI向不同的代理发送流量或提供不同的文件。 这些块是使用放置在server指令中的location指令来定义的。

例如,您可以定义三个location块,以指示虚拟服务器向一个代理服务器发送一些请求,将其他请求发送到不同的代理服务器,并通过从本地文件系统传递文件来提供其余请求。

NGINX测试根据所有location指令的参数请求URI,并应用匹配location中定义的指令。 在每个location块内,通常可能(除了一些例外)放置更多的location指令以进一步细化特定组请求的处理。

注意:在本教程文章中,单词location是指单个location上下文。

location指令有两种类型的参数:前缀字符串(路径名)和正则表达式。 对于要匹配前缀字符串的请求URI,必须以前缀字符串开头。

具有pathname参数的以下示例位置匹配以/some/path/开头的请求URI,例如/some/path/document.html,它不匹配/my-site/some/path,因为/some/path

아래 예는 IP 주소 127.0.0.1 및 포트 8080을 수신하는 서버의 구성을 보여줍니다.

location /some/path/ {
    ...
}

포트가 생략되면 표준 포트가 사용됩니다. 마찬가지로 주소를 생략하면 서버가 모든 주소를 수신합니다. 청취 지시문이 포함되지 않은 경우 "표준" 포트는 80/tcp이고 "기본" 포트는 8000입니다. /tcp. 슈퍼유저 권한에 따라 다릅니다.

요청된 IP 주소 및 포트와 일치하는 서버가 여러 개 있는 경우 NGINX는 서버 블록의 server_name 지시어에 대해 요청된 호스트 헤더 필드를 테스트합니다. (정확함). 이름, 와일드카드 또는 정규식

와일드카드는 시작, 끝 또는 둘 다에 별표(*)가 포함된 문자열입니다. ) 이 예는 정확한 이름을 보여줍니다.
    location ~ \.html? {
        ...
    }
  • 여러 이름이 호스트와 일치하는 경우 NGINX는 다음 순서로 이름을 검색하고 찾은 첫 번째 일치 항목을 사용하여 하나를 선택합니다.

  • 정확한 이름(완전하고 정확한 이름) )

    🎜🎜별표로 시작하는 가장 긴 와일드카드(예: *.example.org🎜🎜🎜🎜별표로 끝나는 가장 긴 와일드카드, 예: mail.* 🎜🎜🎜🎜첫 번째로 일치하는 정규 표현식(in 구성 파일에 나타나는 순서) 🎜🎜
🎜호스트 헤더 필드가 서버 이름과 일치하지 않으면 NGINX는 요청을 요청 도착 포트의 기본값인 서버로 라우팅합니다. 기본 서버는 첫 번째 서버입니다. 🎜
location = / {
    ...
}
🎜전체 Nginx 가상 머신 구성 예는 다음과 같습니다. 데모에서는 두 개의 가상 머신을 구성합니다. 해당 도메인 이름은 vhost1.com 및 vhost2.com입니다. vhost1.com 웹사이트의 기본 디렉터리는 /data/www/vhost1에 있고 vhost2.com 웹사이트의 기본 디렉터리는 다음과 같습니다. /data/www/vhost2: 🎜
server {
    location /images/ {
        root /data;
    }
    location / {
        proxy_pass http://www.example.com;
    }
}
🎜🎜2. 구성 위치 🎜🎜🎜NGINX는 요청 URI를 기반으로 트래픽을 다른 프록시로 보내거나 다른 파일을 제공할 수 있습니다. 🎜🎜예를 들어, 가상 서버에 일부 요청을 하나의 프록시 서버로 보내고, 다른 요청을 다른 프록시 서버로 보내고, 로컬 파일 시스템에서 파일을 전달하여 나머지 요청을 처리하도록 지시하는 세 개의 위치 블록을 정의할 수 있습니다. 🎜🎜NGINX는 모든 위치 지시어의 매개변수를 기반으로 요청 URI를 테스트하고 위치에 정의된 일치하는 지시어를 적용합니다. 각 위치 블록 내에서는 일반적으로 특정 요청 그룹의 처리를 더욱 구체화하기 위해 추가 위치 지시어를 배치하는 것이 가능합니다(일부 예외 있음). 🎜🎜참고: 이 튜토리얼 기사에서 위치라는 단어는 단일 위치 컨텍스트를 나타냅니다. 🎜🎜위치 지시문에는 접두사 문자열(경로 이름)과 정규 표현식이라는 두 가지 유형의 매개 변수가 있습니다. 요청 URI가 접두사 문자열과 일치하려면 접두사 문자열로 시작해야 합니다. 🎜🎜pathname 매개변수가 있는 다음 예제 위치는 /some/path/로 시작하는 요청 URI와 일치합니다(예: /some/path/document.html/my-site/와 일치하지 않음). some /path, 왜냐하면 /some/path가 URI의 시작 부분에 나타나지 않기 때문입니다. 🎜
location /wrong/url {
    return 404;
}
🎜정규 표현식 앞에는 대소문자를 구분하는 일치의 경우 물결표(~)가, 대소문자를 구분하지 않는 일치의 경우 물결표(~*)가 앞에 옵니다. 다음 예에서는 .html 또는 .html 문자열이 포함된 URI와 임의의 위치를 ​​일치시킵니다. 🎜
location /permanently/moved/url {
    return 301 http://www.example.com/moved/here;
}
🎜 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 웹 서버 구성 블록이란 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

    성명:
    본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.