Nginx的配置详解

小逗比iswho

已于 2023-09-05 11:01:26 修改

阅读量167

点赞数

文章标签： nginx 服务器运维

于 2022-12-28 11:01:27 首次发布

本文链接：https://blog.csdn.net/qq_44861126/article/details/128465640

版权

Nginx的配置文件详解

##代码块中的events、http、server、location、upstream等都是块配置项##
##块配置项可以嵌套。内层块直接继承外层快，例如：server块里的任意配置都是基于http块里的已有配置的##
 
##Nginx worker进程运行的用户及用户组 
#语法：user username[groupname]  默认：user nobody nobody
#user用于设置master进程启动后，fork出的worker进程运行在那个用户和用户组下。当按照"user username;"设置时，用户组名与用户名相同。
#若用户在configure命令执行时，使用了参数--user=usergroup 和 --group=groupname,此时nginx.conf将使用参数中指定的用户和用户组。
#user nobody;
 
##Nginx worker进程个数：其数量直接影响性能。
#每个worker进程都是单线程的进程，他们会调用各个模块以实现多种多样的功能。如果这些模块不会出现阻塞式的调用，那么，有多少CPU内核就应该配置多少个进程，反之，有可能出现阻塞式调用，那么，需要配置稍多一些的worker进程。
worker_processes 1;
 
##ssl硬件加速。
#用户可以用OpneSSL提供的命令来查看是否有ssl硬件加速设备：openssl engine -t
#ssl_engine device;
 
##守护进程(daemon)。是脱离终端在后台允许的进程。它脱离终端是为了避免进程执行过程中的信息在任何终端上显示。这样一来，进程也不会被任何终端所产生的信息所打断。##
##关闭守护进程的模式，之所以提供这种模式，是为了放便跟踪调试nginx，毕竟用gdb调试进程时最繁琐的就是如何继续跟进fork出的子进程了。##
##如果用off关闭了master_proccess方式，就不会fork出worker子进程来处理请求，而是用master进程自身来处理请求
#daemon off;  #查看是否以守护进程的方式运行Nginx 默认是on 
#master_process off; #是否以master/worker方式工作 默认是on
 
##error日志的设置#
#语法： error_log /path/file level;
#默认： error_log / log/error.log error;
#当path/file 的值为 /dev/null时，这样就不会输出任何日志了，这也是关闭error日志的唯一手段；
#leve的取值范围是debug、info、notice、warn、error、crit、alert、emerg从左至右级别依次增大。
#当level的级别为error时，error、crit、alert、emerg级别的日志就都会输出。大于等于该级别会输出，小于该级别的不会输出。
#如果设定的日志级别是debug，则会输出所有的日志，这一数据量会很大，需要预先确保/path/file所在的磁盘有足够的磁盘空间。级别设定到debug，必须在configure时加入 --with-debug配置项。
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
 
##pid文件（master进程ID的pid文件存放路径）的路径
#pid    logs/nginx.pid;
 
 
events {
 #仅对指定的客户端输出debug级别的日志： 语法：debug_connection[IP|CIDR]
 #这个设置项实际上属于事件类配置，因此必须放在events{……}中才会生效。它的值可以是IP地址或者是CIRD地址。
 #debug_connection 10.224.66.14; #或是debug_connection 10.224.57.0/24
 #这样，仅仅以上IP地址的请求才会输出debug级别的日志，其他请求仍然沿用error_log中配置的日志级别。
 #注意：在使用debug_connection前，需确保在执行configure时已经加入了--with-debug参数，否则不会生效。
 worker_connections 1024;
}
 
##核心转储(coredump):在Linux系统中，当进程发生错误或收到信号而终止时，系统会将进程执行时的内存内容(核心映像)写入一个文件(core文件)，以作为调试只用，这就是所谓的核心转储(coredump).
 
