NGINX基本优化

更改nginx服务默认用户
优化nginx进程对应配置
优化绑定不同的nginx进程到不同cpu,
nginx事件处理模型优化,采用epoll模型
调整优化单个worker进程并发连接数
配置nginx worker进程最大打开文件数
优化服务器域名的hash表大小
开启高效文件传输模式sendfile,设置tcp_nopush参数
优化nginx连接参数调整连接超时时间
上传文件大小(http Request body size)的限制
fastcgi相关参数调优,fastcgi buffer/cache
配置nginx gzip压缩实现性能优化
配置nginx expires缓存实现性能优化
访问日志轮询,不记录某些日志,代理不开访问日志
Nginx站点目录及文件URL访问控制
限制网站来源IP访问

 

1、隐藏版本号优化

http://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens
Syntax: server_tokens on | off | string;
Default: server_tokens on;
Context: http, server, location
Enables or disables emitting nginx version in error messages and in the “Server” response header field.

# curl -I 192.168.0.82
HTTP/1.1 200 OK
Server: nginx/1.8.1
Date: Sun, 10 Jul 2016 08:30:40 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Sun, 15 May 2016 23:28:20 GMT
Connection: keep-alive
ETag: "57390614-264"
Accept-Ranges: bytes

# vi /usr/local/nginx/conf/nginx.conf
在http标签内加入参数server_tokens off;
# curl -I 192.168.0.82
HTTP/1.1 200 OK
Server: nginx

 

2、隐藏软件名称

# vi /home/tools/nginx-1.8.1/src/core/nginx.h
13 #define NGINX_VERSION      "1.8.1"              #显示的版本号,修改为想要显示的版本号
14 #define NGINX_VER          "nginx/" NGINX_VERSION    #将nginx修改为想要的软件名称,如GWS
22 #define NGINX_VAR          "NGINX"             #显示的软件名称如如GWS(GTMSWEB SERVER)
23 #define NGX_OLDPID_EXT     ".oldbin"

# vi /home/tools/nginx-1.8.1/src/http/ngx_http_header_filter_module.c
49 static char ngx_http_server_string[] = "Server: nginx" CRLF;    改==> "Server: GTMSWS" CRLF;

# vi /home/tools/nginx-1.8.1/src/http/ngx_http_special_response.c
     21 static u_char ngx_http_error_full_tail[] =
     22 "<hr><center>" NGINX_VER "</center>" CRLF
     23 "</body>" CRLF
     24 "</html>" CRLF
     25 ;
     26 
     27 
     28 static u_char ngx_http_error_tail[] =
     29 "<hr><center>nginx</center>" CRLF   ==》修改为/GTMS WEB SERVER /
     30 "</body>" CRLF
     31 "</html>" CRLF
[root@test83 core]# /usr/local/nginx/sbin/nginx -V  取到编译参数后重新编译安装
nginx version: nginx/1.8.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) 
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx-1.8.1 --user=nginx --group=nginx --with-http_stub_status_module --with-http_ssl_module

3、更改nginx服务的默认用户
编译时未指定user和group,默认nobody
编译时指定,默认即为nginx用户
root@test83 conf]# ps -ef | grep nginx | grep -v grep 
root       1873      1  0 16:45 ?        00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx      1874   1873  0 16:45 ?        00:00:00 nginx: worker process    
默认主进程是root,在高标准环境一般设置为普通用户,防止提权。也能使普通用户对服务进行重启等管理

4、优化nginx进程对应配置(worker进程数)

# vi /usr/local/nginx/conf/nginx.conf
worker_processes  1;    #一般cpu核数,后续继续调整,最高一般为2倍 
查看cpu个数信息   top按1 可以看到核数
# grep processor /proc/cpuinfo | wc -l  或者# grep processor -c /proc/cpuinfo    (查看核数)
1    ==>1颗单核
# grep "physical id" /proc/cpuinfo | sort|uniq|wc -l    (cpu个数)
1

 

