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结构（如以{或[起始） - 不推荐全量解析——性能损耗大，且仍无法替代后端校验
