ProxyPass 默认解码后匹配，易破坏原始编码语义；应改用 RewriteRule+[P,B,NE] 组合透传未解码路径，如 /search/a%2Fb 原样转发至后端。
ProxyPass 本身不负责解码或编码 URL 中的特殊字符，它按 Apache 接收到的原始请求路径（已由核心模块初步解码）进行前缀匹配。真正影响特殊字符处理的是 编码时机 和 代理方式选择，尤其在反向代理场景下容易出错。
特殊字符在 ProxyPass 中的行为本质
Apache 在接收请求时，会将 URI 中的百分号编码（如 %20、%E4%B8%AD）自动解码为原始字节，再交给 ProxyPass 匹配。这意味着：
-
/api/name%2Fvalue会被解码成/api/name/value再匹配； - 如果后端服务实际期望接收未解码的原始编码串（比如某些 API 明确要求
name%2Fvalue而非name/value），直接用 ProxyPass 就会破坏原始语义。
反向代理中保留原始编码的正确做法
当需要透传带特殊字符（如 /、?、中文、空格等）的路径段时，不要用 ProxyPass 直接代理，而应改用 RewriteRule + [P,B,NE] 标志组合：
-
P：启用代理（等效于 ProxyPass） -
B：对 RewriteRule 的替换目标 重新编码一次（防止 Apache 多次解码） -
NE：禁止对替换结果再次编码（避免双重编码，如%2520）
示例：代理含路径分隔符 %2F 的请求
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
RewriteEngine On RewriteRule ^/search/(.*)$ http://backend:8080/search/$1 [P,B,NE]
这样 /search/a%2Fb 会原样转发为 http://backend:8080/search/a%2Fb，而不是被解成 a/b 后再拼接。
ProxyPass 自身的限制与规避建议
- ProxyPass 默认行为是「解码后匹配 + 拼接」，无法跳过解码步骤；
- 若后端部署在子路径（如
/myapp/），且路径中含特殊字符，务必确保 ProxyPass 前缀和后端地址末尾斜杠严格一致，否则拼接逻辑会进一步扭曲编码； - 对于 WebSocket 或需精确控制请求头的场景（如含
Upgrade: websocket的请求），ProxyPass 不够灵活，必须搭配 RewriteCond + RewriteRule 才能可靠透传原始 URI。
实际调试技巧
用 curl -v 观察真实请求路径和响应头：
curl -v 'https://example.com/api/v1/user%2F123'
检查 Apache access log 是否记录为 user%2F123 还是 user/123，以此判断编码是否被提前破坏；再对比后端收到的路径，确认是否一致。
不复杂但容易忽略