http {
##嵌入其他配置文件 语法：include /path/file
#参数既可以是绝对路径也可以是相对路径（相对于Nginx的配置目录，即nginx.conf所在的目录）
  include    mime.types;
  default_type application/octet-stream;
 
  #log_format main '$remote_addr - $remote_user [$time_local] "$request" '
  #         '$status $body_bytes_sent "$http_referer" '
  #         '"$http_user_agent" "$http_x_forwarded_for"';
 
  #access_log logs/access.log main;
 
  sendfile    on;
  #tcp_nopush   on;
 
  #keepalive_timeout 0;
  keepalive_timeout 65;
 
  #gzip on;
 
  server {
##listen监听的端口
#语法：listen address:port [ default(deprecated in 0.8.21) | default_server | [ backlog=num | rcvbuf=size | sndbuf=size | accept_filter=filter | deferred | bind | ssl ] ]
#default_server: 如果没有设置这个参数，那么将会以在nginx.conf中找到的第一个server块作为默认server块
 listen    8080;
 
#主机名称：其后可以跟多个主机名称，开始处理一个HTTP请求时，nginx会取出header头中的Host，与每个server中的server_name进行匹配，以此决定到底由那一个server来处理这个请求。有可能一个Host与多个server块中的server_name都匹配，这时会根据匹配优先级来选择实际处理的server块。server_name与Host的匹配优先级见文末。
 server_name localhost;
 
    #charset koi8-r;
 
    #access_log logs/host.access.log main;
 
    #location / {
    #  root  html;
    #  index index.html index.htm;
    #}
 
##location 语法： location [=|~|~*|^~] /uri/ { ... }
# location的使用实例见文末。
#注意：location时有顺序的，当一个请求有可能匹配多个location时，实际上这个请求会被第一个location处理。
 location / {
 proxy_pass http://192.168.1.60;
    }
 
    #error_page 404       /404.html;
 
    # redirect server error pages to the static page /50x.html
    #
    error_page  500 502 503 504 /50x.html;
    location = /50x.html {
      # 用root属性指定的值是要加入到最终路径中的，匹配条件会拼接到路径中,最终效果：ip/html/50x.html
      # html目录是Nginx的Web根目录，其中index.html文件是Nginx默认首页。
      root  html;
    }
 
    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
    #  proxy_pass  http://127.0.0.1;
    #}
 
    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
    #  root      html;
    #  fastcgi_pass  127.0.0.1:9000;
    #  fastcgi_index index.php;
    #  fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
    #  include    fastcgi_params;
    #}
 
    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #  deny all;
    #}
  }
 
 
 
  # another virtual host using mix of IP-, name-, and port-based configuration
  #
  #server {
  #  listen    8000;
  #  listen    somename:8080;
  #  server_name somename alias another.alias;
 
  #  location / {
  #    root  html;
  #    index index.html index.htm;
  #  }
  #}
 
 
  # HTTPS server
  #
  #server {
  #  listen    443 ssl;
  #  server_name localhost;
 
  #  ssl_certificate   cert.pem;
  #  ssl_certificate_key cert.key;
 
  #  ssl_session_cache  shared:SSL:1m;
  #  ssl_session_timeout 5m;
 
  #  ssl_ciphers HIGH:!aNULL:!MD5;
  #  ssl_prefer_server_ciphers on;
 
  #  location / {
  #    root  html;
  #    index index.html index.htm;
  #  }
  #}
 
}