5、优化绑定不同的nginx进程到不同cpu,使平均运行(ngx_core_module,实测差不多

默认情况nginx的多个进程有可能跑在某一个或某一核的CPU上,导致nginx进程使用的硬件的资源不均,
本节优化是尽可能地分配不同的nginx进程给不同的CPU处理,达到充分有效利用硬件的多CPU多核资源的目的优化nginx进程对应不同的CPU配置 在优化不同的nginx进程对应不同CPU配置时,四核CPU服务器的参考配置参考如下 worker_processes
4; worker_cpu_affinity 0001 0010 0100 10000; #worker_cpu_affinity就是配置nginx进程CPU亲和力的参数,即把不同的进程分配给不同的CPU处理,0001等掩码,分别代表CPU核心,由于worker_processes进程为4,因此,上述配置会把每个进程分配一核CPU处理,默认不会绑定,参数配置为main段 # man taskset 分配cpu功能 NAME taskset - retrieve or set a process?[7m<80><99>s CPU affinity SYNOPSIS taskset [options] mask command [arg]... taskset [options] -p [mask] pid 举例 task -c 1,2,3 /etc/init.d/mysql start (多实例可以指定)

 

6nginx事件处理模型优化

nginx的连接处理机制在于不同的操作系统会采用不同的I/O模型,在Linux下,nginx使用epoll的I/O多路复用模型,
在freebsd中使用kqueue的I/O多路复用模型,在solaris中使用/dev/poll方式的I/O多路复用模型,在windows使用的是icop,等等. 要根据系统类型选择不同的事件处理模型,可供使用的选择有use [kqueue|rtsig|epoll|dev/poll/select|poll];
本次用的是centos6.6,因此我们将nginx的事件处理模型调整为epoll模型 events { 加到main区块event标签,一般nginx已经自动用epoll模式 worker_connections 1024; use epoll; }

7、调整优化单个worker进程并发连接数及worker进程最大打开文件数

worker_connections是个时间模块指令,用于定义nginx每个进程的最大并发连接数,默认1024,最大客户端连接数等于worker_processes* worker_connections。
进程的最大连接数也受linux系统进程的最大打开文件数限制,在执行“ulimit -HSn 65535”或配置相应文件后,此设置才生效 events { worker_connections 1024; } 说明:这个连接数包括了所有连接(一个用户请求是两个链接)例如:代理服务器的连接、客户端的连接等,
实际的并发连接数受此参数控制外,还和最大打开文件数worker_rlimit_nofile有关 配置nginx进程最大打开文件数 worker_rlimit_nofile
65535; ==>可设置为系统优化后的ulimit -HSn的结果 Syntax: worker_rlimit_nofile number; Default: —

8、优化服务器域名的hash表大小

确切名字和通配符名字存储在哈希表中。哈希表和监听端口关联,每个端口都最多关联三张表:确切的名字的哈希表,以星号(*)起始的通配符名字的哈希表和以星号结束的通配符名字的哈希表。
哈希表的尺寸在配置阶段进行了优化,可以以最小的CPU缓存命中失败来找到名字。nginx首先搜索切确名字的的哈希表,如果没有找到,则搜索以星号(*)其实的通配符名字的哈希表,如果还是没有找到,继续搜索以星号结束的通配符名字的哈希表。
因为名字是按照域名的节点来搜索的。所以搜索通配符名字的哈希表比搜索确切名字的哈希表慢。注意:nginx.org存储在通配符名字的哈希表中,而不在确切名字的哈希表中。正则表达式是一个一个串行的测试,所以是最慢的,而且不可扩展。
由于上述原因,我们一般尽可能的使用确切的名字。比如如果使用nginx.org和www.nignx.org来访问服务器是最频繁的,那么我们明确的定义出来对访问搜索域名的速度效率来说更有效:
如果定义了大量名字,或者定义了非常长的名字,那就需要在php配置模块中调整server_names_hash_max_size 默认512kb,一般是cpu L1的4
-5倍,
存放server name的最大哈希表大小server_names_hash_bucket_size Sets the bucket size for the server names hash tables. server_names_hash_bucket_size的默认值可能是32,或者是64,或者是其他值,取决于CPU的缓存行的长度。如果这个值是32,那么定义“too.long.server.name.nginx.org”作为虚拟机主机名就会失败,显示如下错误信息: could not build the server_names_hash, you should increase server_names_hash_bucket_size;32 出现这种情况,那就需要设置值扩大一倍: http{ server_names_hash_bucket_size 64; }

9 、开启高效文件传输模式sendfile

sendfile参数用于开启文件的高效传输模式。同时将tcp_nopush和tcp_nodely两个指令设置为on,可防止网络及磁盘IO阻塞,提升nginx工作效率
http://nginx.org/en/docs/http/ngx_http_core_module.html#sendfile
Syntax: sendfile on | off;
Default: sendfile off;
Context: http, server, location, if in location
参数作用:激活或者禁用sendfile()功能。sendfile()作用是用于两个文件描述符之间的数据拷贝函数,这个拷贝函数在内核中的,被称为“零拷贝”,
sendfile()比read和write函数要高效很多,因为read和write函数要把数据拷贝到应用层进行操作。相关控制参数还有sendfile_max_chunk
设置tcp_nopush参数 tcp_nopush on http:
//nginx.org/en/docs/http/ngx_http_core_module.html#tcp_nopush Syntax: tcp_nopush on | off; Default: tcp_nopush off; Context: http, server, location 参数作用:激活或者禁用linux上的TCP_CORK scoket选项,此选项仅仅当开启sendfile才生效,
激活tcp_nopush参数可以允许把http response header和文件的开始放在一个文件里发布,积极的作用是减少网络报文的数量

10、优化nginx连接参数调整连接超时时间

先来个比喻,饭店请了服务员招待顾客,但是饭店不景气,此时为了节约开支,需要解雇服务员
这里的服务员就相当于nginx服务器建立的连接,当服务器建立的连接没有接收处理请求时,在指定时间内就让它超时自动退出,
还有当nginx和fastcgi服务建立连接请求PHP时,因为有些原因(负载高,停止响应)fastcgi服务无法给nginx返回数据,
此时可以通过配置nginx服务参数,使其不会等死,因为前面用户还等着它返回数据。例如,可设置为如果请求fastcgi,10秒内不能返回数据,
那么nginx就中断本次请求,向用户汇报取不到数据的错误
连接超时的作用:简单来说是一种自我管理,自我保护的重要机制
1、设置将无用的连接尽快超时,可以保护服务器的系统资源(cpu、内存、磁盘) 2、当连接很多时。及时断掉那些已经建立好的但是长时间不做事的连接,减少其占用服务器资源,因为服务器维护连接也是消耗资源的 3、有时黑客或恶意用户攻击网站,就会不断地和服务器建立多个连接,消耗连接数,但是啥也不干,只是持续建立连接,就会大量消耗服务器资源,此时就应该及时断掉这些恶意占用资源的连接 4、lnmp环境中,如果用户请求了动态服务,则nginx就会建立连接请求fastcgi服务以及mysql服务,此时这个nginx连接就要设定一个超时时间,
  在用户容忍的时间内返回数据,或者再多等一会后端服务返回数据,具体策略按具体业务分析,当然,后端的fastcgi服务以及mysql服务也有对连接超时的控制
连接超时带来的问题
1、服务器建立新连接也是要消耗资源的,因此,超时设置的太短,就会导致服务器瞬间无法响应用户的请求,导致体验下降 2、企业生产有些PHP程序站点希望设置短连接,因为PHP程序建立连接消耗的资源和时间要少。
  而JAVA程序站点一般建立设置长连接,因为java程序建立的连接消耗的资源和时间更多,这是语言运行的机制决定的 nginx连接超时的参数设置
1、keepalive_timeout 60; 设置客户端连接保持会话的超时时间为60秒,超过后,服务器会关闭该连接,此数值为参考值 http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests Syntax: keepalive_timeout timeout [header_timeout]; Default: keepalive_timeout 75s; Context: http, server, location

2、tcp_nodelay on; 激活tcp_nodelay功能,提高IO性能 http://nginx.org/en/docs/http/ngx_http_core_module.html#tcp_nodelay Syntax: tcp_nodelay on | off; Default: tcp_nodelay on; Context: http, server, location 参数作用:默认情况下数据发送时,内核并不会马上发送,可能会等待更多的字节组成一个数据包,这样可以提高IO性能,但是,在每次发送很少字节的业务场景,
使用此功能,等待时间会比较长 生效条件:激活或禁用tcp_nodelay选项,当一个连接进入到keep_alive状态时生效

3、client_header_timeout 15s; 设置读取客户端请求头部数据的超时时间。如果超过这个时间客户端还没发送完整的header数据,服务端将返回“Request time out (408)”错误。经验参考值15秒,指定一个超时时间防止客户端利用http协议进行攻击 http://nginx.org/en/docs/http/ngx_http_core_module.html#client_header_timeout Syntax: client_header_timeout time; Default: client_header_timeout 60s; Context: http, server

4、client_body_timeout 15s; 设置读取客户端请求主体的超时时间,默认60 http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_timeout Syntax: client_body_timeout time; Default: client_body_timeout 60s; Context: http, server, location 参数作用:读取客户端请求主题的超时时间,这个超时仅仅为两次成功的读取操作之间的一个超时,非请求整个主题数据的时间,如在这个超时时间内,客户端没有发送任何数据,nginx将返回“Request time out (408)”错误

5、send_timeout 25s; http://nginx.org/en/docs/http/ngx_http_core_module.html#send_timeout Syntax: send_timeout time; Default: send_timeout 60s; Context: http, server, location 参数作用:设置服务器端传送http响应信息到客户端的超时时间,这个超时时间仅仅为两次成功握手后的一个超时,非请求整个数据的超时时间,在这个超时时间内,客户端没有接受任何数据,连接将被关闭


client_max_body_size

 

 

11、nginx fastcgi相关参数调优(配合PHP引擎动态服务)

fastcgi_connect_timeout
Syntax: fastcgi_connect_timeout time;
Default: fastcgi_connect_timeout 60s;
Context: http, server, location
Defines a timeout for establishing a connection with a FastCGI server. It should be noted that this timeout cannot usually exceed 75 seconds.
表示nginx服务器和后端fastcgi服务器服务器连接的超时时间默认60s,这个参数值通常不要超过75s,因为建立的连接越多消耗的资源就越多

fastcgi_send_timeout
Syntax: fastcgi_send_timeout time;
Default: fastcgi_send_timeout 60s;
Context: http, server, location
Sets a timeout for transmitting a request to the FastCGI server. The timeout is set only between two successive write operations, not for the transmission of the whole request.
If the FastCGI server does not receive anything within this time, the connection is closed.
设置nginx允许fastcgi服务器端返回数据的超时时间,即在规定时间之内后端服务器必须传完所有数据,否则,nginx将断开这个连接,默认为60s

fastcgi_read_timeout
Syntax: fastcgi_read_timeout time;
Default: fastcgi_read_timeout 60s;
Context: http, server, location
Defines a timeout for reading a response from the FastCGI server. The timeout is set only between two successive read operations, not for the transmission of the whole response.
If the FastCGI server does not transmit anything within this time, the connection is closed.
设置nginx从fastcgi服务器端读取响应信息的超时时间,表示连接建立成功后,nginx等待后端服务器的响应时间,是nginx已经进入后端的排队之中等待处理的时间

fastcgi_buffer_size
Syntax: fastcgi_buffer_size size;
Default: fastcgi_buffer_size 4k|8k;
Context: http, server, location
Sets the size of the buffer used for reading the first part of the response received from the FastCGI server. This part usually contains a small response header.
By default, the buffer size is equal to one memory page. This is either 4K or 8K, depending on a platform. It can be made smaller, however.
这个是nginx fastcgi的缓冲区大小参数,设定用来读取从fastcgi服务器收到的第一部分响应信息的缓冲区大小,这里的第一部分通常会包含一个小的响应头部,默认情况,这个参数的大小是由fastcgi_buffers指定的一个缓冲区大小。


fastcgi_buffers
Syntax: fastcgi_buffers number size;
Default: fastcgi_buffers 8 4k|8k;
Context: http, server, location
Sets the number and size of the buffers used for reading a response from the FastCGI server, for a single connection.
By default, the buffer size is equal to one memory page. This is either 4K or 8K, depending on a platform.
指定本地需要用多少和多大的缓冲区来缓冲FastCGI的应答请求。如果一个PHP脚本所产生的页面大小为256KB,那么会为其分配4个64KB的缓冲区来缓存;
如果页面大小大于256KB,那么大于256KB的部分会缓存到fastcgi_temp指定的路径中,但是这并不是好方法,因为内存中的数据处理速度要快于硬盘。
一般这个值应该为站点中PHP脚本所产生的页面大小的中间值,如果站点大部分脚本所产生的页面大小为256KB,那么可以把这个值设置为“16 16k”、“4 64k”等。

fastcgi_busy_buffers_size
Syntax: fastcgi_busy_buffers_size size;
Default: fastcgi_busy_buffers_size 8k|16k;
Context: http, server, location
When buffering of responses from the FastCGI server is enabled, limits the total size of buffers that can be busy sending a response to the client while the response is not yet fully read.
In the meantime, the rest of the buffers can be used for reading the response and, if needed, buffering part of the response to a temporary file.
By default, size is limited by the size of two buffers set by the fastcgi_buffer_size and fastcgi_buffers directives.

fastcgi_temp_file_write_size
Syntax: fastcgi_temp_file_write_size size;
Default: fastcgi_temp_file_write_size 8k|16k;
Context: http, server, location
Limits the size of data written to a temporary file at a time, when buffering of responses from the FastCGI server to temporary files is enabled.
By default, size is limited by two buffers set by the fastcgi_buffer_size and fastcgi_buffers directives. The maximum size of a temporary file is set by the fastcgi_max_temp_file_size directive.

fastcgi_temp_path
Syntax: fastcgi_temp_path path [level1 [level2 [level3]]];
Default: fastcgi_temp_path fastcgi_temp;
Context: http, server, location
Defines a directory for storing temporary files with data received from FastCGI servers. Up to three-level subdirectory hierarchy can be used underneath the specified directory.
For example, in the following configuration fastcgi_temp_path /spool/nginx/fastcgi_temp 1 2;
a temporary file might look like this:
/spool/nginx/fastcgi_temp/7/45/00000123457
See also the use_temp_path parameter of the fastcgi_cache_path directive.

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
fastcgi_temp_path /usr/local/nginx/fastcgi_tmp 1 2;

fastcgi_cache(buffer一份给用户,一份写到缓存)
表示开启FastCGI缓存并为其指定一个名称。开启缓存非常有用,可以有效降低CPU的负载,并且防止502错误的发生,但是开启缓存也会引起很多问题,要视具体情况而定。
为FastCGI缓存指定一个文件路径、目录结构等级、关键字区域存储时间和非活动删除时间
Syntax: fastcgi_cache_path path [levels=levels] [use_temp_path=on|off] keys_zone=name:size [inactive=time] [max_size=size]
[manager_files=number] [manager_sleep=time] [manager_threshold=time] [loader_files=number] [loader_sleep=time]
[loader_threshold=time] [purger=on|off] [purger_files=number] [purger_sleep=time] [purger_threshold=time];
Default: —
Context: http


 

 

12、配置nginx gzip压缩实现性能优化

nginx gzip压缩功能介绍
Syntax: gzip on | off;
Default: gzip off;
Context: http, server, location, if in location
nginx gzip压缩模块提供了对文件内容压缩的功能,nginx服务器将用户请求的内容在发送给用户客户端之前会根据一些具体的策略实施压缩,以节约网站出口带宽,同时加快了数据数据传输效率,提升了用户访问体验 nginx gzip压缩的优点
1、提升网站用户体验 由于发给用户的内容小了,所以用户访问单位大小的页面就快了,用户体验提升了,网站口碑就好了。 2、节约网站带宽成本 由于数据是压缩传输的,因此,此举节省了网站的带宽流量成本,不过压缩时会稍微消耗些CPU资源,这个一般可以忽略 此功能既让用户舒服了,公司也少花钱了,一举多得,对于所有web服务器来说,这是个非常重要的功能 需要(大于1k的纯文本)和不需要压缩的对象 1、 纯文本内容压缩比很高,因此纯文本的内容最好要压缩,例如html、js、css、xml、shtml等各式的文件 2、 被压缩的纯文本文件必须大于1kb,由于压缩算法的特殊原因,极小的文件压缩可能反而变大 3、 图片、视频(流媒体)等文件尽量不要压缩,因为这些文件大多都是经过压缩的,如果再压缩很可能不会减小或减小很多,或者有可能增大,而在压缩时还会消耗大量的CPU、内存资源 完整的配置如下 gzip on; gzip_min_length 1k; # 1k以上进行压缩 gzip_buffers 4 32k; # 4个32k的buffer gzip_http_version 1.1; #压缩版本 gzip_comp_level 9; #压缩级别9最大,传输速度最快,但处理最慢,也比较消耗cpu资源。 gzip_types text/css/ test/html text/xml application/javascript; #cat mime.types gzip_vary on; #vary header支持。该选项可以让前端的缓存服务器缓存经过gzip压缩的页面,例如用squid缓存经过nginx压缩的数据

使用firefox 安装yslow firebug检验



 

 

配置nginx expires缓存实现性能优化

nginx expires功能介绍
简单的说,nginx expires功能就是为用户访问的网站内容设定一个过期时间,当用户第一次访问这些内容的时,会把这些内容存储在用户浏览器本地,
这样用户第二次以后继续访问网站,浏览器会检查加载已经缓存在用户浏览器本地的内容,就不会去服务器下载了,直到缓存的内容过期或被清除为止。 深入一点理解,expires功能就是允许通过nginx配置文件控制HTTP的“Expires”和“Cache
-Control”响应头部内容,告诉客户端浏览器是否缓存以及缓存多久访问内容,
这个expire模块控制nginx服务器应答时的Expires头内容和Cache-Control头max-age指令。缓存的有效期可以设置为相对于源文件的最后修改时刻或者客户端的访问时刻。
这些HTTP头向客户端表明了内容的有效性和持久性,如果客户端本地有内容缓存,则内容可以从缓存(除非已经过期)而不是从服务器读取,然后客户端会检查缓存中的副本,看看是否过期或者失效,以决定是否重新从服务器获得内容更新 nginx expires作用介绍 在网站开发和运营中,对于视频、图片、CSS、JS等网站元素的更改机会较少,特别是图片,这时可以将图片设置在客户浏览器本地缓存365天或3650天,而将CSS、JS、html等代码缓存10
-30天,这样用户第一次打开页面后,会在本地的浏览器按照过期日期缓存相应的上述内容,下次用户再打开类似的页面,重复的元素就无需下载了,从而加快了用户访问速度,由于用户访问请求和数据减少了,因此节省了服务期端大量的带宽。此功能同apache的expires。 nginx expires功能优点 1、expires 可以降低网站的带宽,节约成本。 2、加快用户访问网站的速度,提升了用户访问体验。 3、服务器访问量降低了,服务器压力就减轻了,服务器成本也会降低,甚至可以节约人力成本。 对于几乎所有web服务来说,这都是非常重要的功能之一,Apache服务也有此功能 Server { listen 80; root html/www; server_name www.gmts.org; location / { index index.html index.htm;} location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {expires 10y;} location ~ .*\.(js|css)$ {expires 30d;} } location ~ ^/(images|javascript|js|css|flash|media|static)/ { expires 360d } #也可以针对目录 root@test80 ~]# curl -I http://d1.leju.com/ia/2016/10/14/f580042c2895a2img.gif HTTP/1.1 200 OK Date: Sat, 22 Oct 2016 17:28:08 GMT Content-Type: image/gif Content-Length: 15073 Connection: keep-alive Expires: Thu, 12 Jan 2017 02:37:09 GMT 缓存过期时间 Server: Apache Last-Modified: Fri, 14 Oct 2016 02:28:18 GMT Accept-Ranges: bytes Cache-Control: max-age=7776000 缓存的总时间(毫秒) X-Ser: BC18_dx-hebei-shijiazhuang-1-cache-1, BC26_dx-jiangsu-xuzhou-1-cache-3 nginx expire 功能的缺点及解决方法 几乎所有事物都有两面性,没有十全十美的人和事。nginx expire也会给企业带来一些困惑 当网站被缓存的页面或数据更新了,此时用户看到的可能还是旧的已经缓存的内容,这样会影响用户体验 解决办法有如下几个: 1、对于经常需要变动的图片等文件,可以缩短对象缓存时间,例如谷歌和百度的图片经常根据不同的日期换成一些节日的图,所以这里可以将这个图片设置为缓存期1天 2、当网站改变或更新内容时,可以在服务器将缓存的对象改名(网站代码程序)。 a、对于网站的图片、附件,一般不会被用户直接修改,用户层面上修改的图片实际上是重新传到服务器,虽然内容一样但是是个新的图片名了 b、网站改版升级会修改JS、CSS元素,若改版的时候对这些元素改了名,会使得前端的CDN以及用户端需要的重新缓存内容 企业网站缓存日期曾经的案例参考 不同的企业的业务和网站访问量不同,网站的缓存期时间设置也是不同的,比如,如下企业所用的缓存日期就是不一样的 51cto 1周 sina 15天 京东 25年 淘宝 10年 企业网站有可能不希望被缓存的内容 1、广告图片,用于广告服务,都缓存了就不好控制展示了 2、网站流量统计工具(js代码),都缓存了流量统计就不准了 3、更新频繁的文件(goole的logo),如果这个按天,缓存效果还是显著的

 

nginx日志相关优化与安全

nginx没有类似Apache的cronolog日志分割处理的功能,但是,可以通过nginxNginx的信号控制功能或者reload重载,然后利用脚本来实现日志的自动切割。
1、配置日志切割脚本: 
mkdir -p /server/scripts/  
cd /server/scripts/
cat cut_nginx_log.sh
cd /application/nginx/logs && \
/bin/mv www_access.log www_access_$(date +%F -d -1day).log
/application/nginx/sbin/nginx -s reload
提示:实际上脚本的功能很简单,就是更名日志,然后重新加载nginx,重新生成文件记录日志

2、将这段脚本保存后加入到Linux的crontab守护进程,让此脚本在每天凌晨0点执行,就可以实现日志的每天分割功能了,操作结果如下:
crontab -l |tail -2
#cut nginx log on 00:00 everynight
00  00 * * * /bin/sh  /server/scripts/cut_nginx_log.sh >/dev/null 2>&1


不记录不需要的访问日志
在实际工作中,对于负载均衡器健康检查节点或某些特定文件(图片,js,css)的日志,一般不需要记录下来,因为在统计PV时时按照页面计算的。而且日志写入太频繁会大量消耗磁盘I/O,降低服务的性能
具体配置方法为:
location ~ .*\.(js|jpg|jpeg|JPEG|css|bmp|gif|GIF)$ {
access_log off;
}
访问日志的权限设置
假如日志目录为/app/logs,则授权方法为:
chown –R root.root /app/logs
chmod –R 700 /app/logs
#不需要在日志目录上给nginx用户读或者写许可,没必要给大权限,nginx有master进程root用户,控制可以写入日志

Nginx站点目录及文件URL访问控制

根据扩展名限制程序和文件访问
Web2.0时代,绝大多数网站都是以用户为中心,例如:bbs、blog、sns产品,这几个产品有个共同的特点,就是不但允许用户发布内容到服务器,还允许用户发图片甚至附件到服务器上,由于为用户开了上传功能,因此给服务器带来了很大的安全风险,虽然很多程序在上传前会做一定的控制。例如:文件的大小、类型等,但是,一不小心就会被黑客钻了空子,上传了木马程序
安全的权限: 
1、所有站点目录的用户和组都应该为root,
2、所有目录默认权限是755;
3、所有文件默认权限为644;
注意:网站服务的用户不能用root,
以上权限的设置可以做到防止黑客上传木马,以及修改站点文件,但是,合理的用户上传内容也被拒之门外了,那么如何解决可以让合法的用户上传文件又不至于被黑客利用攻击呢?
这就是对业务进行分离,在比较好的网站业务架构中,应该把资源文件,包括用户上传的图片,附件等的服务和程序
大多数公司的不安全的授权如下:
1chmod -R 777 /sitedir(最不安全)
2) chmod -R nginx.nginx /sitedir(最不安全)
如果大多数公司授权一般的授权,会给网站带来最大的安全隐患
下面是利用Nginx配置禁止访问上传资源目录下的PHP、shell、perl、python程序文件,这样用户即使上传了木马文件也没法去执行,从而加强了网站的安全
范例1: 配置nginx限制指定目录下的指定程序被解析,需要写在PHP配置的前面
location ~ ^images/.*\.(php|php5|.sh|.pl|.py)$
{    deny all;  }

