Shulou(Shulou.com)06/02 Report--

This article mainly explains "the basic attribute configuration of Nginx". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "the basic attribute configuration of Nginx".

1. Basic configuration of the Nginx service 1.1 configuration items for debugging processes and locating problems

Whether to run nginx as a daemon

# default ondaemon on | off

Whether to work in master/worker mode

# default on, which specifies whether to run as a master-worker process. If set to off, all requests will only be processed by the master process master_process on | off

Settings for error logs

# specifies the directory and log level of error logs. The second parameter is used to specify the directory, and the third parameter is used to specify the log level. A total of debug, info, notice, warn, error, crit, alert, emerg are specified. Among these log levels, the priority increases from left to right. The default is infoerror_log logs/error.log error.

Whether to deal with several special adjustment points

# specified debug_points stop for tuning points | abort

Output debug-level logs only to specified clients

Debug_connection IP | CIDR

This parameter is mainly used in the events module to record debug logs for the specified ip or network segment:

Events {debug_connection 10.224.66.14; debug_connection 10.224.57.0 take 24;}

It should be noted that when using this parameter, you must make sure that the-- with-debug parameter has been added to the configure, otherwise it will not take effect.

Limit the size of coredump core dump files

Worker_rlimit_core size

In the Linux operating system, if a process is terminated due to an error or received a signal, the memory contents of the process execution will be written to a file (core file) for debugging, which is called core dump. When the nginx process goes down, it produces a core dump file, and the file usually has several gigabytes, so if the size of the file is not limited, it is likely to fill up the server disk. The purpose of this parameter is to limit the size of the core dump file.

Specify the coredump file generation directory

Working_directory path

This parameter specifies the directory where the core dump file will be stored when it is generated.

1.2 configuration items for normal operation

Define environment variables

Env TESTPATH=/tmp/

This configuration item allows the user to set environment variables directly on the operating system.

Embed other profiles

Include / path/file

Used to bring in other configuration files, which can be absolute or relative, or, if relative, specified based on the nginx configuration directory.

The path to the pid file

Pid path/file

Used to specify the path to the file of the process id used by the master process that stores the nginx.

Users and user groups running the worker process of Nginx

User username [groupName]

It is used to specify the user and user group under which the worker process is run. The default is nobody. If groupName is not specified here, the group name is the same as the user name.

Specifies the maximum number of handle descriptors that can be opened by the worker process of nginx

Worker_rlimit_nofile limit

Sets the maximum number of handle descriptors that a worker process can open.

Limit signal queue

Worker_rlimit_sigpending limit

Set the size of the signal queue that each user can send to nginx, if the signal queue is full, then the new signal will be discarded.

1.3 configuration items for optimizing performance

Number of worker processes in nginx

Worker_processes 1

It is used to specify the number of worker processes when nginx is running. When nginx is running, each worker process runs in a single thread. Here you need to determine whether the worker process has performed an blocking operation. If there is such an operation, it is better to configure a little more worker processes. If not, setting the number of worker processes to the same as the number of CPU can get better performance.

Bind the worker process of nginx to the specified CPU kernel

Worker_cpu_affinity cpumask [cpumask...]

Bind the worker process to the specified CPU, which prevents multiple worker processes from preempting the same CPU, thus avoiding synchronization problems. The following is a 4-core CPU configuration:

Worker_processes 4 workerplate CPUs 1000 0100 0010 0001

It is important to note that worker_cpu_affinity is only valid for Linux systems.

SSL hardware acceleration

Ssl_engine device

If you have a SSL hardware acceleration device on the server, you can configure it to speed up the processing of the SSL protocol. Users can use the commands provided by OpenSSL to see if there are SSL hardware acceleration devices:

Openssl engine-t

The execution frequency of the system call gettimeofday

Timer_resolution-t

By default, a gettimeofday is executed every time the kernel event call returns. In the early Linux version, there was a data replication from kernel state to user mode when getting the system time, which was expensive, but in the latest x86-64 architecture, gettimeofday is only a vsyscall and only access to the data in the shared memory page, which is not expensive.

Worker process priority of nginx

Worker_priority nice

