Nginx攻略-EW帮帮网

在这里插入图片描述

🤖 作者简介：水煮白菜王，一位前端劝退师 👻
👀 文章专栏：前端专栏，记录一下平时在博客写作中，总结出的一些开发技巧和知识归纳总结✍。
感谢支持💕💕💕

单体节点部署

在传统的单体架构中，Nginx 通常以单一节点的形式运行，作为 Web 服务器或反向代理服务器。这种部署方式简单易用，适合小型项目或开发测试环境。

类型	描述
✅ 优点	- 部署简单，配置方便 - 成本低，资源占用少 - 维护成本较低
❌ 缺点	- 无法承载高并发流量：随着业务的发展和用户量的增长，单体结构难以应对日益增长的访问压力，容易成为性能瓶颈 - 存在单点故障风险：一旦后端服务节点宕机或 Nginx 本身出现异常，整个系统将无法对外提供服务，导致业务中断

因此，在生产环境中，建议采用更加高可用、可扩展的部署方案，如负载均衡集群。

Nginx反向代理-负载均衡

为提升系统的可用性和处理能力，可以使用 Nginx 搭配多个后端应用服务器，实现反向代理 + 负载均衡的架构设计。

1.示例

通过一个简单的 Spring Boot 应用来展示不同实例的响应结果。

@Controller
public class IndexNginxController {

    @Value("${server.port}")
    private String port;

    @RequestMapping("/")
    public ModelAndView index() {
        ModelAndView model = new ModelAndView();
        model.addObject("port", port);
        model.setViewName("index");
        return model;
    }
}

在该Controller类中，存在一个成员变量：port，它的值即是从application.properties配置文件中获取server.port值。当出现访问/资源的请求时，跳转前端index页面，并将该值携带返回。

前端模板 index.ftl 展示当前请求被分发到的服务端口，前端的index.ftl文件代码如下：

<html>  
  <head>  
    <title>Nginx Page</title>  
    <link href="nginx_style.css" rel="stylesheet" type="text/css"/>  
  </head>  
  <body>  
    <div style="border: 2px solid red;margin: auto;width: 800px;text-align: center">  
      <div  id="nginx_title">  
        <h1>欢迎来到 ${port}页面！</h1>  
      </div>  
    </div>  
  </body>  
</html>

2.Nginx conf配置（负载均衡）

upstream nginx_boot{  
  # 30s内检查心跳发送两次包，未回复就代表该机器宕机，请求分发权重比为1:2  
  server 192.168.0.000:8080 weight=100 max_fails=2 fail_timeout=30s;   
  server 192.168.0.000:8090 weight=200 max_fails=2 fail_timeout=30s;  
  # 这里的IP请配置成你WEB服务所在的机器IP  
}  

server {  
  location / {  
    root   html;  
    # 配置一下index的地址，最后加上index.ftl。
    index  index.html index.htm index.jsp index.ftl;  
    proxy_set_header Host $host;  
    proxy_set_header X-Real-IP $remote_addr;  
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  
    # 请求交给名为nginx_boot的upstream上  
    proxy_pass http://nginx_boot;  
  }  
}

3.Nginx请求分发原理：

客户端发出的请求192.168.12.129最终会转变为：http://192.168.12.129:80/，然后再向目标IP发起请求：

● 由于Nginx监听了192.168.12.129的80端口，所以最终该请求会找到Nginx进程；
● Nginx首先会根据配置的location规则进行匹配，根据客户端的请求路径/，会定位到location /{}规则；
● 然后根据该location中配置的proxy_pass会再找到名为nginx_boot的upstream；
● 最后根据upstream中的配置信息，将请求转发到运行WEB服务的机器处理，由于配置了多个WEB服务，且配置了权重值，因此Nginx会依次根据权重比分发请求。

Nginx 通过 upstream 模块定义一组后端服务器，并根据配置的负载均衡算法（如轮询、加权轮询、IP哈希等）将客户端请求合理地分发到不同的后端节点上。

常见的分发策略包括：

轮询（默认）：依次将请求分发给每个节点；
加权轮询（weight）：根据节点的配置权重分配请求比例；
IP哈希（ip_hash）：保证来自同一 IP 的请求始终转发到同一个后端节点；
最少连接数（least_conn）：将请求分配给当前连接数最少的节点。

Nginx动静分离

