nginx管理基线 nginx安全配置基线

转载

mob64ca14144dde 2024-06-14 16:32:25

文章标签 nginx管理基线 Nginx 配置项 nginx 文章分类 运维

　　Nginx的配置中，至少需要加载几个核心模块和一个事件模块。这些模块运行所支持的配置项被称为基本配置---其他模块执行时的依赖配置项。

本文主要记录基本配置项的用法，这里主要分四类来进行记录：

1.用于调试、定位问题的

2.正常运行的

3.优化性能的

4.事件类

在Nginx中有一些配置项，不需要显式配置，它们具有一个默认的值，比如daemon、pid。

1.用于调试、定位问题的

1）是否以守护进程方式运行Nginx

语法：daemon on|off;

默认：deamon on;

注：守护进程是脱离终端并在后台运行的进程，它不会输出信息在任何终端上。

2）是否以master/worker方式工作

语法：master_process on|off;

默认：master_process on;

注：前文Nginx进程间的关系有详细介绍。

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文件的目录。

2.正常运行的

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将会直接丢掉。

3.性能优化

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值。

4.事件类

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;