websocket代理不依赖proxypassreverse，因其基于http升级协议（upgrade: websocket），不涉及重定向响应头；关键在于透传upgrade/connection头、启用mod_proxy_wstunnel、使用ws://前缀及合理超时配置。
websocket 代理本身不依赖 proxypassreverse 修复路径，因为它走的是 http 升级协议（upgrade: websocket），不涉及重定向响应头（如 location）。所以你不需要、也不应该为 websocket 路径配置 proxypassreverse。
为什么 ProxyPassReverse 对 WebSocket 无效
ProxyPassReverse 只处理后端返回的 301/302 等重定向响应中的 Location、Content-Location 和 URI 响应头。而 WebSocket 连接建立过程是：
- 客户端发一个带
Upgrade: websocket的 HTTP 请求 - 后端成功响应
101 Switching Protocols，不带任何重定向头 - 连接直接升级为二进制帧通信，不再走 HTTP 响应头替换逻辑
WebSocket 代理真正要配的关键项
重点不是路径修正，而是确保升级请求完整透传、连接不被中断：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
必须启用
mod_proxy_wstunnel：这是 Apache 支持 WebSocket 代理的专用模块，仅靠mod_proxy_http不行 -
使用
ws://或wss://协议前缀：例如ProxyPass /ws/ ws://127.0.0.1:8080/（不能写http://） -
透传 Upgrade 和 Connection 头：
Header always set Connection "upgrade"Header always set Upgrade "websocket" -
关闭代理层连接复用干扰：
ProxySet keepalive=offProxySet timeout=300
路径映射仍靠 ProxyPass，但无需 Reverse
比如你想把 wss://example.com/chat/ 代理到后端 ws://localhost:9001/：
- 写
ProxyPass /chat/ ws://localhost:9001/✅（路径前缀一致，尾部斜杠匹配） - 不写
ProxyPassReverse /chat/ ws://localhost:9001/❌（语法虽不报错，但完全无作用） - 如果后端实际监听在
/chat/子路径，就写成ws://localhost:9001/chat/，让路径自然对齐
常见路径错位问题其实是前端或后端配置偏差
所谓“路径偏移”，通常不是代理导致，而是：
- 前端 JS 连接时写了
new WebSocket("wss://example.com/ws")，但代理规则是/api/ws/→ 应统一路径前缀 - 后端框架（如 Spring Boot）自动拼接了上下文路径，需设
server.servlet.context-path=为空 - 反向代理未透传
Host头，导致后端生成错误的回调地址 → 加ProxyPreserveHost On