在讨论网站性能优化时，“动静分离”是一个常见的话题。那么，为什么我们需要实施动静分离？它具体带来了哪些好处呢？

1.什么是动静分离？

实际上，一旦理解了网站运行的本质，动静分离的重要性就不言而喻了。简而言之，动静分离是指将静态资源（如 HTML、CSS、JavaScript 文件和图片等）与动态内容（由服务器端脚本生成的内容）分开处理。这样做不仅可以显著提高页面加载速度，还能减轻服务器负担，从而提升用户体验。

通过合理配置 Nginx 实现动静分离，可以使得静态资源直接从 Nginx 服务器快速响应给客户端，而动态请求则转发至后端应用服务器进行处理。这种架构不仅提高了资源的利用效率，还增强了系统的可扩展性和稳定性。

2.一个真实场景：访问淘宝首页

在这里插入图片描述
以访问 www.taobao.com 首页为例，打开浏览器开发者工具可以看到，首页加载时会出现 200+ 的请求。其中至少有 100+ 是静态资源请求（如 .js、.css、.html、.jpg 等）。

在常规项目开发中，这些静态资源通常存放在后端项目的 resources/static/ 目录下，并随着应用打包部署到后端服务中。

但如果淘宝也采用这种方式部署，那意味着：

每个用户访问首页，都会对后端服务器发起上百次请求！

这无疑会给后端服务器带来极大的并发压力。

3.动静分离的核心

既然这些静态资源很少变动，为什么不提前处理掉呢？答案是肯定的 —— 我们完全可以在 Nginx 层就拦截这些请求，直接返回资源，避免请求穿透到后端。

✅ 做了动静分离之后，后端服务器的并发请求数可以减少一半以上！

这就是动静分离所带来的巨大性能收益。

4.Nginx操作

在 Nginx 安装目录下创建一个专门存放静态资源的目录：

mkdir /soft/nginx/static_resources

将项目中所有的静态资源（如 HTML、JS、CSS、图片等）拷贝到该目录下，并从项目中移除这些文件重新打包部署。
编辑 nginx.conf 文件，在 server 块中添加如下配置：

location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)$ {
    root   /soft/nginx/static_resources;
    expires 7d;  # 设置缓存时间为7天，提升加载效率
}

🔍 配置说明：

~：表示正则匹配，且区分大小写；
.*：匹配任意字符多次；
.：转义点号，用于匹配文件后缀；
(html|…|css)：匹配括号内列出的所有静态资源类型；
root：指定静态资源根目录；
expires 7d：设置浏览器缓存时间，减少重复请求。

优势	描述
提升加载速度	静态资源由 Nginx 快速响应，无需等待后端处理
减少后端压力	后端只需处理真正的动态请求，降低并发量
提高系统稳定性	分层架构更健壮，便于维护和扩展

动静分离不仅是性能优化的一种手段，更是构建高性能 Web 架构的基础实践之一。结合 Nginx 强大的静态资源处理能力，能够有效支撑高并发、低延迟的业务需求。

Nginx资源压缩

建立在动静分离的基础之上，如果一个静态资源的Size越小，那么自然传输速度会更快，同时也会更节省带宽，因此我们在部署项目时，也可以通过Nginx对于静态资源实现压缩传输，一方面可以节省带宽资源，第二方面也可以加快响应速度并提升系统整体吞吐。

在Nginx也提供了三个支持资源压缩的模块：
ngx_http_gzip_module、ngx_http_gzip_static_module、ngx_http_gunzip_module，
其中，ngx_http_gzip_module 是 Nginx 的内置模块，意味着可以直接使用该模块下的相关压缩指令来配置资源压缩功能。

http {
    # 开启压缩机制
    gzip on;

    # 指定会被压缩的文件类型（也可根据需要自行扩展）
    gzip_types text/plain application/javascript text/css application/xml text/javascript image/jpeg image/gif image/png;

    # 设置压缩级别，数值越高压缩效果越好，但资源消耗也越大
    gzip_comp_level 5;

    # 在响应头部中添加 Vary: Accept-Encoding（建议开启）
    gzip_vary on;

    # 压缩请求处理的缓冲区数量和大小
    gzip_buffers 16 8k;

    # 对于不支持压缩的客户端请求，不启用压缩机制
    gzip_disable "MSIE [1-6]\."; # 禁用低版本 IE 浏览器的压缩支持

    # 设置压缩响应所支持的 HTTP 最低版本
    gzip_http_version 1.1;

    # 设置触发压缩的最小文件大小
    gzip_min_length 2k;

    # 关闭对后端服务器响应结果的压缩处理
    gzip_proxied off;
}

