必须设置x-forwarded-proto $scheme头以透传原始协议（wss→https、ws→http），配合host $host和精准路径匹配，确保后端正确处理cors、重定向及url构造；wss场景下nginx应终止ssl并proxy_pass至http://后端。
要让 Nginx 代理 WebSocket 时透传原始请求协议（比如客户端用的是 wss:// 还是 ws://），关键不是“猜测”或“转换”，而是把协议信息以标准 HTTP 头的形式明确传递给后端服务，让后端能据此生成正确响应（如重定向、CORS 判断、URL 构造等）。
必须设置 X-Forwarded-Proto 头
这是最直接、最通用的方式。Nginx 不会自动把 wss 或 ws 协议映射成某个变量，但它提供了 $scheme 变量——它代表当前 Nginx 接收到的请求所用的协议（http 或 https）。WebSocket 客户端的 wss:// 一定对应 Nginx 的 https 请求，ws:// 对应 http 请求。
-
proxy_set_header X-Forwarded-Proto $scheme;—— 这行必须加在 WebSocket 的location块内 - 后端服务（如 Node.js、Python、Java）需主动读取该头，而不是只看自己的监听协议
- 例如：前端访问
wss://api.example.com/ws，Nginx 收到的是 HTTPS 请求，$scheme就是https，后端收到X-Forwarded-Proto: https后，就知道该走安全通道
确保 Host 和路径一致性
WebSocket 握手依赖完整的原始请求上下文。除了协议，域名和路径也影响后端行为（尤其是跨域校验、路由匹配、Origin 验证）：
-
proxy_set_header Host $host;—— 透传原始 Host，避免后端因 Host 不匹配拒绝连接 - 路径要严格对应：如果前端连的是
/ws，Nginx 的location /ws就得精准匹配，且proxy_pass目标地址末尾不带斜杠（如http://127.0.0.1:9501，不是http://127.0.0.1:9501/） - 若后端做 Origin 校验，它通常会检查
Origin请求头（浏览器自动携带），而该头值由前端 URL 决定（如https://example.com），Nginx 不修改它，所以无需额外配置
HTTPS 场景下注意 SSL 终止位置
WSS 要求 TLS 在某一层终止。常见做法是 Nginx 终止 SSL，再以普通 HTTP 与后端通信。这时：
- Nginx 必须已正确加载证书，并监听
443端口 -
proxy_pass目标应为http://（不是https://），否则多加一层 TLS 反而增加复杂度和失败风险 - 后端不需要也不应该自己处理 TLS；它只需信任 Nginx 传来的
X-Forwarded-Proto和X-Forwarded-For
避免混淆：Connection 和 Upgrade 头不负责协议透传
有人误以为 Connection: upgrade 或 Upgrade: websocket 能表示原始协议，其实不是：
- 这两个头只用于 HTTP → WebSocket 的协议升级协商，跟
ws/wss无关 - 它们的作用是告诉后端“请切换成 WebSocket 模式”，不是告诉后端“用户是从 HTTPS 来的”
- 真正承载原始协议语义的，只有
X-Forwarded-Proto
