Nginx不解析JSON，仅透明转发；应禁用proxy_buffering和proxy_request_buffering，标准化Content-Type为application/json; charset=utf-8，并可选Lua做轻量JSON结构预检。

当Nginx作为反向代理层处理JSON请求时，若客户端发送的JSON格式不规范（如末尾多逗号、缺少引号、换行符异常等），后端服务可能直接返回400错误。Nginx本身不解析JSON，无法主动修正，但可通过合理配置规避部分常见容错问题，确保请求能被后端接收并由业务逻辑处理。

严格校验交给后端，Nginx只做透明转发

Nginx默认对请求体不做语法检查，只要Content-Type为application/json且请求体可完整读取，就会原样转发。这意味着：

• JSON语法错误（如{"name": "Alice",}）不会被Nginx拦截，会透传给上游
• 超大JSON或特殊编码（如UTF-8 BOM、控制字符）也不会被Nginx拒绝，除非触发client_max_body_size或client_body_timeout限制
• 关键是要避免Nginx自身因配置不当“提前截断”或“静默改写”请求体

关闭可能干扰JSON体的代理指令

以下Nginx指令在处理JSON请求时易引发意外行为，建议显式禁用：

• 禁用proxy_buffering on：启用缓冲可能导致JSON流式请求（如SSE、长连接推送）被截断或延迟；设为off确保实时透传
• 禁用proxy_request_buffering on（Nginx ≥1.7.11）：该功能会缓存整个请求体再转发，对大JSON或分块传输不友好；设为off可支持chunked编码直通
• 避免proxy_set_header Content-Length ""：清空Length头会导致某些后端（如Java Spring）无法正确读取body，应保留原始头

统一Content-Type与字符集声明

部分客户端发送Content-Type: application/json但未带charset，而另一些发application/json; charset=utf-8。后端若严格校验，可能拒收前者。可在Nginx中标准化：

• 用proxy_set_header Content-Type "application/json; charset=utf-8";强制覆盖
• 搭配charset utf-8;确保响应头也一致，减少前端解析歧义
• 注意：仅当确认后端接受该声明时使用，避免覆盖客户端明确指定的其他charset（如gbk）

配合后端做轻量预检（可选）

若需在Nginx层做极简JSON有效性判断（如防止明显非法体导致后端崩溃），可用ngx_http_lua_module实现基础检测：

• 检查Content-Type是否匹配application/json（含可选charset）
• 用Lua尝试cjson.safe_decode前N个KB，仅验证开头是否符合JSON结构（如以{或[起始）
• 不推荐全量解析——性能损耗大，且仍无法替代后端校验