Nginx缓冲区

我们先来思考一个问题：接入 Nginx 的项目，其请求流程通常为：

客户端 → Nginx → 服务端

在这个过程中，存在两个独立的连接：

客户端 ←→ Nginx
Nginx ←→ 服务端

如果这两个连接之间的传输速度不一致，就可能影响用户体验（例如浏览器加载速度跟不上服务端响应速度）。

这种情况其实类似于计算机中 CPU 和内存之间的速度差异。为了缓解这种速率不匹配带来的性能瓶颈，CPU 设计中引入了“三级高速缓冲区”。同样地，Nginx 也提供了缓冲区机制，其核心目的就是：

解决前后端连接之间传输速度不匹配的问题。

有了缓冲机制后，Nginx 可以暂存后端服务器的响应数据，然后根据客户端的实际接收能力，按需输出数据给客户端，从而提升整体的访问体验。

常见的缓冲区相关配置项如下：

proxy_buffering：是否启用缓冲机制，默认为 on，即开启状态。
client_body_buffer_size：设置用于缓冲客户端请求体的内存大小。
proxy_buffers：为每个请求设置缓冲区的数量和大小，默认为 4 4k/8k。
proxy_buffer_size：设置用于存储后端响应头的缓冲区大小。
proxy_busy_buffers_size：当后端尚未完全返回数据时，Nginx 可将处于“busy”状态的缓冲区数据提前发送给客户端。该参数用于控制 busy 状态下可发送的数据大小，默认为 proxy_buffer_size * 2。
proxy_temp_path：当内存缓冲区已满时，可以将数据临时写入磁盘。此参数用于设置临时存储缓冲数据的目录路径。
proxy_temp_file_write_size：设置每次写入临时文件的数据大小限制。
proxy_max_temp_file_size：设置临时缓冲目录中允许存储的最大容量。
非缓冲相关参数：
- proxy_connect_timeout：设置与后端服务器建立连接的超时时间。
- proxy_read_timeout：设置从后端服务器读取响应的超时时间。
- proxy_send_timeout：设置向后端服务器发送请求数据的超时时间。

具体的nginx.conf配置如下：

http {
    proxy_connect_timeout 10;
    proxy_read_timeout 120;
    proxy_send_timeout 10;

    proxy_buffering on;
    client_body_buffer_size 512k;
    proxy_buffers 4 64k;
    proxy_buffer_size 16k;
    proxy_busy_buffers_size 128k;

    proxy_temp_file_write_size 128k;
    proxy_temp_path /soft/nginx/temp_buffer;
}

上述的缓冲区参数，是基于每个请求分配的空间，而并不是所有请求的共享空间。当然，具体的参数值还需要根据业务去决定，要综合考虑机器的内存以及每个请求的平均数据大小。

合理使用缓冲机制，还可以有效减少即时传输对带宽的瞬时占用，进一步提升系统稳定性与网络利用率。

Nginx缓存机制

在性能优化方案中，缓存是一种能够显著提升系统性能的有效手段。因此，在现代架构设计中几乎随处可见缓存的身影：客户端缓存、代理缓存、服务器缓存等。

而 Nginx 的缓存机制属于“代理缓存”，即位于客户端与后端服务器之间的中间层缓存。引入缓存机制对整个系统来说，具有以下几个显著优势：

减少了向后端或文件服务器重复请求资源所带来的带宽消耗；
降低了下游服务器的访问压力，从而提升系统的整体吞吐能力；
缩短了响应时间，加快了页面加载速度，用户体验更佳。

那么在 Nginx 中，我们又该如何配置代理缓存呢？首先来看一下与缓存相关的核心配置项。

✅ 核心缓存配置项：proxy_cache_path

proxy_cache_path path [levels=levels] [use_temp_path=on|off] keys_zone=name:size [inactive=time] [max_size=size] [manager_files=number] [manager_sleep=time] [manager_threshold=time] [loader_files=number] [loader_sleep=time] [loader_threshold=time] [purger=on|off] [purger_files=number] [purger_sleep=time] [purger_threshold=time];

每个参数项的含义：