location ~ ^/static/.*\.(php|php5|.sh|.pl|.py)$
{    deny all;  }

location ~* ^/data/(attachment|avatar)/.*\.(php|php5)$
{    deny all;  }
范例2:Nginx下配置禁止访问*.txt文件,实际配置信息如下:
location ~* \.(txt|doc)$
if (-f $request_filename) {
root /data/www/www;
#rewrite …… 可以重定向到某个URL
break;
}
location ~* \.(txt|doc)$ {
    root /data/www/www;
    deny all;
    }
配置禁止访问指定的单个或多个目录。单目录
location ~ ^/(static)/ {
    deny all;
    }
location ~ ^/static {
    deny all;
    }
多个目录:
location ~ ^ /(static|js){
     deny all;
}

范例2:禁止访问目录并返回指定的http状态码
server {
    listen        80;
    server_name     www.gmts.org
    root        /data0/www/www;
    index        index.html index.htm;
    access_log  /app/logs/www_access.log  commonlog;
    location /admin/ { return 404; }
    location /templates/ { return 403;}
    }

限制网站来源IP访问

下面介绍如何使用ngx_http_access_module限制网站来源ip访问
案例环境:phpmyadmin数据库的web客户端,内部开发人员用的。
范例1:禁止某目录让外界访问,但是允许某IP访问该目录,且支持PHP解析
location ~ ^/gtms/ {
    allow 202.111.12.211;
    deny all;
}

