nginx原生不支持请求体动态加密，因其无内置加密模块和body处理钩子；可行方案包括openresty+lua实现或下沉至客户端、api网关、服务网格层处理。
不能直接用 Nginx 对请求体做动态加密传输——Nginx 本身不支持在代理过程中对 request body 进行加解密操作，它没有内置的加密模块，也不提供可编程的 body 处理钩子（如读取、修改、重写原始请求体后再转发）。
为什么 Nginx 原生无法实现请求体动态加密
Nginx 的设计目标是高性能反向代理和负载均衡，其 HTTP 处理流程中：
- 请求体默认被缓冲或流式传递，但仅用于透传或简单校验（如 limit_req、client_body_timeout）
- 所有 rewrite、set、map 等指令仅作用于 header、URI、变量，无法访问或修改原始 request body 内容
- 第三方模块如 ngx_http_lua_module（OpenResty）可读取 body，但需显式启用 lua_need_request_body on，且加密逻辑需完全由 Lua 实现，属于“扩展能力”，非 Nginx 标准功能
可行的技术路径：OpenResty + Lua 实现动态加密
若坚持使用 Nginx 生态，推荐基于 OpenResty（增强版 Nginx + Lua），在 access_by_lua* 或 body_filter_by_lua* 阶段介入：
- 在 access_by_lua_block 中调用 lua-resty-http 或原生 socket，将原始 body 加密后暂存为自定义变量
- 用 rewrite_by_lua_block 修改 $request_body（需配合 lua_need_request_body on 和 client_body_buffer_size 调整）
- 通过 proxy_pass_request_body off 关闭默认 body 透传，改用 content_by_lua_block 构造加密后的 POST 请求（用 resty-http 手动发包）
- 密钥建议从请求头（如 X-Encrypt-Key）、JWT payload 或上游服务动态获取，避免硬编码
更合理、更可控的替代方案
把加密逻辑下沉到客户端或上游应用层，Nginx 仅负责透明代理：
- 前端/SDK 层加密：客户端在发送前用 AES-GCM 或 SM4 加密 body，并附加 iv、算法标识、签名等元数据到 header，后端服务解密 —— 安全性高、Nginx 零改造
- API 网关层处理：用 Kong（支持插件）、Apigee 或自研网关，在入口处统一加解密，Nginx 退为最外层负载均衡器
- 服务网格（如 Istio）：通过 Envoy Filter 编写 WASM 模块，在 sidecar 层拦截并加密 HTTP body，适合云原生架构
注意事项与风险提示
即使采用 OpenResty 方案，也需警惕：
- 开启 lua_need_request_body on 会强制缓存整个 body 到内存或临时文件，大文件上传易导致 OOM 或磁盘耗尽
- 加密操作增加 CPU 开销，可能成为性能瓶颈，需压测验证吞吐量下降幅度
- 无法兼容 chunked transfer-encoding 流式请求，必须要求客户端发送 Content-Length
- 加密后丢失原始 body 的可读性，调试困难；建议配套记录加密前日志（脱敏后）供审计
不复杂但容易忽略：加密不是目的，端到端机密性与完整性才是。优先保障 TLS 1.2+ 传输安全，再考虑应用层加密是否真有必要。
