Mastering Nginx 필기 1 - Nginx 기초 및 위치 설명

Installing NGINX and Third-Party Modules
    Installing NGINX using a package
    manager 

yum install nginx

    CentOS
Add the NGINX repository to your yum configuration by creating the following file:

    vi /etc/yum.repos.d/nginx.repo
    
    [nginx]
    name=nginx repo
    baseurl=http://nginx.org/packages/centos/6/$basearch/
    gpgcheck=0
    enabled=1

Preparing a build environment

  yum install pcre-devel
  yum install zlib-devel
  yum install openssl-devel

Installing NGINX from source
I would therefore recommend the following  configure options for a web
accelerator/proxy:

$ ./configure --with-http_ssl_module --with-http_realip_module --with-
http_geoip_module --with-http_stub_status_module --with-openssl=${BUILD_
DIR}/openssl-1.0.1c

And the following for a web server:

$ ./configure --with-http_stub_status_module

installing third-party modules
    1. Locate the module you would like to use (either search on
    https://github.com or see  http://wiki.nginx.org/3rdPartyModules ).
    2. Download the module.
    3. Unpack the source.
    4. Read the README file, if included. See if there are any dependencies
    that you will need to install.
    5. Configure NGINX to use the module as follows.  /configure –add-
    module= 
A Configuration Guide
    The  server_name directive is fairly straightforward, but can be used to solve a number
    of configuration problems. Its default value is  "" , which means that a server section
    without a  server_name directive will match a request that has no  Host header field
    set. This can be used, for example, to drop requests that lack this header:
    server {
    listen 80;
    return 444;
    }
    The non-standard HTTP code,  444 , used in this example will cause NGINX to
    immediately close the connection.
NGINX uses the following logic when determining which virtual server should
serve a specific request:
    1. Match the IP address and port to the  listen directive.
    2. Match the  Host header field against the  server_name directive as a string.
    3. Match the  Host header field against the  server_name directive with a
    wildcard at the beginning of the string.
    4. Match the  Host header field against the  server_name directive with a
    wildcard at the end of the string.
    5. Match the  Host header field against the  server_name directive as a regular
    expression.
    6. If all the  Host headers match  fail , then direct to the  listen directive
    marked as  default_server .
    7. If all the  Host headers match  fail and there is no  default_server ,
    direct to the first server with a  listen directive that satisfies step 1.
Locations
The  location directive may be used within a virtual server section and indicates a
URI that comes either from the client or from an internal redirect
A location is defined as follows:
    location [modifier] uri {...}
Or for a named location:
    location @name {…}
A named location is only reachable from an internal redirect. It preserves the URI
as it was before entering the location block. It may only be defined at the server
context level.
Location modifiers
Modifier Handling
=        Use exact match and terminate search.
~        Case-sensitive regular expression matching.
~*       Case-insensitive regular expression matching.
^~       Stops processing before regular expressions are  
         checked for a match of this location's string, if
         it's the most specific match. Note that this is not
         a regular expression match – its purpose is to
         preempt regular expression matching. uri 는 일반적인 문자열 로 시작 하여 url 경로 와 일치 하 는 것 으로 이해 하면 됩 니 다. nginx 는 url 에 인 코딩 을 하지 않 기 때문에 / static / 20% / aa 로 요청 하면 규칙 ^ ~ / static / / / aa 에 일치 할 수 있 습 니 다 (빈 칸 주의).