Server names

Server names are defined using the server_name directive and determine which server block is used for a given request. See also “ How nginx processes a request ”. They may be defined using exact names, wildcard names, or regular expressions: server { listen 80; server_name example.org www.example.org; server { listen 80; server_name *.example.org; server { listen 80; server_name mail.*; server { listen 80; server_name ~^(?<user>.+)\.example\.net$; When searching for a virtual server by name, if name matches more than one of the specified variants, e.g. both wildcard name and regular expression match, the first matching variant will be chosen, in the following order of precedence: exact name longest wildcard name starting with an asterisk, e.g. “ *.example.org ” longest wildcard name ending with an asterisk, e.g. “ mail.* ” first matching regular expression (in order of appearance in a configuration file)

There are some server names that are treated specially. If it is required to process requests without the “Host” header field in a server block which is not the default, an empty name should be specified: server { listen 80; server_name example.org www.example.org ""; If no server_name is defined in a server block then nginx uses the empty name as the server name. nginx versions up to 0.8.48 used the machine’s hostname as the server name in this case. If a server name is defined as “ $hostname ” (0.9.4), the machine’s hostname is used. If someone makes a request using an IP address instead of a server name, the “Host” request header field will contain the IP address and the request can be handled using the IP address as the server name: server { listen 80; server_name example.org www.example.org 192.168.1.1 In catch-all server examples the strange name “ _ ” can be seen: server { listen 80 default_server; server_name _; return 444; There is nothing special about this name, it is just one of a myriad of invalid domain names which never intersect with any real name. Other invalid names like “ -- ” and “ !@# ” may equally be used. nginx versions up to 0.6.25 supported the special name “ * ” which was erroneously interpreted to be a catch-all name. It never functioned as a catch-all or wildcard server name. Instead, it supplied the functionality that is now provided by the server_name_in_redirect directive. The special name “ * ” is now deprecated and the server_name_in_redirect directive should be used. Note that there is no way to specify the catch-all name or the default server using the server_name directive. This is a property of the listen directive and not of the server_name directive. See also “ How nginx processes a request ”. It is possible to define servers listening on ports *:80 and *:8080, and direct that one will be the default server for port *:8080, while the other will be the default for port *:80: server { listen 80; listen 8080 default_server; server_name example.net; server { listen 80 default_server; listen 8080; server_name example.org;

Internationalized domain names ( IDNs ) should be specified using an ASCII (Punycode) representation in the server_name directive: server { listen 80; server_name xn--e1afmkfd.xn--80akhbyknj4f; # пример.испытание

First, a connection is created in a default server context. Then, the server name can be determined in the following request processing stages, each involved in server configuration selection: if the server name was not determined after processing the request line or from the Host header field, nginx will use the empty name as the server name. in case of the ssl_protocols directive, the protocol list is set by the OpenSSL library before the server configuration could be applied according to the name requested through SNI, thus, protocols should be specified only for a default server; client_header_buffer_size merge_slashes directives are involved before reading the request line, thus, such directives use a default server configuration or the server configuration chosen by SNI; in case of the ignore_invalid_headers , large_client_header_buffers , underscores_in_headers directives involved in processing request header fields, it additionally depends whether the server configuration was updated according to the request line or the Host header field; an error response will be handled with the error_page directive in the server that currently fulfills the request.

Exact names, wildcard names starting with an asterisk, and wildcard names ending with an asterisk are stored in three hash tables bound to the listen ports. The sizes of hash tables are optimized at the configuration phase so that a name can be found with the fewest CPU cache misses. The details of setting up hash tables are provided in a separate document . The exact names hash table is searched first. If a name is not found, the hash table with wildcard names starting with an asterisk is searched. If the name is not found there, the hash table with wildcard names ending with an asterisk is searched. Searching wildcard names hash table is slower than searching exact names hash table because names are searched by domain parts. Note that the special wildcard form “ .example.org ” is stored in a wildcard names hash table and not in an exact names hash table. Regular expressions are tested sequentially and therefore are the slowest method and are non-scalable. For these reasons, it is better to use exact names where possible. For example, if the most frequently requested names of a server are example.org and www.example.org , it is more efficient to define them explicitly: server { listen 80; server_name example.org www.example.org *.example.org; than to use the simplified form: server { listen 80; server_name .example.org; If a large number of server names are defined, or unusually long server names are defined, tuning the server_names_hash_max_size and server_names_hash_bucket_size directives at the http level may become necessary. The default value of the server_names_hash_bucket_size directive may be equal to 32, or 64, or another value, depending on CPU cache line size. If the default value is 32 and server name is defined as “ too.long.server.name.example.org ” then nginx will fail to start and display the error message: could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32 In this case, the directive value should be increased to the next power of two: http { server_names_hash_bucket_size 64; If a large number of server names are defined, another error message will appear: could not build the server_names_hash, you should increase either server_names_hash_max_size: 512 or server_names_hash_bucket_size: 32 In such a case, first try to set server_names_hash_max_size to a number close to the number of server names. Only if this does not help, or if nginx’s start time is unacceptably long, try to increase server_names_hash_bucket_size . If a server is the only server for a listen port, then nginx will not test server names at all (and will not build the hash tables for the listen port). However, there is one exception. If a server name is a regular expression with captures, then nginx has to execute the expression to get the captures.