path：缓存数据的存储路径；
levels：设置缓存目录的层级结构，最多支持三层（如 1:2 表示一级目录 + 二级目录）；
use_temp_path：是否使用临时路径进行缓存写入；
keys_zone：定义共享内存区域用于存储热点 Key（1MB 可存储约 8000 个 Key）；
inactive：设置缓存多长时间未被访问后自动清除，默认为 10 分钟；
max_size：允许缓存的最大磁盘空间，超出后按 LRU 算法清理，Nginx 会通过 Cache Manager 进程进行清理，也可以通过 purge 方式手动清除；
manager_files：每次 Cache Manager 清理缓存时的最大文件数量；
manager_sleep：Cache Manager 每次清理操作的最大执行时间；
manager_threshold：Cache Manager 每次清理完成后暂停的时间间隔；
loader_files：重启 Nginx 时，每次加载缓存的最大文件数，默认为 100；
loader_sleep：每次加载缓存时的最大允许时间，默认为 200ms；
loader_threshold：一次加载后暂停的时间间隔，默认为 50ms；
purger：是否开启基于 purge 的缓存删除机制；
purger_files：每次 purge 删除的最大缓存文件数；
purger_sleep：每次 purge 删除操作的最大执行时间；
purger_threshold：purge 删除完成后的暂停时间间隔。

常见缓存配置（nginx.conf）

http {
    # 设置缓存目录，并指定内存中的缓存区名为 hot_cache，大小为 128MB，
    # 3 天未被访问的缓存将被自动清除，磁盘最大缓存容量为 2GB。
    proxy_cache_path /soft/nginx/cache levels=1:2 keys_zone=hot_cache:128m inactive=3d max_size=2g;

    server {
        location / {
            # 使用名为 hot_cache 的缓存空间
            proxy_cache hot_cache;

            # 对于 200、206、304、301、302 状态码的数据缓存 1 天
            proxy_cache_valid 200 206 304 301 302 1d;

            # 其他状态码的缓存时间为 30 分钟
            proxy_cache_valid any 30m;

            # 定义缓存键规则（以 host + uri + args 作为 Key）
            proxy_cache_key $host$uri$is_args$args;

            # 资源至少被访问三次后才加入缓存
            proxy_cache_min_uses 3;

            # 当有多个相同请求时，只让一个去后端取数据，其余从缓存读取
            proxy_cache_lock on;

            # 锁等待超时时间为 3 秒，超过后其他请求直接去后端获取
            proxy_cache_lock_timeout 3s;

            # 若 cookie 或参数中声明不缓存，则跳过缓存
            proxy_no_cache $cookie_nocache $arg_nocache $arg_comment;

            # 在响应头中添加缓存命中状态，便于调试分析
            add_header Cache-Status $upstream_cache_status;
        }
    }
}

第一次访问时，由于缓存中尚未存在该资源，所以不会命中；第二次、第三次访问仍未命中；直到第四次访问时才会显示缓存命中。这是因为在配置中设置了 proxy_cache_min_uses 3，意味着资源必须被请求三次以上才会被加入缓存，从而避免无效缓存占用存储空间。

✅ 缓存清理

当缓存数据过多而不及时清理时，可能会导致磁盘空间被占满。因此我们需要一套完善的缓存清理机制。

在前面提到的 proxy_cache_path 配置中，已经包含了一些自动清理缓存的参数，例如 inactive 和 manager 相关选项。但需要注意的是：

❗ purger 系列参数仅在商业版 Nginx Plus 中可用，普通开源版本不支持。

不过可以借助强大的第三方模块 ngx_cache_purge 来实现缓存清理功能。

ngx_cache_purge 是一个第三方模块，它允许我们通过 HTTP 请求来清除指定的缓存。以下是安装和配置步骤：

1. 安装 ngx_cache_purge

首先确保已经下载了 Nginx ，并且准备好了 ngx_cache_purge 模块

# 假设你的 Nginx 源码位于 /usr/local/src/nginx-1.21.4
cd /usr/local/src/nginx-1.21.4

# 下载 ngx_cache_purge 模块
git clone https://github.com/FRiCKLE/ngx_cache_purge.git

# 重新编译 Nginx 并添加 ngx_cache_purge 模块
./configure --add-module=/path/to/ngx_cache_purge
make
make install

2. 配置 ngx_cache_purge

在 nginx.conf 中添加 purge 相关配置：

