Example Configuration
user www www;
worker_processes 2;
error_log /var/log/nginx-error.log info;
events {
use kqueue;
worker_connections 2048;
}
...
Directives
|
syntax:
|
daemon on | off;
|
|
default:
|
daemon on;
|
|
context:
|
main
|
Determines whether nginx should become a daemon.
Mainly used during development.
|
syntax:
|
error_log
file
[debug |
info |
notice |
warn |
error |
crit |
alert |
emerg];
|
|
default:
|
error_log logs/error.log error;
|
|
context:
|
main, http, server, location
|
Configures logging.
The first parameter defines a file that will store the log.
The second parameter determines the level of logging.
Log levels above are listed in the order of increasing severity.
Setting a certain log level will cause all messages of
the specified and more severe log levels to be logged.
For example, the default level error will
cause error, crit,
alert, and emerg messages
to be logged.
For debug logging to work, nginx needs to
be built with --with-debug.
|
syntax:
|
env variable[=value];
|
|
default:
|
env TZ;
|
|
context:
|
main
|
Allows to limit a set of environment variables, change their values,
or create new environment variables, for the following cases:
-
variable inheritance during a
live upgrade
of an executable file;
-
use of variables by the module
ngx_http_perl_module;
-
use of variables by worker processes.
Please bear in mind that controlling system libraries in this way
is not always possible as it is not uncommon for libraries to check
variables only during initialization, well before they can be set
using this directive.
An exception from this is an above mentioned
live upgrade
of an executable file.
The TZ variable is always inherited and made available to the module
ngx_http_perl_module,
unless configured explicitly.
Usage example:
env MALLOC_OPTIONS;
env PERL5LIB=/data/site/modules;
env OPENSSL_ALLOW_PROXY_CERTS=1;
|
syntax:
|
include file | mask;
|
|
default:
|
—
|
|
context:
|
any
|
Includes another file, or files matching the
specified mask, into configuration.
Included files should consist of
syntactically correct directives and blocks.
Usage example:
include mime.types;
include vhosts/*.conf;
|
syntax:
|
master_process on | off;
|
|
default:
|
master_process on;
|
|
context:
|
main
|
Determines whether worker processes are started.
This directive is intended for nginx developers.
|
syntax:
|
pcre_jit on | off;
|
|
default:
|
pcre_jit off;
|
|
context:
|
main
|
This directive appeared in version 1.1.12.
Enables or disables the use of “just-in-time compilation” (PCRE JIT)
for regular expressions known at configuration parse time.
PCRE JIT can speed up processing of regular expressions significantly.
The JIT is available in PCRE libraries starting from version 8.20
built with the --enable-jit configuration parameter.
When building the PCRE library with nginx (--with-pcre=),
the JIT support should be enabled with the
--with-pcre-jit configuration parameter.
|
syntax:
|
pid file;
|
|
default:
|
pid nginx.pid;
|
|
context:
|
main
|
Defines a file that will store the process ID of the main process.
|
syntax:
|
ssl_engine device;
|
|
default:
|
—
|
|
context:
|
main
|
Defines the name of the hardware SSL accelerator.
|
syntax:
|
timer_resolution interval;
|
|
default:
|
—
|
|
context:
|
main
|
Reduces timer resolution in worker processes, thus reducing the
number of gettimeofday() system calls made.
By default, gettimeofday() is called each time
on receiving a kernel event.
With reduced resolution, gettimeofday() is only
called once per specified interval.
Example:
timer_resolution 100ms;
An internal implementation of interval depends on the method used:
-
an
EVFILT_TIMER filter if kqueue is used;
-
timer_create() if eventport is used;
-
setitimer() otherwise.
|
syntax:
|
user user [group];
|
|
default:
|
user nobody nobody;
|
|
context:
|
main
|
Defines user and group
credentials used by worker processes.
If group is omitted, a group whose name equals
that of user is used.
|
syntax:
|
worker_priority number;
|
|
default:
|
worker_priority 0;
|
|
context:
|
main
|
Defines a scheduling priority for worker processes like is
done by the nice command: a negative
number
means higher priority.
Allowed range normally varies from -20 to 20.
Example:
worker_priority -10;
|
syntax:
|
worker_processes number;
|
|
default:
|
worker_processes 1;
|
|
context:
|
main
|
Defines the number of worker processes.
The optimal value depends on many factors including (but not
limited to) the number of CPU cores, the number of hard disk
drives that store data, and load pattern.
When in doubt, setting it to the number of available CPU cores
would be a good start.
|
syntax:
|
worker_rlimit_core size;
|
|
default:
|
—
|
|
context:
|
main
|
Changes the limit on the largest size of a core file
(RLIMIT_CORE) for worker processes.
Used to increase the limit without restarting the main process.
|
syntax:
|
worker_rlimit_nofile number;
|
|
default:
|
—
|
|
context:
|
main
|
Changes the limit on the maximum number of open files
(RLIMIT_NOFILE) for worker processes.
Used to increase the limit without restarting the main process.
|
syntax:
|
working_directory directory;
|
|
default:
|
—
|
|
context:
|
main
|
Defines a current working directory for a worker process.
It is primarily used when writing a core-file, in which case
a worker process should have write permission for the
specified directory.
|