Nginx的配置可分为三块：全局块、events块、http块
全局块：
1、主要设置一些影响nginx 服务器整体运行的配置指令，主要包括配置运行 Nginx 服务器的用户（组）、允许生成的 worker process 数，进程 PID 存放路径、日志存放路径和类型以及配置文件的引入等。
2、worker_processes 是 Nginx 服务器并发处理服务的关键配置，值越大，可以支持的并发处理量也越多，但是会受到硬件、软件等设备的制约。
events块：
1、涉及的指令主要影响 Nginx 服务器与用户的网络连接，常用的设置包括是否开启对多 work process 下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型来处理连接请求，每个 word process 可以同时支持的最大连接数等。上述例子就表示每个 work process 支持的最大连接数为 1024。
http块：
1、location 中root所指向的html是一个相对路径，相对的是这个配置文件的路径，假设此配置文件的位置是/etc/nginx/conf.d，那么这个html的绝对路径就是/etc/nginx/conf.d/html。因此为避免出现不必要的麻烦，在配置root路径的过程中最好用绝对路径。

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    server {
        listen       80;
        server_name  localhost;

        location / {
            root   html;
            index  index.html index.htm;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

可参考:https://blog.csdn.net/qq_46312987/article/details/118895520

nginx Location匹配规则详解

location指令是http模块当中最核心的一项配置，根据预先定义的URL匹配规则来接收用户发送的请求，根据匹配结果，将请求转发到后台服务器、非法的请求直接拒绝并返回403、404、500错误处理等。

nginx的location匹配规则

先匹配 =，表示精确匹配，例如 location = /path，只有当请求的路径完全匹配 /path 时，才会生效。

再匹配 ^~，表示以指定路径开头的前缀匹配，例如 location ^~ /path，只有当请求的路径以 /path 开头时，才会生效。此规则将优先于正则表达式规则匹配。

再匹配正则表达式，通过 ~ 或 ~* 指定大小写敏感或不敏感匹配。例如 location ~ ^/path$，只有当请求的路径和 /path 完全匹配，并且大小写敏感时，才会生效。而 location ~* .(png|jpg)$，只要请求的路径以 .png 或 .jpg 结尾，不区分大小写，就会生效。

最后匹配普通路径规则。例如 location /path，只有当请求的路径与 /path 没有匹配到任何location时默认的location才会生效。

当有匹配成功时候，停止匹配，按当前匹配规则处理请求

“普通location ”与“正则location ”之间的匹配规则是：先匹配普通location ，再匹配正则location 。那么，“普通location ”内部（普通location 与普通location）是如何匹配的呢？简单的说：最大前缀匹配。意思是普通location先匹配，而且选择了最大前缀匹配后，不能就停止后面的匹配，最大前缀匹配只是一个临时的结果，nginx还需要继续检查正则location。
正则location ”与“正则location”内部的匹配规则是：按照正则location 在配置文件中的物理顺序（编辑顺序）匹配的（这句话就说明location 并不是一定跟顺序无关，只是普通location与顺序无关，正则location 还是与顺序有关的），并且只要匹配到一条正则location ，就不再考虑后面的（这与“普通location”与“正则location”之间的规则不一样， “普通location”与“正则location”之间的规则是：选择出“普通location ”的最大前缀匹配结果后，还需要继续搜索正则location ）。
最大前缀匹配，如果继续搜索的“正则location”也有匹配上的，那么“正则location”会覆盖“普通location”的最大前缀匹配（因为有这个覆盖关系，所以造成有些同学以为正则location先于普通location执行的错误理解）
通常的规则是，匹配完了“普通location”指令，还需要继续匹配“正则location”，但是你也可以告诉Nginx：匹配到了“普通location”后，不再需要继续匹配“正则location”了，要做到这一点只要在“普通location”前面加上^~符号（表示“非”，~表示“正则”，字符意思是：不要继续匹配正则）。
除了上面的^~可以阻止继续搜索正则location 外，还可以使用=。那么如果^~和=都能阻止继续搜索正则location 的话，那它们之间有什么区别呢？区别很简单，共同点是它们都能阻止继续搜索正则location，不同点是^~依然遵守“最大前缀”匹配规则，然而=不是“最大前缀”，而是必须是严格匹配（exact match ）。

符号	含义
=	字面精准匹配，如果匹配，则跳出匹配过程（不再进行正则匹配）
~	开头区分大小写的正则匹配
~*	开头不区分大小写的正则匹配
^~	开头表示uri以某个常规字符串开头，理解为匹配url路径即可
/	通用匹配，在没有正则表达式匹配时，任何请求都会匹配到
@	不是普通的location匹配，用于location内部重定向的变量

location = / {
　　# 精确匹配 / ，主机名后面不能带任何字符串
　　[ configuration A ]
}

location / {
　　# 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求
　　# 但是正则和最长字符串会优先匹配
　　[ configuration B ]
}

location /documents/ {
　　# 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索
　　# 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
　　[ configuration C ]
}

location ~ /documents/Abc {
　　# 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索
　　# 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
　　[ configuration CC ]
}

location ^~ /images/ {
　　# 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条。即使是例如 /images/abc 这种普通的最长匹配，也停止。
　　[ configuration D ]
}

location ~* \.(gif|jpg|jpeg)$ {
　　# 匹配所有以 gif,jpg或jpeg 结尾的请求
　　# 然而，所有请求 /images/ 下的图片会被 config D 处理，因为 ^~ 到达不了这一条正则
　　[ configuration E ]
}

location /images/ {
　　# 字符匹配到 /images/，继续往下，会发现 ^~ 存在
　　[ configuration F ]
}

location /images/abc {
　　# 最长字符匹配到 /images/abc，继续往下，会发现 ^~ 存在
　　# F与G的放置顺序是没有关系的
　　[ configuration G ]
}

location ~ /images/abc/ {
　　# 只有去掉 config D 才有效：先最长匹配 config G 开头的地址，继续往下搜索，匹配到这一条正则，采用
　　[ configuration H ]
}

常用必选规则

直接匹配网站根

第一个必选规则
location = / {
    proxy_pass http://locolhost/index
}

处理静态文件请求

location ^~ /static/ {
    root /webroot/static/;
}
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {
    root /webroot/res/;
}

通用规则

location / {
    proxy_pass http://localhost/
}

禁止访问.sh后缀的文件

location ~.*\.(sh)${
		return 405;
	}

Nginx负载均衡配置

1、轮询（默认）：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

upstream 服务名{

    server 192.168.11.112;

    server 192.168.11.113;
}

2、weight（权重）：指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

upstream 服务名{

    server 192.168.11.112 weight=3;

    server 192.168.11.113 weight=7;

}

3、ip_hash（IP哈希）：采用ip_hash指令，如果客户已经访问了某个服务器，当用户再次访问时，会将该请求通过哈希算法，自动定位到该服务器。每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

upstream backserver {

    ip_hash;

    server 192.168.11.112:8888;

    server 192.168.11.113:8889;

}

4、fair（第三方）：按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstream backserver {

    server 192.168.11.112;

    server 192.168.11.112;

    fair;

}

关于location URI结尾带不带 /

如果 URI 结构是 https://domain.com/ 的形式，尾部有没有 / 都不会造成重定向。因为浏览器在发起请求的时候，默认加上了 / 。虽然很多浏览器在地址栏里也不会显示 / 。这一点，可以访问百度验证一下。

如果 URI 的结构是 https://domain.com/some-dir/ 。尾部如果缺少 / 将导致重定向。因为根据约定，URL 尾部的 / 表示目录，没有 / 表示文件。所以访问 /some-dir/ 时，服务器会自动去该目录下找对应的默认文件。如果访问 /some-dir 的话，服务器会先去找 some-dir 文件，找不到的话会将 some-dir 当成目录，重定向到 /some-dir/ ，去该目录下找默认文件。