nginx配置-生产配置
# nginx.conf（Main）
当代理的服务非常多，此时就需要比较细致的配置才能满足需求。完整的配置文件内容比较多，所以我们使用include指令来拆分主配置文件
# 全局块配置
include main.conf;
#工作模式与连接数上限
events {
# 事件模型相关配置
include events_core.conf;
include events_other.conf;
}
#设定http服务器
http {
# http块通用配置
include http_common.conf;
# 访问日志相关配置
include access_log.conf;
# sendfile相关配置
include sendfile.conf;
# gzip压缩相关配置
include gzip.conf;
# 使用buffer读取header的相关配置
include header_buffer.conf;
# URL访问时是否显示访问目录
include autoindex.conf;
# 发送大文件相关配置
include send_large_file.conf;
# upstream负载均衡相关配置
include upstream.conf;
#虚拟主机的配置
server{
# server全局块相关配置
include server_global.conf;
# 静态资源location配置
include static_locations.conf;
#对 "/" 启用反向代理
location / {
proxy_pass http://192.168.1.117:8080 ;
# 动态代理相关配置
include proxy.conf;
}
# 查看Nginx状态的地址
include nginx_status_location.conf;
# HTTP 自动跳转 HTTPS
rewrite ^(.*) https://www.baidu.com;
deny 127.0.0.1; #拒绝的ip
allow 172.18.5.54; #允许的ip
}
# https虚拟主机相关配置
include https_server.conf;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
# Main块
# main.conf
# 全局参数设置
user nginx;
worker_processes auto;
# 错误日志路径
error_log /var/log/nginx/error.log warn;
# PID 文件路径
pid /var/run/nginx.pid;
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
# Event块
# events_core.conf
# 当某一时刻只有一个网络连接到来时，多个睡眠进程会被同时叫醒，但只有一个进程可获得连接。如果每次唤醒的进程数目太多，会影响一部分系统性能。在Nginx服务器的多进程下，就有可能出现这样的问题。
# 开启的时候，将会对多个Nginx进程接收连接进行序列化，防止多个进程对连接的争抢
# 默认是开启状态，只能在events块中进行配置
accept_mutex on | off; #设置网路连接序列化锁，防止惊群现象发生，默认为on。
# 如果multi_accept被禁止了，nginx一个工作进程只能同时接受一个新的连接。否则，一个工作进程可以同时接受所有的新连接。
# 如果nginx使用kqueue连接方法，那么这条指令会被忽略，因为这个方法会报告在等待被接受的新连接的数量。
# 默认是off状态，只能在event块配置
multi_accept on | off; #设置一个进程是否同时接受多个网络连接，默认为off
# 指定使用哪种网络IO模型
# method可选择的内容有：select、poll、kqueue、epoll、rtsig、/dev/poll以及eventport，一般操作系统不是支持上面所有模型的。
# 【IO 复用，提升性能】epoll模型是Linux 2.6以上版本内核中的高性能网络I/O模型,如果跑在FreeBSD上面,就用kqueue模型.
# 只能在events块中进行配置
# use [method]
use epoll;
# 设置允许每一个worker process同时开启的最大连接数，当每个工作进程接受的连接数超过这个值时将不再接收连接
# 当所有的工作进程都接收满时，连接进入logback，logback满后连接被拒绝
# 只能在events块中进行配置
# 注意：这个值不能超过超过系统支持打开的最大文件数，也不能超过单个进程支持打开的最大文件数
worker_connections 1024; #单个进程最大连接数，默认为512（最大连接数=连接数*进程数）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#客户端请求头部的缓冲区大小。这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。
#分页大小可以用命令getconf PAGESIZE 取得。
#[root@web001 ~]# getconf PAGESIZE
#4096
#但也有client_header_buffer_size超过4k的情况，但是client_header_buffer_size该值必须设置为“系统分页大小”的整倍数。
client_header_buffer_size 4k;
#这个将为打开文件指定缓存，默认是没有启用的
# max：指定缓存数量，建议和打开文件数一致
# inactive：是指经过多长时间文件没被请求后删除缓存。
open_file_cache max=65535 inactive=60s;
#这个是指多长时间检查一次open_file_cache缓存的有效信息。
#语法:open_file_cache_valid time
# 默认值:open_file_cache_valid 60
# 使用字段:http, server, location
open_file_cache_valid 80s;
#open_file_cache指令中的inactive参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive时间内一次没被使用，它将被移除。
#语法:open_file_cache_min_uses number 默认值:open_file_cache_min_uses 1 使用字段:http, server, location 这个指令指定了在open_file_cache指令无效的参数中一定的时间范围内可以使用的最小文件数,如果使用更大的值,文件描述符在cache中总是打开状态.
open_file_cache_min_uses 1;
# 这个指令指定是否在搜索一个文件时记录cache错误.
#语法:open_file_cache_errors on | off
# 默认值:open_file_cache_errors off
# 使用字段:http, server, location
open_file_cache_errors on;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
推荐配置：
accept_mutex on;
multi_accept on;
1
2
2
# http块
# send_large_file.conf
# 限制请求体的大小，若超过所设定的大小，返回413错误。
client_max_body_size 50m; #文件大小限制，默认1m
# 读取请求头的超时时间，若超过所设定的大小，返回408错误。
client_header_timeout 1m;
# 读取请求实体的超时时间，若超过所设定的大小，返回413错误。
client_body_timeout 1m;
# http请求无法立即被容器(tomcat, netty等)处理，被放在nginx的待处理池中等待被处理。
# 此参数为等待的最长时间，默认为60秒，官方推荐最长不要超过75秒。
proxy_connect_timeout 60s;
# http请求被容器(tomcat, netty等)处理后，nginx会等待处理结果，也就是容器返回的response。
# 此参数即为服务器响应时间，默认60秒。
proxy_read_timeout 1m;
# http请求被服务器处理完后，把数据传返回给Nginx的用时，默认60秒。
proxy_send_timeout 1m;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# autoindex.conf
# 开启目录列表访问,默认关闭.
autoindex on; # 显示目录
autoindex_exact_size on; # 显示文件大小 默认为on,显示出文件的确切大小,单位是bytes 改为off后,显示出文件的大概大小,单位是kB或者MB或者GB
autoindex_localtime on; # 显示文件时间 默认为off,显示的文件时间为GMT时间 改为on后,显示的文件时间为文件的服务器时间
1
2
3
4
2
3
4
# upstream.conf
#负载均衡配置
upstream www.itxh.com {
#upstream的负载均衡，weight是权重，可以根据机器配置定义权重。weigth参数表示权值，权值越高被分配到的几率越大。
server 192.168.80.121:80 weight=3;
server 192.168.80.122:80 weight=2;
server 192.168.80.123:80 weight=3;
#nginx的upstream目前支持4种方式的分配
#1、轮询（默认）
#每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
#2、weight
#指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
#例如：
#upstream bakend {
# server 192.168.0.14 weight=10;
# server 192.168.0.15 weight=10;
#}
#2、ip_hash
#每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
#例如：
#upstream bakend {
# ip_hash;
# server 192.168.0.14:88;
# server 192.168.0.15:80;
#}
#3、fair（第三方）
#按后端服务器的响应时间来分配请求，响应时间短的优先分配。
#upstream backend {
# server server1;
# server server2;
# fair;
#}
#4、url_hash（第三方）
#按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
#例：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法
#upstream backend {
# server squid1:3128;
# server squid2:3128;
# hash $request_uri;
# hash_method crc32;
#}
#tips:
#upstream bakend{#定义负载均衡设备的Ip及设备状态}{
# ip_hash;
# server 127.0.0.1:9090 down;
# server 127.0.0.1:8080 weight=2;
# server 127.0.0.1:6060;
# server 127.0.0.1:7070 backup;
#}
#在需要使用负载均衡的server中增加 proxy_pass http:
#每个设备的状态设置为:
#1.down表示单前的server暂时不参与负载
#2.weight为weight越大，负载的权重就越大。
#3.max_fails：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream模块定义的错误
#4.fail_timeout:max_fails次失败后，暂停的时间。
#5.backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。
#nginx支持同时设置多组的负载均衡，用来给不用的server来使用。
#client_body_in_file_only设置为On 可以讲client post过来的数据记录到文件中用来做debug
#client_body_temp_path设置记录文件的目录 可以设置最多3层目录
#location对URL进行匹配.可以进行重定向或者进行新的代理 负载均衡
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
# location块
每个server块中可以包含多个location块。在整个Nginx配置文档中起着重要的作用，而且Nginx服务器在许多功能上的灵活性往往在location指令的配置中体现出来。地址定向、数据缓存和应答控制等功能都是在这部分实现。许多第三方模块的配置也是在location块中提供功能。
location块的主要作用是，基于Nginx服务器接收到的请求字符串（例如， server_name/uri-string），对除虚拟主机名称（也可以是IP别名，后文有详细阐述）之外的字符串（前例中“/uri-string”部分）进行匹配，对特定的请求进行处理。
在Nginx的官方文档中定义的location的语法结构为：
location [ = | ~ | ~* | ^~ ] uri { ... }
1
uri变量是待匹配的请求字符串，可以是不含正则表达的字符串，如/myserver等；也可以是包含有正则表达的字符串，如 .jpg$（表示以.jpg结尾的URL）等。为了方便，我们约定，不含正则表达的uri称为“标准uri”，使用正则表达式的uri称为“正则uri”。方括号里的部分，[ = | ~ | ~* | ^~ ]是可选项，用来改变请求字符串与 uri 的匹配方式。在介绍四种标识的含义之前，我们需要先了解不添加此选项时，Nginx服务器是如何在server块中搜索并使用location块的uri和请求字符串匹配的。在不添加此选项时，Nginx服务器首先在server块的多个location块中搜索是否有标准uri和请求字符串匹配，如果有多个可以匹配，就记录匹配度最高的一个。然后，服务器再用location块中的正则uri和请求字符串匹配，当第一个正则uri匹配成功，结束搜索，并使用这个location块处理此请求；如果正则匹配全部失败，就使用刚才记录的匹配度最高的location块处理此请求。
“=”，用于标准uri前，要求请求字符串与uri严格匹配。具备截断机制，如果已经匹配成功，就停止继续向下搜索并立即处理此请求。“^～”，用于标准uri前，要求Nginx服务器找到标识uri和请求字符串匹配度最高的location后，立即使用此location处理请求，而不再使用location块中的正则uri和请求字符串做匹配。“～”，用于表示uri包含正则表达式，并且区分大小写。“～*”，用于表示uri包含正则表达式，并且不区分大小写。注意如果uri包含正则表达式，就必须要使用“～”或者“～*”标识。
这里可聊的内容很多》》》
server {
listen 80;
server_name localhost;
location /doc {
return 402;
}
location /docu {
return 401;
}
}
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
完善页面 (opens new window)