Nginx原生不支持小请求合并，需通过第三方模块ngx_http_concat_module实现，核心目标是减少HTTP请求数、降低TCP与TLS开销，适用于JS/CSS等静态资源批量加载。
小请求合并转发不是 Nginx 原生支持的功能，必须通过第三方模块 ngx_http_concat_module 实现，核心目标是减少 HTTP 请求数量、降低 TCP 握手与 TLS 开销，特别适合静态资源（如 JS、CSS）的批量加载场景。
启用 concat 模块的前提条件
该模块不内置在标准 Nginx 中，需重新编译安装：
- 下载对应 Nginx 版本的源码，并获取官方维护或社区验证的 concat 模块（如
nginx-http-concat） - 编译时添加
--add-module=/path/to/ngx_http_concat_module - 确认编译后运行
nginx -V 2>&1 | grep concat能看到模块名
基础 concat 配置示例
在 location 块中启用合并逻辑，通常用于静态资源目录：
- 设置
concat on;启用模块 - 用
concat_max_files 10;限制单次最多合并文件数（防滥用） - 指定分隔符，如
concat_types application/javascript text/css; - 客户端通过 URL 参数触发合并，例如：
/static/??a.js,b.js,c.js → 合并返回三份 JS 内容，以两个问号开头、逗号分隔
配合反向代理使用的注意事项
concat 处理发生在 Nginx 接收请求阶段，若后端才是静态资源提供方，需确保：
- proxy_pass 目标地址能正确响应合并后的路径（比如后端也支持类似逻辑，或 concat 在 Nginx 层直接读取本地文件）
- 更常见做法是：Nginx 自身托管静态资源，concat 在本地完成，再由 proxy_pass 转发其他动态请求 —— 不建议让 concat 和 proxy_pass 在同一 location 混用
- 若必须代理到支持 concat 的上游服务（如某些 CDN 或自研静态服务），需确保 upstream 返回内容类型、ETag、缓存头等仍有效
替代方案：用 Nginx 缓存 + 合并逻辑前置
对于无法编译模块的环境，可考虑间接优化小请求压力：
- 用
proxy_cache缓存高频小资源，降低回源次数 - 前端构建阶段做资源打包（如 Webpack 的 code splitting + preload），比运行时合并更可控
- 利用
HTTP/2 Server Push（需 SSL + HTTP/2 开启），由服务端主动推送关联资源，效果接近合并但无需改 URL
