不建议在 Nginx 层实现 HTTPS 接口的自定义动态加密，因其缺乏原生加解密能力，强行实施会导致协议破坏、性能骤降、工具兼容性丧失；应由后端对敏感字段 AES-256-GCM 加密，Nginx 仅负责 TLS 终止与透传。
不建议也不可行在 Nginx 层实现 HTTPS 接口的自定义动态加密（即所谓“二次加密”或“双重加密”）。
Nginx 本质是传输层/应用层代理，不是业务逻辑处理器。它无法安全、可靠、高效地承担应用级加解密任务，强行实施会带来严重风险与运维负担。
Nginx 做动态加密的核心障碍
- TLS 终止后，Nginx 虽可见明文 HTTP，但缺乏原生加解密能力：没有 AES/RSA 运行时支持，不支持 IV 随机生成、密钥派生、PKCS#7 填充等关键操作
- 即使借助 OpenResty + Lua 模块（如
lua-resty-nettle），也仅适合头部校验或轻量转换；对完整请求体/响应体做 AES-GCM 动态加解密，会导致：- Content-Length 与实际 payload 不一致，触发客户端解析失败
- 破坏 chunked transfer 编码，造成流式响应中断
- 禁用 proxy_buffering、gzip、缓存等优化项，性能下降 3–10 倍（实测常见）
- 客户端必须同步实现相同加解密逻辑，实质退化为私有二进制协议，丧失浏览器、curl、Postman 等标准工具兼容性
真正有效且符合工程实践的安全分层方案
传输链路加密（必须）
- 在 Nginx 启用 TLSv1.2+（推荐 TLSv1.3），使用 ECDSA 或 RSA 2048+ 证书
- 配置强密码套件，例如：
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384 - 开启 HSTS 头（
Strict-Transport-Security: max-age=31536000; includeSubDomains）强制 HTTPS
敏感字段加密（推荐）
- 由后端服务（如 Java Spring Boot、Node.js、Go）对身份证、手机号、token、银行卡号等字段单独 AES-256-GCM 加密
- 密钥通过 KMS 或 HashiCorp Vault 动态获取，IV 每次请求随机生成并 Base64 编入 JSON 字段（如
"phone": {"ciphertext":"...", "iv":"..."}） - Nginx 仅透传 JSON，不做任何内容感知——既满足等保/个保法要求，又保持协议标准性
调用方身份强化（按需）
- 启用 mTLS：在 Nginx 中配置
ssl_client_certificate和ssl_verify_client on - 客户端需携带由内部 CA 签发的证书，Nginx 可提取证书中
CN或SAN用于限流、路由或日志标记 - 此方式不加密 payload，但可杜绝未授权系统直连后端，属于零信任架构基础组件
若确属极特殊内网场景（如硬件加密网关前置、无后端改造权限）
- 仅限 OpenResty 环境，使用
body_filter_by_lua_block对响应体加密，access_by_lua_block对请求体解密 - 密钥严禁硬编码，须通过
resty.session或共享内存 + 定时轮询方式加载 - 必须关闭
proxy_buffering、gzip、chunked_transfer_encoding，并手动重写Content-Length和Content-Encoding: aes-gcm（需客户端主动识别） - 此类方案不可用于面向公网、移动端或浏览器直连场景，维护成本高，升级易断裂
不复杂但容易忽略：HTTPS 已经是端到端加密，所谓“再加一层”，往往不是增强安全，而是引入新漏洞和兼容性黑洞。把加密责任交给更可控、更灵活、更贴近业务的后端层，才是稳健选择。
