Nginx配置最全详解(万字图文总结)

[TOC]

Nginx 也是我们比较常见的“玩具”了，不过有的小伙伴对 Nginx 配置不熟悉，每次使用的时候都要搜索，松哥在本文中给出一些常见的配置案例，小伙伴们可以收藏备用。

一 什么是 Nginx

Nginx（发音为“Engine-X”）是一个开源的高性能 HTTP 和反向代理服务器，同时也是一个 IMAP/POP3/SMTP 代理服务器。由俄罗斯程序员 Igor Sysoev 创建。它以其高稳定性、丰富的功能集、简单的配置和低资源消耗而闻名。

Nginx 最初是为了解决 C10K 问题（即同时处理 10000 个客户端连接）而设计的，现在已经成为世界上最流行的 Web 服务器之一。

二 为什么选择 Nginx

选择 Nginx 当然是因为它好，好在哪里呢？

• 高性能：Nginx 能够处理大量的并发连接，而内存使用率相对较低。
• 高可靠性：Nginx 的设计目标是提供 7x24 小时不间断的服务。
• 模块化：Nginx 拥有丰富的模块系统，可以轻松扩展其功能。
• 配置简单：Nginx 的配置文件结构清晰，易于理解和管理。
• 跨平台：Nginx 可以在多种操作系统上运行，包括 Linux、BSD、MacOS 和 Windows。

三 Nginx 配置示例

3.1 负载均衡

Nginx 是我们常用的负载均衡工具之一，它可以将请求分发到多个服务器上，以实现负载均衡。

举个栗子：

http {  
    upstream myapp1 {  # 定义一个名为myapp1的服务器组  
        server backend1.example.com weight=5;  # 添加一个服务器，并设置权重为5  
        server backend2.example.com;  # 添加另一个服务器，权重默认为1  
        server backend3.example.com down;  # 将此服务器标记为down，不参与负载均衡  
        server backup1.example.com backup;  # 将此服务器作为备份服务器  
    }  
  
    server {  
        listen 80;  # 监听80端口  
  
        location / {  # 匹配所有请求  
            proxy_pass http://myapp1;  # 将请求转发到myapp1服务器组  
            proxy_set_header Host $host;  # 设置请求头中的Host字段为原始请求的Host  
            proxy_set_header X-Real-IP $remote_addr;  # 设置请求头中的X-Real-IP字段为客户端的真实IP地址  
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  # 设置请求头中的X-Forwarded-For字段，以记录原始请求和代理链的IP地址  
            proxy_set_header X-Forwarded-Proto $scheme;  # 设置请求头中的X-Forwarded-Proto字段为原始请求的协议（http或https）  
        }  
    }  
}

上面的负载均衡策略是权重，除了权重之外，还有轮询以及 ip_hash 等。

轮询（Round Robin）

轮询是 Nginx 默认的负载均衡策略，它将客户端的请求按顺序轮流分配到后端服务器上。如果后端服务器宕机，Nginx 会自动将其剔除出队列，直到该服务器恢复正常。

举个栗子：

upstream backend {  
    server backend1.example.com;  
    server backend2.example.com;  
    server backend3.example.com;  
}  
  
server {  
    ...  
    location / {  
        proxy_pass http://backend;  
    }  
    ...  
}

在上面的配置中，Nginx 会将请求依次分配给 backend1、backend2 和 backend3，循环往复。

权重（Weight）

权重策略允许你为后端服务器分配不同的权重，权重越高的服务器将接收更多的请求。这可以根据服务器的硬件配置、处理能力等因素进行灵活配置。

这个就不举例了，3.1 小节的就是权重。

IP 哈希（IP Hash）

IP 哈希策略根据客户端的 IP 地址进行哈希运算，将相同的请求分配给同一个后端服务器。

这种策略适用于需要保持会话（Session）的场景，因为同一个客户端的请求会被发送到同一个服务器，从而避免了会话信息的丢失。

举个栗子：

upstream backend {  
    ip_hash;  
    server backend1.example.com;  
    server backend2.example.com;  
    server backend3.example.com;  
}  
  
server {  
    ...  
    location / {  
        proxy_pass http://backend;  
    }  
    ...  
}

在上面的配置中，Nginx 会根据客户端的 IP 地址进行哈希运算，然后将请求分配到对应的后端服务器。

