Nginx的配置中，至少需要加载几个核心模块和一个事件模块。这些模块运行所支持的配置项被称为基本配置---其他模块执行时的依赖配置项。
本文主要记录基本配置项的用法，这里主要分四类来进行记录：
1.用于调试、定位问题的
2.正常运行的
3.优化性能的
4.事件类
在Nginx中有一些配置项，不需要显式配置，它们具有一个默认的值，比如daemon、pid。
1）是否以守护进程方式运行Nginx
语法：daemon on|off;
默认：deamon on;
注：守护进程是脱离终端并在后台运行的进程，它不会输出信息在任何终端上。
2）是否以master/worker方式工作
语法：master_process on|off;
默认：master_process on;
3）error日志设置
语法：error_log pathfile level;
默认：error_log logs/error.log error;
注：error日志是定位Nginx问题的最佳日志，我们可以根据自己的需要修改日志的路径与等级。pathfile是一个具体文件，如果需要关闭nginx的日志输出的话，可以将pathfile改成/dev/null，熟悉linux应该都知道，这就是一个黑洞。level是日志的输出级别，可选项有debug、info、notice、warn、error、crit、alert、emerg，从左到右级别依次增大，nginx不会打印级别低于配置项的日志。
4）是否处理几个特殊的调试点
语法：debug_points stop|abort;
注：该配置项是用于跟踪调试Nginx的，Nginx在一些关键的错误逻辑中加入了调试点。如果配置debug_point为stop的话，Nginx运行到调试点时将会发出SIGSTOP信号用于调试。如果debug_point为abort的话，将会产生一个coredump文件，可以使用gdb来查看当时的信息。一般情况下都不会使用到这个配置项。
5）仅对指定客户端输出debug日志
语法：debug_connection IP|CIDR
events { debug_connection 10.224.66.14;
debug_connection 10.224.57.0/24;
}
注：该配置其实是一个事件类的配置，它必须在events块配置中才有效，值可以是IP地址或者CIDR地址。这样的话，只有来自于配置项的请求才会打印debug日志，其他请求还是按照error_log的配置输出。
6）限制coredump核心转载文件大小
语法：worker_rlimit_core size;
在linux系统中，当进程异常中断时，系统将会把进程执行时的内存内容写入到一个core文件，用于调试，这就是所谓的核心转载（core dumps）。当Nginx进程出现异常被强制结束时，就会生成想要的core文件，可以从core文件中获取当时的堆栈和寄存器等信息，来保证我们定位问题。但是这个core中有大量的信息不一定是我们想要的，而且不加限制的话，可能一个core文件就会达到数G的大小，会造成空间占用。通过这个配置可以限制Nginx服务的core文件大小。
7）指定coredump文件生成目录
语法：working_directory path;
work进程的工作目录，这个配置的唯一用处就是设置coredump文件的目录。
1）定义环境变量
语法：env VAR|VAR=VALUE;
该配置可以让用户直接设置操作系统的环境变量。如：
env TESTPATH=/tmp/;
2)导入其它配置文件
语法：include pathfile;
include可以将其它配置文件导入到当前的nginx.conf文件中，它的参数可以是相当路径或者绝对路径，也可以是含通配符的文件名。
include mime.type;
include vhost/*.conf
3)pid文件的路径
语法：pid path/file;
默认：pid logs/nginx.pid;
保持master进程id的pid文件所在的路径，默认是configure执行时指定的--pid-path路径，可以随时修改，但是需要确保Nginx服务有权在指定的路径下创建文件。
4）Nginx worker进程运行的用户与用户组
语法：user username[groupname];
默认： user nobody nobody;
user设置worker进程运行在哪个用户和用户组下，当只有一个配置值时，用户组名与用户名一致。如果用户在configure执行时使用--user=username和--group=groupname时，Nginx将会使用参数中指定的用户与用户名。
5）最大句柄描述符数
语法：worker_rlimit_nofile limit;
设置一个worker进程可以打开的最大文件句柄数。
6）限制信号队列
语法：worker_rlimit_sigpending limit;
设置每一个用户发给Nginx的信号队列大小，当用户发送的信号量沾满了信号队列，后续的信号Nginx将会直接丢掉。
1）worker进程个数
语法：worker_processes number;
默认：worker_processes 1;
设置在worker运行方式下，worker进程的个数，这里在前文中有详细介绍。
2）worker进程绑定CPU
语法：worker_cpu_affinity cpumask[cpumask...]
例：
worker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;
将worker进程绑定到指定的CPU上，可以实现内核调度策略上的并发。
3）SSL硬件加速
语法：ssl_engine device;
如果服务器上有SSL硬件加速设备的话，我们可以使用ssl_engine配置来加快SSL协议的处理速度，下面附上查看是否存在SSL硬件加速设备的方法。
openssl engine -t
4) gettimeofday执行频率
语法：timer_resolution t;
默认情况下，每一次内核时间调用返回时，都会执行一次gettimeofday，它是使用内核的时间来更新Nginx的缓存中的时间。在以前的linux内核中，需要进行内核态到用户态的内存复制，大于系统的消耗不小，但是现在的内核中只需要访问共享内存页，代价不大，可以不进行配置。
5）worker进程优先级
语法：worker_priority nice;
默认：worker_priority 0;
该配置用户设置worker进程的nice优先级，在linux系统中，当很多进程都处于可执行的姿态时，系统将会按照进程的优先级来决定本次内核选择先运行哪一个进程。同时，如果进程的优先级更高的话，可以分配到的时间片越大。nice值是进程的静态优先级，可取值-20-+19，数值越低优先级越高。如果想要Ngin占用更加多的系统资源的话，可以调小nice值，但是不建议小于-5，因为-5是系统内核进程的nice值。
1）是否打开accept锁
语法：accept_mutex [on|off]
默认：accept_mutex on;
accept_mutex是Nginx的负载均衡锁，该锁可以使多个worker进程轮流的、序列化的与客户端建立TCP连接。如果某一个worker进程的连接数达到了worker_connections配置值的7/8时，它会减少与客户端的TCP连接，尽量使得worker进程的请求数相近。
accept默认打开，关闭的话，会减少TCP连接的时间，但是会造成worker进程之间的负载很不均衡。
2）lock文件路径
语法：locak_file path/file;
默认：lock_file logs/nginx.lock;
当accept锁关闭时，lock_file配置完成不生效。只有在打开了accept锁，并且由于一些原因（编译程序或者操作系统等因素）导致Nginx不支持原子锁的时候，才会使用文件锁来实现accept锁。
3）连接建立延迟时间
语法：accept_mutex_delay Nms;
默认：accept_mutex_delay 500ms;
该配置只有在accept锁开启的时候才有效，在开启accept锁的时候，同一时间只有一个worker进程可以拿到锁，该锁不是堵塞锁，拿不到会直接返回。如果一个worker进程没有拿到锁的话，至少需要等配置的延迟时间之后才能再次获取该锁。
4）批量建立连接
语法：multi_accept [on|off];
默认：multi_accept off;
当事件模型通知有新的连接的时候，尽可能的对本次调度中客户端的所有TCP都建立连接。
5）选择事件模型
语法：use [kqueue|rtsig|epoll|/dev/poll|select|poll|eventport];
Nginx会自动去使用最合适的事件模型，linux系统中可以选择poll、select与epoll，其中epoll性能最好。
6）进程最大连接数
语法：worker_connections number;
该配置决定每一个worker进程可以同时处理的最大连接数。