方法1:使用if来控制
if  ($remote_addr = 10.0.0.7 ) {
return 403;
    }
if  ($remote_addr = 218.247.17.130 ) {
    set $allow_access_root  `true`;
}
注意事项:通过防火墙 效率高
1、deny 一定要加一个ip,否则403,不往下执行了,如在同一域名下,会造成死循环
2、ip段 127.0.0.    10.10.10.0/16
3、以deny all;结尾,表示除了上面allow的,其他都禁止,如
location / {
deny 192.168.1.1;
allow 127.0.0.0/24
allow .......
deny all;
}

Nginx如何防止用户IP访问网站(恶意域名解析,也相当于是直接IP访问企业网站) 方法1、让使用IP访问网站的,或者访问经恶意解析域名,收到501错误 说明:直接报501错误,从用户体验上不是很好 上述代码放到第一个虚拟主机前面 方法2:通过301跳转到主页 server { listen
80 default_server; server_name _;
return 501;
#通过ip访问返回501 Not Implemented
#nginx #rewrite
^(.*) http://blog.gtms.org/$1 permanent } 方法3:发现某域名恶意解析到公司的服务器IP,在server标签里添加以下代码即可,若有多个server要多处添加。 if ($host !~ www/.gtms/.com$) { rewrite ^(.*) http://www.gtms.com/$1 permanent; }