Nginx攻略

水煮白菜王2025-06-12 18:58

🤖 作者简介：水煮白菜王，一位前端劝退师 👻

👀 文章专栏： 前端专栏 ，记录一下平时在博客写作中，总结出的一些开发技巧和知识归纳总结✍。

感谢支持💕💕💕

目录

单体节点部署

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

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

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

Nginx反向代理-负载均衡

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

1.示例

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

java 复制代码 
@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 复制代码 
<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配置（负载均衡）

javascript 复制代码 
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发起请求：
192.168.0.000 请求分发 web服务:8080 web服务:8090 192.168.12.129 80端口 location /
proxy_pass http://nginx_boot; upstream nginx_boot {
server 192.168.0.000:8080;
server 192.168.0.000:8090;
} 192.168.12.129 192.168.12.129:80 192.168.12.129:80

● 由于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 安装目录下创建一个专门存放静态资源的目录：

bash 复制代码 
mkdir /soft/nginx/static_resources

将项目中所有的静态资源（如 HTML、JS、CSS、图片等）拷贝到该目录下，并从项目中移除这些文件重新打包部署。

编辑 nginx.conf 文件，在 server 块中添加如下配置：

javascript 复制代码 
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 的内置模块，意味着可以直接使用该模块下的相关压缩指令来配置资源压缩功能。

javascript 复制代码 
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配置如下：

javascript 复制代码 
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

javascript 复制代码 
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）

javascript 复制代码 
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 模块

javascript 复制代码 
# 假设你的 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 相关配置：

javascript 复制代码 
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 日志文件。

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

javascript 复制代码 
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 添加到日志格式中进行记录：

javascript 复制代码 
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
javascript 复制代码 
location / {
    if ($arg_id = "") {
        return 404;
    }
    proxy_cache hot_cache;
    proxy_cache_valid 200 1d;
    proxy_cache_valid 404 1m;  # 对于不存在的数据缓存 1 分钟
}
2.缓存雪崩

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

解决方案：

  • 随机化过期时间：为每个缓存项设置不同的过期时间，避免同时失效。
  • 多级缓存：除了 Nginx 缓存外，还可以增加应用层缓存或客户端缓存。
javascript 复制代码 
proxy_cache_valid 200 1d random=$rnd(60m);  # 随机过期时间
3. 缓存击穿

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

解决方案：

  • 加锁机制：保证只有一个请求去数据库取数据，其他请求等待缓存更新完成后再读取缓存。
  • 提前续期：在缓存即将过期前，提前刷新缓存。
javascript 复制代码 
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配置项来实现：

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

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

javascript 复制代码 
# -------- 黑名单：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中导入，以达到灵活控制的目的：

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

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

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

Nginx跨域配置

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

javascript 复制代码 
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 支持的参数说明：

javascript 复制代码 
valid_referers none | blocked | server_names | string ...;
  • none：表示接受没有 Referer 字段的请求；
  • blocked：表示允许 Referer 被防火墙或代理屏蔽的情况（即非标准协议请求）；
  • server_names：指定允许访问的域名列表，作为白名单；
  • string：可以是字符串、通配符或正则表达式，用于自定义允许的 Referer 地址。
javascript 复制代码 
# 在动静分离的 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

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

javascript 复制代码 
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;
        }
    }
}

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

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

相关推荐
崔庆才丨静觅3 小时前
hCaptcha 验证码图像识别 API 对接教程
前端
passerby60614 小时前
完成前端时间处理的另一块版图
前端·github·web components
掘了4 小时前
「2025 年终总结」在所有失去的人中，我最怀念我自己
前端·后端·年终总结
崔庆才丨静觅4 小时前
实用免费的 Short URL 短链接 API 对接说明
前端
崔庆才丨静觅4 小时前
5分钟快速搭建 AI 平台并用它赚钱！
前端
崔庆才丨静觅5 小时前
比官方便宜一半以上！Midjourney API 申请及使用
前端
Moment5 小时前
富文本编辑器在 AI 时代为什么这么受欢迎
前端·javascript·后端
崔庆才丨静觅5 小时前
刷屏全网的“nano-banana”API接入指南！0.1元/张量产高清创意图，开发者必藏
前端
剪刀石头布啊5 小时前
jwt介绍
前端
爱敲代码的小鱼5 小时前
AJAX（异步交互的技术来实现从服务端中获取数据）：
前端·javascript·ajax
热门推荐
01GitHub 镜像站点02Claude Code + GLM4.7 避坑指南：解决 Unable to connect to Anthropic services03openclaw配置教程（linux+局域网ollama）04UV安装并设置国内源05OpenClaw Chrome扩展使用教程 - 浏览器中继控制06Linux下V2Ray安装配置指南07Claude Code Skills 实用使用手册08Vue-skills的中文文档09一文了解国产算子编程语言 TileLang，TileLang 对国产开源生态的影响与启示10让 Trae IDE 智能体 “读懂”文档 Excel+PDF+DOCX ：mcp-documents-reader 工具使用指南