apache mod_proxy代理中文参数乱码的核心在于url解码不一致：默认按iso-8859-1解码utf-8中文导致乱码，需在proxypass中加nocanon禁用自动解码，并确保前后端统一utf-8编码。

apache mod_proxy 代理中文参数乱码，核心问题不在 mod_proxy 本身，而在于请求路径和查询参数在转发过程中被错误解码或编码。默认情况下，apache 对 url 路径按 iso-8859-1 解码，但现代应用（尤其 utf-8 编码的前端、后端）发送的中文参数实际是 utf-8 字节序列。若未显式干预，apache 会把 utf-8 的多字节当作单字节 iso-8859-1 解，结果就是乱码（如“测试”变成“测试”）。

确保后端接收的是原始字节，不提前解码

Apache 默认会对 ProxyPass 转发前的请求路径做一次 URL 解码（使用 ISO-8859-1），这会导致中文参数损坏。解决方法是禁用该自动解码：

• 在 ProxyPass 指令中添加 nocanon 标志： ProxyPass /api/ http://backend:8080/api/ nocanon
• nocanon 表示 Apache 不对路径执行规范化（包括解码），直接将原始字节转发给后端
• 后端服务（如 Spring Boot、Node.js、Python Flask）需自行按 UTF-8 正确解码原始路径和 query 参数

统一 URI 编码规范：前端发 UTF-8，后端收 UTF-8

前后端必须协同遵守 UTF-8 编码约定：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• 前端 JS 发送请求时，确保 encodeURI 或 encodeURIComponent 处理中文参数（它们默认按 UTF-8 编码）
• 避免手动用 GBK 等编码再转义——这会让 Apache 和后端更难处理
• 后端框架要明确设置请求解析编码为 UTF-8 例如 Spring Boot 中加：server.tomcat.uri-encoding=UTF-8；Flask 中确保 request.args 自动用 UTF-8 解码

检查并修正 Apache 的字符集响应头干扰

虽然乱码发生在请求侧，但响应头配置不当会掩盖问题或引发二次混乱：

• 确认没有全局 AddDefaultCharset GB2312 或类似指令，它可能影响某些 CGI/脚本响应头
• 推荐在虚拟主机或目录级配置：AddDefaultCharset UTF-8，保证 HTML 响应头带 charset=urf-8，避免浏览器误判
• 注意：该设置不影响请求解码逻辑，但能防止响应阶段因 meta 与 header 不一致导致的显示乱码，便于排查

验证与调试关键点

快速定位是否为编码链路断裂：

• 用 curl 直接访问后端（绕过 Apache），确认中文参数能正常处理 → 若 OK，说明问题在代理层
• 开启 Apache 错误日志：LogLevel debug proxy:trace4，查看 mod_proxy 日志中转发前后的原始 Request-URI
• 在后端打印原始 query string 的字节（如 Python 中 request.query_string 的 bytes 值），确认收到的是 UTF-8 字节还是已损坏的乱码字节