Used to set the priority of the worker process for nginx, where the default value for nice is 0. In the Linux operating system, when multiple processes are competing for CPU execution resources, they will give priority to the execution rights according to the priority set by each process, and the time slice allocated is also higher. The value of priority is between-20 and 19, and the lower the value, the higher the priority. It is generally recommended to set the priority of nginx to a lower level to ensure its permission to execute, but it is not recommended to set it lower than the process priority of the kernel (the value is-5).

1.4 event class configuration items

Whether to open the accept lock

Accept_mutex [on | off]

The accept_mutex parameter is used to control whether the load balancer lock is enabled. Its default value is on, which ensures that each worker takes turns and serializes to establish a connection with the new client. When the number of connections of a worker reaches 7 / 8 of the maximum number of connections configured by the worker_connections, the lock will reduce the number of new connections to be established by the worker, thus ensuring the load balance of each worker.

The path to the lock file

Lock_file path/file

This parameter specifies the path to the lock file. Nginx uses locking capabilities provided by the operating system, but file locks are used to implement lock only if the operating system does not support atomic locks. If the accept_mutex parameter is set to off, it will not take effect.

The delay time between using accept locks and actually establishing a connection

Accept_mutex_delay Nms

If a worker process fails in its attempt to acquire a lock, it waits for the time period specified by this parameter to try to acquire the lock again, which defaults to 500ms.

Establish new connections in batch

Multi_accept [on | off]

When the event model notifies that there is a new connection establishment request, try to establish a connection to all TCP requests initiated by the client in this scheduling. This value defaults to off.

Select event model

Use [kqueue | rtsig | epoll | / dev/poll | select | poll | eventport]

The event model chosen by nginx automatically uses the most appropriate model. Poll, select and epoll are supported under Linux operating system, among which epoll has the highest performance.

Maximum number of connections per worker

Worker_connections number

Specifies the maximum number of connections that each worker process can establish.

2. Http core module configuration 2.1 listening port listen address:port [default (deprecated) | default_server | [backlog=num | rcvbuf=size | sndbuf=size | accept_filter=filter | deferred | bind | ipv6only= [on | off] | ssl]]

The configuration of the IP address and port number here is very flexible. If the port number is not configured, the default is port 80, while the ip address can be matched using wildcards, such as:

Listen 127.0.0.1 8080 investors *: 8080

The parameters of listen are as follows:

Default and default_server: use the current server block as the default server block for the entire web server, or the first server block in the nginx.conf as the default server block if no server sets this parameter. The reason for setting this parameter is that if the current request does not match any server, the first server is used to process the request

Backlog=num: specifies the size of the backlog queue in TCP, with a default value of-1. During the three-way handshake in TCP, the process has not yet started to process the listening handle, and these requests will be placed in the backlog queue. When the backlog queue is full, the client's new handshake request will be rejected.

Rcvbuf=size: sets the SO_RCVBUF parameter of the listening handle

Sndbuf=size: sets the SO_SNDBUF parameter of the listening handle

Accept_filter: set accept filter, useful only for FreeBSD operating system

Deferred: if this parameter is set, if the user initiates a TCP connection request, the kernel will not schedule the corresponding process to process the request after the three-way handshake is successful, but will not send the request to the specific process for processing until the user has actually sent the packet

Bind: binds the current port / address pair, such as 127.0.0.1 8000, which will only take effect if multiple addresses are listening on a port at the same time.

Ssl: the connection established on the currently listening port must be based on the SSL protocol

2.2 Host name syntax: server_name name [...]; default: server_name ""; configuration block: server

Server_name can be followed by multiple host names. When processing a HTTP request, it will match the host name of the Host header in the request with the host name in the server block. If it encounters a host name match in multiple server blocks, it will match it according to the following rules:

If no hostname is found that can match, the server block is looked for according to the following rule:

Give priority to the server block with [default | default_server] added to the listen entry

Find the first server block of the matching listen port

First match the server block with exactly the hostname match

Then match server blocks with wildcard prefixes

Then match the server block with the suffix using wildcards

Finally, match the server blocks that use regular expressions;,

