Tianyi's Blog
tianyi
2023-10-28
目录

nginx配置-生产配置

# nginx.conf（Main）

当代理的服务非常多，此时就需要比较细致的配置才能满足需求。完整的配置文件内容比较多，所以我们使用include指令来拆分主配置文件

指令索引 (opens new window)

# 全局块配置
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

# 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

# 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
#客户端请求头部的缓冲区大小。这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过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

推荐配置：

accept_mutex on;
multi_accept on;
1
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

# autoindex.conf

# 开启目录列表访问,默认关闭.
autoindex on; # 显示目录
autoindex_exact_size on; # 显示文件大小 默认为on,显示出文件的确切大小,单位是bytes 改为off后,显示出文件的大概大小,单位是kB或者MB或者GB
autoindex_localtime on; # 显示文件时间 默认为off,显示的文件时间为GMT时间 改为on后,显示的文件时间为文件的服务器时间
1
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

# 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
nginx配置-最佳实践
nginx常用指令

← nginx常用指令→

最近更新
01
前端学习路线
01-15
02
Idea的基本使用
01-09
03
html、css
11-15
更多文章>
Theme by Vdoing | Copyright © 2021-2025 Tandy