最少连接（Least Connections）

最少连接策略将新的请求分配给当前连接数最少的后端服务器。这种策略可以确保每个后端服务器的负载相对均衡，避免某个服务器过载而其他服务器空闲的情况。

注意：Nginx 原生的 Stream 模块支持最少连接，但在 HTTP 模块中通常需要借助第三方插件或脚本实现。

对于 HTTP 模块，可以通过第三方插件如 ngx_http_upstream_fair_module 或编写 Lua 脚本来实现类似的功能。

但在 Stream 模块中，可以直接配置，下面是一个 Stream 中配置的例子：

upstream backend {  
    least_conn;  
    server backend1.example.com;  
    server backend2.example.com;  
    server backend3.example.com;  
}  
  
stream {  
    server {  
        listen 12345;  
        proxy_pass backend;  
    }  
}

3.2 动静分离

Nginx 可以将动态请求（如 Java API）和静态请求（如图片、CSS 和 JavaScript 文件）分离处理，提高网站性能。这也是我们目前在部署前后端分离项目时常见的方案之一。

动静分离可以根据请求后缀确定资源类别（动态资源还是静态资源），也可以通过请求的 URL 去确定资源类别，下面松哥给的案例是通过请求 URL 后缀来确定资源类别。

举个栗子：

server {  
    listen 80;  
    server_name example.com;  
  
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {  
        root /data/static;  
        expires 30d; # 缓存静态文件30天  
    }  
  
    location / {  
        proxy_pass http://javaboy.org; # 假设后端应用服务器  
        proxy_set_header Host $host;  
        proxy_set_header X-Real-IP $remote_addr;  
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  
    }  
}

3.3 反向代理

Nginx 可以作为反向代理服务器，将客户端请求转发到后端服务器。

这个配置其实有点类似于负载均衡。

举个栗子：

server {  
    listen 80;  
    server_name example.com;  
  
    location / {  
        proxy_pass http://localhost:8080; # 转发请求到本地的8080端口  
        proxy_set_header Host $host;  
        proxy_set_header X-Real-IP $remote_addr;  
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  
    }  
}

3.4 限流

Nginx 可以通过限制请求频率来防止服务器过载。

Nginx 官方版本限制 IP 的连接和并发分别有两个模块：

• limit_req_zone：用来限制单位时间内的请求数，即速率限制,采用的漏桶算法 "leaky bucket"。
• limit_req_conn 用来限制同一时间连接数，即并发限制。

举个栗子：

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;

    server {
        listen 80;

        location / {
            limit_req zone=mylimit burst=5 nodelay;;
            proxy_pass http://javaboy.org;
        }
    }
}

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;

• 第一个参数：$binary_remote_addr 表示通过 remote_addr 这个标识来做限制，“binary_” 的目的是缩写内存占用量，是限制同一客户端 ip 地址。
• 第二个参数：zone=mylimit:10m 表示生成一个大小为 10M，名字为 mylimit 的内存区域，用来存储访问的频次信息。
• 第三个参数：rate=1r/s 表示允许相同标识的客户端的访问频次，这里限制的是每秒 1 次，还可以有比如 30r/m 的。

limit_req zone=mylimit burst=5 nodelay;

• 第一个参数：zone=one 设置使用哪个配置区域来做限制，与上面 limit_req_zone 里的 name 对应。
• 第二个参数：burst=5，重点说明一下这个配置，burst 爆发的意思，这个配置的意思是设置一个大小为 5 的缓冲区，当有大量请求（爆发）过来时，超过了访问频次限制的请求可以先放到这个缓冲区内。
• 第三个参数：nodelay，如果设置，超过访问频次而且缓冲区也满了的时候就会直接返回 503，如果没有设置，则所有请求会等待排队。

3.5 缓存

Nginx 可以缓存静态内容，减少后端服务器的负载。

举个栗子：

http {  
    proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;  
    # 定义缓存路径、目录结构、缓存区名称和大小、最大缓存大小、非活动数据清理时间，以及是否使用临时路径  
  
    server {  
        listen 80;  
  
        location / {  
            proxy_pass http://backend;  # 转发请求到后端服务器  
            proxy_cache my_cache;  # 启用名为my_cache的缓存  
            proxy_cache_valid 200 302 10m;  # 对HTTP 200和302响应缓存10分钟  
            proxy_cache_valid 404      1m;  # 对HTTP 404响应缓存1分钟  
            proxy_cache_methods GET HEAD;  # 对哪些方法进行缓存
            # 其他可能的配置，如缓存清理策略、缓存键计算等  
        }  
    }  
}