2.3 server_names_hash_bucket_size syntax: server_names_hash_bucket_size size; default: server_names_hash_bucket_size 32 | 64 | 128; configuration blocks: http, server, location

The role of server_names_hash_bucket_size is primarily for hash matching of server name, and when doing hash matching, this parameter specifies the amount of memory consumed by each bucket of the hash table.

2.4 server_names_hash_max_size syntax: server_names_hash_max_size size; default: server_names_hash_max_size 512; configuration blocks: http, server, location

Server_names_hash_max_size specifies the size of the hash table used for server name lookups, and the higher the value, the more memory is consumed, but the more efficient the query is.

2.5 processing syntax for redirecting host names: server_name_in_redirect on | off; default: server_name_in_redirect on; configuration block: http, server or location

This configuration needs to be used with server_name. When it is opened with on, the first hostname configured in server_name will be used to replace the Host header in the original request, while when off is closed, the Host header of the request itself will be used when redirecting the request.

2.6 location syntax: location [= | ~ | ~ * | ^ ~ | @] / uri/ {...} configuration block: server

The main role of location is to match the URI in the request, and if so, the configuration in the location block is used to process the user's request. The following are the matching rules for location:

= indicates that the URI is taken as a string so that the uri in the parameters can be matched exactly. For example:

Location = / {# the configuration under this location will be used only if the user's request is /

~ indicates that letters are case sensitive when matching URI

~ * indicates that it is case-insensitive when matching URI

^ ~ means that only the first half of the URI needs to match the uri parameter. For example:

Location ^ ~ / images/ {# all requests starting with / images/ will match.

@ indicates that it is only used for redirection between requests within the nginx service. Location with @ does not directly handle user requests.

You can use regular expressions in the uir parameter. Such as:

Location ~ *\. (gif | jpg | jpeg) ${# matches requests ending with .gif, .jpg, .jpeg}

One thing to note about location matching is that location matching is sequential, and when a request matches multiple location, the request is actually processed by the first location.

3. Definition of file path 3.1 set resource path syntax in root: root path; default: root html; configuration block: http, server, locationo, if

Examples are as follows:

Location / download/ {root / opt/web/html/;}

This configuration maps requests started by / download/ to the / opt/web/html/ directory. For example, if a request is / download/test/index.html, nginx will look for the / opt/web/html/download/test/index.html file on the server.

3.2 set resource file syntax in alias mode: alias path; configuration block: location

Like root, alias also configures the resource file path, but alias is the specified part of the destination path that is replaced by the path after location with an alias, such as the following configuration:

Location / conf {alias / usr/local/nginx/conf;}

At this point, if a request is / conf/index.html, its prefix / conf will match the current location, and the alias parameter will replace the matching part of the request uri, that is, the converted uri will be / usr/local/nginx/conf/index.html.

Syntax: index file...; default: index index.html; configuration block: http, server, location

The main function of this configuration block is to map an address accessed by the user to the home page. During the home page lookup, the file after the index parameter is queried sequentially, if it exists, it is returned, and if it does not exist, it continues to look for the next one. For example, the following example:

Location / {root path; index / index.html / html/index.php / index.php}

When a user's / request is received, it first queries whether the / path/index.html file exists, if not, whether the next / path/html/index.php exists, if so, returns directly, and so on.

3.4 redirect page syntax based on http return code: error_page code [code...] [= | = answer-code] uri | @ named_location configuration block: http, server, location, if

The main purpose of this configuration is to redirect it to a subsequent error page if the current request returns the specified status code. Such as:

Error_page 404 / 404.htmlerror_page 502 503 504 / 50x.htmlerror_page 403 http://example.com/forbidden.htmlerror_page 404 = @ fetch

It should be noted that even if URI is redirected, the returned HTTP status code is still the original status code. If you need to modify the status code, you can use = to modify the original status code, such as:

Error_page 404 / empty.gif;error_page 404 = 403 / forbidden.gif

Instead of specifying the modified status code, the returned status code is determined by the redirected request:

Error_page 404 = / empty.gif

After redirection, instead of modifying the URI, you can redirect the request to another location for processing, such as:

Location / {error_page 404 @ fallback;} location @ fallback {proxy_pass http://backend;}

3.5 whether recursive error_page syntax is supported: recursive_error_pages [on | off]; default: recursive_error_pages off; configuration block: http, server, location

This configuration is mainly used to control whether recursive definition error_page is supported.

3.6 try_files syntax: try_files path2 [path3] uri; configuration block: server, location

The main function of this parameter is that after the user request arrives, it will try each path path specified later, and if it matches, the value of that path will be returned directly. If none of them match, then the last uri is used as the default processing path. For example:

Try_files / system/maintenance.html $uri $uri/index.html $uri.html @ otherlocation @ other {proxy_pass http://backend;}

4. Allocation of memory and disk resources 4.1 http packets are only stored in disk files syntax: client_body_in_file_only on | clean | off; default: client_body_in_file_only off; configuration blocks: http, server, location

When the value is configured as non-off, all the http packets requested by the user are stored in the disk file, even if there are only 0 bytes. When the request ends, if configured as on, the file will not be deleted, and if configured as clean, the file will be deleted.

4.2 http packet body is written into a memory buffer as far as possible syntax: client_body_in_single_buffer on | off; default: client_body_in_single_buffer off; configuration block: http, server, location

All the http packets requested by users are stored in the memory buffer. If the stored packet size exceeds the size specified by client_body_buffer_size, the request will still be stored in the disk file.

4.3. memory buffer size syntax for storing http headers: client_header_buffer_size size; default: client_header_buffer_size 1k; configuration blocks: http, server

This parameter specifies the size size of the http header requested by the user. If the request header size exceeds this value, the request will be handed over to the buffer defined by the large_client_header_buffers parameter.

4.4 memory buffer size syntax for storing super-large http headers: large_client_header_buffers number size; default: large_client_header_buffers 48k; configuration blocks: http, server

This parameter is mainly used when the request header information of the user exceeds the size that the client_header_buffer_size can store. This parameter defines the size of the data that can be transmitted by each header and the maximum number of header that can be transmitted. If the size of a single header exceeds the limit, a 414 (Request URI too large) status code is returned, and if the number of header exceeds the limit, a 400 (Bad Request) status code is returned.

4.5. size syntax of memory buffer for storing http packets: client_body_buffer_size size; default: client_body_buffer_size 8kUnip 16k; configuration blocks: http, server, location

This parameter specifies the size of the packet body buffer in which the nginx receives the user's http request, and if this size is exceeded, that request packet will be stored in the disk file.

It should be noted that if the header requested by the user contains Content-Length and the length of its identity is less than the length specified in the above parameters, then the size of the buffer used in this request will be automatically reduced.

4.6 temporary storage directory syntax for http package: client_body_temp_path dir-path [level 1 [level 2 [level 3] default: client_body_temp_path client_body_temp; configuration block: http, server, location

The main function of this parameter is to specify the disk directory where the http package is stored. The following level indicates that there can be several levels of subdirectories, because if there are more requests, more files will be generated, and frequent access to the same directory may degrade performance, so you can set multi-level subdirectories for file storage.

It should be noted that the above level parameter indicates the number of characters in the target file name occupied by the generated directory name, for example, the generated target file name is 00000123456, and the above parameters are configured as follows:

Client_body_temp_path / opt/nginx/client_temp 1 2

Then nginx will intercept the last character of the target file name as the primary directory, and the penultimate and third total two characters as the secondary directory, and the final file will be stored in the following directory:

/ opt/nginx/client_temp/6/45/00000123456

When nginx generates the target file, its file name is named by a sequentially incremented integer.

4.7 connection_pool_size syntax: connection_pool_size size; default: connection_pool_size 256; configuration blocks: http, server

This parameter specifies the memory pool size pre-allocated by nginx for each successfully established TCP connection, and size specifies the pre-allocated memory pool size.

This parameter needs to be configured carefully, because a larger configuration will consume more memory of the server, while a smaller configuration will cause the server to allocate more memory in order to expand capacity.

4.8request_pool_size syntax: request_pool_size size; default: request_pool_size 4k; configuration block: http, server

When nginx receives each http request, it requests a memory pool for it. This parameter specifies the size of the memory pool. It should be noted that the memory pool is essentially applied from the connection_pool_size memory pool described above.

At the end of each http request, it destroys the requested memory pool and returns it to the connection_pool_size memory pool, while the entire connected memory pool is destroyed only when the TCP connection is closed.

5. Settings for network connections 5.1 timeout syntax for reading http headers: client_header_timeout time (default unit: seconds); default: client_header_timeout 60; configuration blocks: http, server, location

After the client establishes a connection with the server, nginx will read the http header sent by the client. If the byte sent by the client has not been read beyond the time specified by this parameter, it will be considered to have timed out, and the 408 (Request timed out) status code will be returned to the client.

5.2.timeout syntax for reading http packets: client_body_timeout time (default unit: seconds); default: client_body_timeout 60; configuration blocks: http, server, location

The main purpose of this parameter is to specify the timeout for nginx to read the request packet.

5.3 timeout syntax for sending responses: send_timeout time; default: send_timeout 60; configuration blocks: http, server, location

This parameter mainly specifies the timeout for nginx to send a response to the client, and if the client has not tried to receive data, then nginx will close the connection.

Reset_timeout_connection Syntax: reset_timeout_connection on | off; default: reset_timeout_connection off; configuration block: http, server, location

If this parameter is enabled, after the connection timeout, nginx will send RST packets to the client to reset the connection directly, and will release all cached data about the connection on the server (such as TCP sliding window, etc.). Compared with the normal shutdown mode, it enables the server to avoid making many TCP connections in FIN_WAIT_1, FIN_WAIT_2, and TIME_WAIT states.

It is important to note that closing a connection using the RST reset package causes some problems and is not opened by default.

5.5 lingering_close Syntax: lingering_close off | on | always; default: lingering_close on; configuration block: http, server, location

This configuration block controls how nginx closes user connections. Always indicates that data sent by all users on the connection must be processed unconditionally before closing the connection. Off means that when you close a connection, it doesn't matter whether there is user-ready data on the connection. On is the intermediate value. Usually, the data sent by the user on the connection is processed before closing the connection, unless the data is discarded at some point when the business decides that the data is not needed.

Lingering_time syntax: lingering_time time; defaults to lingering_time 30s; configuration blocks: http, server, location

After lingering_close is enabled, this configuration item is mainly used for the transfer of large files. For example, when the data transferred by a request exceeds max_client_body_size, nginx will send 413 (Request entity too large) status code to the client, but some clients may ignore the status code and continue to send data to the server. In this case, nginx will directly close the connection after the timeout of this parameter.

Lingering_timeout syntax: lingering_timeout time; default: lingering_timeout 5s; configuration blocks: http, server, location

After lingering_close is enabled, nginx detects whether there is any outstanding data on the user connection before closing the connection, and closes the link if no corresponding data arrives after the time specified by this parameter.

5.8 disable the keepalive function syntax for some browsers: keepalive_disable [msie6 | safari | none]. Default: keepalive_disablemsie6 safari configuration block: http, server, location

This parameter mainly specifies which browsers to disable the keepalive feature, and keepalive establishes a long connection between the client and the server, which is very useful for sending multiple http requests, but for IE6 and previous versions, and Safari browsers have functional problems when handling POST requests, so these browsers are disabled by default.

5.9 keepalive timeout syntax: keepalive_timeout time (default unit: seconds); default: keepalive_timeout 75; configuration block: http, server, location

This parameter mainly closes a keepalive connection when it does not receive a new request within a specified period of time.

5.10 maximum number of requests that can be carried on keepalive persistent connections syntax: keepalive_requests n; default: keepalive_requests 100; configuration blocks: http, server, location

This parameter specifies the maximum number of connections that can be carried on a keepalive persistent connection, which defaults to 100.

5.11 tcp_nodelay Syntax: tcp_nodelay on | off; default: tcp_nodelay on; configuration block: http, server, location

Determine whether to use the TCP_NODELAY option for keepalive connections

5.12 tcp_nopush Syntax: tcp_nopush on | off; default: tcp_nopush off; configuration block: http, server, location

When the sendfile option is turned on, determine whether to turn on TCP_NOPUSH on the FreeBSD system or TCP_CORK on the Linux system. When tcp_nopush is opened, the entire response header will be sent in a TCP packet when the response is sent.

6. MIME type setting 6.1 MIME type and file extension mapping syntax: type {...}; configuration blocks: http, server, location

This configuration item defines the mapping of MIME type to file extension. Multiple extensions can be mapped to the same MIME type. For example:

Types {text/html html; text/html conf; image/gif gif; image/jpeg jpg;}

6.2 default MIME type syntax: default_type MIME-type; default: default_type text/plain; configuration block: http, server, location

When the corresponding mapping between MIME type and file extension cannot be found, the default MIME type is used as the Content-Type of http header.

6.3 types_hash_bucket_size syntax: types_hash_max_size size; default: types_hash_max_size 1024; configuration blocks: http, server, location

Nginx uses a hash table to hold the mapping between MIME type and the file extension, which specifies the size of the hash bucket.

6.4 types_hash_max_size syntax: types_hash_max_size size; default: types_hash_max_size 1024; configuration block: http, server, location

This parameter specifies the maximum size of the hash storing MIME type and file extension. The higher the value, the more sparse the hash key and the faster the retrieval, but it takes up more memory; the smaller the value, the smaller the memory, but the collision rate increases and the retrieval is slower.

7. Restrictions on client requests 7.1 restrict user request syntax by http method name: limit_except method... {...} configuration block: location

The main purpose of this configuration item is to restrict access to requests for certain methods, and the following parameters can be GET, HEAD, POST, DELETE, MKCOL, COPY, MOVE, OPTIONS, PROPFIND, PROPPATCH, LOCK, UNLOCK, or PATCH. For example:

Limit_except GET {allow 192.168.1.0 Universe 32; deny all;}

The above configuration will restrict access to all GET requests and allow requests from other methods.

Maximum syntax for http request packet body: client_max_body_size size; default: client_max_body_size 1m; configuration block: http, server, location

This parameter specifies the size of the maximum packet of the http request. Nginx will determine whether it matches the current parameter according to the length represented by the Content-Length in the request header. If not, it will directly return the 413 (Request too large) status code to the client.

Speed limit syntax for request: limit_rate speed; default: limit_rate 0; configuration block: http, server, location, if

This configuration mainly limits the speed of the bytes requested by the client per second. The default is 0, which means there is no speed limit.

You can use the $limit_rate parameter to implement different speed limit policies for different clients. Such as:

Server {if ($slow) {set $limit_rate 4k;}}

7.4 limit_rate_after syntax: limit_rate_after time; default: limit_rate_after 1m; configuration block: http, server, location, if

This parameter indicates that the speed limit does not begin until the response size sent by nginx to the client exceeds the value specified by limit_rate_after.

8. Sendfile system call syntax: sendfile on | off; default: sendfile off; configuration block: http, server, location

This parameter is used to open the sendfile system call on Linux. When sending data to the network card, it reduces two data copying processes between the user mode and the kernel state, and directly sends the data to the network card after the data is read on the disk, thus improving the efficiency of data transmission.

8.2 AIO system call syntax: aio on | off; default: aio off; configuration block: http, server, location

This parameter specifies whether or not to start the kernel-level asynchronous file Iploo function on FreeBSD or Linux systems, and it should be noted that it is mutually exclusive with the sendfile function.

8.3 directio Syntax: directio size | off; default: directio off; configuration block: http, server, location

This configuration item uses the O_DIRECT option to read files on FreeBSD and Linux systems, and the buffer size is size, which usually optimizes the read speed of large files. Note that it is mutually exclusive with the sendfile instruction.

8.4 directio_alignment syntax: directio_alignment size; default: directio_alignment 512; configuration blocks: http, server, location

It is used in conjunction with directio to specify how files are read in directio. In general, 512B is sufficient, but for some high-performance file systems, such as the XFS file system under Linux, you may need to set 4KB as the alignment.

8.5 Open file cache syntax: open_file_cache max=N [inactive=time] | off; default: open_file_cache off; configuration block: http, server, location

The file cache stores the following three types of information in memory:

File handle, file size, and last modified time

Directory structure that has been opened

File information that is not found or does not have permission to operate

The three parameters of the above configuration item have the following meanings:

Max: represents the maximum number of elements stored in memory. When the maximum number is reached, the LRU algorithm will be used to eliminate the least recently used elements from the cache

Inactive: indicates that elements that have not been accessed within the time period specified by inactive will be eliminated. The default time is 60 seconds

Off: turn off caching.

Examples are as follows:

Open_file_cache max=1000 inactive=20s

Syntax: open_file_cache_errors on | off; default: open_file_cache_errors off; configuration block: http, server, location

This configuration item indicates whether information such as file cannot be found or permission error is cached when the file is opened.

Syntax: open_file_cache_min_uses number; default: open_file_cache_min_uses 1; configuration blocks: http, server, location

This parameter is used with open_file_cache, and if the number of times the file is accessed within a specified time is less than the number of times specified by the parameter, the file will still be eliminated.

8.8 Frequency syntax for verifying the validity of elements in the cache: open_file_cache_valid time; default: open_file_cahce_valid 60s; configuration blocks: http, server, location

This parameter specifies how often each interval checks the validity of the data in the cache. The default is 60 seconds.

9. Special handling of client requests 9.1 ignore illegal http header syntax: ignore_invalid_headers on | off; default: ignore_invalid_headers on; configuration blocks: http, server

If it is set to off, it will respond directly when there is an illegal header in the client request (Bad Request); if it is set to on, this header will be ignored.

9.2 whether the http header allows underlining syntax: underscores_in_headers on | off; default: underscores_in_headers off; configuration block: http, server

This parameter specifies whether underscores can be placed in the http header, which is not allowed by default.

Syntax for processing If-Modified-Since headers: if_modified_since [off | exact | before]; default: if_modified_since exact; configuration block: http, server, location

The If-Modified-Since header is mainly a caching strategy made by the browser for performance considerations. After requesting a file, the browser will cache the file locally and record the cache time. The next request will include the time of the last cache in the If-Modified-Since header. When the server receives the request, it will compare the modification time of the server file with the time in the request. If the file has been modified since then, the server will return the file content and 200status code normally. If the file has not been modified, the cached file in the browser is up-to-date, and the Not Modified status code will be returned.

There are three options for this configuration parameter, which mean as follows:

Off: ignores the If-Modified-Since header in the user's request and returns the file content on each request. The response status code is 200.

Exact: accurately compare the time contained in the If-Modified-Since header with the last modification time of the file to be returned. If there is no match, 200 and the actual contents of the file are returned. If there is a match, the file content is up-to-date, and the Not Modified status code is returned. After receiving it, the browser will directly read the local cache.

Before: this is a more relaxed policy than exact. As long as the last modification time of the file is before the time specified in the If-Modified-Since header requested by the user, the Not Modified status code will be returned to the client.

Whether to return error log syntax if the file is not found: log_not_found on | off; default: log_not_found on; configuration block: http, server, location

The main purpose of this configuration is whether to record this information in the error log when a user requests a file if the file does not exist, which is mainly used to locate the problem.

9.5 merge_slashes Syntax: merge_slashes on | off; default: merge_slashes on; configuration block: http, server, location

This configuration item indicates whether to merge adjacent /, such as / / test///a.txt, which will be matched to location/test/a.txt; when configured as on. If configured as off, it will not match, and URI will still be / / test///a.txt.

9.6 DNS resolution address syntax: resolver address...; configuration block: http, server, location

Set the address of the DNS name resolution server, such as:

Resolver 127.0.0.1 192.0.2.1

9.7 timeout syntax for DNS parsing: resolver_timeout time; default: resolver_timeout 30s; configuration blocks: http, server, location

The secondary configuration item represents the timeout for DNS parsing

9.8 whether to indicate the syntax of nginx version in server when returning error page: server_tokens on | off; default: server_tokens on; configuration block: http, server, location

Indicates whether the specific nginx version is returned in the Server header when the error page is returned, mainly for the convenience of locating the problem.

Thank you for your reading, the above is the content of "basic property configuration of Nginx". After the study of this article, I believe you have a deeper understanding of the basic attribute configuration of Nginx, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.