Nginx 日志中出现 \xXX 十六进制序列是默认转义行为，非乱码；应配置 log_format 中 $request_body 后加 escape=json，并确保 Nginx ≥ 1.11.8、请求体未落盘且 HTTPS 配置正确。
直接看日志里有没有 \xXX 这类十六进制序列，比如 \xE7\xA7\x80\xE6\x98\x82 或 \x22，有就说明发生了默认转义，不是乱码，是 Nginx 主动“加密”了。
确认是否为 Nginx 默认转义行为
这种编码不是日志损坏或系统编码错误，而是 Nginx 为保障日志格式安全，对非 ASCII 字符（中文、引号、换行符、反斜杠等）做的自动十六进制转义。典型表现包括：
- 中文显示为
\xE7\x94\xA8\xE6\x88\xB7等字节序列 - JSON 请求体中的双引号变成
\x22，空格变成\x20 -
$request_body字段内容无法被 jq / Logstash 直接解析为合法 JSON
检查 escape=json 是否已正确启用
这是最常用也最有效的修复方式，但配置容易出错。关键点有：
-
escape=json必须写在log_format中具体变量的后面，例如："$request_body" escape=json，不能加在整行末尾或写成"$request" escape=json;这种语法错误形式 -
$request_body要有值：需确保配置了client_max_body_size和client_body_buffer_size，且未设置client_body_in_file_only on - Nginx 版本必须 ≥ 1.11.8，可用
nginx -v验证
排除 SSL 或配置干扰因素
少数情况下，十六进制编码可能与 HTTPS 配置异常有关，尤其是日志中混入了 TLS 握手原始字节：
- 检查
server块是否正确定义了ssl参数，如listen 443 ssl - 确认证书路径、密钥权限和格式正确，
ssl_certificate和ssl_certificate_key指向有效文件 - 如果只在 HTTPS 接口日志中出现异常而 HTTP 正常，需重点核对
ssl_protocols和ssl_ciphers是否引发协议协商异常
验证与替代方案
若 escape=json 不生效，可快速验证并切换策略：
- 用
$request_uri替代$request或$args：它保留原始 URL 编码（如%E7%94%A8%E6%88%B7），结构稳定，适合字段切分 - 在采集层解码：Filebeat 中加
decode_json_fields，Logstash 中用urldecode或json过滤器——仅作临时过渡 - 避免使用 Lua 解码：需编译安装
lua-nginx-module，运维成本高，不推荐线上常规使用