缓存这块松哥稍微解释下：

• /data/nginx/cache 定义缓存文件存放位置；
• levels=1:2 表示定义缓存路径的目录层级，默认所有缓存文件都放在上面指定的根路径中，最多三级，每层目录长度为 1 或 2 字节；
• keys_zone=my_cache:10m 表示共享内存名称，用于在共享内存中定义一块存储区域来存放缓存的 key 和 metadata（类似于使用次数），这样 nginx 可以快速判断一个 request 是否命中缓存。由 proxy_cache 指令使用；10M 表示共享内存大小，1M 大约可以存放 8000 个 key；
• max_size=10g 表示设置缓存大小的上限。它是可选的，不指定值则表示允许缓存增长以使用所有可用磁盘空间。当缓存大小达到限制时，缓存管理器进程将依据 LRU 进行删除；
• inactive=60m 表示在 inactive 时间内没有被访问的缓存会被淘汰掉，默认是 10 分钟；
• use_temp_path=off 为 off 表示 nginx 会将缓存文件直接写入指定的 cache 文件中，而不使用 temp_path 指定的临时存储路径。

3.6 SSL 加速

Nginx 可以处理 SSL/TLS 握手，减轻后端服务器的负担。

举个栗子：

server {  
    listen 443 ssl;  # 监听443端口，并启用SSL  
    server_name example.com;  # 设置服务器名称  
  
    ssl_certificate /path/to/your/fullchain.pem;  # SSL证书文件路径  
    ssl_certificate_key /path/to/your/privatekey.pem;  # SSL私钥文件路径  
  
    ssl_session_timeout 1d;  # SSL会话超时时间  
    ssl_session_cache shared:MozSSL:10m;  # SSL会话缓存设置  
    ssl_session_tickets off;  # 禁用SSL会话票证  
  
    ssl_protocols TLSv1.2 TLSv1.3;  # 启用的SSL/TLS协议版本  
    ssl_prefer_server_ciphers on;  # 偏好使用服务器端的密码套件配置  
  
    ssl_ciphers '...';  # 使用的密码套件列表，这里省略了具体值  
  
    location / {  
        # 这里可以配置如何处理HTTP请求，但通常对于HTTPS，主要配置在server块级别  
    }  
}

3.7 +WebSocket

Nginx 支持 WebSocket 协议，可以用于实时通信。

举个栗子：

server {  
    listen 80;  # 监听80端口（注意：WebSocket通常使用443端口并启用SSL，但这里为了示例保持简单）  
  
    location /ws {  # 匹配以/ws开头的请求  
        proxy_pass http://websocket_backend;  # 转发请求到WebSocket后端服务器  
        proxy_http_version 1.1;  # 代理时使用的HTTP版本  
        proxy_set_header Upgrade $http_upgrade;  # 传递Upgrade头部以支持WebSocket  
        proxy_set_header Connection "upgrade";  # 设置Connection头部为upgrade以支持WebSocket  
        proxy_set_header Host $host;  # 传递Host头部  
  
        # 其他可能的配置，如处理WebSocket特有的超时、缓冲等  
    }  
}

3.8 API 网关

Nginx 亦可以用作 API 网关，配置如下：

http {  
    # 定义一个或多个upstream块，用于配置后端服务器组  
    upstream backend_servers {  
        server backend1.example.com;  
        server backend2.example.com;  
    }  
  
    server {  
        listen 80; # 监听80端口  
        server_name api.example.com; # 设置你的API网关域名  
  
        # 配置SSL（如果需要HTTPS）  
        # ssl_certificate /path/to/cert.pem;  
        # ssl_certificate_key /path/to/cert.key;  
  
        # 定义不同的location块，用于匹配不同的API路径  
        location /api/v1/video/ {  
            proxy_pass http://video_service; # 假设你有一个视频服务的upstream  
            proxy_http_version 1.1;  
            proxy_set_header Host $host;  
            proxy_set_header X-Real-IP $remote_addr;  
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  
        }  
  
        location /api/v1/homework/ {  
            proxy_pass http://homework_service; # 假设你有一个作业服务的upstream  
            # 其他代理设置...  
        }  
  
        # 可以继续添加其他location块以匹配更多API路径  
  
        # 其他server块配置...  
    }  
  
    # 其他http块配置...  
  
    # 定义其他upstream块，如video_service、homework_service等  
    upstream video_service {  
        server video1.example.com:8080;  
        server video2.example.com:8080;  
    }  
  
    upstream homework_service {  
        server homework1.example.com:8080;  
        server homework2.example.com:8080;  
    }  
  
    # ... 其他upstream定义  
}

