Nginx 不原生支持请求合并与去重，但可通过 proxy_cache + proxy_cache_lock 实现逻辑等效的去重：首个请求透传后端并缓存，其余并发请求等待并复用缓存响应。
Nginx 本身不原生支持“请求合并”与“去重”（如将多个相同 GET 请求聚合成一次后端调用），这类功能超出其设计定位——它专注高性能转发、路由和协议处理，而非应用层语义缓存或请求协调。但可通过组合配置与外部协作，在常见场景中**模拟或逼近请求合并效果**，核心思路是：利用缓存机制规避重复后端调用，配合合理缓存策略实现逻辑等效的“去重”。
用 proxy_cache 实现高频相同请求的自动去重
当多个客户端几乎同时发起完全相同的请求（如 /api/status），Nginx 可将首个请求透传后端，缓存响应；后续请求在缓存有效期内直接返回缓存内容，不再打到后端——这在效果上等同于“请求去重”。
- 启用缓存区：在
http块中定义共享内存缓存区
- 在
location中启用缓存并设置键（确保相同参数生成相同 key）
proxy_pass http://backend;
proxy_cache api_cache;
proxy_cache_valid 200 302 1s;
proxy_cache_lock on;
proxy_cache_lock_timeout 3s;
proxy_cache_key "$scheme$request_method$host$request_uri";
}
关键点：proxy_cache_lock on 是实现“合并”的关键——它让 Nginx 对同一缓存 key 的并发请求中，只放行第一个去后端，其余等待；待首个响应返回并写入缓存后，所有等待请求统一从缓存读取。这避免了“缓存击穿+雪崩”，也达成事实上的请求合并。
通过 upstream + keepalive 减少连接开销，间接提升合并感知
虽然不合并请求体，但复用 TCP 连接可显著降低高并发下重复请求的延迟和资源消耗，使“看似合并”的体验更平滑。
- 定义带长连接的 upstream
server 127.0.0.1:8000;
keepalive 32;
keepalive_timeout 60s;
keepalive_requests 1000;
}
- 在 location 中启用连接复用
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection '';
}
真正需要请求合并时，应交由上游服务或专用中间件
若业务要求严格合并（例如把 10 个 /user?id=123 合成一个批量接口 /users?id=123,456,789），Nginx 无法完成此逻辑转换。此时推荐：
- 前端聚合：JS 层做防抖+批量化请求（如 100ms 内的多个用户查询合并为一次
GET /users?ids=123,456,789） - 网关层处理：使用 Kong、Apache APISIX 或自研网关，在七层解析参数并执行合并逻辑
- 后端服务适配：提供原生批量接口，并让 Nginx 直接代理该接口，前端按需调用
注意：别误用 proxy_buffering 或 gzip 去“合并”
proxy_buffering 控制响应体是否缓存在 Nginx 内存/磁盘中再返回，仅影响传输效率，不改变请求次数；gzip 是压缩响应体，与请求去重完全无关。二者不能解决本问题。