http {
    # 配置缓存路径
    proxy_cache_path /soft/nginx/cache levels=1:2 keys_zone=hot_cache:128m inactive=3d max_size=2g;

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend;
            proxy_cache hot_cache;
            proxy_cache_valid 200 1d;
        }

        # 配置 purge 功能
        location ~ /purge(/.*) {
            allow 127.0.0.1;  # 允许本地 IP 进行清除操作
            deny all;         # 拒绝其他所有 IP 的清除请求
            proxy_cache_purge hot_cache $host$1$is_args$args;
        }
    }
}

现在，你可以通过访问 http://example.com/purge/some/path 来清除特定 URL 的缓存。

缓存命中率如何监控？

为了监控缓存命中率，可以在响应头中添加 X-Cache-Status 或者直接查看 Nginx 日志文件。

在响应头中添加缓存状态信息：

location / {
    proxy_cache hot_cache;
    add_header X-Cache-Status $upstream_cache_status;
}

$upstream_cache_status 可能返回以下几种状态：

MISS：未命中缓存，从后端服务器获取数据。
HIT：命中缓存，直接返回缓存数据。
EXPIRED：缓存已过期，需要重新获取数据。
UPDATING：正在更新缓存。
STALE：返回过期缓存（仅当启用 stale 数据时）

使用日志分析工具：

可以将 $upstream_cache_status 添加到日志格式中进行记录：

log_format cache '$remote_addr - $remote_user [$time_local] "$request" '
                 '$status $body_bytes_sent "$http_referer" '
                 '"$http_user_agent" "$http_x_forwarded_for" '
                 'Cache-Status:$upstream_cache_status';

access_log /var/log/nginx/access.log cache;

然后使用日志分析工具（如 GoAccess、ELK Stack 等）分析命中率。

缓存穿透、缓存雪崩、缓存击穿的解决方案

1.缓存穿透

定义：指查询一个不存在的数据，由于缓存中没有该数据，导致每次都要去数据库查询，增加了数据库的压力。

解决方案：

布隆过滤器：用于过滤掉那些不可能存在的数据，减少对数据库的无效查询。
缓存空结果：对于查询不到的数据，也可以设置短暂的缓存时间（如 5 分钟），避免频繁查询。
nginx

location / {
    if ($arg_id = "") {
        return 404;
    }
    proxy_cache hot_cache;
    proxy_cache_valid 200 1d;
    proxy_cache_valid 404 1m;  # 对于不存在的数据缓存 1 分钟
}

2.缓存雪崩

定义：指大量缓存在同一时间段内失效，导致大量请求直接打到数据库，造成系统崩溃。

解决方案：

随机化过期时间：为每个缓存项设置不同的过期时间，避免同时失效。
多级缓存：除了 Nginx 缓存外，还可以增加应用层缓存或客户端缓存。

proxy_cache_valid 200 1d random=$rnd(60m);  # 随机过期时间

3. 缓存击穿

定义：某个热点数据在缓存中过期，但短时间内有大量请求到达，导致这些请求都打到了数据库。

解决方案：

加锁机制：保证只有一个请求去数据库取数据，其他请求等待缓存更新完成后再读取缓存。
提前续期：在缓存即将过期前，提前刷新缓存。

proxy_cache_lock on;  # 开启锁机制
proxy_cache_lock_timeout 3s;  # 锁超时时间为 3 秒

完整的缓存调优建议值表格

参数	描述	推荐值	备注
`proxy_cache_path`	设置缓存目录及参数	`/data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m`	根据实际需求调整大小
`proxy_cache_min_uses`	资源至少被访问几次后才加入缓存	`3`	减少无效缓存占用空间
`proxy_cache_valid`	设置不同状态码的缓存时间	`200 1d`, `404 1m`	根据业务需求调整
`proxy_cache_key`	定义缓存键规则	`$scheme$proxy_host$request_uri`	确保唯一性
`proxy_cache_lock`	开启锁机制防止缓存击穿	`on`	提高并发性能
`proxy_cache_lock_timeout`	锁等待超时时间	`3s`	根据实际情况调整
`proxy_no_cache`	不缓存特定条件下的请求	`$cookie_nocache $arg_nocache`	根据具体场景定制

通过以上优化措施，可以有效提升系统的缓存效率，减少不必要的数据库查询，降低服务器负载，从而提高整体性能和用户体验。

Nginx实现IP黑白名单