3.9 TCP/UDP 负载均衡

这个需要在 Nginx 配置文件中新增 stream 块（如果不存在的话）stream 块类似于 http 块，然后添加如下配置：

stream {  
    upstream tcp_backend {  
        server 192.168.1.10:3306 weight=5;  
        server 192.168.1.11:3306;  
    }  

    upstream udp_backend {  
        server 192.168.1.12:53 udp;  
        server 192.168.1.13:53 udp;  
    }  

    server {  
        listen 3306;  
        proxy_pass tcp_backend;  
    }  

    server {  
        listen 53 udp;  
        proxy_pass udp_backend;  
    }  
}

• 在 upstream 块中定义后端服务器组，可以指定服务器的 IP 地址、端口号以及权重（weight）。
• 在 server 块中，通过 listen 指令指定 Nginx 监听的端口和协议（TCP 为默认，UDP 需要显式指定），并通过 proxy_pass 指令将请求转发到相应的后端服务器组。

四 其他配置

4.1 全局配置

Nginx 的全局配置包含了影响 Nginx 服务器整体行为的指令，这些指令主要位于全局块中。全局块通常位于 events 和 http 块之外，它包含了对 Nginx 服务器运行所需的基本配置，如用户和用户组、进程数、工作目录、错误日志级别、PID 文件路径等。

常用的 Nginx 全局配置的主要指令包括：

• user：指定 Nginx 工作进程运行的用户和用户组。
• worker_processes：设置工作进程的数量，可以设置为 auto 自动匹配 CPU 核心数，或者指定具体数值。
• error_log：配置错误日志的路径和日志级别。
• pid：指定 Nginx 主进程 ID 文件的存放位置。

松哥举个简单例子：

# 全局配置  
user nginx nginx;  # 指定运行Nginx的用户和用户组为nginx  
worker_processes auto;  # 自动设置工作进程数量，等于CPU核心数  
  
# 错误日志配置  
error_log /var/log/nginx/error.log warn;  # 设置错误日志的路径和级别为warn  
  
# PID文件配置  
pid /var/run/nginx.pid;  # 设置PID文件的存放位置  

4.2 events 块

events 块用于设置服务器与客户端连接的相关属性配置。这些配置主要涉及网络连接和事件处理。

松哥这里也举几个常用的例子。

worker_connections

设置每个工作进程的最大客户端连接数。这个指令通常与 worker_processes 指令结合使用，来计算整个 Nginx 服务器的最大并发连接数。

举个栗子

events {
    worker_connections 1024;
}

use

指定使用哪种事件模型。Nginx 支持多种事件模型，如 epoll（Linux）、kqueue（BSD）、select 和 poll 等。通常，Nginx 会根据操作系统自动选择最佳的事件模型，但也可以手动指定。

举个栗子

events {
    use epoll;
}

multi_accept

设置是否允许服务器在单个监听事件中接受多个连接。这可以减少 I/O 等待时间，提高性能。

举个栗子

events {
    multi_accept on;
}

accept_mutex

在某些情况下，可以设置为 on 来允许多个工作进程同时监听相同的端口。默认情况下，它是关闭的，以避免多个进程间的端口竞争。

举个栗子

events {
    accept_mutex on;
}

accept_mutex_delay

当 accept_mutex 被启用时，这个指令可以设置尝试获取互斥锁的延迟时间。

举个栗子

events {
    accept_mutex_delay 10ms;
}

五 总结

Nginx 是一个多功能、高性能的 Web 服务器和反向代理，适用于各种网络应用场景。它的模块化设计、简单的配置和高效的性能使其成为构建现代网络基础设施的理想选择。通过上述配置示例，我们可以看到 Nginx 在实际应用中的灵活性和强大功能。