Detailed explanation of how to configure Nginx web server sample code

Overview

Today we will mainly share how to configure NGINX as a web server, and include the following parts:

• Setting up a virtual server
• Configuration Location
• Using variables
• Return a specific status code
• Rewriting HTTP responses

At a high level, there are some issues to understand when configuring NGINX as a web server, defining which URLs it handles and how it handles HTTP requests for resources at those URLs. At a low level, a configuration defines a set of virtual servers that control the processing of requests for a specific domain or IP address.

Each virtual server used for HTTP traffic defines special configuration instances called locations, which control the handling of a specific set of URIs. Each location defines its own mapping for what happens to requests to that location. NGINX has full control over this process. Each location can proxy a request or return a file. Additionally, the URI can be modified to redirect the request to another location or virtual server. Additionally, specific error codes can be returned, and specific pages can be configured to correspond to each error code.

1. Set up a virtual server

The NGINX configuration file must contain at least one server directive to define a virtual server. When NGINX processes a request, it first selects a virtual server to serve the request.

A virtual server is defined by a server directive in the http context, for example:

http { 
 server { 
 # Server configuration 
 } 
}

Multiple server directives can be added to the http context to define multiple virtual servers.

The server configuration block typically includes a listen directive that specifies the IP address and port (or Unix domain socket and path) on which the server listens for requests. Both IPv4 and IPv6 addresses are accepted; enclose the square brackets (.

The following example shows the configuration of a server listening on IP address 127.0.0.1 and port 8080:

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

If port is omitted, the standard port is used. Likewise, if an address is omitted, the server listens on all addresses. If no listen directive is included, the "standard" port is 80/tcp and the "default" port is 8000/tcp, depending on superuser privileges.

If more than one server matches the requested IP address and port, NGINX tests the request’s Host header field against the server_name directive in the server block. The server_name argument can be a full (exact) name, a wildcard, or a regular expression. A wildcard is a string that contains an asterisk (*) at the beginning, end, or both; the asterisk matches any sequence of characters. NGINX uses Perl syntax for regular expressions; precede them with a tilde (). This example illustrates an exact name.

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

2. Configuration location

NGINX can send traffic to different proxies or serve different files based on the request URI. These blocks are defined using location directives placed within the server directive.

For example, you can define three location blocks to instruct the virtual server to send some requests to one proxied server, other requests to a different proxied server, and serve the rest by delivering files from the local file system.

The NGINX test requests the URI based on the parameters of all location directives and applies the directives defined in the matching locations. Within each location block, it is generally possible (with some exceptions) to place more location directives to further refine the handling of specific sets of requests.

Note: Throughout this tutorial article, the word location refers to a single location context.

The location directive takes two types of arguments: a prefix string (path name) and a regular expression. For a request URI to match the prefix string, it must start with the prefix string.

The following example location with the pathname parameter matches request URIs that begin with /some/path/, such as /some/path/document.html. It does not match /my-site/some/path because /some/path does not appear at the beginning of that URI.

location /some/path/ { 
 ... 
}

The regular expression is preceded by a tilde (~) for case-sensitive matching, or a tilde (~*) for case-insensitive matching. The following example matches URIs containing the string .html or .html anywhere.

location ~ \.html? { 
 ... 
}

To find the location that best matches a URI, NGINX first compares the URI to the location of the prefix string. Then search the location with a regular expression.

The location context can contain directives that define how the request should be resolved - to serve static files or to pass the request to a proxied server. In the following example, requests matching the first location context will serve files from the /data/images directory, and requests matching the second location will be passed to the proxy server hosting content for the www.example.com domain.

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

The root directive specifies the file system path to search for static files to serve. The request URI associated with the location will be appended to the path to obtain the full name of the static file to be served. In the above example, in response to the request for /images/logo.png, NGINX provides the actual corresponding file locally on the server: /data/images/logo.png.

The proxy_pass directive passes the request to the proxied server using the configured URL. The proxy server's response is then transmitted back to the client. In the example above, all requests for URIs that do not begin with /images/ will be passed to the proxied server (ie: www.example.com).

3. Using variables

You can use variables in the configuration file to make NGINX process requests differently depending on the circumstances you define. Variables are named values ​​computed at runtime and used as arguments to instructions. A variable is indicated by a $ (dollar) sign at the beginning of its name. Variables define information based on the state of NGINX, such as properties of the request being processed.

There are many predefined variables, such as the core HTTP variables, and you can define custom variables using the set, map, and geo directives. Most variables are computed at runtime and contain information relevant to a specific request. For example, $remote_addr contains the client IP address and $uri holds the current URI value.

4. Return a specific status code

Some website URIs need to return a response immediately with a specific error or redirect code, such as when a page is moved temporarily or permanently. The easiest way is to use the return instruction. For example, a 404 Not Found status code is returned:

location /wrong/url { 
 return 404; 
}

The first parameter returned is the response code. The optional second argument can be a URL to redirect to (codes 301, 302, 303, and 307) or a text to return in the response body. For example:

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

Return directives can be included in both location and server contexts.

5. Rewrite HTTP Response

Sometimes you need to rewrite or change the content in an HTTP response, replacing one string with another. You can use the sub_filter directive to define the rewrites to be applied. The directive supports variables and substitution chains, making more complex changes possible.

For example, you can change the absolute link to reference the proxy server:

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

Another example changes the method from http:// to http:// and replaces the localhost address to the host name from the request header field. The sub_filter_once directive tells NGINX to apply sub_filter directives consecutively within a location:

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

Note that if another sub_filter match occurs, the part of the response modified with the sub_filter will no longer be replaced.

This is the end of this article about the sample code of how to configure the web server with Nginx. For more information about how to configure the web server with Nginx, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!