Nginx反向代理时应通过proxy_set_header统一设置字符集：显式声明Content-Type charset=utf-8、条件透传Accept-Charset、添加X-Request-Charset自定义头，并禁用URI自动转义以避免中文乱码。
在 Nginx 作为反向代理时，后端服务（如 PHP、Python 或 Java 应用）有时会因请求头缺失或不一致，导致中文参数乱码、文件名解析异常等问题。虽然编码问题根源常在于应用层，但通过 proxy_set_header 合理设置请求头，可为后端提供统一、明确的编码上下文，减少歧义。
明确传递 Content-Type 字符集
当客户端以 application/x-www-form-urlencoded 或 multipart/form-data 提交含中文的数据时，若请求头未声明字符集，部分后端（尤其是 Java Servlet 容器）默认按 ISO-8859-1 解析，造成乱码。Nginx 本身不解析请求体，但可通过添加标准头影响后端行为：
- 对表单类请求，建议在 location 块中显式设置：
proxy_set_header Content-Type "application/x-www-form-urlencoded; charset=utf-8"; - 注意：该设置仅适用于已知固定类型的请求；若需动态适配，应结合
map指令根据原始$content_type进行条件覆盖，避免强行覆盖 JSON 等类型。
透传并标准化 Accept-Charset（供后端参考）
Accept-Charset 是客户端声明“我能接受的字符集”的请求头，虽现代浏览器基本不再发送，但在内部系统或特定客户端场景下仍有意义。Nginx 可统一补全或重写，确保后端收到一致信号：
- 强制告知后端客户端支持 UTF-8：
proxy_set_header Accept-Charset "utf-8"; - 更稳妥的做法是继承原始值（若存在），否则设默认值：
proxy_set_header Accept-Charset "$http_accept_charset";proxy_set_header Accept-Charset "utf-8"; # fallback
补充 X-Request-Charset 自定义头（应用层友好）
标准 HTTP 头对编码缺乏强约定，许多框架不主动读取 Content-Type 中的 charset 参数。引入自定义头可让后端无歧义地获知代理层的编码意图：
- 在 proxy 配置中添加：
proxy_set_header X-Request-Charset "UTF-8"; - 后端代码（如 PHP 的
$_SERVER['HTTP_X_REQUEST_CHARSET']，或 Spring Boot 的request.getHeader("X-Request-Charset")）可据此统一设置 request character encoding，比依赖容器默认更可靠。 - 该方式不干扰标准协议，也便于灰度控制或日志追踪。
配套建议：禁用 Nginx 自动转义与保持原始 URI
编码问题常伴随 URI 中中文路径或查询参数被双重编码。需确认以下配置避免干扰：
- 关闭不必要的 URI 重写：
proxy_http_version 1.1;proxy_redirect off;proxy_pass_request_headers on; - 确保不启用
underscores_in_headers on以外的非标准解析（除非后端明确要求）；X-Request-Charset类下划线命名无需额外开启。 - 若使用
rewrite，务必加break或last并避免对含中文的 $args 做未经 decode 的拼接。
