Skip to main content

2.配置文件简解

配置文件位置​

NGINX配置文件位置取决于用于安装NGINX的软件包系统和操作系统。 它通常是 /usr/local/nginx/conf、/etc/nginx 或 /usr/local/etc/nginx 中。

配置文件组成​

Directives(指令)​

配置文件由Directives及其参数组成。简单（单行）指令每个都以分号结尾。其他指令充当“容器”，将相关指令组合在一起，将它们括在大括号 （ {}）;这些通常被称为 块(blocks) 。下面是一些简单指令的示例。

user             nobody;
error_log        logs/error.log notice;
worker_processes 1;

特定于功能的配置文件(Feature-Specific Configuration Files)​

为了使配置更易于维护，建议将配置文件拆分，存储在 /etc/nginx/conf.d 目录中，并使用主 nginx.conf 文件中的 include 指令来引用特定于功能的文件的内容。

include conf.d/http;
include conf.d/stream;
include conf.d/exchange-enhanced;

上下文(Contexts)​

一些顶级指令（称为 上下文(contexts , ) ）将适用于不同流量类型(different traffic types)的指令组合在一起：

放置在这些上下文之外的指令被称为在主要上下文(main context)中。

虚拟服务器(Virtual Servers)​

在每个流量处理上下文中，您可以包含一个或多个 server块来定义控制请求处理的 虚拟服务器 。可以包含在 server上下文中的指令因流量类型而异。

对于 HTTP 流量（http上下文），每个服务器指令控制对特定域（particular domains）或 IP 地址的资源请求的处理。server上下文中的一个或多个location上下文定义如何处理特定的 URI 集。

对于邮件和 TCP/UDP 流量（邮件(mail)和流(stream)上下文），每个 server指令都控制到达特定 TCP 端口或 UNIX 套接字的流量的处理。

具有多个上下文的示例配置文件​

user nobody; # a directive in the 'main' context

events {
    # configuration of connection processing
}

http {
    # Configuration specific to HTTP and affecting all virtual servers  

    server {
        # configuration of HTTP virtual server 1   
        location /one {
            # configuration for processing URIs starting with '/one'
        }
        location /two {
            # configuration for processing URIs starting with '/two'
        }
    } 
  
    server {
        # configuration of HTTP virtual server 2
    }
}

stream {
    # Configuration specific to TCP/UDP and affecting all virtual servers
    server {
        # configuration of TCP virtual server 1 
    }
}

Inheritance（继承）​

通常，子上下文(child context)（包含在另一个上下文（其父上下文）中的子上下文）继承父级别包含的指令的设置。某些指令可以出现在多个上下文中，在这种情况下，您可以通过在子上下文中包含指令来覆盖从父级继承的设置。有关示例，请参阅 proxy_set_header 指令。

主进程和工作进程​

NGINX有一个主进程（master process）和一个或多个工作进程（worker processes）。如果启用了缓存，则缓存加载程序和缓存管理器进程也会在启动时运行。

主进程的主要目的是读取和评估配置文件，以及维护工作进程。

工作进程执行请求的实际处理。NGINX 依赖于操作系统的机制在工作进程之间有效地分发请求（NGINX relies on OS-dependent mechanisms to efficiently distribute requests among worker processes.）。工作进程的数量由 nginx.conf 配置文件中的 worker_processes 指令定义，可以设置为固定数量，也可以配置为自动调整可用 CPU 内核的数量。

  1. Master Process（主进程）:
    • 启动和管理： 主进程负责启动和管理Nginx服务器。当你启动Nginx服务时，主进程会读取配置文件，加载配置，然后启动工作进程。
    • 信号处理： 主进程接收并处理信号，例如重新加载配置、关闭服务器等。通过发送信号给主进程，你可以实现在不停止服务的情况下重新加载配置文件或者优雅地关闭Nginx。
  2. Worker Processes（工作进程）:
    • 处理请求： 每个工作进程都是一个独立的进程，负责处理客户端的请求。当有请求到达时，主进程会将请求分配给一个可用的工作进程来处理。
    • 并发处理： 工作进程之间是并发运行的，每个工作进程都能处理多个请求。这使得Nginx能够有效地处理大量并发请求。
    • 独立性： 工作进程是相互独立的，一个工作进程的崩溃不会影响其他工作进程。这有助于提高Nginx的稳定性。

分离主进程和工作进程的设计使得Nginx能够更好地应对高并发的请求，提高服务器的性能和稳定性。主进程负责管理工作进程，而工作进程负责实际处理请求。

基本指令​

如果需要要重新加载配置，可以停止或重新启动 NGINX，或将信号发送到主进程。可以通过运行nginx -s命令（调用 NGINX 可执行文件）来发送信号。

nginx -s <SIGNAL>

<SIGNAL>可以是以下之一：

  • quit– 优雅地关闭（SIGQUIT信号）
  • reload– 重新加载配置文件（SIGHUP信号）
  • reopen– 重新打开日志文件（SIGUSR1信号）
  • stop– 立即关闭（或快速关机，SIGTERM信号）

该实用程序还可用于将 kill信号直接发送到主进程。默认情况下，主进程的进程 ID 写入 nginx.pid 文件，该文件位于 /usr/local/nginx/logs 或 /var/run 目录中。

连接处理方式​

nginx支持多种连接处理方式。特定方法的可用性取决于所使用的平台。在支持多种方法的平台上，nginx 通常会自动选择最有效的方法。如果需要，可以使用use指令显式选择连接处理方法 。

支持以下连接处理方式：

  • select ——标准方法。支持模块是在缺乏更有效方法的平台上自动构建的。和配置 --with-select_module参数 --without-select_module可用于强制启用或禁用该模块的构建。

  • poll ——标准方法。支持模块是在缺乏更有效方法的平台上自动构建的。和配置 --with-poll_module参数 --without-poll_module可用于强制启用或禁用该模块的构建。

  • kqueue — 在 FreeBSD 4.1+、OpenBSD 2.9+、NetBSD 2.0 和 macOS 上使用的有效方法。

  • epoll — Linux 2.6+ 上使用的有效方法。

    自 1.11.3 起支持 EPOLLRDHUP(Linux 2.6.17, glibc 2.8) 和 EPOLLEXCLUSIVE(Linux 4.5, glibc 2.24) 标志。

    一些较旧的发行版（例如 SuSE 8.2）提供了为 2.4 内核添加 epoll 支持的补丁。

  • /dev/poll — 在 Solaris 7 11/99+、HP/UX 11.22+ (eventport)、IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+ 上使用的有效方法。

  • eventport — 事件端口，Solaris 10+ 上使用的方法（由于已知问题，建议改用该 /dev/poll方法）。