有时候往往有些需求，可能某些接口只能开放给对应的合作商，或者购买/接入API的合作伙伴，那么此时就需要实现类似于IP白名单的功能。而有时候有些恶意攻击者或爬虫程序，被识别后需要禁止其再次访问网站，因此也需要实现IP黑名单。那么这些功能无需交由后端实现，可直接在Nginx中处理。
Nginx做黑白名单机制，主要是通过allow、deny配置项来实现：

allow xxx.xxx.xxx.xxx; # 允许指定的IP访问，可以用于实现白名单。  
deny xxx.xxx.xxx.xxx; # 禁止指定的IP访问，可以用于实现黑名单。

当需要配置多个 IP 地址时，如果将所有规则都直接写在 nginx.conf 中，会导致配置文件臃肿冗余。因此建议采用外部配置文件的方式进行管理。新建两个文件BlocksIP.conf、WhiteIP.conf：

# -------- 黑名单：BlocksIP.conf ---------
deny 192.177.12.222;        # 屏蔽 192.177.12.222 的访问
deny 192.177.44.201;        # 屏蔽 192.177.44.201 的访问
deny 127.0.0.0/8;           # 屏蔽 127.0.0.1 到 127.255.255.254 的网段访问
  
# -------- 白名单：WhiteIP.conf ---------
allow 192.177.12.222;       # 允许 192.177.12.222 访问
allow 192.177.44.201;       # 允许 192.177.44.201 访问
allow 127.45.0.0/16;        # 允许 127.45.0.1 到 127.45.255.254 的网段访问
deny all;                   # 除上述 IP 外，其他 IP 均禁止访问

可以将配置文件在nginx.conf中导入，以达到灵活控制的目的：

http {
    # 全局屏蔽黑名单中的 IP
    include /soft/nginx/IP/BlocksIP.conf;

    server {
        location /api/some_route {
            # 只允许白名单中的 IP 访问该接口
            include /soft/nginx/IP/WhiteIP.conf;
        }
    }
}

这种方式可以非常方便地维护大量 IP 规则，并且提高了可读性和可维护性。

Nginx跨域配置

在前后端分离架构中，前端应用和后端服务通常部署在不同的域名下，这就可能导致浏览器出现跨域请求限制（CORS）。为了避免这一问题，我们可以在 Nginx 层面配置响应头，直接支持跨域请求，而无需交由后端处理

location / {
    # 允许跨域请求的源，可以使用变量 $http_origin 指定具体域名，* 表示允许所有
    add_header 'Access-Control-Allow-Origin' *;

    # 允许携带 Cookie 发起跨域请求
    add_header 'Access-Control-Allow-Credentials' 'true';

    # 允许的跨域请求方法：GET、POST、OPTIONS、PUT 等
    add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT';

    # 允许请求中携带的头部信息，* 表示允许所有头部
    add_header 'Access-Control-Allow-Headers' *;

    # 允许客户端访问的响应头（如分段请求相关字段）
    add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';

    # 必须配置！否则 POST 请求无法完成跨域
    # 浏览器在发送 POST 跨域请求前会先发送 OPTIONS 预检请求，服务器接受后才会正式发起请求
    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Content-Type' 'text/plain; charset=utf-8';
        add_header 'Content-Length' 0;

        # 对于 OPTIONS 请求返回 204 No Content，表示接受跨域请求
        return 204;
    }
}

配置项	作用说明
`Access-Control-Allow-Origin`	指定允许访问的源（域名），建议不要使用 `*`，应指定具体域名以提高安全性
`Access-Control-Allow-Credentials`	是否允许发送 Cookie，设置为 `true` 时前端需配合设置 `withCredentials: true`
`Access-Control-Allow-Methods`	允许的 HTTP 方法，根据实际接口需求调整，如 `GET, POST, OPTIONS` 等
`Access-Control-Allow-Headers`	允许的请求头字段，例如 `Authorization`, `Content-Type` 等
`Access-Control-Expose-Headers`	客户端可访问的响应头字段，如 `Content-Length`, `Content-Range` 等
`OPTIONS` 处理块	对于预检请求必须返回 `204`，才能继续进行正式请求

Nginx防盗链设计

“盗链”指的是外部网站直接引用当前网站上的资源（如图片、视频、CSS、JS 文件等）进行展示或下载的行为。

