ProxyPassReverse 不处理编码问题，仅改写响应头中的 Location、Content-Location 和 URI 字段；多语言站点编码错乱主因是后端未正确声明字符集（如缺失 Content-Type: text/html; charset=utf-8 或 meta charset），或 Apache 的 AddDefaultCharset 冲突，需关闭 AddDefaultCharset 并交由后端显式控制。
ProxyPassReverse 本身不处理编码问题，它只改写响应头中的 Location、Content-Location 和 URI 相关字段。多语言站点出现编码错乱，根源通常在字符集声明缺失或冲突，而非 ProxyPassReverse 配置错误。
确保后端应用正确声明字符集
这是最关键的一步。Apache 不会自动添加或修正 Content-Type 中的 charset，必须由后端服务明确返回：
- 响应头中必须包含类似 Content-Type: text/html; charset=utf-8（注意分号和空格）
- HTML 页面内应有对应 meta 标签：<meta charset="UTF-8">
- 如果后端是 PHP，检查是否执行了 header('Content-Type: text/html; charset=utf-8');
- Node.js/Python 等服务也需显式设置响应头，不能依赖默认值
避免 Apache 自动添加错误的 charset
Apache 的 AddDefaultCharset 指令可能覆盖后端设置，导致冲突：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 检查主配置或虚拟主机中是否启用了 AddDefaultCharset On 或 AddDefaultCharset UTF-8
- 建议改为 AddDefaultCharset Off，把字符集控制权完全交给后端
- 如需全局兜底，可限定作用范围，例如仅对 .html 文件启用：AddDefaultCharset UTF-8 .html
ProxyPassReverse 不影响编码，但要注意重写路径是否破坏资源链接
若代理路径嵌套过深（如 ProxyPass /zh/ http://backend/zh/），而页面中硬编码了相对路径或 base 标签，可能导致 CSS/JS/字体等资源加载失败，间接引发渲染异常（误判为编码问题）：
- 确认后端返回的 HTML 中 <base href="/"> 值与代理前缀一致，或设为绝对路径
- 用浏览器开发者工具检查 Network 面板，看字体文件（.woff2）、翻译 JSON 等是否 404 或返回乱码内容
- 必要时配合 ProxyPassReverseCookieDomain 和 ProxyPassReverseCookiePath 修复 Cookie 路径，避免登录态丢失影响语言切换
验证与调试建议
直接查看原始响应头和内容，绕过浏览器渲染干扰：
- 用 curl 检查真实响应：curl -I https://yoursite.com/zh/（看 Content-Type）
- 用 curl 获取正文并 hexdump 查看字节：curl -s https://yoursite.com/zh/ | head -c 200 | hexdump -C，确认 UTF-8 BOM 或中文字符字节是否正确（如“你好”应为 e4 bd a0 e5-a5 bd）
- 对比直连后端和经 Apache 代理后的响应头差异，确认没有中间模块（如 mod_charset_lite）介入转码
