Nginx 配置文件注释


user                 nobody;  # Nginx worker进程运行的用户及用户组
worker_processes     4; # 在master/worker运行方式下,定义worker进程的个数; 可以为auto
worker_rlimit_nofile 65535; # 设置 Nginx worker 进程可以打开的最大文件描述符数量。这个指令通常用于确保 Nginx 能够处理大量并发连接,因为每个连接通常会占用一个文件描述符。
worker_rlimit_core 1m;  # 通过worker_rlimit_core配置可以限制core文件的大小
working_directory /usr/local/lighthouse/softwares/nginx/coredump;  # 设置coredump文件所放置的目录
daemon on; # 是否以守护进程方式运行Nginx
master_process on;  # 是否以 master/worker 方式工作
worker_cpu_affinity 1000 0100 0010 0001; # 绑定worker进程到指定的CPU内核
error_log  logs/error.log  notice; # error_log/path/file level;
timer_resolution 100ms; # 每次内核的事件调用(如epoll、select、poll、kqueue等)返回时,都会执行一次gettimeofday,实现用内核的时钟来更新Nginx中的缓存时钟。

events { # 处理网络连接设置的核心部分
    debug_connection 10.224.66.14;  # 仅仅来自以上IP地址的请求才会输出debug级别的日志
    debug_connection 10.224.57.0/24;  # 其他请求仍然沿用error_log中配置的日志级别
    accept_mutex on; # 负载均衡锁 accept锁默认是打开的,如果关闭它,那么建立TCP连接的耗时会更短,但worker进程之间的负载会非常不均衡
    accept_mutex_delay 500ms; # 使用accept锁后,同一时间只有一个worker进程能够取到accept锁。这个accept锁不是阻塞锁,如果取不到会立刻返回。 如果有一个worker进程试图取accept锁而没有取到,它至少要等accept_mutex_delay定义的时间间隔后才能再次试图取锁。
    multi_accept off; # 当事件模型通知有新连接时,尽可能地对本次调度中客户端发起的所有TCP请求都建立连接。
    use epoll; # 事件驱动模型
    worker_connections  8192; # 每个worker进程可以同时处理的最大连接数。
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format       combinedio  '$remote_addr - $remote_user [$time_local] '
                                 '"$request" $status $body_bytes_sent '
                                 '"$http_referer" "$http_user_agent" $request_length $request_time $upstream_response_time';
    access_log logs/access.log combinedio;

    sendfile                     on; # 硬盘 >> kernel buffer >> user buffer>> kernel socket buffer >>协议栈  | 硬盘 >> kernel buffer (快速拷贝到kernelsocket buffer) >>协议栈
    gzip                         on; # 压缩响应内容
    tcp_nopush                   on; # 数据量达到一定值后发送
    tcp_nodelay                  on; # 对keepalive连接是否使用TCP_NODELAY选项。# 应用程序每产生一次操作就会发送一个包, delay 会等待数据,因此操作后它不会发送一个数据包,而是将这段时间内的数据打成一个大的包

    keepalive_timeout            0;  #  一个keepalive连接在闲置超过一定时间后,服务器关闭这个连接。
    client_body_timeout          10; # second HTTP包体
    client_header_timeout        10; # second  客户端与服务器建立连接后将开始接收HTTP头部,在这个过程中,如果在一个时间间隔(超时时间)内没有读取到客户端发来的字节,则认为超时,并向客户端返回408($$$"Request timed out")响应。

    client_header_buffer_size    1k; # 正常情况下Nginx接收用户请求中HTTP header部分(包括HTTP行和HTTP头部)时分配的内存buffer大小。
    large_client_header_buffers  4  4k; # Nginx接收一个超大HTTP头部请求的buffer个数和每个buffer的大小。如果HTTP请求行(如GET/index HTTP/1.1)的大小超过上面的单个buffer,则返回414
    output_buffers               2  32k;
    client_max_body_size         64m;  # 浏览器在发送含有较大HTTP包体的请求时,其头部会有一个Content-Length字段,client_max_body_size是用来限制Content-Length所示值的大小的。因此,这个限制包体的配置非常有用处,因为不用等Nginx接收完所有的HTTP包体——这有可能消耗很长时间——就可以告诉用户请求过大不被接受。
    client_body_buffer_size      256k; # Nginx接收HTTP包体的内存缓冲区大小。也就是说,HTTP包体会先接收到指定的这块缓存中,之后才决定是否写入磁盘
    client_body_in_file_only     off;  # 当值为非off时,用户请求中的HTTP包体一律存储到磁盘文件中,即使只有0字节也会存储为文件。当请求结束时,如果配置为on,则这个文件不会被删除(该配置一般用于调试、定位问题)​,但如果配置为clean,则会删除该文件。
    client_body_in_single_buffer off;  # 用户请求中的HTTP包体一律存储到内存buffer中。当然,如果HTTP包体的大小超过了下面client_body_buffer_size设置的值,包体还是会写入到磁盘文件中。
    large_client_header_buffers  2k;  # HTTP包体会先接收到指定的这块缓存中,之后才决定是否写入磁盘。如果用户请求中含有HTTP头部Content-Length,并且其标识的长度小于定义的buffer大小,那么Nginx会自动降低本次请求所使用的内存buffer,以降低内存消耗。
    connection_pool_size         256;  # Nginx对于每个建立成功的TCP连接会预先分配一个内存池,上面的size配置项将指定这个内存池的初始大小
    request_pool_size            1k; # Nginx开始处理HTTP请求时,将会为每个请求都分配一个内存池,size配置项将指定这个内存池的初始大小
    # client_body_temp_path  # HTTP包体的临时存放目录
    send_timeout                 30;  # second 发送响应的超时时间,即Nginx服务器向客户端发送了数据包,但客户端一直没有去接收这个数据包。如果某个连接超过send_timeout定义的超时时间,那么Nginx将会关闭这个连接。
    reset_timeout_connection     on;  # 连接超时后将通过向客户端发送RST包来直接重置连接。这个选项打开后,Nginx会在某个连接超时后,不是使用正常情形下的四次握手关闭TCP连接,而是直接向用户发送RST重置包,不再等待用户的应答,直接释放Nginx服务器上关于这个套接字使用的所有缓存(如TCP滑动窗口
    keepalive_requests           100; # 一个keepalive连接上默认最多只能发送100个请求。
    limit_rate                   4k;  # 此配置是对客户端请求限制每秒传输的字节数。
    limit_rate_after             1m;  # 发送的响应长度超过limit_rate_after后才开始限速
    ignore_invalid_headers       off; # 忽略不合法的头部,默认on,如果将其设置为off,那么当出现不合法的HTTP头部时,Nginx会拒绝服务,并直接向用户发送400(Bad Request)错误。如果将其设置为on,则会忽略此HTTP头部。
    underscores_in_headers       off; # HTTP头部的名称中不允许带下划线
    if_modified_since            exact; # 浏览器在第一次请求资源后会缓存响应内容。在后续请求中,浏览器会在请求头中添加 If-Modified-Since,服务器根据该值判断是否需要返回最新的资源内容
                                        # off:表示忽略用户请求中的If-Modified-Since头部。这时,如果获取一个文件,那么会正常地返回文件内容。HTTP响应码通常是200。
                                        # exact:将If-Modified-Since头部包含的时间与将要返回的文件上次修改的时间做精确比较,如果没有匹配上,则返回200和文件的实际内容,如果匹配上,则返回 304 Not Modified
                                        # before:是比exact更宽松的比较。只要文件的上次修改时间等于或者早于用户请求中的If-Modified-Since头部的时间,就会向客户端返回304 Not Modified。

    log_not_found                on;  # 此配置项表示当处理用户请求且需要访问文件时,如果没有找到文件,是否将错误日志记录到error.log文件中。
    merge_slashes                on;  # 是否合并相邻的/
    resolver                     127.0.0.1 127.0.0.2; # DNS 解析地址
    resolver_timeout             30; # DNS解析超时时间

    server_tokens                off;  # 表示处理请求出错时是否在响应的Server头部中标明Nginx版本

    server {
        listen 443 default deferred backlog=100 ssl;

        server_name work.ronie.ren; # 在开始处理一个HTTP请求时,Nginx会取出header头中的Host,与每个server中的server_name进行匹配,以此决定到底由哪一个server块来处理这个请求。有可能一个Host与多个server块中的server_name都匹配,这时就会根据匹配优先级来选择实际处理的server块。server_name与Host的匹配优先级如下:1)首先选择所有字符串完全匹配的server_name,如www.testweb.com。2)其次选择通配符在前面的server_name,如*.testweb.com。3)再次选择通配符在后面的server_name,如www.testweb.*。4)最后选择使用正则表达式才匹配的server_name,如~^\.testweb\.com$。
        server_names_hash_bucket_size 1024 # 用于设置存储服务器名称的哈希表的桶大小。
        server_names_hash_max_size 512 # 会影响散列表的冲突率。server_names_hash_max_size越大,消耗的内存就越多,但散列key的冲突率则会降低,检索速度也更快。
        server_tokens off;
        keepalive_timeout 10;

        ssl_certificate /usr/local/lighthouse/softwares/nginx/certificates/work.ronie.ren_bundle.crt;
        ssl_certificate_key /usr/local/lighthouse/softwares/nginx/certificates/work.ronie.ren.key;
        ssl_session_timeout 5m;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
        ssl_prefer_server_ciphers on;

        # 反向代理配置
        location / {
            proxy_pass http://workservers;  # 设置代理
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }

        access_log  "logs/work.ronie.ren.log";
        error_log  "logs/work.ronie.ren.error.log";
    }


    upstream workservers{
        ip_hash;  # 据客户端的IP地址计算出一个key,将key按照upstream集群里的上游服务器数量进行取模,然后以取模后的结果把请求转发到相应的上游服务器中。这样就确保了同一个客户端的请求只会转发到指定的上游服务器中。
        server 192.168.0.1:8080 weight=5 down; # down表示所在的上游服务器永久下线,只在使用ip_hash配置项时才有用。
        server 192.168.0.2:8080 weight=5 max_fails=3 fail_timeout=30s; # 与fail_timeout配合使用,指在fail_timeout时间段内;
        server 192.168.0.3:8080 weight=5 max_fails=3 fail_timeout=30s; # 如果向当前的上游服务器转发失败次数超过number,则认为在当前的fail_timeout时间段内这台上游服务器不可用。
        server 192.168.0.4:8080 weight=5 max_fails=3 fail_timeout=30s backup; # backup:在使用ip_hash配置项时它是无效的。

    }


}

声明:Hello World|版权所有,违者必究|如未注明,均为原创|本网站采用BY-NC-SA协议进行授权

转载:转载请注明原文链接 - Nginx 配置文件注释


我的朋友,理论是灰色的,而生活之树是常青的!