举个例子：壁纸网站 X 拥有大量正版授权素材，而网站 Y 没有购买这些资源，却通过类似的方式，直接调用 X 站的图片资源并展示给用户。这不仅消耗了 X 站的带宽资源，也侵犯了其版权利益。

为了避免这种行为，我们可以借助 Nginx 的防盗链机制，对请求来源进行限制。

Nginx 的防盗链机制依赖于 HTTP 请求头中的 Referer 字段。该字段用于标识当前请求是从哪个页面发起的。可以在 Nginx 中使用 valid_referers 指令来定义哪些 Referer 是合法的，然后通过 $invalid_referer 变量判断是否为非法请求。如果是非法请求，则返回 403 或重定向到提示图片。

✅ valid_referers 支持的参数说明：

valid_referers none | blocked | server_names | string ...;

none：表示接受没有 Referer 字段的请求；
blocked：表示允许 Referer 被防火墙或代理屏蔽的情况（即非标准协议请求）；
server_names：指定允许访问的域名列表，作为白名单；
string：可以是字符串、通配符或正则表达式，用于自定义允许的 Referer 地址。

# 在动静分离的 location 中开启防盗链机制
location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css) {
    # 最后面的值在上线前可配置为允许的域名地址
    valid_referers blocked 192.168.12.129;

    if ($invalid_referer) {
        # 可以配置成返回一张禁止盗取的图片
        # rewrite ^/ http://xx.xx.com/NO.jpg;

        # 也可直接返回 403 禁止访问
        return 403;
    }

    root /soft/nginx/static_resources;
    expires 7d;
}

Nginx大文件传输配置

在某些业务场景中（如文件上传、资源下载等），需要通过 Nginx 传输大文件。然而，在默认配置下，Nginx 对请求体大小、连接超时时间等都有一定限制，可能导致一些 “请求体过大”、“请求超时”、“连接被中断” 等问题。
为了解决这些问题，我们可以在 Nginx 中进行一些针对性的配置调整。其中，以下几个参数在传输大文件时尤为重要：
client_max_body_size、client_header_timeout、proxy_read_timeout、proxy_send_timeout
这四个参数值都可以根据自己项目的实际情况来配置。

配置项	作用说明
`client_max_body_size`	设置请求体允许的最大体积，默认为 1MB，建议根据实际需求调大（如 100M）
`client_header_timeout`	等待客户端发送一个请求头的超时时间，默认为 60s
`client_body_timeout`	设置读取请求体的超时时间，默认为 60s
`proxy_read_timeout`	设置请求被后端服务器读取时，Nginx等待的最长时间，默认为 60s
`proxy_send_timeout`	设置后端向Nginx返回响应时的超时时间，默认为 60s

⚠️ 注意：这些参数应根据实际业务场景中的文件大小、网络带宽、传输速度等因素进行合理设置，避免因配置不当引发性能浪费或服务异常。

http {
    client_max_body_size 100M;
    client_header_timeout 300s;
    client_body_timeout 300s;

    server {
        listen 80;

        location /upload/ {
            proxy_pass http://backend_server;
            proxy_read_timeout 300s;
            proxy_send_timeout 300s;
        }
    }
}

通过以上配置，可以有效支持大文件的稳定传输，减少因超时或大小限制导致的传输失败问题，提升系统的兼容性和稳定性。

如果你觉得这篇文章对你有帮助，请点赞 👍、收藏 👏 并关注我！👀

在这里插入图片描述

Nginx攻略

目录

单体节点部署

Nginx反向代理-负载均衡

1.示例

2.Nginx conf配置（负载均衡）

3.Nginx请求分发原理：

Nginx动静分离

1.什么是动静分离？

2.一个真实场景：访问淘宝首页

3.动静分离的核心

4.Nginx操作

Nginx资源压缩

Nginx缓冲区

Nginx缓存机制

✅ 缓存清理

1. 安装 ngx_cache_purge

2. 配置 ngx_cache_purge

缓存命中率如何监控？

使用日志分析工具：

缓存穿透、缓存雪崩、缓存击穿的解决方案

1.缓存穿透

2.缓存雪崩

3. 缓存击穿

Nginx实现IP黑白名单

Nginx跨域配置

Nginx防盗链设计

Nginx大文件传输配置

如果你觉得这篇文章对你有帮助，请点赞 👍、收藏 👏 并关注我！👀

网站公告

今日签到

热门文章

最新发布