Do you really understand how to configure Nginx as a web server

Do you really understand how to configure Nginx as a web server

Before reading, it is recommended to read Getting to Know Nginx. After that, let's take a look at Nginx configuration.

Abstractly speaking, configuring Nginx as a web server is to define which URLS to process and how to process the requests corresponding to these URLS. Specifically, it is to define some virtual servers (Virtual Servers) to control requests with specific IP and domain names.

More specifically, Nginx controls the choice of URIS by defining a series of locations. Each location defines the processing scenario for the request mapped to it: return a file or proxy request, or return different error pages according to different error codes. In addition, depending on the URI, the request can also be redirected to other servers or locations.

Set up a virtual server


The Nginx configuration file contains at least one server command, which is used to define a virtual server. When a request comes, Nginx will first select a virtual server to process the request.

The virtual server is defined in the server in the http context:

http {server {# Server configuration



Note: Multiple servers can be defined in http

The server configuration block uses the listen command to monitor the local IP and port number (including Unix domain socket and path), supports IPv4, IPv6, and IPv6 addresses need to be enclosed in square brackets:

server {listen; # IPv4 address, port 8080

# listen [2001:3CA1:10F:1A:121B:0:0:10]:80; # IPv6 address, port 80

# listen [::]:80; # Listen to all IPv4 and IPv6 addresses of this machine, port 80

# The rest of server configuration}

In the above configuration, if the port number is not written, port 80 is used by default, and if the IP is not written, all IPs of the machine will be monitored.


If the listen IP and port numbers of multiple servers are exactly the same, Nginx uses the Host in the request header

Compare with the host name defined by server_name to select the appropriate virtual server to process the request:

server {listen 80;




The parameters of server_name can be:

The full host name, such as:

Contains wildcards (including *), such as: * or api.*.

Regular expression, starting with ~.

Wildcards can only be at the beginning or end, and can only be adjacent to one. Both www.* and w* are invalid. However, you can use regular expressions to match these names, such as ~^www\..+\.example\.org$ and ~^w.*\.example\.org$. And * can match multiple parts. The name * matches not only but also

For regular expressions: The regular expressions used by Nginx are compatible with the regular expressions used by the Perl programming language (PCRE). To use regular expressions, it must start with ~.

Named regular expressions can capture variables and then use:

server {server_name ~^(www\.)?(?.+)$; location/{root/sites/$domain;



The matching content between parentheses () can also be quoted later by $1, and $2 represents the content in the second () before. Therefore, the above content can also be written as:

server {server_name ~^(www\.)?(.+)$; location/{root/sites/$2;



A server_name example:

server {listen 80;

server_name *;



Similarly, if multiple names match the Host header, Nginx selects in the following order:

The full host name, such as

The longest wildcard name starting with *, such as *

The longest wildcard name ending with *, such as api.*.

The first matching regular expression. (According to the order in the configuration file)

Namely priority:> *> api.*> regular.

If the Host header does not match any server_name, Nginx will route the request to the default virtual server. The default virtual server refers to: the first server in the nginx.conf file or explicitly declared with default_server:

server {listen 80 default_server;



Configure location

URI and location parameter matching

When the server is selected, Nginx will select the appropriate location based on the URIs to determine whether to proxy the request or return the file.

The location command accepts two types of parameters:

Prefix string (path name)

Regular expression

For prefix string parameters, URIs must strictly start with it. For example, for the/some/path/parameter, it can match/some/path/document.html but not/my-site/some/path, because/my-site/some/path does not start with/some/path/.




For regular expressions, starting with ~ means case-sensitive, and starting with ~* means case-insensitive. Note that the. In the path should be written as/.. For example, a location that matches a URI ending in .html or .htm:

location ~/.html? {



The priority of the regular expression is greater than the prefix string. If a matching prefix string is found, the regular expression will continue to be searched, but if the prefix string starts with ^~, the regular expression will not be checked.

The specific search matching process is as follows:

Compare the URI with all prefix strings.

The = modifier indicates that the URI must be equal to the prefix string (not the beginning, but equal). If found, the search stops.

If the longest prefix matching string found starts with ^~, no more search is made for whether the regular expression matches.

Store the longest prefix string that matches.

The test compares URIs and regular expressions.

Stop after finding the first matching regular expression.

If no regular expression matches, the location corresponding to the prefix string stored in 4 is used.

The = modifier has the highest precedence. If the homepage of the website is frequently visited, we can specifically define a location to reduce the number of search matches (because the searched = modified matching location will stop the search) and improve the speed:

location =/{



Static files and proxy

The location also defines how to handle matching requests: return static files or pass them to a proxy server for processing. In the following example, the first location returns the static files in the/data directory, and the second location passes the request to the domain server for processing:

server {location/images/{root/data;

} location/{proxy_pass;



The root directive defines the root directory of the static file, and is spliced ​​with the URI to form the final local file path. If/images/example.png is requested, the local server file/data/images/example.png will be returned after splicing.

The proxy_pass directive passes the request to the proxy server pointed to by the URL. After that, the response from the proxy server is forwarded to the client. In the above example, all requests for URIs that do not start with/images/will be passed to the proxy server for processing.

For example, if I set proxy_pass to, then visit you will get the same response (page) as the Baidu homepage (you can try the search for interested children's shoes) The function is no different from Baidu):


listen 80;






Use Variables (Variables)

You can use variables to make Nginx use different processing methods for different requests. Variables are calculated at runtime and used as parameters of instructions. Variables are represented by the symbol beginning with $. Variables are defined based on the state of Nginx, such as the attributes of the currently processed request.

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

Some commonly used variables are as follows:

Variable name function

The current URI in the $uri request (without request parameters). It can be modified through internal redirection or using the index command. $uri does not contain the host name, such as/foo/bar.html.

The parameter name in the $arg_name request, that is, the arg_name in the form of arg_name=arg_value after the "?"

$hostname hostname

$args parameter value in request

$query_string is the same as $args

$request represents the request address of the client

The variable $request_uri is equal to the original URI containing some client request parameters. It cannot be modified and does not contain the host name, such as:/cnphp/test.php?arg=freemouse.


A simple application is to bring path information when redirecting from http to https:


... return 301$request_uri;



Return a specific status code

If some resources on your website are permanently removed, the fastest and most concise way is to use the return command to return directly:

location/wrong/url {return 404;


The first parameter of return is the response code. The optional second parameter can be the URL of the redirect (corresponding to codes 301, 302, 303, and 307) or the text returned in the response body. E.g:

location/permanently/moved/url {return 301;


The return instruction can be included in the location and server contexts:


location/{return 404;





... return 404;





Error handling

The error_page command can configure an error page with a specific error code, or redirect to another page. The following example will return the/404.html page when a 404 error occurs.

error_page 404/404.html;

The error_page command defines how to handle errors, so it does not return directly, and return does return immediately. When the proxy server or Nginx processes the corresponding error code, the corresponding error page will be returned.

In the example below, when Nginx cannot find the page, it will replace code 404 with code 301 and redirect the client to This configuration is useful. For example, when the client is still trying to access the page with the old URI, the 301 code informs the browser that the page has been permanently removed and needs to be automatically replaced with the new address returned.

location/old/path.html {error_page 404 =301 http:/;


Rewrite URIs

The rewrite command can modify the requested URI multiple times. The first parameter of rewrite is the regular expression that the URI needs to match, and the second parameter is the URI to be replaced. The third parameter is optional, indicating whether to continue to rewrite or return the redirect code (301 or 302). E.g:

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


You can include multiple rewrite instructions in the server and location contexts. Nginx executes the instructions one by one in the order in which they occur. When server is selected, the rewrite instruction in server will be executed once.

After Nginx processes a set of rewrite instructions, it selects the location based on the new URI. If the selected location still contains rewrite instructions, they will be executed in sequence. If the URI matches all, after processing all defined rewrite instructions, search for a new location.

The following example uses the rewrite instruction in conjunction with the return instruction:

server {


rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 last;

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



The URI such as/download/some/media/file has been changed to/download/some/mp3/file.mp3. Due to the last flag, subsequent instructions (the second rewrite instruction and return instruction) are skipped, but Nginx continues to process the request with the changed URI. Similarly, URIs such as/download/some/audio/file are replaced with/download/some/mp3/file.ra. If the URI does not match the rewrite command, Nginx will return a 403 error code to the client.

The difference between last and break is:

last: Stop executing the rewrite command in the context of the current server or location, but Nginx continues to search for the location that matches the rewritten URI, and applies any rewrite command in the new location (this means that the URI may change again).

break: Stop the processing of the rewrite instruction in the current context, and cancel the search for the location that matches the new URI. The rewrite command in the new location will not be executed.


Commonly used regular

.: Match any character except newline

?: Repeat 0 times or 1 time

+: Repeat 1 or more times

*: Repeat 0 or more times

\d: match numbers

^: match the beginning of the string

$: Introduction to the matching string

{n}: Repeat n times

{n,}: Repeat n times or more

[c]: Match a single character c

[az]: Match any of the lowercase letters of az

Global variable

$args: #This variable is equal to the parameters in the request line, the same as $query_string

$content_length: Content-length field in the request header.

$content_type: Content-Type field in the request header.

$document_root: The value specified in the root directive of the current request.

$host: Request host header field, otherwise it is the server name.

$http_user_agent: client agent information

$http_cookie: client cookie information

$limit_rate: This variable can limit the connection rate.

$request_method: The action requested by the client, usually GET or POST.

$remote_addr: The IP address of the client.

$remote_port: The port of the client.

$remote_user: The user name that has been verified by the Auth Basic Module.

$request_filename: The file path of the current request, generated by the root or alias command and URI request.

$scheme: HTTP method (such as http, https).

$server_protocol: The protocol used by the request, usually HTTP/1.0 or HTTP/1.1.

$server_addr: server address, this value can be determined after completing a system call.

$server_name: server name.

$server_port: The port number of the request to reach the server.

$request_uri: contains the original URI of the request parameters, excluding the host name, such as:/foo/bar.php?arg=baz.

$uri: The current URI without request parameters. $uri does not contain the host name, such as/foo/bar.html.

$document_uri: Same as $uri.

For example request: http://localhost:88/test1/test2/test.php

$host: localhost

$server_port: 88

$request_uri: http://localhost:88/test1/test2/test.php




Reference: Do you really know how to configure Nginx as a web server-Cloud + Community-Tencent Cloud