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 字节还是已损坏的乱码字节
