rewrite无法重写WebSocket路径，因其仅作用于HTTP请求阶段，而WebSocket升级发生在请求头解析后、连接建立前；正确做法是用location匹配路径并配置proxy_pass及Upgrade头透传。
直接用 rewrite 重写 WebSocket 路径是行不通的——因为 rewrite 只作用于 HTTP 请求阶段，而 WebSocket 协议升级（Upgrade）发生在请求头解析之后、连接建立之前，此时 rewrite 已完成执行，无法干预后续的长连接行为。
为什么 rewrite 不适用于 WebSocket 路径重写
WebSocket 连接依赖 Upgrade: websocket 和 Connection: upgrade 头部触发协议切换。Nginx 的 rewrite 指令只修改 URI 字符串，不改变请求方法、头部或协议状态，因此：
- rewrite 后的 URI 若未被 location 正确捕获，请求会走默认处理逻辑（如 404 或 proxy_pass 到错误后端）
- 即使 URI 被重写成功，若对应 location 缺少 WebSocket 必需的 header 设置和 upgrade 配置，连接仍会失败
- rewrite + break 或 last 均无法让 Nginx “重新识别”该请求为 WebSocket 升级请求
正确做法：用 location 匹配 + proxy_pass + 升级配置
真正起作用的是 location 的正则匹配能力，配合专用的 WebSocket 代理参数。关键不在重写路径，而在精准路由和协议透传：
- 用
location ~ ^/ws/或location /ws/捕获 WebSocket 请求路径 - 必须设置
proxy_http_version 1.1和proxy_set_header Upgrade $http_upgrade - 通过
map指令动态设置Connection头（upgrade或close） -
proxy_pass直接指向后端 WebSocket 服务地址，不加 rewrite
典型可运行配置示例
以下配置将 /ws/chat、/ws/notify 等所有以 /ws/ 开头的请求，透明转发给后端 http://127.0.0.1:8080，并完成协议升级：
（放在 http {} 块中）
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}（放在 server {} 块中）
location /ws/ {
proxy_pass http://127.0.0.1:8080/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_read_timeout 86400; # 防止空闲断连
}注意：proxy_pass 末尾的 / 表示自动剥离 /ws/ 前缀——这相当于“路径重写”的实际效果，但它是 proxy_pass 内置行为，不是 rewrite 指令。
如果真需要改写路径（极少数场景）
例如前端固定请求 /websocket-api/xxx，而后端只认 /ws/xxx，这时可在 location 内用 rewrite + break 实现前置转换：
location /websocket-api/ {
rewrite ^/websocket-api/(.*)$ /ws/$1 break;
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
}重点：rewrite 必须带 break，避免后续 location 匹配干扰；且 proxy_pass 后不能加路径，否则 rewrite 结果会被忽略。
