Nginx 默认透明透传任意深度嵌套JSON，关键在于不覆盖Content-Type、不限制body大小、不启用sub_filter等破坏性配置，并合理调优超时与缓冲参数。
在 Nginx 中使用 proxy_pass 转发请求时，JSON 数据本身并不需要特殊处理即可透传——Nginx 默认不会解析、修改或重写请求体（request body）或响应体（response body），包括嵌套很深的 JSON。所谓“复杂嵌套 JSON 的透传”，关键不在 Nginx 做什么，而在于它 不做什么，以及你是否无意中引入了破坏透传的行为。
确保 Content-Type 和编码正确
Nginx 不修改请求/响应体，但客户端和后端服务依赖 Content-Type 头来解析 JSON。若该头被意外覆盖或丢失，接收方可能无法识别为 JSON。
- 确认上游服务返回的响应头中包含
Content-Type: application/json; charset=utf-8 - 避免在 Nginx 配置中用
add_header Content-Type ...覆盖原有值（尤其注意add_header不继承，且对 204/304 等响应无效） - 如需统一设置，推荐用
proxy_hide_header Content-Type+proxy_set_header Content-Type $sent_http_content_type保持原样透传（较少需要，通常默认已透传）
禁用可能导致 JSON 截断或损坏的配置
以下配置看似无关，实则可能破坏 JSON 透传：
-
proxy_buffering on;（默认开启）：一般安全，但若 JSON 很大（>1MB）且缓冲区不足，可能触发临时文件写入或截断 —— 可设proxy_buffer_size 128k和proxy_buffers 8 128k缓冲大响应 -
proxy_max_temp_file_size 0;：禁用临时文件，避免磁盘 I/O 导致超时或中断大 JSON 响应 -
proxy_read_timeout和proxy_send_timeout：对长耗时 JSON 接口（如导出、聚合计算），需调大（如 300s），否则连接被 Nginx 主动关闭，JSON 不完整 - 避免使用
sub_filter或第三方模块（如nginx-http-json-filter）——它们会解析并重写响应体，必然破坏嵌套结构
验证请求体是否真正透传（尤其 POST/PUT）
前端发送的嵌套 JSON 是否原样到达后端，取决于客户端请求头和 Nginx 对 body 的处理：
- 确保客户端设置了
Content-Type: application/json - Nginx 默认透传 request body，但若启用了
proxy_buffering on且 body 过大，可能触发流式转发异常；可加proxy_buffering off;强制流式（慎用，影响性能） - 检查是否有
client_max_body_size限制（默认 1MB）——嵌套深的大 JSON 容易超限，返回 413；建议设为client_max_body_size 20m; - 如需调试，可用
log_format记录$request_body（仅调试环境！生产禁用，有安全与性能风险）
不要尝试在 Nginx 层解析或改写 JSON
Nginx 是反向代理，不是 API 网关。它没有内置 JSON 解析能力，任何“修改某个字段”“扁平化嵌套”需求都不该在 Nginx 实现：
- 不要找 Lua 模块（如
lua-resty-json）去 decode/encode —— 易出错、难维护、性能差 - 不要用
map或正则匹配 JSON 字段 —— JSON 格式自由（空格、换行、键序不定），正则不可靠 - 真正需要 JSON 转换，请交给上游服务、专用网关（Kong、APISIX）或业务层处理
只要不主动干预、不限制大小、不覆盖关键 header，Nginx 的 proxy_pass 对任意深度嵌套的 JSON 都是透明的。问题往往出在周边配置，而非转发本身。
